Through other two grpc message types CreateSmartContract and TriggerSmartContract to create and use smart contract.
This page covers the basics of using java-tron, which includes generating accounts, joining the TRON Nile testnet, and sending TRX between accounts. wallet-cli is also used in this document. wallet-cli is a command-line tool of the TRON network. This tool provides user interactive commands, which can be used to interact with java-tron more conveniently.
java-tron is a TRON network client written in Java. This means a computer running java-tron will become a TRON network node. TRON is a distributed network where information is shared directly between nodes rather than being managed by a central server. After the super representative's node generates a new block, it will send the block to its peers. On receiving a new block, each node checks that it is valid and adds it to their database. java-tron uses the information provided by each block to update its "state" - the balance of each account on the TRON network. There are two types of accounts on the TRON network: externally owned accounts and contract accounts. The contract account executes the contract code when a transaction is received. An external account is an account that a user manages locally in order to sign and submit transactions. Each external account is a public-private key pair, where the public key is used to derive a unique address for the user, and the private key is used to protect the account and securely sign messages. Therefore, in order to use the TRON network, it is first necessary to generate an external account (hereinafter referred to as "account"). This tutorial will guide users on how to create an account, deposit TRX tokens, and transfer TRX.
-There are various ways to generate a TRON network account, here we will demonstrate how to generate an account using wallet-cli. An account is a pair of keys (public and private keys).
Enter the command java -jar wallet-cli.jar in the terminal to start a wallet-cli:
$ java -jar wallet-cli.jar
diff --git a/search/search_index.json b/search/search_index.json
index fd301688..1de67b6c 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Welcome to the java-tron user manual!","text":"java-tron is a TRON client implemented in Java, it provides completely open source code, you can download the java-tron source code on Github. This article will introduce the knowledge related to java-tron. Through this article, you will learn how to use java-tron and how to participate in the development and maintenance of java-tron, including the following parts:
- Getting Started With java-tron
- Using java-tron
- API
- Core Protocol
- For java-tron Developers
- For Dapp Developers
- Clients
- Releases
For other TRON related information, please visit the official website tron.network or the following resource links:
- TRON Whitepaper
- TRON Improvement Proposals (TIPs)
- TRON Developer Hub
"},{"location":"glossary/","title":"Glossary","text":"energyUsage
The Energy conumption of the contract caller in one contract trigger.
energyFee
The number of TRX burned from the contract caller for Energy conumption in one contract trigger.
originEnergyUsage
The total Energy conumption of the contract developer in one contract trigger.
energyUsageTotal
The total Energy conumption of the contract developer and the contract caller combined.
Feelimit
When the user triggers or create the contract, this is used to set the usage limit of the Energy consumption got from burning TRX or staking TRX, Energy got from staking TRX will be used first.
CallValue
When the user triggers or create the contract, this can be used to send TRX to the contract.
consume_user_resource_percent
For a contract, Resource consumption is composed of two parts, one part is afforded by contract developer and the other part is afforded by contract caller. This is the percentage of the two parts in the Resource consumption.
origin_energy_limit
The usage limit of the Energy consumption of the developer in one contract trigger, should be greater than 0.
net_usage
The Bandwidth consumption in one contract trigger. (NetFee not included)
net_fee
The TRX burned for Bandwidth consumption in one contract trigger.
Bandwidth
The Bandwidth Points consumed by a transaction is the size of the byte array in this transaction. If the byte array length of a transaction is 100, then the transaction needs to consume 100 Bandwidth Points.
Energy
The creation and operation of a smart contract consume CPU resources. It takes time for smart contracts to operate in virtual machines (VMs), and the time consumed in the system is calculated in microseconds. CPU resources are consumed in energy, which means 1 Energy = 1 Microsecond (\u03bcs). If a contract takes 100 \u03bcs to execute in a VM, it needs to consume 100 Energy.
TRON Power(TP)
1 staked TRX = 1 TP, TP can be used to vote, 1 TP = 1 vote.
Super Representative(SR)
The current block producing Top 27 nodes.
"},{"location":"api/http/","title":"HTTP API","text":"This article introduces FullNode's HTTP APIs and their usage.
Note
Although TRON has avoided XSS by setting the Content-Type of HTTP APIs to application/json, there are a few APIs that don't have input validation. To better protect user data security, we recommend that you correctly encode any data from APIs before they use it in any UI, especially when the parameter visible equals true.
Here is a typical XSS protection method: Encode all data from the APIs in HTML. Use methods such as encodeURIComponent() or escape() to encode the data, which can convert special characters into their HTML entities and prevent them from being interpreted as HTML code by the browser.
Please be sure to implement XSS protection for all data from the APIs to ensure the security of user data. We understand that you may need more information about XSS protection. It is recommended that you refer to the following resources: OWASP XSS Prevention Cheat Sheet.
First, Let's explain the selection of the address format in the HTTP API: Account addresses of the TRON network have two formats: HexString format and Base58 format. The Fullnode HTTP API supports address format selection. Users can set the address format through the visible parameter. The default value is false and the address format in the parameter and return value is hex format. When visible is set to true, the address format in the parameter and return value are in Base58 format. If the parameter format does not match the visible setting, an error will be reported. Setting method:
- For HTTP GET API or the api needs no parameter: by adding
visible=true parameter to the url http://127.0.0.1:8090/wallet/listexchanges?visible=true\n
- For POST API: By adding
\"visible\": true parameter to the most out layer of the json curl -X POST http://127.0.0.1:8090/wallet/createtransaction -d\n'{\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"to_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\",\n \"amount\": 1000000,\n \"visible\": true\n}'\n
"},{"location":"api/http/#fullnode-http-api","title":"Fullnode HTTP API","text":"The FullNode HTTP API is categorized as follows:
- Accounts
- Transfer and Transactions
- Account Resources
- Query The Network
- Smart Contracts
- TRC-10 Token
- Voting & SRs
- Proposals
- DEX Exchange
- TRONZ Shielded Smart Contract
- Pending Pool
"},{"location":"api/http/#accounts","title":"Accounts","text":"The following are the APIs related to on-chain accounts:
- wallet/validateaddress
- wallet/createaccount
- wallet/getaccount
- wallet/updateaccount
- wallet/accountpermissionupdate
- wallet/getaccountbalance
- wallet/setaccountid
- wallet/getaccountbyid
"},{"location":"api/http/#walletvalidateaddress","title":"wallet/validateaddress","text":"Description: Check the validity of the address
curl -X POST http://127.0.0.1:8090/wallet/validateaddress -d '{\"address\": \"4189139CB1387AF85E3D24E212A008AC974967E561\"}'\n
Parameters: address Return: the address is correct or not
"},{"location":"api/http/#walletcreateaccount","title":"wallet/createaccount","text":"Description: Create an account. Uses an already activated account to create a new account. If the owner_address has enough bandwidth obtained by freezing TRX, then creating an account will only consume bandwidth , otherwise, 0.1 TRX will be burned to pay for bandwidth, and at the same time, 1 TRX will be required to be created.
curl -X POST http://127.0.0.1:8090/wallet/createaccount -d '{\"owner_address\":\"41d1e7a6bc354106cb410e65ff8b181c600ff14292\", \"account_address\": \"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\"}'\n
Parameters: owner_address Owner address, default hexStringaccount_address New address, default hexStringPermission_id Optional, for multi-signature use
Return: Unsigned transaction object
"},{"location":"api/http/#walletgetaccount","title":"wallet/getaccount","text":"Description: Query an account information
curl -X POST http://127.0.0.1:8090/wallet/getaccount -d '{\"address\": \"41E552F6487585C2B58BC2C9BB4492BC1F17132CD0\"}'\n
Parameters: address - account address Return: Account object
"},{"location":"api/http/#walletupdateaccount","title":"wallet/updateaccount","text":"Description: Update the name of an account
curl -X POST http://127.0.0.1:8090/wallet/updateaccount -d '{\"account_name\": \"0x7570646174654e616d6531353330383933343635353139\" ,\"owner_address\":\"41d1e7a6bc354106cb410e65ff8b181c600ff14292\"}'\n
Parameters: account_name Account name, default hexStringowner_address Owner address, default hexStringPermission_id Optional, for multi-signature use
Return:\u200b\u672a\u200b\u7b7e\u540d\u200b\u7684\u200b\u4fee\u6539\u200b\u540d\u79f0\u200bTransaction
"},{"location":"api/http/#walletaccountpermissionupdate","title":"wallet/accountpermissionupdate","text":"Description: Update the account's permission.
curl -X POST http://127.0.0.1:8090/wallet/accountpermissionupdate -d\n'{\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"owner\": {\n \"type\": 0,\n \"permission_name\": \"owner\",\n \"threshold\": 1,\n \"keys\": [{\n \"address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"weight\": 1\n }]\n },\n \"witness\": {\n \"type\": 1,\n \"permission_name\": \"witness\",\n \"threshold\": 1,\n \"keys\": [{\n \"address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"weight\": 1\n }]\n },\n \"actives\": [{\n \"type\": 2,\n \"permission_name\": \"active12323\",\n \"threshold\": 2,\n \"operations\": \"7fff1fc0033e0000000000000000000000000000000000000000000000000000\",\n \"keys\": [{\n \"address\": \"TNhXo1GbRNCuorvYu5JFWN3m2NYr9QQpVR\",\n \"weight\": 1\n }, {\n \"address\": \"TKwhcDup8L2PH5r6hxp5CQvQzZqJLmKvZP\",\n \"weight\": 1\n }]\n }],\n \"visible\": true}'\n
Parameters: - owner_address: Owner address of the account, default hexString
- owner: Account owner permission
- witness: Account witness permission, only for witness
- actives: List of active permissions for the account
Return: Unsigned transaction
"},{"location":"api/http/#walletgetaccountbalance","title":"wallet/getaccountbalance","text":"Description\uff1a Get the account balance in a specific block.
curl -X POST http://127.0.0.1:8090/wallet/getaccountbalance -d\n'{\n \"account_identifier\": {\n \"address\": \"TLLM21wteSPs4hKjbxgmH1L6poyMjeTbHm\"\n },\n \"block_identifier\": {\n \"hash\": \"0000000000010c4a732d1e215e87466271e425c86945783c3d3f122bfa5affd9\",\n \"number\": 68682\n },\n \"visible\": true\n}'\n
Parameters:
account_identifier: The account address. block_identifier: The block number.
Return: The balance object of the account in a specific block, the block_identifier is the block hash.
{\n \"balance\": 64086449348265042,\n \"block_identifier\": {\n \"hash\": \"0000000000010c4a732d1e215e87466271e425c86945783c3d3f122bfa5affd9\",\n \"number\": 68682\n }\n}\n
"},{"location":"api/http/#walletsetaccountid","title":"wallet/setaccountid","text":"Description: To set an account id for an account
curl -X POST http://127.0.0.1:8090/wallet/setaccountid -d '{\n\"owner_address\":\"41a7d8a35b260395c14aa456297662092ba3b76fc0\",\"account_id\":\"6161616162626262\"}'\n
Parameters: owner_address: Owner address, default hexStringaccount_id :Account id, default hexString
Return: Unsigned transaction
"},{"location":"api/http/#walletgetaccountbyid","title":"wallet/getaccountbyid","text":"Description: Query an account information by account id
curl -X POST http://127.0.0.1:8090/wallet/getaccountbyid -d\n'{\"account_id\":\"6161616162626262\"}'\n
Parameters: account_id Account id, default hexString Return:Account object
"},{"location":"api/http/#transfers-and-transactions","title":"Transfers and transactions","text":"The following are transfer and transaction related APIs:
- wallet/createtransaction
- wallet/broadcasttransaction
- wallet/broadcasthex
- wallet/getsignweight
- wallet/getapprovedlist
"},{"location":"api/http/#walletcreatetransaction","title":"wallet/createtransaction","text":"Description: Create a transfer transaction, if to address is not existed, then create the account on the blockchain
curl -X POST http://127.0.0.1:8090/wallet/createtransaction -d '{\"to_address\": \"41e9d79cc47518930bc322d9bf7cddd260a0260a8d\", \"owner_address\": \"41D1E7A6BC354106CB410E65FF8B181C600FF14292\", \"amount\": 1000 }'\n
Parameters: to_address To address, default hexStringowner_address Owner address, default hexStringamount Transfer amountPermission_id Optional, for multi-signature use
Return: Unsigned transaction
"},{"location":"api/http/#walletbroadcasttransaction","title":"wallet/broadcasttransaction","text":"Description: Broadcast transaction after sign
curl -X POST http://127.0.0.1:8090/wallet/broadcasttransaction -d '{\"signature\":[\"97c825b41c77de2a8bd65b3df55cd4c0df59c307c0187e42321dcc1cc455ddba583dd9502e17cfec5945b34cad0511985a6165999092a6dec84c2bdd97e649fc01\"],\"txID\":\"454f156bf1256587ff6ccdbc56e64ad0c51e4f8efea5490dcbc720ee606bc7b8\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"amount\":1000,\"owner_address\":\"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\",\"to_address\":\"41d1e7a6bc354106cb410e65ff8b181c600ff14292\"},\"type_url\":\"type.googleapis.com/protocol.TransferContract\"},\"type\":\"TransferContract\"}],\"ref_block_bytes\":\"267e\",\"ref_block_hash\":\"9a447d222e8de9f2\",\"expiration\":1530893064000,\"timestamp\":1530893006233}}'\n
Parameters: Transaction after sign Return:The result of the broadcast
"},{"location":"api/http/#walletbroadcasthex","title":"wallet/broadcasthex","text":"Description: Broadcast transaction hex string after sign
curl -X POST http://127.0.0.1:8090/wallet/broadcasthex -d '{\"transaction\":\"0A8A010A0202DB2208C89D4811359A28004098A4E0A6B52D5A730802126F0A32747970652E676F6F676C65617069732E636F6D2F70726F746F636F6C2E5472616E736665724173736574436F6E747261637412390A07313030303030311215415A523B449890854C8FC460AB602DF9F31FE4293F1A15416B0580DA195542DDABE288FEC436C7D5AF769D24206412418BF3F2E492ED443607910EA9EF0A7EF79728DAAAAC0EE2BA6CB87DA38366DF9AC4ADE54B2912C1DEB0EE6666B86A07A6C7DF68F1F9DA171EEE6A370B3CA9CBBB00\"}'\n
Parameters: Transaction hex after sign Return: The result of the broadcast
"},{"location":"api/http/#walletgetsignweight","title":"wallet/getsignweight","text":"Description: Query the current signatures total weight of a transaction after sign
curl -X POST http://127.0.0.1:8090/wallet/getsignweight -d '{\n \"signature\": [\n \"e0bd4a60f1b3c89d4da3894d400e7e32385f6dd690aee17fdac4e016cdb294c5128b66f62f3947a7182c015547496eba95510c113bda2a361d811b829343c36501\",\n \"596ead6439d0f381e67f30b1ed6b3687f2bd53ce5140cdb126cfe4183235804741eeaf79b4e91f251fd7042380a9485d4d29d67f112d5387bc7457b355cd3c4200\"\n ],\n \"txID\": \"0ae84a8439f5aa8fd2c458879a4031a7452aebed8e6e99ffbccd26842d4323c4\",\n \"raw_data\": {\n \"contract\": [{\n \"parameter\": {\n \"value\": {\n \"amount\": 1000000,\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"to_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\"\n },\n \"type_url\": \"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\": \"TransferContract\"\n }],\n \"ref_block_bytes\": \"163d\",\n \"ref_block_hash\": \"77ef4ace148b05ba\",\n \"expiration\": 1555664823000,\n \"timestamp\": 1555664763418\n },\n \"raw_data_hex\": \"0a02163d220877ef4ace148b05ba40d8c5e5a6a32d5a69080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541a7d8a35b260395c14aa456297662092ba3b76fc01215415a523b449890854c8fc460ab602df9f31fe4293f18c0843d2802709af4e1a6a32d\",\n \"visible\": true}'\n
Parameters: Transaction object after sign Return: The current signatures total weight
"},{"location":"api/http/#walletgetapprovedlist","title":"wallet/getapprovedlist","text":"Description: Query the signatures list of a transaction after sign
curl -X POST http://127.0.0.1:8090/wallet/getapprovedlist -d '{\n \"signature\": [\n \"e0bd4a60f1b3c89d4da3894d400e7e32385f6dd690aee17fdac4e016cdb294c5128b66f62f3947a7182c015547496eba95510c113bda2a361d811b829343c36501\",\n \"596ead6439d0f381e67f30b1ed6b3687f2bd53ce5140cdb126cfe4183235804741eeaf79b4e91f251fd7042380a9485d4d29d67f112d5387bc7457b355cd3c4200\"\n ],\n \"txID\": \"0ae84a8439f5aa8fd2c458879a4031a7452aebed8e6e99ffbccd26842d4323c4\",\n \"raw_data\": {\n \"contract\": [{\n \"parameter\": {\n \"value\": {\n \"amount\": 1000000,\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"to_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\"\n },\n \"type_url\": \"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\": \"TransferContract\"\n }],\n \"ref_block_bytes\": \"163d\",\n \"ref_block_hash\": \"77ef4ace148b05ba\",\n \"expiration\": 1555664823000,\n \"timestamp\": 1555664763418\n },\n \"raw_data_hex\": \"0a02163d220877ef4ace148b05ba40d8c5e5a6a32d5a69080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541a7d8a35b260395c14aa456297662092ba3b76fc01215415a523b449890854c8fc460ab602df9f31fe4293f18c0843d2802709af4e1a6a32d\",\n \"visible\": true}'\n
Parameter: Transaction object after sign Return: The list of the signatures
"},{"location":"api/http/#account-resources","title":"Account Resources","text":"The following are account resource related APIs:
- wallet/getaccountresource
- wallet/getaccountnet
- wallet/unfreezebalance
- wallet/getdelegatedresource
- wallet/getdelegatedresourceaccountindex
- wallet/freezebalancev2
- wallet/unfreezebalancev2
- wallet/cancelallunfreezev2
- wallet/delegateresource
- wallet/undelegateresource
- wallet/withdrawexpireunfreeze
- wallet/getavailableunfreezecount
- wallet/getcanwithdrawunfreezeamount
- wallet/getcandelegatedmaxsize
- wallet/getdelegatedresourcev2
- wallet/getdelegatedresourceaccountindexv2
"},{"location":"api/http/#walletgetaccountresource","title":"wallet/getaccountresource","text":"Description: Query the resource information of an account
curl -X POST http://127.0.0.1:8090/wallet/getaccountresource -d {\"address\" : \"419844f7600e018fd0d710e2145351d607b3316ce9\"}\n
Parameters: address: Address, default hexString
Return: The resource information
"},{"location":"api/http/#walletgetaccountnet","title":"wallet/getaccountnet","text":"Description: Query the bandwidth information of an account
curl -X POST http://127.0.0.1:8090/wallet/getaccountnet -d '{\"address\": \"4112E621D5577311998708F4D7B9F71F86DAE138B5\"}'\n
Parameters: address - Address, default hexString Return: Bandwidth information
"},{"location":"api/http/#walletfreezebalance","title":"wallet/freezebalance","text":"Description: Stake TRX. This interface has been deprecated, please use FreezeBalanceV2 to stake TRX to obtain resources.
"},{"location":"api/http/#walletunfreezebalance","title":"wallet/unfreezebalance","text":"Description: Unstake the TRX that staked during stake1.0 phase.
curl -X POST http://127.0.0.1:8090/wallet/unfreezebalance -d '{\n\"owner_address\":\"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n\"resource\": \"BANDWIDTH\",\n\"receiver_address\":\"414332f387585c2b58bc2c9bb4492bc1f17342cd1\"\n}'\n
Parameters: owner_address Owner address, default hexStringresource unstake type 'BANDWIDTH' or 'ENERGY'receiverAddress The address that will lose the resource, default hexStringPermission_id Optional, for multi-signature use
Return: Unsigned transaction
"},{"location":"api/http/#walletgetdelegatedresource","title":"wallet/getdelegatedresource","text":"Description: Query the resource delegation information
curl -X POST http://127.0.0.1:8090/wallet/getdelegatedresource -d '\n{\n\"fromAddress\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n\"toAddress\": \"41c6600433381c731f22fc2b9f864b14fe518b322f\"\n}'\n
Parameters: fromAddress: from address, default hexStringtoAddress: to address, default hexString
Return: Resource delegation information
"},{"location":"api/http/#walletgetdelegatedresourceaccountindex","title":"wallet/getdelegatedresourceaccountindex","text":"Description: Query the resource delegation by an account during stake1.0 phase. i.e. list all addresses that have delegated resources to an account.
curl -X POST http://127.0.0.1:8090/wallet/getdelegatedresourceaccountindex -d '\n{\n\"value\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n}'\n
Parameters: value: account address
Return:resource delegation index
"},{"location":"api/http/#walletfreezebalancev2","title":"wallet/freezebalancev2","text":"Description: Stake TRX
curl -X POST http://127.0.0.1:8090/wallet/freezebalancev2 -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"frozen_balance\": 10000,\n \"resource\": \"BANDWIDTH\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringfrozen_balance: TRX stake amount, the unit is sunresource: TRX stake type, 'BANDWIDTH' or 'ENERGY'permission_id: Optional, for multi-signature use
Return: Unsigned transaction
"},{"location":"api/http/#walletunfreezebalancev2","title":"wallet/unfreezebalancev2","text":"Description: Unstake some TRX staked in Stake2.0, release the corresponding amount of bandwidth or energy, and voting rights (TP)
curl -X POST http://127.0.0.1:8090/wallet/unfreezebalancev2 -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"unfreeze_balance\": 1000000,\n \"resource\": \"BANDWIDTH\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringresource: Resource type: 'BANDWIDTH' or 'ENERGY'unfreeze_balance: The amount of TRX to unstake, in sunpermission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#walletcancelallunfreezev2","title":"wallet/cancelallunfreezev2","text":"Description: Cancel unstakings, all unstaked funds still in the waiting period will be re-staked, all unstaked funds that exceeded the 14-day waiting period will be automatically withdrawn to the owner\u2019s account
curl -X POST http://127.0.0.1:8090/wallet/cancelallunfreezev2 -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringpermission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#walletdelegateresource","title":"wallet/delegateresource","text":"Description: Delegate bandwidth or energy resources to other accounts in Stake2.0.
curl -X POST http://127.0.0.1:8090/wallet/delegateresource -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"receiver_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"balance\": 1000000,\n \"resource\": \"BANDWIDTH\",\n \"lock\": false\n}'\n
Parameters:
owner_address: Account addressreceiver_address: Resource receiver addressbalance: Amount of TRX staked for resources to be delegated, unit is sunresource: Resource type: 'BANDWIDTH' or 'ENERGY'lock: Whether it is locked, if it is set to true, the delegated resources cannot be undelegated within 3 days. When the lock time is not over, if the owner delegates the same type of resources using the lock to the same address, the lock time will be reset to 3 dayslock_period: lock time,The unit is block interval(3 seconds), indicates the time of how many blocks will be produced from the moment the transaction is executed. Only when lock is true, this field is valid. If the delegate lock period is 1 day, the lock_period is: 28800permission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#walletundelegateresource","title":"wallet/undelegateresource","text":"Description: Cancel the delegation of bandwidth or energy resources to other account
curl -X POST http://127.0.0.1:8090/wallet/undelegateresource -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"receiver_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"balance\": 1000000,\n \"resource\": \"BANDWIDTH\"\n}'\n
Parameters:
owner_address: Account addressreceiver_address: Resource receiver addressbalance: Amount of TRX staked for resources to be delegated, unit is sunresource: Resource type: 'BANDWIDTH' or 'ENERGY'permission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#walletwithdrawexpireunfreeze","title":"wallet/withdrawexpireunfreeze","text":"Description: Withdraw unfrozen balance in Stake2.0, the user can call this API to get back their funds after executing /wallet/unfreezebalancev2 transaction and waiting N days, N is a network parameter
curl -X POST http://127.0.0.1:8090/wallet/withdrawexpireunfreeze -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n}'\n
Parameters:
owner_address: Account addresspermission_id: Optional, for multi-signature use
Return: Unsigned transaction
"},{"location":"api/http/#walletgetavailableunfreezecount","title":"wallet/getavailableunfreezecount","text":"Description:Remaining times of executing unstake operation in Stake2.0
curl -X POST http://127.0.0.1:8090/wallet/getavailableunfreezecount -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account address
Return:Remaining times of available unstaking.
"},{"location":"api/http/#walletgetcanwithdrawunfreezeamount","title":"wallet/getcanwithdrawunfreezeamount","text":"Description:Query the withdrawable balance at the specified timestamp In Stake2.0
curl -X POST http://127.0.0.1:8090/wallet/getcanwithdrawunfreezeamount -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"timestamp\": 1667977444000,\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account addresstimestamp: query cutoff timestamp, in milliseconds.
Return: withdrawable balance, unit is sun.
"},{"location":"api/http/#walletgetcandelegatedmaxsize","title":"wallet/getcandelegatedmaxsize","text":"Description: In Stake2.0, query the amount of delegatable resources share of the specified resource type for an address, unit is sun.
curl -X POST http://127.0.0.1:8090/wallet/getcandelegatedmaxsize -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"type\": 0,\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account addresstype: resource type, 0 is bandwidth, 1 is energy
Return:the amount of delegatable resource share, unit is sun.
"},{"location":"api/http/#walletgetdelegatedresourcev2","title":"wallet/getdelegatedresourcev2","text":"In Stake2.0, query the detail of resource share delegated from fromAddress to toAddress
curl -X POST http://127.0.0.1:8090/wallet/getdelegatedresourcev2 -d\n'{\n \"fromAddress\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"toAddress\": \"TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1\",\n \"visible\": true\n}\n'\n
Parameters:
fromAddress: resource from address, default hexStringtoAddress: resource to address
Return:Resource delegation list
"},{"location":"api/http/#walletgetdelegatedresourceaccountindexv2","title":"wallet/getdelegatedresourceaccountindexv2","text":"In Stake2.0, query the resource delegation index by an account. Two lists will return, one is the list of addresses the account has delegated its resources(toAddress), and the other is the list of addresses that have delegated resources to the account(fromAddress).
curl -X POST http://127.0.0.1:8090/wallet/getdelegatedresourceaccountindexv2 -d\n'{\n \"value\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"visible\": true\n}\n'\n
Parameters:
value: account address
Return:Two lists will return, one is the list of addresses the account has delegated its resources(toAddress), and the other is the list of addresses that have delegated resources to the account(fromAddress).
"},{"location":"api/http/#query-the-network","title":"Query The Network","text":"The following is the API for querying data on the chain:
- wallet/getnowblock
- wallet/getblock
- wallet/getblockbynum
- wallet/getblockbyid
- wallet/getblockbylatestnum
- wallet/getblockbylimitnext
- wallet/getblockbalance
- wallet/gettransactionbyid
- wallet/gettransactioninfobyid
- wallet/gettransactioncountbyblocknum
- wallet/gettransactioninfobyblocknum
- wallet/listnodes
- wallet/getnodeinfo
- wallet/getchainparameters
- wallet/getenergyprices
- wallet/getbandwidthprices
- wallet/getburntrx
"},{"location":"api/http/#walletgetnowblock","title":"wallet/getnowblock","text":"Description: Query the latest block information
curl -X POST http://127.0.0.1:8090/wallet/getnowblock\n
Parameters: N/A Return: The latest block
"},{"location":"api/http/#walletgetblock","title":"wallet/getblock","text":"Query block header information or entire block information according to block height or block hash
curl -X POST http://127.0.0.1:8090/wallet/getblock -d '{\"detail\":false}'\n
Parameters: id_or_num: id_or_num can be the block height or the block hash. No value entered means to query the latest block.detail: true means query the entire block information include the header and body. false means only query the block header information.
Return: block or block header
"},{"location":"api/http/#walletgetblockbynum","title":"wallet/getblockbynum","text":"Description: Query a block information by block height
curl -X POST http://127.0.0.1:8090/wallet/getblockbynum -d '{\"num\": 1}'\n
Parameters: Block height Return: block
"},{"location":"api/http/#walletgetblockbyid","title":"wallet/getblockbyid","text":"Description: Query a block information by block id
curl -X POST http://127.0.0.1:8090/wallet/getblockbyid -d '{\"value\": \"0000000000038809c59ee8409a3b6c051e369ef1096603c7ee723c16e2376c73\"}'\n
Parameters: Block id Return: block
"},{"location":"api/http/#walletgetblockbylatestnum","title":"wallet/getblockbylatestnum","text":"Description: Query the several latest blocks
curl -X POST http://127.0.0.1:8090/wallet/getblockbylatestnum -d '{\"num\": 5}'\n
Parameters: The number of the blocks expected to return Return:The list of the blocks
"},{"location":"api/http/#walletgetblockbylimitnext","title":"wallet/getblockbylimitnext","text":"Description: Query a list of blocks by range
curl -X POST http://127.0.0.1:8090/wallet/getblockbylimitnext -d '{\"startNum\": 1, \"endNum\": 2}'\n
Parameters: startNum: The start block height, itself includedendNum: The end block height, itself not included
Return: The list of the blocks
"},{"location":"api/http/#walletgetblockbalance","title":"wallet/getblockbalance","text":"Description\uff1aGet all balance change operations in a block.
curl -X POST http://127.0.0.1:8090/wallet/getblockbalance -d\n'{\n \"hash\": \"000000000000dc2a3731e28a75b49ac1379bcc425afc95f6ab3916689fbb0189\",\n \"number\": 56362,\n \"visible\": true\n}'\n
Parameters: The hash and block number must match. Return:
{\n \"block_identifier\": {\n \"hash\": \"000000000000dc2a3731e28a75b49ac1379bcc425afc95f6ab3916689fbb0189\",\n \"number\": 56362\n },\n \"timestamp\": 1530060672000,\n \"transaction_balance_trace\": [\n {\n \"transaction_identifier\": \"e6cabb1833cd1f795eed39d8dd7689eaa70e5bb217611766c74c7aa9feea80df\",\n \"operation\": [\n {\n \"operation_identifier\": 0,\n \"address\": \"TPttBLmFuykRi83y9HxDoEWxTQw6CCcQ4p\",\n \"amount\": -100000\n },\n {\n \"operation_identifier\": 1,\n \"address\": \"TLsV52sRDL79HXGGm9yzwKibb6BeruhUzy\",\n \"amount\": 100000\n },\n {\n \"operation_identifier\": 2,\n \"address\": \"TPttBLmFuykRi83y9HxDoEWxTQw6CCcQ4p\",\n \"amount\": -10000000\n },\n {\n \"operation_identifier\": 3,\n \"address\": \"TMrysg7DbwR1M8xqhpaPdVCHCuWFhw7uk1\",\n \"amount\": 10000000\n }\n ],\n \"type\": \"TransferContract\",\n \"status\": \"SUCCESS\"\n }\n ]\n}\n
"},{"location":"api/http/#walletgettransactionbyid","title":"wallet/gettransactionbyid","text":"Description: Query a transaction information by transaction id
curl -X POST http://127.0.0.1:8090/wallet/gettransactionbyid -d '{\"value\": \"d5ec749ecc2a615399d8a6c864ea4c74ff9f523c2be0e341ac9be5d47d7c2d62\"}'\n
Parameters: Transaction id Return: Transaction information
"},{"location":"api/http/#walletgettransactioninfobyid","title":"wallet/gettransactioninfobyid","text":"Description: Query the transaction fee, block height by transaction id
curl -X POST http://127.0.0.1:8090/wallet/gettransactioninfobyid -d '{\"value\" : \"309b6fa3d01353e46f57dd8a8f27611f98e392b50d035cef213f2c55225a8bd2\"}'\n
Parameters: value - Transaction id Return: Transaction fee & block height
"},{"location":"api/http/#walletgettransactioncountbyblocknum","title":"wallet/gettransactioncountbyblocknum","text":"Description: Query th the number of transactions in a specific block
curl -X POST http://127.0.0.1:8090/wallet/gettransactioncountbyblocknum -d '{\"num\" : 100}'\n
Parameters: num - Block height Return: The number of transactions
"},{"location":"api/http/#walletgettransactioninfobyblocknum","title":"wallet/gettransactioninfobyblocknum","text":"Description: Query the list of transaction information in a specific block
curl -X POST http://127.0.0.1:8090/wallet/gettransactioninfobyblocknum -d '{\"num\" : 100}'\n
Parameters: num is the Block height Return:The list of transaction information
"},{"location":"api/http/#walletlistnodes","title":"wallet/listnodes","text":"Description: Query the list of nodes connected to the ip of the api
curl -X POST http://127.0.0.1:8090/wallet/listnodes\n
Parameters: N/A Return: The list of nodes
"},{"location":"api/http/#walletgetnodeinfo","title":"wallet/getnodeinfo","text":"Description: Query the current node information
curl http://127.0.0.1:8090/wallet/getnodeinfo\n
Return: The node information"},{"location":"api/http/#walletgetchainparameters","title":"wallet/getchainparameters","text":"Description: Query the parameters of the blockchain used for SR(Super Representatives) to create a proposal
curl -X POST http://127.0.0.1:8090/wallet/getchainparameters\n
Return: The list of parameters of the blockchain"},{"location":"api/http/#walletgetenergyprices","title":"wallet/getenergyprices","text":"Description: Query historical energy unit price
curl -X POST http://127.0.0.1:8090/wallet/getenergyprices\n
Return: All historical energy unit price information. Each unit price change is separated by a comma. Before the colon is the millisecond timestamp, and after the colon is the energy unit price in sun."},{"location":"api/http/#walletgetbandwidthprices","title":"wallet/getbandwidthprices","text":"Description: Query historical bandwidth unit price
curl -X POST http://127.0.0.1:8090/wallet/getbandwidthprices\n
Return: All historical bandwidth unit price information. Each unit price change is separated by a comma. Before the colon is the millisecond timestamp, and after the colon is the bandwidth unit price in sun."},{"location":"api/http/#walletgetburntrx","title":"wallet/getburntrx","text":"Description: Query the amount of TRX burned due to on-chain transaction fees since No. 54 Committee Proposal took effect
curl -X POST http://127.0.0.1:8090/wallet/getburntrx\n
Return: Amount of TRX burned, in sun."},{"location":"api/http/#smart-contracts","title":"Smart Contracts","text":"The following are smart contract related APIs:
- wallet/getcontract
- wallet/getcontractinfo
- wallet/deploycontract
- wallet/triggersmartcontract
- wallet/triggerconstantcontract
- wallet/updatesetting
- wallet/updateenergylimit
- wallet/clearabi
- wallet/estimateenergy
"},{"location":"api/http/#walletgetcontract","title":"wallet/getcontract","text":"Queries a contract's information from the blockchain, including the bytecode of the contract, ABI, configuration parameters, etc.
curl -X POST http://127.0.0.1:8090/wallet/getcontract -d '{\"value\":\"4189139CB1387AF85E3D24E212A008AC974967E561\"}'\n
Parameters: value - Contract address Return:SmartContract
"},{"location":"api/http/#walletgetcontractinfo","title":"wallet/getcontractinfo","text":"Queries a contract's information from the blockchain. The difference from the wallet/getcontract interface is that this interface returns not only the bytecode but also the runtime bytecode of the contract. Compared with bytecode, runtime bytecode does not contain constructor and constructor parameter information.
curl -X POST http://127.0.0.1:8090/wallet/getcontractinfo -d '{\"value\":\"4189139CB1387AF85E3D24E212A008AC974967E561\"}'\n
Parameters: value - Contract address Return: contract's information
"},{"location":"api/http/#walletdeploycontract","title":"wallet/deploycontract","text":"Description: Deploy a smart contract
curl -X POST http://127.0.0.1:8090/wallet/deploycontract -d '{\"abi\":\"[{\\\"constant\\\":false,\\\"inputs\\\":[{\\\"name\\\":\\\"key\\\",\\\"type\\\":\\\"uint256\\\"},{\\\"name\\\":\\\"value\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"name\\\":\\\"set\\\",\\\"outputs\\\":[],\\\"payable\\\":false,\\\"stateMutability\\\":\\\"nonpayable\\\",\\\"type\\\":\\\"function\\\"},{\\\"constant\\\":true,\\\"inputs\\\":[{\\\"name\\\":\\\"key\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"name\\\":\\\"get\\\",\\\"outputs\\\":[{\\\"name\\\":\\\"value\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"payable\\\":false,\\\"stateMutability\\\":\\\"view\\\",\\\"type\\\":\\\"function\\\"}]\",\"bytecode\":\"608060405234801561001057600080fd5b5060de8061001f6000396000f30060806040526004361060485763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631ab06ee58114604d5780639507d39a146067575b600080fd5b348015605857600080fd5b506065600435602435608e565b005b348015607257600080fd5b50607c60043560a0565b60408051918252519081900360200190f35b60009182526020829052604090912055565b600090815260208190526040902054905600a165627a7a72305820fdfe832221d60dd582b4526afa20518b98c2e1cb0054653053a844cf265b25040029\",\"parameter\":\"\",\"call_value\":100,\"name\":\"SomeContract\",\"consume_user_resource_percent\":30,\"fee_limit\":10,\"origin_energy_limit\": 10,\"owner_address\":\"41D1E7A6BC354106CB410E65FF8B181C600FF14292\"}'\n
Parameters: abi:abibytecode:bytecode\uff0chexStringparameter:The list of the parameters of the constructor, It should be converted hexString after encoded according to ABI encoder. If constructor has no parameter, this can be optionalconsume_user_resource_percent: Consume user's resource percentage. It should be an integer between [0, 100]. if 0, means it does not consume user's resource until the developer's resource has been used upfee_limit: The maximum TRX burns for resource consumptioncall_value: The TRX transfer to the contract for each callowner_address:Owner address of the contract, default hexStringname:Contract nameorigin_energy_limit: The maximum resource consumption of the creator in one execution or creationcall_token_value: The amount of trc10 token transfer to the contract for each call (Optional)token_id:The id of trc10 token transfer to the contract (Optional)Permission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#wallettriggersmartcontract","title":"wallet/triggersmartcontract","text":"Description: Trigger smart contract
$ curl -X POST http://127.0.0.1:8090/wallet/triggersmartcontract -d\n'{\n \"contract_address\": \"4189139CB1387AF85E3D24E212A008AC974967E561\",\n \"function_selector\": \"set(uint256,uint256)\",\n \"parameter\": \"00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000002\",\n \"fee_limit\": 10,\n \"call_value\": 100,\n \"owner_address\": \"41D1E7A6BC354106CB410E65FF8B181C600FF14292\"\n}'\n
Parameters: contract_address: Contract address, default hexStringfunction_selector: Function call, must not leave a blank spaceparameter: The parameter passed to 'function_selector', the format must match with the VM's requirement. You can use a js tool provided by remix to convert a parameter like [1,2] to the format that VM requiresdata: The data for interacting with smart contracts, including the contract function and parameters. You can choose to use this field, or you can choose to use function_selector and parameter for contract interaction. When both of data and function_selector exist, function_selector is preferredfee_limit: The maximum TRX burns for resource consumptioncall_value: The TRX transfer to the contract for each callcall_token_value: The amount of trc10 token transfer to the contract for each calltoken_id: The id of trc10 token transfer to the contractowner_address: Owner address that triggers the contract, default hexStringpermission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#wallettriggerconstantcontract","title":"wallet/triggerconstantcontract","text":"Description: Trigger the constant of the smart contract, the transaction is off the blockchain
$ curl -X POST http://127.0.0.1:8090/wallet/triggerconstantcontract -d\n'{\n \"contract_address\": \"4189139CB1387AF85E3D24E212A008AC974967E561\",\n \"function_selector\": \"set(uint256,uint256)\",\n \"parameter\": \"00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000002\",\n \"call_value\": 100,\n \"owner_address\": \"41D1E7A6BC354106CB410E65FF8B181C600FF14292\"\n}'\n
Parameters: contract_address: Smart contract address, default hexStringfunction_selector: Function call, must not leave a blank spaceparameter: The parameter passed to 'function_selector', the format must match with the VM's requirement. You can use a hs tool provided by remix to convert a parameter like [1,2] to the format that VM requiresdata: The data for interacting with smart contracts, including the contract function and parameters. You can choose to use this field, or you can choose to use function_selector and parameter for contract interaction. When both of data and function_selector exist, function_selector is preferredcall_value: The TRX transfer to the contract for each callowner_address: Owner address that triggers the contract, default hexStringcall_token_value: The amount of trc10 token transfer to the contract for each calltoken_id: The id of trc10 token transfer to the contract
Return: Transaction object
Note: The unit of TRX in the parameters is SUN
"},{"location":"api/http/#walletupdatesetting","title":"wallet/updatesetting","text":"Description: Update the consume_user_resource_percent parameter of a smart contract
$ curl -X POST http://127.0.0.1:8090/wallet/updatesetting -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"contract_address\": \"41c6600433381c731f22fc2b9f864b14fe518b322f\",\n \"consume_user_resource_percent\": 7\n}'\n
owner_address:Owner address of the smart contract, default hexStringcontract_address:Smart contract address, default hexStringconsume_user_resource_percent:Consume user's resource percentagePermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletupdateenergylimit","title":"wallet/updateenergylimit","text":"Description: Update the origin_energy_limit parameter of a smart contract
$ curl -X POST http://127.0.0.1:8090/wallet/updateenergylimit -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"contract_address\": \"41c6600433381c731f22fc2b9f864b14fe518b322f\",\n \"origin_energy_limit\": 7\n}'\n
Parameters: owner_address: Owner address of the smart contract, default hexStringcontract_address: Smart contract address, default hexStringorigin_energy_limit: The maximum resource consumption of the creator in one execution or creationpermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletclearabi","title":"wallet/clearabi","text":"Description: To clear the abi of a smart contract
$ curl -X POST http://127.0.0.1:8090/wallet/clearabi -d\n'{\n \"owner_address\": \"41a7d8a35b260395c14aa456297662092ba3b76fc0\",\n \"contract_address\": \"417bcb781f4743afaacf9f9528f3ea903b3782339f\"\n}'\n
Parameters:
owner_address:Owner address of the smart contractcontract_address: Smart contract address, default hexString
Return: Transaction object
"},{"location":"api/http/#walletestimateenergy","title":"wallet/estimateenergy","text":"Estimate the energy required for the successful execution of smart contract transactions
curl -X POST http://127.0.0.1:8090/wallet/estimateenergy -d '{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"contract_address\": \"TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs\",\n \"function_selector\": \"transfer(address,uint256)\",\n \"parameter\": \"00000000000000000000004115208EF33A926919ED270E2FA61367B2DA3753DA0000000000000000000000000000000000000000000000000000000000000032\",\n \"visible\": true\n}'\n
Parameters:
contract_address : Smart contract address. If visible=true, use base58check format, otherwise use hex format.function_selector: Function call, must not be left blank.parameter: Parameter encoding needs to be in accordance with the ABI rules, the rules are more complicated, users can use the ethers library to encodedata: The data for interacting with smart contracts, including the contract function and parameters. You can choose to use this field, or you can choose to use function_selector and parameter for contract interaction. When both of data and function_selector exist, function_selector is preferredcall_value: The TRX transfer to the contract for each callowner_address:Owner address that triggers the contract. If visible=true, use base58check format, otherwise use hex call_token_value: The amount of trc10 token transfer to the contract for each calltoken_id: The id of trc10 token transfer to the contract
Return:Estimated the energy value
"},{"location":"api/http/#trc10-token","title":"TRC10 token","text":"The following are TRC10 token-related APIs:
- wallet/getassetissuebyaccount
- wallet/getassetissuebyname
- wallet/getassetissuelistbyname
- wallet/getassetissuebyid
- wallet/getassetissuelist
- wallet/getpaginatedassetissuelist
- wallet/transferasset
- wallet/participateassetissue
- wallet/createassetissue
- wallet/unfreezeasset
- wallet/updateasset
"},{"location":"api/http/#walletgetassetissuebyaccount","title":"wallet/getassetissuebyaccount","text":"Description: Query the token issue information of an account
$ curl -X POST http://127.0.0.1:8090/wallet/getassetissuebyaccount -d\n'{\n \"address\": \"41F9395ED64A6E1D4ED37CD17C75A1D247223CAF2D\"\n}'\n
Parameter address: Token issuer's address, default hexString
Return: Token object
"},{"location":"api/http/#walletgetassetissuebyname","title":"wallet/getassetissuebyname","text":"Description: Query a token by token name
$ curl -X POST http://127.0.0.1:8090/wallet/getassetissuebyname -d\n'{\n \"value\": \"44756354616E\"\n}'\n
Parameter value: Token name, default hexString
Return: Token object
"},{"location":"api/http/#walletgetassetissuelistbyname","title":"wallet/getassetissuelistbyname","text":"Description: Query the list of tokens by name
$ curl -X POST http://127.0.0.1:8090/wallet/getassetissuelistbyname -d\n'{\n \"value\": \"44756354616E\"\n}'\n
Parameter value: Token name, default hexString
Return: The list of tokens
"},{"location":"api/http/#walletgetassetissuebyid","title":"wallet/getassetissuebyid","text":"Description: Query a token by token id
$ curl -X POST http://127.0.0.1:8090/wallet/getassetissuebyid -d\n'{\n \"value\": \"1000001\"\n}'\n
Parameter value: Token id
Return: Token object
"},{"location":"api/http/#walletgetassetissuelist","title":"wallet/getassetissuelist","text":"Description: Query the list of all the tokens
$ curl -X GET http://127.0.0.1:8090/wallet/getassetissuelist\n
Parameter: No parameter
Return: The list of all the tokens
"},{"location":"api/http/#walletgetpaginatedassetissuelist","title":"wallet/getpaginatedassetissuelist","text":"Description: Query the list of all the tokens by pagination
$ curl -X POST http://127.0.0.1:8090/wallet/getpaginatedassetissuelist -d\n'{\n \"offset\": 0,\n \"limit\": 10\n}'\n
Parameters:
offset: The index of the start tokenlimit: The amount of tokens per page
Return: The list of tokens by pagination
"},{"location":"api/http/#wallettransferasset","title":"wallet/transferasset","text":"Description: Transfer token
$ curl -X POST http://127.0.0.1:8090/wallet/transferasset -d\n'{\n \"owner_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"to_address\": \"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\",\n \"asset_name\": \"31303030303031\",\n \"amount\": 100\n}'\n
Parameters: owner_address: Owner address, default hexStringto_address: To address, default hexStringasset_name: Token id, default hexStringamount: Token transfer amountpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'amount' is the smallest unit of the token
"},{"location":"api/http/#walletparticipateassetissue","title":"wallet/participateassetissue","text":"Description: Participate a token
$ curl -X POST http://127.0.0.1:8090/wallet/participateassetissue -d\n'{\n \"to_address\": \"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\",\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"amount\": 100,\n \"asset_name\": \"3230313271756265696a696e67\"\n}'\n
Parameters: to_address: The issuer address of the token, default hexStringowner_address: The participant address, default hexStringamount: Participate token amountasset_name: Token id, default hexStringpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'amount' is the smallest unit of the token
"},{"location":"api/http/#walletcreateassetissue","title":"wallet/createassetissue","text":"Description: Issue a token
$ curl -X POST http://127.0.0.1:8090/wallet/createassetissue -d\n'{\n \"owner_address\": \"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\",\n \"name\": \"0x6173736574497373756531353330383934333132313538\",\n \"abbr\": \"0x6162627231353330383934333132313538\",\n \"total_supply\": 4321,\n \"trx_num\": 1,\n \"num\": 1,\n \"start_time\": 1530894315158,\n \"end_time\": 1533894312158,\n \"description\": \"007570646174654e616d6531353330363038383733343633\",\n \"url\": \"007570646174654e616d6531353330363038383733343633\",\n \"free_asset_net_limit\": 10000,\n \"public_free_asset_net_limit\": 10000,\n \"frozen_supply\": {\n \"frozen_amount\": 1,\n \"frozen_days\": 2\n }\n}'\n
Parameters: owner_address: Owner address, default hexStringname: Token name, default hexStringabbr: Token name abbreviation, default hexStringtotal_supply: Token total supplytrx_num: Define the price by the ratio of trx_num/numnum: Define the price by the ratio of trx_num/numstart_time: ICO start timeend_time: ICO end timedescription: Token description, default hexStringurl: Token official website url, default hexStringfree_asset_net_limit: Token free asset net limitpublic_free_asset_net_limit: Token public free asset net limitfrozen_supply: Token staked supplypermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'trx_num' is SUN
"},{"location":"api/http/#walletunfreezeasset","title":"wallet/unfreezeasset","text":"Description: Unstake the staked token that is due
$ curl -X POST http://127.0.0.1:8090/wallet/unfreezeasset -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\"\n}'\n
Parameters: - owner_address: Owner address, default hexString - permission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletupdateasset","title":"wallet/updateasset","text":"Description: Update token information
$ curl -X POST http://127.0.0.1:8090/wallet/updateasset -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"description\": \"\",\n \"url\": \"\",\n \"new_limit\": 1000000,\n \"new_public_limit\": 100\n}'\n
Parameters:
owner_address: The issuers address of the token, default hexStringdescription: The description of token, default hexStringurl: The token's website url, default hexStringnew_limit: Each token holder's free bandwidthnew_public_limit: The total free bandwidth of the tokenpermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#vote-and-sr","title":"Vote and SR","text":"The following are voting and SR related APIs:
- wallet/createwitness
- wallet/updatewitness
- wallet/listwitnesses
- wallet/withdrawbalance
- wallet/votewitnessaccount
- wallet/getBrokerage
- wallet/updateBrokerage
- wallet/getReward
- wallet/getnextmaintenancetime
"},{"location":"api/http/#walletcreatewitness","title":"wallet/createwitness","text":"Description: Apply to become a super representative
$ curl -X POST http://127.0.0.1:8090/wallet/createwitness -d\n'{\n \"owner_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"url\": \"007570646174654e616d6531353330363038383733343633\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringurl: Website url, default hexStringpermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletupdatewitness","title":"wallet/updatewitness","text":"Description: Update the super representative' website url
$ curl -X POST http://127.0.0.1:8090/wallet/updatewitness -d\n'{\n \"owner_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"update_url\": \"007570646174654e616d6531353330363038383733343633\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringupdate_url: Website url, default hexStringpermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletlistwitnesses","title":"wallet/listwitnesses","text":"Description: Qyery the list of the super representatives
curl -X POST http://127.0.0.1:8090/wallet/listwitnesses\n
Parameters: N/A Return:SR(Super Representatives) list
"},{"location":"api/http/#walletwithdrawbalance","title":"wallet/withdrawbalance","text":"Description: Withdraw reward to account balance for super representatives
$ curl -X POST http://127.0.0.1:8090/wallet/withdrawbalance -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: It can only withdraw once for every 24 hours
"},{"location":"api/http/#walletvotewitnessaccount","title":"wallet/votewitnessaccount","text":"Description: Vote for super representatives
$ curl -X POST http://127.0.0.1:8090/wallet/votewitnessaccount -d\n'{\n \"owner_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"votes\": [\n {\n \"vote_address\": \"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\",\n \"vote_count\": 5\n }\n ]\n}'\n
Parameters:
owner_address: Owner address, default hexStringvotes: 'vote_address' stands for the address of the super representative you want to vote, default hexString, 'vote_count' stands for the number of votes you want to votepermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletgetbrokerage","title":"wallet/getBrokerage","text":"Description: Query the ratio of brokerage of the super representative
$ curl -X GET http://127.0.0.1:8090/wallet/getBrokerage -d '{\n\"address\":\"41E552F6487585C2B58BC2C9BB4492BC1F17132CD0\"}'\n
Parameter address: The address of the SR's account, default hexString
Return: The ratio of brokerage of the SR
"},{"location":"api/http/#walletupdatebrokerage","title":"wallet/updateBrokerage","text":"Description: Update the ratio of brokerage
$ curl -X POST http://127.0.0.1:8090/wallet/updateBrokerage -d '{\n\"owner_address\":\"41E552F6487585C2B58BC2C9BB4492BC1F17132CD0\",\n\"brokerage\":30\n}'\n
Parameters:
owner_address: The address of the SR's account, default hexStringbrokerage: The ratio of brokerage you want to update to
Return: Transaction object
"},{"location":"api/http/#walletgetreward","title":"wallet/getReward","text":"Description: Query unclaimed reward
$ curl -X GET\nhttp://127.0.0.1:8090/wallet/getReward -d '{\n\"address\":\"41E552F6487585C2B58BC2C9BB4492BC1F17132CD0\"}'\n
Parameter address: The address of the voter's account, default hexString
Return: Unclaimed reward
"},{"location":"api/http/#walletgetnextmaintenancetime","title":"wallet/getnextmaintenancetime","text":"Description: Query the time interval till the next vote round
curl -X POST http://127.0.0.1:8090/wallet/getnextmaintenancetime\n
Parameters: N/A Return: The time interval till the next vote round(unit: ms)
"},{"location":"api/http/#proposals","title":"Proposals","text":"The following are proposal-related APIs:
- wallet/proposalcreate
- wallet/getproposalbyid
- wallet/listproposals
- wallet/proposalapprove
- wallet/proposaldelete
- wallet/getpaginatedproposallist
"},{"location":"api/http/#walletproposalcreate","title":"wallet/proposalcreate","text":"Description: Create a proposal
$ curl -X POST http://127.0.0.1:8090/wallet/proposalcreate -d\n'{\n \"owner_address\": \"419844F7600E018FD0D710E2145351D607B3316CE9\",\n \"parameters\": [\n {\n \"key\": 0,\n \"value\": 100000\n },\n {\n \"key\": 1,\n \"value\": 2\n }\n ]\n}'\n
Parameters:
owner_address: Creator addressparameters: Proposal parameterspermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletgetproposalbyid","title":"wallet/getproposalbyid","text":"Description: Query a proposal by proposal id
$ curl -X POST http://127.0.0.1:8090/wallet/getproposalbyid -d\n'{\n \"id\": 1\n}'\n
Parameter id: Proposal id
Return: The proposal information
"},{"location":"api/http/#walletlistproposals","title":"wallet/listproposals","text":"Description: Query all the proposals
$ curl -X POST http://127.0.0.1:8090/wallet/listproposals\n
Parameter: No parameter
Return: The list of all the proposals
"},{"location":"api/http/#walletproposalapprove","title":"wallet/proposalapprove","text":"Description: To approve a proposal
$ curl -X POST http://127.0.0.1:8090/wallet/proposalapprove -d\n'{\n \"owner_address\": \"419844F7600E018FD0D710E2145351D607B3316CE9\",\n \"proposal_id\": 1,\n \"is_add_approval\": true\n}'\n
Parameters:
owner_address: The address that makes the approve action, default hexStringproposal_id: Proposal idis_add_approval: Whether to approvepermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletproposaldelete","title":"wallet/proposaldelete","text":"Description: To delete a proposal
$ curl -X POST http://127.0.0.1:8090/wallet/proposaldelete -d\n'{\n \"owner_address\": \"419844F7600E018FD0D710E2145351D607B3316CE9\",\n \"proposal_id\": 1\n}'\n
Parameters:
owner_address: Owner address of the proposal, default hexStringproposal_id: Proposal idpermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletgetpaginatedproposallist","title":"wallet/getpaginatedproposallist","text":"Description: Query the list of all the proposals by pagination
$ curl -X POST http://127.0.0.1:8090/wallet/getpaginatedproposallist -d\n'{\n \"offset\": 0,\n \"limit\": 10\n}'\n
Parameters:
offset: The index of the start proposallimit: The amount of proposals per page
Return: The list of proposals by pagination
"},{"location":"api/http/#dex-exchange","title":"DEX Exchange","text":"The following are the APIs related to decentralized exchanges:
- wallet/exchangecreate
- wallet/exchangeinject
- wallet/exchangewithdraw
- wallet/exchangetransaction
- wallet/getexchangebyid
- wallet/listexchanges
- wallet/getpaginatedexchangelist
- wallet/marketsellasset
- wallet/marketcancelorder
- wallet/getmarketorderbyaccount
- wallet/getmarketpairlist
- wallet/getmarketorderlistbypair
- wallet/getmarketpricebypair
- wallet/getmarketorderbyid
"},{"location":"api/http/#walletexchangecreate","title":"wallet/exchangecreate","text":"Description: Create an exchange pair
$ curl -X POST http://127.0.0.1:8090/wallet/exchangecreate -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"first_token_id\": \"token_a\",\n \"first_token_balance\": 100,\n \"second_token_id\": \"token_b\",\n \"second_token_balance\": 200\n}'\n
Parameters:
owner_address: addressfirst_token_id: The first token's id, default hexStringfirst_token_balance: The first token's balancesecond_token_id: The second token's id, default hexStringsecond_token_balance: The second token's balancepermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'first_token_balance' and 'second_token_balance' is the smallest unit of the token
"},{"location":"api/http/#walletexchangeinject","title":"wallet/exchangeinject","text":"Description: Inject funds for exchange pair
$ curl -X POST http://127.0.0.1:8090/wallet/exchangeinject -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"exchange_id\": 1,\n \"token_id\": \"74726f6e6e616d65\",\n \"quant\": 100\n}'\n
Parameters:
owner_address: Owner address of the exchange pair, default hexStringexchange_id: Exchange pair idtoken_id: Token id, default hexStringquant: Token inject amountpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'quant' is the smallest unit of the token
"},{"location":"api/http/#walletexchangewithdraw","title":"wallet/exchangewithdraw","text":"Description: Withdraw from exchange pair
$ curl -X POST http://127.0.0.1:8090/wallet/exchangewithdraw -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"exchange_id\": 1,\n \"token_id\": \"74726f6e6e616d65\",\n \"quant\": 100\n}'\n
Parameters:
owner_address: Owner address of the exchange pair, default hexStringexchange_id: Exchange pair idtoken_id: Token id, default hexStringquant: Token withdraw amountpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'quant' is the smallest unit of the token
"},{"location":"api/http/#walletexchangetransaction","title":"wallet/exchangetransaction","text":"Description: Participate the transaction of exchange pair
$ curl -X POST http://127.0.0.1:8090/wallet/exchangetransaction -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"exchange_id\": 1,\n \"token_id\": \"74726f6e6e616d65\",\n \"quant\": 100,\n \"expected\": 10\n}'\n
Parameters:
owner_address: Owner address of the exchange pair, default hexStringexchange_id: Exchange pair idtoken_id: Token id, default hexStringquant: Sell token amountexpected: Expected token amount to getpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'quant' and 'expected' is the smallest unit of the token
"},{"location":"api/http/#walletgetexchangebyid","title":"wallet/getexchangebyid","text":"Description: Query an exchange pair by exchange pair id
$ curl -X POST http://127.0.0.1:8090/wallet/getexchangebyid -d\n'{\n \"id\": 1\n}'\n
Parameter id: Exchange pair id
Return: Exchange pair information
"},{"location":"api/http/#walletlistexchanges","title":"wallet/listexchanges","text":"Description: Query the list of all the exchange pairs
$ curl -X GET http://127.0.0.1:8090/wallet/listexchanges\n
Parameter: No parameter
Return: The list of all the exchange pairs
"},{"location":"api/http/#walletgetpaginatedexchangelist","title":"wallet/getpaginatedexchangelist","text":"Description: Query the list of all the exchange pairs by pagination
$ curl -X POST http://127.0.0.1:8090/wallet/getpaginatedexchangelist -d\n'{\n \"offset\": 0,\n \"limit\": 10\n}'\n
Parameters:
offset: The index of the start exchange pairlimit: The amount of exchange pairs per page
Return: The list of exchange pairs by pagination
"},{"location":"api/http/#walletmarketsellasset","title":"wallet/marketsellasset","text":"Description\uff1aCreate an market order
curl -X POST http://127.0.0.1:8090/wallet/marketsellasset -d \n'{\n \"owner_address\": \"4184894b42f66dce8cb84aec2ed11604c991351ac8\",\n \"sell_token_id\": \"5f\",\n \"sell_token_quantity\": 100,\n \"buy_token_id\": \"31303030303031\",\n \"buy_token_quantity\": 200 \n}' \n
Parameters\uff1a owner_address\uff1aowner address, default hexString sell_token_id\uff1asell token id, default hexString sell_token_quantity\uff1asell token quantity buy_token_id\uff1abuy token id, default hexString buy_token_quantity\uff1abuy token quantity (min to receive)
Return\uff1aTransaction object
"},{"location":"api/http/#walletmarketcancelorder","title":"wallet/marketcancelorder","text":"Description\uff1aCancel the order
curl -X POST http://127.0.0.1:8090/wallet/marketcancelorder -d \n'{\n \"owner_address\": \"4184894b42f66dce8cb84aec2ed11604c991351ac8\",\n \"order_id\": \"0a7af584a53b612bcff1d0fc86feab05f69bc4528f26a4433bb344d453bd6eeb\"\n}' \n
Parameters\uff1a owner_address\uff1aowner address, default hexString order_id\uff1aorder id
Return\uff1aTransaction object
"},{"location":"api/http/#walletgetmarketorderbyaccount","title":"wallet/getmarketorderbyaccount","text":"Description\uff1aGet all orders for the account
curl -X POST http://127.0.0.1:8090/wallet/getmarketorderbyaccount -d \n'{\n \"value\": \"4184894b42f66dce8cb84aec2ed11604c991351ac8\" \n}' \n
Parameters\uff1avalue - owner address, default hexString Return\uff1aorder list
"},{"location":"api/http/#walletgetmarketpairlist","title":"wallet/getmarketpairlist","text":"Description\uff1aGet all trading pairs
curl -X get http://127.0.0.1:8090/wallet/getmarketpairlist\n
Parameters: N/A Return: makket pair list
"},{"location":"api/http/#walletgetmarketorderlistbypair","title":"wallet/getmarketorderlistbypair","text":"Description\uff1aGet all orders for the trading pair demo:
curl -X POST http://127.0.0.1:8090/wallet/getmarketorderlistbypair -d \n'{\n \"sell_token_id\": \"5f\" ,\n \"buy_token_id\": \"31303030303031\"\n}' \n
Parameters\uff1a sell_token_id\uff1asell token id, default hexString buy_token_id\uff1abuy token id, default hexString
Return\uff1aorder list
"},{"location":"api/http/#walletgetmarketpricebypair","title":"wallet/getmarketpricebypair","text":"Description\uff1aGet all prices for the trading pair
curl -X POST http://127.0.0.1:8090/wallet/getmarketpricebypair -d \n'{\n \"sell_token_id\": \"5f\" \n \"buy_token_id\": \"31303030303031\" \n}' \n
Parameters\uff1a sell_token_id\uff1asell token id, default hexString buy_token_id\uff1abuy token id, default hexString Return\uff1aprice list
"},{"location":"api/http/#walletgetmarketorderbyid","title":"wallet/getmarketorderbyid","text":"Description\uff1aGet all orders for the account
curl -X POST http://127.0.0.1:8090/wallet/getmarketorderbyid -d \n'{\n \"value\": \"orderid\" \n}' \n
Parameters\uff1avalue - order id, default hexString Return\uff1aorder
"},{"location":"api/http/#tronz-shielded-smart-contract","title":"TRONZ Shielded Smart Contract","text":"The following are TRONZ anonymous smart contract related APIs:
- wallet/getexpandedspendingkey
- wallet/getakfromask
- wallet/getnkfromnsk
- wallet/getspendingkey
- wallet/getdiversifier
- wallet/getincomingviewingkey
- wallet/getzenpaymentaddress
- wallet/createshieldedtransactionwithoutspendauthsig
- wallet/scannotebyivk
- wallet/scanandmarknotebyivk
- wallet/scannotebyovk
- wallet/createshieldnullifier
- wallet/getshieldtransactionhash
- wallet/createshieldedtransaction
- wallet/getnewshieldedaddress
- wallet/createshieldedcontractparameters
- wallet/createshieldedcontractparameterswithoutask
- wallet/scanshieldedtrc20notesbyivk
- wallet/scanshieldedtrc20notesbyovk
- wallet/isshieldedtrc20contractnotespent
- wallet/gettriggerinputforshieldedtrc20contract
- wallet/getrcm
- wallet/getmerkletreevoucherinfo
- wallet/isspend
- wallet/createspendauthsig
"},{"location":"api/http/#walletgetexpandedspendingkey","title":"wallet/getexpandedspendingkey","text":"Description: To get expanded spending keys from spending key
curl -X POST http://127.0.0.1:8090/wallet/getexpandedspendingkey -d\n'{\n \"value\": \"06b02aaa00f230b0887ff57a6609d76691369972ac3ba568fe7a8a0897fce7c4\"\n}'\n
Parameters: value:Spending key Return: Expanded spending keys, it consists of three keys: ask, nsk and ovk.
"},{"location":"api/http/#walletgetakfromask","title":"wallet/getakfromask","text":"Description: To get ak key from ask key
curl -X POST http://127.0.0.1:8090/wallet/getakfromask -d\n'{\n \"value\": \"653b3a3fdd40b60d2f53ba121df8840f6590384993f8fa9a0ecb0dfb23496604\"\n}'\n
Parameters: value:Ask Return:Ak
"},{"location":"api/http/#walletgetnkfromnsk","title":"wallet/getnkfromnsk","text":"Description: To get nk key from nsk key
curl -X POST http://127.0.0.1:8090/wallet/getnkfromnsk -d\n'{\n \"value\": \"428ff3c9e101dc1fca08f7b0e3387b23b68016746ae565aefc19d112b696db01\"\n}'\n
Parameters: value:Nsk Return:Nk
"},{"location":"api/http/#walletgetspendingkey","title":"wallet/getspendingkey","text":"Description: To get spending key
curl -X GET http://127.0.0.1:8090/wallet/getspendingkey\n
Parameters: N/A Return:Spending key
"},{"location":"api/http/#walletgetdiversifier","title":"wallet/getdiversifier","text":"Description: To get diversifier
curl -X GET http://127.0.0.1:8090/wallet/getdiversifier\n
Parameters: N/A Return: Diversifier
"},{"location":"api/http/#walletgetincomingviewingkey","title":"wallet/getincomingviewingkey","text":"Description: To get incoming viewing key
curl -X POST http://127.0.0.1:8090/wallet/getincomingviewingkey -d\n'{\n \"ak\":\"b443f1a303ef5837ba95750b48b6fef15f9c77f63a8c28c161bcd6613f423b5c\",\n \"nk\":\"632137e69179df3d10e252fcce85d13464c3163fe7a619edf8d43ebefa8162d9\"\n }'\n
Parameters: ak:Aknk:Nk
Return:Incoming viewing key
"},{"location":"api/http/#walletgetzenpaymentaddress","title":"wallet/getzenpaymentaddress","text":"Description: To get payment address
curl -X POST http://127.0.0.1:8090/wallet/getzenpaymentaddress -d\n'{\n \"ivk\":\"8c7852e10862d8eec058635974f70f24c1f8d73819131bb5b54028d0a9408a03\",\n \"d\":\"736ba8692ed88a5473e009\"\n }'\n
Parameters: ivk:Ivkd:D
Return: Payment address
"},{"location":"api/http/#walletcreateshieldedtransactionwithoutspendauthsig","title":"wallet/createshieldedtransactionwithoutspendauthsig","text":"Description: To create shielded transaction without using ask
$ curl -X POST http://127.0.0.1:8090/wallet/createshieldedtransactionwithoutspendauthsig -d\n'{\n \"ivk\":\"8c7852e10862d8eec058635974f70f24c1f8d73819131bb5b54028d0a9408a03\",\n \"d\":\"736ba8692ed88a5473e009\"\n }'\n
Parameters:
transparent_from_address: Transparent sender's addressfrom_amount: Send amount from transparent addressask: Asknsk: Nskovk: Ovkshielded_receives: Shielded receive informationshieldedSpends: Shielded spend informationtransparent_to_address: Transparent receiver's addressto_amount: Send amount to transparent address
Return: Transaction object
"},{"location":"api/http/#walletcreateshieldedtransactionwithoutspendauthsig_1","title":"wallet/createshieldedtransactionwithoutspendauthsig","text":"Description: To create shielded transaction with using ask
curl -X POST http://127.0.0.1:8090/wallet/createshieldedtransactionwithoutspendauthsig -d\n'{\n \"ak\": \"bf051629fd8122cd9dd8591d72947b026c214cf7cdac1f68eff97179727d38e9\",\n \"nsk\": \"42963d26af8122204273fa3489d9efd6babf1f7179ff193c955a1f3d9c2df10c\",\n \"ovk\": \"bc9848a83966709655b12efadc9e978785858316045e0115a0e72567a9a2a823\",\n \"shielded_spends\": [\n {\n \"note\": {\n \"value\": 500000000,\n \"payment_address\": \"ztron1jld8fmvujrz2vgkc867zuwklmewy4ypw0wtwgweqs2paee0uhc8f3azy90el770arksa2kunl02\",\n \"rcm\": \"723053bcbfecdf5da66c18ab0376476ef308c61b7abe891b2c01e903bcb87c0e\"\n },\n \"alpha\": \"2608999c3a97d005a879ecdaa16fd29ae434fb67b177c5e875b0c829e6a1db04\",\n \"voucher\": {\n \"tree\": {\n \"left\": {\n \"content\": \"a3d5c9b2db9699f32afec5febbd5586ce9ff33a0bef6fee5691028313b8e1f6a\"\n },\n \"parents\": [\n {\n \"content\": \"d9c38484296b3aa8f5e8b59d418a3775e2bb414e75498ad352e4614f05aae548\"\n },\n {\n \"content\": \"d0420777afdc4151c3f14fbe4c714d82dc15873edb1ca65ebb3887334a4bae15\"\n }\n ]\n },\n \"rt\": \"fb1115d5ddd16c5427c3a608d6b5add5967e70f51c890307c6142083a2c28565\"\n },\n \"path\": \"2020b2eed031d4d6a4f02a097f80b54cc1541d4163c6b6f5971f88b6e41d35c538142012935f14b676509b81eb49ef25f39269ed72309238b4c145803544b646dca62d20e1f34b034d4a3cd28557e2907ebf990c918f64ecb50a94f01d6fda5ca5c7ef722028e7b841dcbc47cceb69d7cb8d94245fb7cb2ba3a7a6bc18f13f945f7dbd6e2a20a5122c08ff9c161d9ca6fc462073396c7d7d38e8ee48cdb3bea7e2230134ed6a20d2e1642c9a462229289e5b0e3b7f9008e0301cbb93385ee0e21da2545073cb582016d6252968971a83da8521d65382e61f0176646d771c91528e3276ee45383e4a20fee0e52802cb0c46b1eb4d376c62697f4759f6c8917fa352571202fd778fd712204c6937d78f42685f84b43ad3b7b00f81285662f85c6a68ef11d62ad1a3ee0850200769557bc682b1bf308646fd0b22e648e8b9e98f57e29f5af40f6edb833e2c492008eeab0c13abd6069e6310197bf80f9c1ea6de78fd19cbae24d4a520e6cf3023208d5fa43e5a10d11605ac7430ba1f5d81fb1b68d29a640405767749e841527673206aca8448d8263e547d5ff2950e2ed3839e998d31cbc6ac9fd57bc6002b15921620cd1c8dbf6e3acc7a80439bc4962cf25b9dce7c896f3a5bd70803fc5a0e33cf00206edb16d01907b759977d7650dad7e3ec049af1a3d875380b697c862c9ec5d51c201ea6675f9551eeb9dfaaa9247bc9858270d3d3a4c5afa7177a984d5ed1be245120d6acdedf95f608e09fa53fb43dcd0990475726c5131210c9e5caeab97f0e642f20bd74b25aacb92378a871bf27d225cfc26baca344a1ea35fdd94510f3d157082c201b77dac4d24fb7258c3c528704c59430b630718bec486421837021cf75dab65120ec677114c27206f5debc1c1ed66f95e2b1885da5b7be3d736b1de98579473048204777c8776a3b1e69b73a62fa701fa4f7a6282d9aee2c7a6b82e7937d7081c23c20ba49b659fbd0b7334211ea6a9d9df185c757e70aa81da562fb912b84f49bce722043ff5457f13b926b61df552d4e402ee6dc1463f99a535f9a713439264d5b616b207b99abdc3730991cc9274727d7d82d28cb794edbc7034b4f0053ff7c4b68044420d6c639ac24b46bd19341c91b13fdcab31581ddaf7f1411336a271f3d0aa52813208ac9cf9c391e3fd42891d27238a81a8a5c1d3a72b1bcbea8cf44a58ce738961320912d82b2c2bca231f71efcf61737fbf0a08befa0416215aeef53e8bb6d23390a20e110de65c907b9dea4ae0bd83a4b0a51bea175646a64c12b4c9f931b2cb31b4920d8283386ef2ef07ebdbb4383c12a739a953a4d6e0d6fb1139a4036d693bfbb6c20d0420777afdc4151c3f14fbe4c714d82dc15873edb1ca65ebb3887334a4bae1520d9c38484296b3aa8f5e8b59d418a3775e2bb414e75498ad352e4614f05aae5482001000000000000000000000000000000000000000000000000000000000000000600000000000000\"\n }\n ],\n \"shielded_receives\": [\n {\n \"note\": {\n \"value\": 40000000,\n \"payment_address\": \"ztron1wd46s6fwmz99gulqpxul6zffqtevzfpl93ng3s5834fhwf6e7w5l6zmjhmpvtwsc4wxa7dusmvr\",\n \"rcm\": \"ccced07d36641fc93cba33cddda7064cb82f6962a0bdf15a4240a4a742770e03\"\n }\n }\n ]\n}'\n
Parameters: transparent_from_address: Transparent sender's addressfrom_amount: Send amount from transparent addressak: Aknsk: Nskovk: Ovkshielded_receives: Shielded receive informationshieldedSpends: Shielded spend informationtransparent_to_address: Transparent receiver's addressto_amount: Send amount to transparent address
Return: Transaction object
"},{"location":"api/http/#walletscannotebyivk","title":"wallet/scannotebyivk","text":"Description: To get all the notes by ivk
$ curl -X POST http://127.0.0.1:8090/wallet/scannotebyivk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ivk\": \"80a481c3c739e54b4e0608090b3a1a6e9f8dce42346e95bf5a2d8a487bf45c05\"\n}'\n
Parameters:
start_block_index: The start block height, itself includedend_block_index: The end block height, itself not includedivk: Incoming viewing key
Return: Notes list
Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletscanandmarknotebyivk","title":"wallet/scanandmarknotebyivk","text":"Description: To get all the notes with spent status by ivk
$ curl -X POST http://127.0.0.1:8090/wallet/scanandmarknotebyivk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ivk\": \"80a481c3c739e54b4e0608090b3a1a6e9f8dce42346e95bf5a2d8a487bf45c05\",\n \"ak\": \"1d4f9b5551f4aa9443ceb263f0e208eb7e26080264571c5ef06de97a646fe418\",\n \"nk\": \"748522c7571a9da787e43940c9a474aa0c5c39b46c338905deb6726fa3678bdb\"\n}'\n
Parameters:
start_block_index: The start block height, itself includedend_block_index: The end block height, itself not includedivk: Incoming viewing keyak: Ak keynk: Nk key
Return: Notes list
Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletscannotebyovk","title":"wallet/scannotebyovk","text":"Description: To get all the notes by ovk
$ curl -X POST http://127.0.0.1:8090/wallet/scannotebyovk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ovk\": \"705145aa18cbe6c11d5d0011419a98f3d5b1d341eb4727f1315597f4bdaf8539\"\n}'\n
Parameters:
start_block_index: The start block height, itself includedend_block_index: The end block height, itself not includedovk: Outgoing viewing key
Return: Notes list
Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletcreateshieldnullifier","title":"wallet/createshieldnullifier","text":"Description: To create a shielded nullifier
$ curl -X POST http://127.0.0.1:8090/wallet/createshieldnullifier -d\n'{\n \"note\": {\n \"payment_address\": \"ztron1aqgauawtkelxfu2w6s48cwh0mchjt6kwpj44l4wym3pullx0294j4r4v7kpm75wnclzycsw73mq\",\n \"rcm\": \"74a16c1b27ec7fbf06881d9d35ddaab1554838b1bddcd54f6bd8a9fb4ba0b80a\",\n \"value\": 500000000\n },\n \"voucher\": {\n \"tree\": {\n \"left\": {\n \"content\": \"a4d763fae3fee78964ccdf7567ec3062c95a5b97825d731202d3dfa6cb01c143\"\n }\n },\n \"rt\": \"7dc3652c2a16e8518a8be0e3e038f9d28c3eb96f13e8da8acc2a9b650702f33e\"\n },\n \"ak\": \"a3e65d509b675aaa2aeda977ceff11eebd76218079b6f543d78a615e396ca129\",\n \"nk\": \"62cfda9bea09a53cf2a21022057913734a8458969e11e0bb9c59ead48fbce83e\"\n}'\n
Parameters:
note: Note informationvoucher: Voucher informationak: Aknk: Nk
Return: A shielded nullifier
"},{"location":"api/http/#walletgetshieldtransactionhash","title":"wallet/getshieldtransactionhash","text":"Description: To get a shielded transaction hash
curl -X POST http://127.0.0.1:8090/wallet/getshieldtransactionhash -d\n'{\n \"txID\": \"de639a64497d86bb27e34a2953093a0cc488ec4c7bc9624ac5857d3799748595\",\n \"raw_data\": {\n \"contract\": [\n {\n \"parameter\": {\n \"value\": {\n \"binding_signature\": \"2b8ae5e11ecad3e6946f54b7ad513bd8692a3edae72d29e266b28e47c9b37ccdb38e3b6433575694b6681136b1734f85afcfe672061d2ee7368755ad0b96a80b\",\n \"spend_description\": [\n {\n \"value_commitment\": \"cbe1063adbe7e10919421fa6133f03150253913f5aff02d165e2c019cea4a869\",\n \"anchor\": \"fb1115d5ddd16c5427c3a608d6b5add5967e70f51c890307c6142083a2c28565\",\n \"nullifier\": \"93e329d464e1dbddc8bb4d2dcc939a796dfe11e985d4e9033a15edf0e3df4f35\",\n \"rk\": \"10c702d6dff1509502ee5acc0b01d4b4531b2ff53b0dd54488aea6031b5e6d16\",\n \"zkproof\": \"abf64b3beacfd873b1db764c3da9f739993518f3f740e761cb8af60682b7171892895c3ccfb550c3cf757e906dbf5313a3676b8226b0b84960f76a185c8d3fdfc3fa9c08479a704852d7b3dfeb913cf13e01c25657561e00a06c61e7c65b50b812902ddc4f17bfe2bcb2f247c2dc6132d0f0e0abcecc0332fdd99077af10d07bbdb88c4fd257948428e233c57f84eee8b2eeab2162c1aeccf2e1dfaa306d5803a8b2d281a549440fbd5a3657a830c1ca07a384cea446aa077b195b29b23023b1\"\n }\n ],\n \"receive_description\": [\n {\n \"value_commitment\": \"f6d45db8ec5a1c8dbbde040b4ea138efbe8db2d0597ed2306ff3fdd0620b3c5a\",\n \"note_commitment\": \"ec3f5472ac8114a9a07987d1c2a0e1254504e352d9574971e77084293900312e\",\n \"epk\": \"719eeb5ebaeeccc55c9f0d73767aadf0c0513603400ccb50bd789637d984b8e6\",\n \"c_enc\": \"3a6c4fe0e79f5b23fed34a419c4728d0b26bca23180a22871743b0a9444c27663cf07c55a0ea6db504d70421768bf17384e180b2ad8b8be88ff5cf662c53a4ba086effc3a4b1df39265f71dfac884bff5a69e1dcdcae8aecf6ae443168ffab692a5c1e4908b415dd830dcf6432fae1c32461132080da74d6b83d3d00887eb2ce9965a749f8d8410ea4182969371ac2fd5e0e74d27d883492a08e6209cd9959d74bb67c2a9fe7faac5a4777f1bff19cf0b6398a2faa9b194bbb93d60f132f382f7d693a722e8cbca1da084ee7e0c371397419a7259d1fa0943078cfe5ea352e4b53907bb6c04ca8ad409fb0ae0b110a6b312200e21ab79d543ae7aeb16802cf87afdac1e8954038caa42818f4ca2847fd642360c098accfeeade4abd1cc9ca3315a4336be224ba3516973c7dae3f41875457236675993df38d3a544470c4f9335d77b005e6a9aec40fd881b34852ec9bbbcc3d24ee92930eae770a5462ce04c4e37b0524ef07e00e8d58c810d6aefb19fa7bc2c3a2fdfab6dd4fe73dbecc0795a280f9b7ca35cc8bc1062aed8e26bd81ba33c6f4c318974636f6d796723e77772ced3dbc1f42afec6fc9bb61f8beac704affea9baf2e2de226250c1d427c7d78b1eb1d239e1f3eb6af0f017b80541333f4fce17340048d826b9b0be8477c996ad8bfc3440dc686fdff6d0d63986db4d95962d7977289cbfd14c745de7c79d4dc0bcd220e5b4ced5b409e79142e0f336e44ca29a9a87f6f43707d8c4936e895236dd2b393a478a8bc27b1f682496ba84a0ddc549da06cb7855c4d8680dc66ac40240733b7f\",\n \"c_out\": \"50be6e77854d4c427b2af4f16e5275f0b0c206b3ea2d2a24ffb287ea356f323523354cd83d15e7c48e6f1fa103dfca3d49ca2263dbb0cd8bfb35d72cdcad1351de6fba7a30aea27184a68bcda19cc6da\",\n \"zkproof\": \"a4e6c50d5753092d005689922c2bdeafc98775bce59db840974163ace23c13fec18112e32aae1c39842c645ed172ad8fa277e63c1e3d6d7fb12eb15d56b573237b776f562a81d0e6be362d147d8604fdfec421482270ca82950de1883fda06e719f5d256d7a039769bffc570a1778d70c17295d1c0336a6ae0903d2460dc139a9563c2d40f37bffefa73003a55af1ff0861b6f79ef40099b6a0cb25ab3f40727210e4629647d0711abff125712a5f0d64fcb6e6a6b0b34478d7da0552b493a80\"\n }\n ]\n },\n \"type_url\": \"type.googleapis.com/protocol.ShieldedTransferContract\"\n },\n \"type\": \"ShieldedTransferContract\"\n }\n ],\n \"ref_block_bytes\": \"0d59\",\n \"ref_block_hash\": \"7356ce5c35d8265e\",\n \"expiration\": 1559237283000,\n \"timestamp\": 1559201285590\n },\n \"raw_data_hex\": \"0a020d5922087356ce5c35d8265e40b899a3ceb02d5a940b0833128f0b0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e747261637412d50a1acb020a20cbe1063adbe7e10919421fa6133f03150253913f5aff02d165e2c019cea4a8691220fb1115d5ddd16c5427c3a608d6b5add5967e70f51c890307c6142083a2c285651a2093e329d464e1dbddc8bb4d2dcc939a796dfe11e985d4e9033a15edf0e3df4f35222010c702d6dff1509502ee5acc0b01d4b4531b2ff53b0dd54488aea6031b5e6d162ac001abf64b3beacfd873b1db764c3da9f739993518f3f740e761cb8af60682b7171892895c3ccfb550c3cf757e906dbf5313a3676b8226b0b84960f76a185c8d3fdfc3fa9c08479a704852d7b3dfeb913cf13e01c25657561e00a06c61e7c65b50b812902ddc4f17bfe2bcb2f247c2dc6132d0f0e0abcecc0332fdd99077af10d07bbdb88c4fd257948428e233c57f84eee8b2eeab2162c1aeccf2e1dfaa306d5803a8b2d281a549440fbd5a3657a830c1ca07a384cea446aa077b195b29b23023b122c2070a20f6d45db8ec5a1c8dbbde040b4ea138efbe8db2d0597ed2306ff3fdd0620b3c5a1220ec3f5472ac8114a9a07987d1c2a0e1254504e352d9574971e77084293900312e1a20719eeb5ebaeeccc55c9f0d73767aadf0c0513603400ccb50bd789637d984b8e622c4043a6c4fe0e79f5b23fed34a419c4728d0b26bca23180a22871743b0a9444c27663cf07c55a0ea6db504d70421768bf17384e180b2ad8b8be88ff5cf662c53a4ba086effc3a4b1df39265f71dfac884bff5a69e1dcdcae8aecf6ae443168ffab692a5c1e4908b415dd830dcf6432fae1c32461132080da74d6b83d3d00887eb2ce9965a749f8d8410ea4182969371ac2fd5e0e74d27d883492a08e6209cd9959d74bb67c2a9fe7faac5a4777f1bff19cf0b6398a2faa9b194bbb93d60f132f382f7d693a722e8cbca1da084ee7e0c371397419a7259d1fa0943078cfe5ea352e4b53907bb6c04ca8ad409fb0ae0b110a6b312200e21ab79d543ae7aeb16802cf87afdac1e8954038caa42818f4ca2847fd642360c098accfeeade4abd1cc9ca3315a4336be224ba3516973c7dae3f41875457236675993df38d3a544470c4f9335d77b005e6a9aec40fd881b34852ec9bbbcc3d24ee92930eae770a5462ce04c4e37b0524ef07e00e8d58c810d6aefb19fa7bc2c3a2fdfab6dd4fe73dbecc0795a280f9b7ca35cc8bc1062aed8e26bd81ba33c6f4c318974636f6d796723e77772ced3dbc1f42afec6fc9bb61f8beac704affea9baf2e2de226250c1d427c7d78b1eb1d239e1f3eb6af0f017b80541333f4fce17340048d826b9b0be8477c996ad8bfc3440dc686fdff6d0d63986db4d95962d7977289cbfd14c745de7c79d4dc0bcd220e5b4ced5b409e79142e0f336e44ca29a9a87f6f43707d8c4936e895236dd2b393a478a8bc27b1f682496ba84a0ddc549da06cb7855c4d8680dc66ac40240733b7f2a5050be6e77854d4c427b2af4f16e5275f0b0c206b3ea2d2a24ffb287ea356f323523354cd83d15e7c48e6f1fa103dfca3d49ca2263dbb0cd8bfb35d72cdcad1351de6fba7a30aea27184a68bcda19cc6da32c001a4e6c50d5753092d005689922c2bdeafc98775bce59db840974163ace23c13fec18112e32aae1c39842c645ed172ad8fa277e63c1e3d6d7fb12eb15d56b573237b776f562a81d0e6be362d147d8604fdfec421482270ca82950de1883fda06e719f5d256d7a039769bffc570a1778d70c17295d1c0336a6ae0903d2460dc139a9563c2d40f37bffefa73003a55af1ff0861b6f79ef40099b6a0cb25ab3f40727210e4629647d0711abff125712a5f0d64fcb6e6a6b0b34478d7da0552b493a802a402b8ae5e11ecad3e6946f54b7ad513bd8692a3edae72d29e266b28e47c9b37ccdb38e3b6433575694b6681136b1734f85afcfe672061d2ee7368755ad0b96a80b70d68b8ebdb02d\"\n}'\n
Parameter transaction: Transaction object
Return: a shielded transaction hash
"},{"location":"api/http/#walletcreateshieldedtransaction","title":"wallet/createshieldedtransaction","text":"Description: To create shielded transaction Please refer to The Demo
Parameters:
transparent_from_address: Transparent sender's addressfrom_amount: Send amount from transparent addressask: Asknsk: Nskovk: Ovkshielded_receives: Shielded receive informationshieldedSpends: Shielded spend informationtransparent_to_address: Transparent receiver's addressto_amount: Send amount to transparent address
Return: Transaction object
"},{"location":"api/http/#walletgetnewshieldedaddress","title":"wallet/getnewshieldedaddress","text":"Description: To get new shieldedAddress
curl -X GET http://127.0.0.1:8090/wallet/getnewshieldedaddress\n
Parameters: N/A Return: Spending key Ask key Nsk key Outgoing viewing key Ak Key Nk key incoming viewing key Diversifier pkD payment address"},{"location":"api/http/#walletcreateshieldedcontractparameters","title":"wallet/createshieldedcontractparameters","text":"Description: create the shielded TRC-20 transaction parameters, which has three types: mint, transfer and burn
demo: curl -X POST http://127.0.0.1:8090/wallet/createshieldedcontractparameters -d\n'{ \n \"ask\": \"0f63eabdfe2bbfe08012f6bb2db024e6809c16e8ed055aa41a6095424f192005\",\n \"nsk\": \"cd43d722fd4b6b01f19449ea826c3e935609648520fcc2a95c0026f0fa9ee404\",\n \"ovk\": \"1797de3b7f33cafffe3fe18c6b43ec6760add2ad81b10978d1fca5290497ede9\",\n \"from_amount\": \"5000\",\n \"shielded_receives\": {\n \"note\": {\n \"value\": 50,\n \"payment_address\": \"ztron15js0jkuxczt8caq5hp59rnh6rgf34sek7vqn9u6ljelxv4nuzz2x9qe3ffm2wzz6ck53yxyhxs6\",\n \"rcm\": \"74baec30dfac8ed59968955ff245ae002009005194e5b824c35ab88c52e5170e\"\n }\n },\n \"shielded_TRC20_contract_address\": \"41f3392eaa7d38749176e0671dbc6912f8ef956943\"\n }'\n
Parameters:
ask: Asknsk: Nskovk: Outgoing view keyfrom_amount: the amount for mint, which is scaled by scalingfactor with note value, namely from_amount = value * scalingFactor. In the above example, the value of scalingFactor is 100shielded_receives: the shielded notes to be createdshielded_TRC20_contract_address: shielded TRC-20 contract address
Return: the shielded TRC-20 transaction parameters
Note: the input parameters will differ according to the variety of shielded TRC-20 transaction type
"},{"location":"api/http/#walletcreateshieldedcontractparameterswithoutask","title":"wallet/createshieldedcontractparameterswithoutask","text":"Description: create the shielded TRC-20 transaction parameters without Ask, which has three types: mint, transfer and burn
demo: curl -X POST http://127.0.0.1:8090/wallet/createshieldedcontractparameterswithoutask -d\n'{\n \"ovk\": \"cd361834b3adc06f130de24f7d0c18f92a093cc885d9ce492cc6c02071f7a4f0\",\n \"from_amount\": \"5000\",\n \"shielded_receives\": {\n \"note\": {\n \"value\": 50,\n \"payment_address\": \"ztron13lvfnt4rau4ad9mmgztd3aftw49e3amz8gm2kvyzrsaw0ugz2grxwkvcfys5e2gkchj7cnnetjz\",\n \"rcm\": \"499e73f2f8aaf05fac41a35b8343bde27f6629cbe66d35da5364a99b94a55a06\"\n }\n },\n \"shielded_TRC20_contract_address\": \"41f3392eaa7d38749176e0671dbc6912f8ef956943\"\n }'\n
Parameters:
ovk: Outgoing view keyfrom_amount: the amount for mint, which is scaled by scalingfactor with note value, namely from_amount = value * scalingFactor. In the above example, the value of scalingFactor is 100shielded_receives: the shielded notes to be createdshielded_TRC20_contract_address: shielded TRC-20 contract address
Return: the shielded TRC-20 transaction parameters
Note: the input parameters will differ according to the variety of shielded TRC-20 transaction type
"},{"location":"api/http/#walletscanshieldedtrc20notesbyivk","title":"wallet/scanshieldedtrc20notesbyivk","text":"Description: scan the shielded TRC-20 notes by ivk and mark their status of whether spent
demo: curl -X POST http://127.0.0.1:8090/wallet/scanshieldedtrc20notesbyivk -d\n'{\n \"start_block_index\": 9200,\n \"end_block_index\": 9240,\n \"shielded_TRC20_contract_address\": \"41274fc7464fadac5c00c893c58bce6c39bf59e4c7\",\n \"ivk\": \"9f8e74bb3d7188a2781dc1db38810c6914eef4570a79e8ec8404480948e4e305\",\n \"ak\":\"8072d9110c9de9d9ade33d5d0f5890a7aa65b0cde42af7816d187297caf2fd64\",\n \"nk\":\"590bf33f93f792be659fd404df91e75c3b08d38d4e08ee226c3f5219cf598f14\"\n}'\n
Parameters:
start_block_index: the start block index, inclusiveend_block_index: the end block index, exclusiveshielded_TRC20_contract_address: shielded TRC-20 contract addressivk: Incoming viewing keyak: Ak keynk: Nk key
Return: notes list
Note: block limit\uff08end_block_index - start_block_index <= 1000\uff09
"},{"location":"api/http/#walletscanshieldedtrc20notesbyovk","title":"wallet/scanshieldedtrc20notesbyovk","text":"Description: scan the shielded TRC-20 notes by ovk
demo: curl -X POST http://127.0.0.1:8090/wallet/scanshieldedtrc20notesbyovk -d\n'{\n \"start_block_index\": 9200,\n \"end_block_index\": 9240,\n \"shielded_TRC20_contract_address\": \"41274fc7464fadac5c00c893c58bce6c39bf59e4c7\",\n \"ovk\": \"0ff58efd75e083fe4fd759c8701e1c8cb6961c4297a12b2c800bdb7b2bcab889\"\n}'\n
Parameters:
start_block_index: start block index, inclusiveend_block_index: end block index, exclusiveshielded_TRC20_contract_address: shielded TRC-20 contract addressovk: Outgoing viewing key
Return: notes list
Note: block limit\uff08end_block_index - start_block_index <= 1000\uff09
"},{"location":"api/http/#walletisshieldedtrc20contractnotespent","title":"wallet/isshieldedtrc20contractnotespent","text":"Description: check the status whether the specified shielded TRC-20 note is spent
Parameters:
note: the specified noteak: Aknk: Nkposition: the leaf position index of note commitment in the Merkle treeshielded_TRC20_contract_address: the shielded TRC-20 contract address
Return: note status
Note: the value in note is the scaled value by scalingFactor set in the shielded TRC-20 contract, namely real_amount = value * scalingFactor.
"},{"location":"api/http/#walletgettriggerinputforshieldedtrc20contract","title":"wallet/gettriggerinputforshieldedtrc20contract","text":"Description: get the trigger input data of shielded TRC-20 contract for the shielded TRC-20 parameters without spend authority signature.
demo: curl -X POST http://127.0.0.1:8090/wallet/gettriggerinputforshieldedtrc20contract -d\n'{ \n \"shielded_TRC20_Parameters\": {\"spend_description\": [{\"value_commitment\": \"e3fcc8609ff6a4b00b77a00ef624f305cec5f55cc7312ff5526d0b3057f2ef9e\",\"anchor\": \"4c9cbebece033dc1d253b93e4a3682187daae4f905515761d10287b801e69816\",\"nullifier\": \"74edce8798a3976ee41e045bb666f3a121c27235b0f1b44b3456d2c84bc725dc\",\"rk\": \"9dcf4254aa7c4fb7c8bc6956d4b0c7c6c87c37a2552e7bf4e60c12cb5bc6c8cd\",\"zkproof\": \"9926045cd1442a7d20153e6abda9f77a6526895f0a29a57cb1bc76ef6b7cacef2d0f4c94aa97c3acacdb95cabb065057b7edb4cbea098149a8aa7114a6a6b340c58007ac64b64e592eb18fdd299de5962a2a32ab0caebb2ab198704c751a9d0e143d68a50257d7c9e2230a7420fa46450299fd167141367e201726532d8e815413d8571d6c8c12937674dec92caf1f4583ebe560ac4c7eba290deee0a1c0da5f72c0b9df89fb3b338c683b654b3dc2373a4c2a4fef7f4fa489b44405fb7d2bfb\"}],\"binding_signature\": \"11e949887d9ec92eb32c78f0bc48afdc9a16a2ecbd5a0eca1be070fb900eeda347918bd6e9521d4baf1f74963bee0c1956559623a9e7cbc886941b227341ea06\",\"message_hash\": \"7e6a00736c4f9e0036cb74c7fa3b1e3cd8f6bf0f038edeb03b668c4c5536a357\",\"parameter_type\": \"burn\"},\n \"spend_authority_signature\": [\n {\n \"value\": \"eeaaecd725ac80ec398b95cf188b769c1be66cc8e76e6c90843b7f23818704595719ce8bf694ffb8cd7aaa8739d50fe8eea7ba39d5026c4b019c973185ca7201\"\n }\n ],\n \"amount\": \"6000\",\n \"transparent_to_address\": \"4140cd765f8e637a2bbe00f9bc458f6b21eb0e648f\"\n }'\n
Parameters:
shielded_TRC20_Parameters: the generated shielded TRC-20 parametersspend_authority_signature: the spend authority signaturesamount: the amount transparent_to_address: the receiver for the burn operation.
Return: the input data for triggering shielded TRC-20 contract.
"},{"location":"api/http/#walletgetrcm","title":"wallet/getrcm","text":"Description: To get a random commitment trapdoor
curl -X GET http://127.0.0.1:8090/wallet/getrcm\n
Parameters: N/A Return:rcm
"},{"location":"api/http/#walletgetmerkletreevoucherinfo","title":"wallet/getmerkletreevoucherinfo","text":"Description: To get a merkle tree information of a note
$ curl -X POST http://127.0.0.1:8090/wallet/getmerkletreevoucherinfo -d\n'{\n \"out_points\":[{\n \"hash\":\"185b3e085723f5862b3a3c3cf54d52f5c1eaf2541e3a1e0ecd08bc12cd958d74\",\n \"index\":0\n }]\n}'\n
Parameter out_points: Note information
Return: A merkle tree of a note
"},{"location":"api/http/#walletisspend","title":"wallet/isspend","text":"Description: To check whether a note is spent or not
$ curl -X POST http://127.0.0.1:8090/wallet/isspend -d\n'{\n \"ak\": \"a3e65d509b675aaa2aeda977ceff11eebd76218079b6f543d78a615e396ca129\",\n \"nk\": \"62cfda9bea09a53cf2a21022057913734a8458969e11e0bb9c59ead48fbce83e\",\n \"note\": {\n \"payment_address\": \"ztron1aqgauawtkelxfu2w6s48cwh0mchjt6kwpj44l4wym3pullx0294j4r4v7kpm75wnclzycsw73mq\",\n \"rcm\": \"74a16c1b27ec7fbf06881d9d35ddaab1554838b1bddcd54f6bd8a9fb4ba0b80a\",\n \"value\": 500000000\n },\n \"txid\": \"7d09e471bb047d3ac044d5d6691b3721a2dddbb683ac02c207fbe78af6302463\",\n \"index\": 1\n}'\n
Parameters:
ak: Ak keynk: Nk keynote: Note informationtxid: Transaction idindex: Note index
Return: Note status
"},{"location":"api/http/#walletcreatespendauthsig","title":"wallet/createspendauthsig","text":"Description: To create a signature for a transaction
$ curl -X POST http://127.0.0.1:8090/wallet/createspendauthsig -d\n'{\n \"ask\": \"e3ebcba1531f6d9158d9c162660c5d7c04dadf77d85d7436a9c98b291ff69a09\",\n \"tx_hash\": \"3b78fee6e956f915ffe082284c5f18640edca9c57a5f227e5f7d7eb65ad61502\",\n \"alpha\": \"2608999c3a97d005a879ecdaa16fd29ae434fb67b177c5e875b0c829e6a1db04\"\n}'\n
Parameters:
ask: Ask keytx_hash: Transaction hashalpha: Alpha
Return: A signature
"},{"location":"api/http/#pending-pool","title":"Pending Pool","text":"The following are Pending Pool related APIs:
- wallet/gettransactionfrompending
- wallet/gettransactionlistfrompending
- wallet/getpendingsize
"},{"location":"api/http/#walletgettransactionfrompending","title":"wallet/gettransactionfrompending","text":"Get transaction details from the pending pool
curl -X POST http://127.0.0.1:8090/wallet/gettransactionfrompending -d\n'{\n \"value\": \"txId\"\n}'\n
Parameters: value: transaction id Return: Transaction details
"},{"location":"api/http/#walletgettransactionlistfrompending","title":"wallet/gettransactionlistfrompending","text":"Get transaction list information from pending pool
curl -X get http://127.0.0.1:8090/wallet/gettransactionlistfrompending\n
Parameters: N/A Return: Pending transaction IDs in the pool
"},{"location":"api/http/#walletgetpendingsize","title":"wallet/getpendingsize","text":"Get the size of the pending pool queue
curl -X get http://127.0.0.1:8090/wallet/getpendingsize\n
Parameters: N/A Return:pending pool size
"},{"location":"api/http/#fullnode-solidity-http-api","title":"FullNode Solidity HTTP API","text":""},{"location":"api/http/#account-resources_1","title":"Account Resources","text":""},{"location":"api/http/#walletsoliditygetaccount","title":"walletsolidity/getaccount","text":"Description: Query an account information
curl -X POST http://127.0.0.1:8091/walletsolidity/getaccount -d '{\"address\": \"41E552F6487585C2B58BC2C9BB4492BC1F17132CD0\"}'\n
Parameters: address - Account to query, default hexString Return: Account object
"},{"location":"api/http/#walletsoliditygetdelegatedresource","title":"walletsolidity/getdelegatedresource","text":"Description: Query the energy delegation information
curl -X POST http://127.0.0.1:8091/walletsolidity/getdelegatedresource -d '\n{\n\"fromAddress\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n\"toAddress\": \"41c6600433381c731f22fc2b9f864b14fe518b322f\"\n}'\n
Parameters: fromAddress: Energy from address, default hexStringtoAddress: Energy to address, default hexString
Return: Energy delegation information list, the elements of the list is DelegatedResource
"},{"location":"api/http/#walletsoliditygetdelegatedresourceaccountindex","title":"walletsolidity/getdelegatedresourceaccountindex","text":"Description: Query the energy delegation index by an account
curl -X POST http://127.0.0.1:8091/walletsolidity/getdelegatedresourceaccountindex -d '\n{\n\"value\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n}'\n
Parameters: value: Address, default hexString
Return: DelegatedResourceAccountIndex of the address
"},{"location":"api/http/#walletsoliditygetaccountbyid","title":"walletsolidity/getaccountbyid","text":"Description: Query an account information by account id
curl -X POST http://127.0.0.1:8091/walletsolidity/getaccountbyid -d '{\"account_id\":\"6161616162626262\"}'\n
Parameters: account_id - Account id, default hexString Return: Account object
"},{"location":"api/http/#walletsoliditygetavailableunfreezecount","title":"walletsolidity/getavailableunfreezecount","text":"Description:Remaining times of executing unstake operation in Stake2.0
curl -X POST http://127.0.0.1:8090/walletsolidity/getavailableunfreezecount -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account address
Return:Remaining times of available unstaking.
"},{"location":"api/http/#walletsoliditygetcanwithdrawunfreezeamount","title":"walletsolidity/getcanwithdrawunfreezeamount","text":"Description: Query the withdrawable balance at the specified timestamp In Stake2.0
curl -X POST http://127.0.0.1:8090/walletsolidity/getcanwithdrawunfreezeamount -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"timestamp\": 1667977444000,\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account addresstimestamp: query cutoff timestamp, in milliseconds.
Return: Withdrawable balance, unit is sun.
"},{"location":"api/http/#walletsoliditygetcandelegatedmaxsize","title":"walletsolidity/getcandelegatedmaxsize","text":"Description: In Stake2.0, query the amount of delegatable resources share of the specified resource type for an address, unit is sun.
curl -X POST http://127.0.0.1:8090/walletsolidity/getcandelegatedmaxsize -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"type\": 0,\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account addresstype: Resource type, 0 is bandwidth, 1 is energy
Return: The amount of delegatable resource share, unit is sun.
"},{"location":"api/http/#walletsoliditygetdelegatedresourcev2","title":"walletsolidity/getdelegatedresourcev2","text":"In Stake2.0, query the detail of resource share delegated from fromAddress to toAddress
curl -X POST http://127.0.0.1:8090/walletsolidity/getdelegatedresourcev2 -d\n'{\n \"fromAddress\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"toAddress\": \"TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1\",\n \"visible\": true\n}\n'\n
Parameters:
fromAddress: resource from address, default hexStringtoAddress: resource to address
Return: Resource delegation list
"},{"location":"api/http/#walletsoliditygetdelegatedresourceaccountindexv2","title":"walletsolidity/getdelegatedresourceaccountindexv2","text":"In Stake2.0, query the resource delegation index by an account. Two lists will return, one is the list of addresses the account has delegated its resources(toAddress), and the other is the list of addresses that have delegated resources to the account(fromAddress).
curl -X POST http://127.0.0.1:8090/walletsolidity/getdelegatedresourceaccountindexv2 -d\n'{\n \"value\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"visible\": true\n}\n'\n
Parameters:
value: account address
Return: Two lists will return, one is the list of addresses the account has delegated its resources(toAddress), and the other is the list of addresses that have delegated resources to the account(fromAddress).
"},{"location":"api/http/#voting-srs","title":"Voting & SRs","text":""},{"location":"api/http/#walletsoliditylistwitnesses","title":"walletsolidity/listwitnesses","text":"Description: Query the list of super representatives
curl -X POST http://127.0.0.1:8091/walletsolidity/listwitnesses\n
Parameters: N/A Return: List of all super representatives
"},{"location":"api/http/#trc10-token_1","title":"TRC10 Token","text":""},{"location":"api/http/#walletsoliditygetassetissuelist","title":"walletsolidity/getassetissuelist","text":"Description: Query the list of all tokens
curl -X POST http://127.0.0.1:8091/walletsolidity/getassetissuelist\n
Parameters: N/A Return: The list of all tokens
"},{"location":"api/http/#walletsoliditygetpaginatedassetissuelist","title":"walletsolidity/getpaginatedassetissuelist","text":"Description: Query the list of all the tokens by pagination
curl -X POST http://127.0.0.1:8091/walletsolidity/getpaginatedassetissuelist -d '{\"offset\": 0, \"limit\":10}'\n
Parameters: - offset: The index of the start token - limit: The amount of tokens per page Return: List of tokens
"},{"location":"api/http/#walletsoliditygetassetissuebyname","title":"walletsolidity/getassetissuebyname","text":"Description: Query a token by token name
curl -X POST http://127.0.0.1:8091/walletsolidity/getassetissuebyname -d '{\"value\": \"44756354616E\"}'\n
Parameters: value - Token name, default hexString Return: Token object Note: Since Odyssey-v3.2, getassetissuebyid or getassetissuelistbyname is recommended, as since v3.2, token name can be repeatable. If the token name you query is not unique, this api will throw out an error.
"},{"location":"api/http/#walletsoliditygetassetissuelistbyname","title":"walletsolidity/getassetissuelistbyname","text":"Description: Query the token list by name
curl -X POST http://127.0.0.1:8091/walletsolidity/getassetissuelistbyname -d '{\"value\": \"44756354616E\"}'\n
Parameters: value - Token name, default hexString Return: Token list
"},{"location":"api/http/#walletsoliditygetassetissuebyid","title":"walletsolidity/getassetissuebyid","text":"Description: Query a token by token id
curl -X POST http://127.0.0.1:8091/walletsolidity/getassetissuebyid -d '{\"value\": \"1000001\"}'\n
Parameters: value - Token id Return: Token object
"},{"location":"api/http/#blocks","title":"Blocks","text":""},{"location":"api/http/#walletsoliditygetnowblock","title":"walletsolidity/getnowblock","text":"Description: Query the latest block information
curl -X POST http://127.0.0.1:8091/walletsolidity/getnowblock\n
Parameters: N/A Return: The latest block from solidityNode
"},{"location":"api/http/#walletsoliditygetblockbynum","title":"walletsolidity/getblockbynum","text":"Description: Query a block information by block height
curl -X POST http://127.0.0.1:8091/walletsolidity/getblockbynum -d '{\"num\" : 100}'\n
Parameters: num - Block height Return: Block information
"},{"location":"api/http/#walletsoliditygetblockbyid","title":"walletsolidity/getblockbyid","text":"Description: Query a block information by block id
curl -X POST http://127.0.0.1:8091/walletsolidity/getblockbyid-d '{\"value\":\n\"0000000000038809c59ee8409a3b6c051e369ef1096603c7ee723c16e2376c73\"}'\n
Parameters: value - Block id Return: The block object
"},{"location":"api/http/#walletsoliditygetblockbylimitnext","title":"walletsolidity/getblockbylimitnext","text":"Description: Query a list of blocks by range
curl -X POST http://127.0.0.1:8091/walletsolidity/getblockbylimitnext -d '{\"startNum\": 1, \"endNum\": 2}'\n
Parameters: startNum: The start block height, inclusiveendNum: The end block height, exclusive
Return: List of blocks
"},{"location":"api/http/#walletsoliditygetblockbylatestnum","title":"walletsolidity/getblockbylatestnum","text":"Description: Query the latest few blocks
curl -X POST http://127.0.0.1:8091/walletsolidity/getblockbylatestnum -d '{\"num\": 5}'\n
Parameters: num - The number of blocks expected to return Return: List of blocks
"},{"location":"api/http/#walletgetnodeinfo_1","title":"wallet/getnodeinfo","text":"Description: Query the current node information
curl -X GET http://127.0.0.1:8091/wallet/getnodeinfo\n
Parameters: N/A Return: NodeInfo of the current node
"},{"location":"api/http/#transactions","title":"Transactions","text":""},{"location":"api/http/#walletsoliditygettransactionbyid","title":"walletsolidity/gettransactionbyid","text":"Description: Query an transaction information by transaction id
curl -X POST http://127.0.0.1:8091/walletsolidity/gettransactionbyid -d '{\"value\" : \"309b6fa3d01353e46f57dd8a8f27611f98e392b50d035cef213f2c55225a8bd2\"}'\n
Parameters: value - Transaction id Return: Transaction information
"},{"location":"api/http/#walletsoliditygettransactioncountbyblocknum","title":"walletsolidity/gettransactioncountbyblocknum","text":"Description: Query th the number of transactions in a specific block
curl -X POST http://127.0.0.1:8091/walletsolidity/gettransactioncountbyblocknum -d '{\"num\" : 100}'\n
Parameters: num - Block height Return: The number of transactions
"},{"location":"api/http/#walletsoliditygettransactioninfobyid","title":"walletsolidity/gettransactioninfobyid","text":"Description: Query the transaction fee, block height by transaction id
curl -X POST http://127.0.0.1:8091/walletsolidity/gettransactioninfobyid -d '{\"value\" : \"309b6fa3d01353e46f57dd8a8f27611f98e392b50d035cef213f2c55225a8bd2\"}'\n
Parameters: value - Transaction id Return: Transaction fee, block height and the time of creation
"},{"location":"api/http/#walletsoliditygettransactioninfobyblocknum","title":"walletsolidity/gettransactioninfobyblocknum","text":"Description: Query the list of transaction information in a specific block
curl -X POST http://127.0.0.1:8091/walletsolidity/gettransactioninfobyblocknum -d '{\"num\" : 100}'\n
Parameters: num - Block height Return: The list of transaction information inside the queried block
"},{"location":"api/http/#dex-exchanges","title":"DEX Exchanges","text":""},{"location":"api/http/#walletsoliditygetexchangebyid","title":"walletsolidity/getexchangebyid","text":"Description: Query an exchange pair by exchange pair id
curl -X POST http://127.0.0.1:8091/walletsolidity/getexchangebyid -d {\"id\":1}\n
Parameters: - id: Exchange pair id
Return: Exchange pair information
"},{"location":"api/http/#walletsoliditylistexchanges","title":"walletsolidity/listexchanges","text":"Description: Query the list of all the exchange pairs
curl -X POST http://127.0.0.1:8091/walletsolidity/listexchanges\n
Parameters: N/A Return: The list of all the exchange pairs
"},{"location":"api/http/#tronz-shielded-smart-contract_1","title":"TRONZ Shielded Smart Contract","text":""},{"location":"api/http/#walletsoliditygetmerkletreevoucherinfo","title":"walletsolidity/getmerkletreevoucherinfo","text":"Description: Get the Merkle tree information of a note
curl -X POST http://127.0.0.1:8090/walletsolidity/getmerkletreevoucherinfo -d\n'{\n \"out_points\":[{\n \"hash\":\"185b3e085723f5862b3a3c3cf54d52f5c1eaf2541e3a1e0ecd08bc12cd958d74\",\n \"index\":0\n }]\n}'\n
Parameters: out_points: Note information
Return: Merkle tree information of a note
"},{"location":"api/http/#walletsolidityscannotebyivk","title":"walletsolidity/scannotebyivk","text":"Description: Get all notes related to ivk
curl -X POST http://127.0.0.1:8090/walletsolidity/scannotebyivk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ivk\": \"80a481c3c739e54b4e0608090b3a1a6e9f8dce42346e95bf5a2d8a487bf45c05\"\n}'\n
Parameters: start_block_index: The start block height, inclusiveend_block_index: The end block height, exclusiveivk: Incoming viewing key
Return: Notes list Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletsolidityscanandmarknotebyivk","title":"walletsolidity/scanandmarknotebyivk","text":"Description: Get all notes with spent status related to ivk
curl -X POST http://127.0.0.1:8090/walletsolidity/scanandmarknotebyivk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ivk\": \"80a481c3c739e54b4e0608090b3a1a6e9f8dce42346e95bf5a2d8a487bf45c05\",\n \"ak\": \"1d4f9b5551f4aa9443ceb263f0e208eb7e26080264571c5ef06de97a646fe418\",\n \"nk\": \"748522c7571a9da787e43940c9a474aa0c5c39b46c338905deb6726fa3678bdb\"\n}'\n
Parameters: start_block_index: The start block height, inclusiveend_block_index: The end block height, exclusiveivk: Incoming viewing keyak: Ak keynk: Nk key
Return: Notes list Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletsolidityscannotebyovk","title":"walletsolidity/scannotebyovk","text":"Description: Query all notes related to ovk
curl -X POST http://127.0.0.1:8090/walletsolidity/scannotebyovk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ovk\": \"705145aa18cbe6c11d5d0011419a98f3d5b1d341eb4727f1315597f4bdaf8539\"\n}'\n
Parameters: start_block_index: The start block height, inclusiveend_block_index: The end block height, exclusiveovk: Outgoing viewing key
Return: Notes list Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletsolidityisspend","title":"walletsolidity/isspend","text":"Description: Check whether a note has been spent
curl -X POST http://127.0.0.1:8090/walletsolidity/isspend -d\n'{\n \"ak\": \"a3e65d509b675aaa2aeda977ceff11eebd76218079b6f543d78a615e396ca129\",\n \"nk\": \"62cfda9bea09a53cf2a21022057913734a8458969e11e0bb9c59ead48fbce83e\",\n \"note\": {\n \"payment_address\": \"ztron1aqgauawtkelxfu2w6s48cwh0mchjt6kwpj44l4wym3pullx0294j4r4v7kpm75wnclzycsw73mq\",\n \"rcm\": \"74a16c1b27ec7fbf06881d9d35ddaab1554838b1bddcd54f6bd8a9fb4ba0b80a\",\n \"value\": 500000000\n },\n \"txid\": \"7d09e471bb047d3ac044d5d6691b3721a2dddbb683ac02c207fbe78af6302463\",\n \"index\": 1\n}'\n
Parameters: ak: Aknk: Nknote: Note informationtxid: Transaction idindex: Note index
Return: Whether a note has been spent
"},{"location":"api/http/#walletsolidityscanshieldedtrc20notesbyivk","title":"walletsolidity/scanshieldedtrc20notesbyivk","text":"Description: Scan the shielded TRC-20 notes by ivk, and mark whether it has been spent
curl -X POST http://127.0.0.1:8091/walletsolidity/scanshieldedtrc20notesbyivk -d\n'{\n \"start_block_index\": 9200,\n \"end_block_index\": 9240,\n \"shielded_TRC20_contract_address\": \"41274fc7464fadac5c00c893c58bce6c39bf59e4c7\",\n \"ivk\": \"9f8e74bb3d7188a2781dc1db38810c6914eef4570a79e8ec8404480948e4e305\",\n \"ak\":\"8072d9110c9de9d9ade33d5d0f5890a7aa65b0cde42af7816d187297caf2fd64\",\n \"nk\":\"590bf33f93f792be659fd404df91e75c3b08d38d4e08ee226c3f5219cf598f14\"\n}'\n
Parameters: start_block_index: The start block index, inclusiveend_block_index: The end block index, exclusiveshielded_TRC20_contract_address: Shielded TRC-20 contract addressivk: Incoming viewing keyak: Ak keynk: Nk key
Return: Notes list Note: Block limit\uff08end_block_index - start_block_index <= 1000\uff09
"},{"location":"api/http/#walletsolidityscanshieldedtrc20notesbyovk","title":"walletsolidity/scanshieldedtrc20notesbyovk","text":"Description: Scan the shielded TRC-20 notes by ovk
curl -X POST http://127.0.0.1:8091/walletsolidity/scanshieldedtrc20notesbyovk -d\n'{\n \"start_block_index\": 9200,\n \"end_block_index\": 9240,\n \"shielded_TRC20_contract_address\": \"41274fc7464fadac5c00c893c58bce6c39bf59e4c7\",\n \"ovk\": \"0ff58efd75e083fe4fd759c8701e1c8cb6961c4297a12b2c800bdb7b2bcab889\"\n}'\n
Parameters: start_block_index: Start block index, inclusiveend_block_index: Start block index, inclusiveshielded_TRC20_contract_address: Shielded TRC-20 contract addressovk: Outgoing viewing key
Return: Notes list
Note: Block limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletsolidityisshieldedtrc20contractnotespent","title":"walletsolidity/isshieldedtrc20contractnotespent","text":"Description: Check the status whether the specified shielded TRC-20 note is spent
curl -X POST http://127.0.0.1:8091/walletsolidity/scanshieldedtrc20notesbyovk -d\n'{\n \"note\": {\n \"value\": 40,\n \"payment_address\":\"ztron1768kf7dy4qquefp46szk978d65eeua66yhr4zv260c0uzj68t3tfjl3en9lhyyfxalv4jus30xs\",\n \"rcm\": \"296070782a94c6936b0b4f6daf8d7c7605a4374fe595b96148dc0f4b59015d0d\"\n },\n \"ak\": \"8072d9110c9de9d9ade33d5d0f5890a7aa65b0cde42af7816d187297caf2fd64\",\n \"nk\": \"590bf33f93f792be659fd404df91e75c3b08d38d4e08ee226c3f5219cf598f14\",\n \"position\": 272,\n \"shielded_TRC20_contract_address\": \"41274fc7464fadac5c00c893c58bce6c39bf59e4c7\"\n}'\n
Parameters: note: The specified noteak: Aknk: Nkposition: The leaf position index of note commitment in the Merkle treeshielded_TRC20_contract_address: The shielded TRC-20 contract address
Return: Note status
Note: The value in note is the scaled value by scalingFactor set in the shielded TRC-20 contract, namely real_amount = value * scalingFactor.
"},{"location":"api/json-rpc/","title":"jsonRPC API","text":""},{"location":"api/json-rpc/#overview","title":"Overview","text":"JSON-RPC is a stateless, lightweight remote procedure call (RPC) protocol. The JSON-RPC interface supported by the TRON network is compatible with Ethereum's. However, due to the difference in chain mechanism and design, TRON cannot support some interfaces on Ethereum. At the same time, TRON also provides dedicated APIs to create different types of transactions.
Please pay attention
- The JSON-RPC service needs to be enabled and set the port in the node configuration file. If not configured, the service is disable by default.
"},{"location":"api/json-rpc/#how-to-enable-or-disable-json-rpc-service-of-a-node","title":"How to enable or disable JSON-RPC service of a node","text":"Add below items in node's configuration file, then enable or disable it:
node.jsonrpc { \n httpFullNodeEnable = true \n httpFullNodePort = 50545 \n httpSolidityEnable = true \n httpSolidityPort = 50555 \n}\n
"},{"location":"api/json-rpc/#hex-value-encoding","title":"HEX value encoding","text":"At present there are two key data types that are passed over JSON: unformatted byte arrays and quantities. Both are passed with a hex encoding, however with different requirements to formatting:
When encoding QUANTITIES (integers, numbers): encode as hex, prefix with \u201c0x\u201d, the most compact representation (slight exception: zero should be represented as \u201c0x0\u201d). Examples:
- 0x41 (65 in decimal)
- 0x400 (1024 in decimal)
- WRONG: 0x (should always have at least one digit - zero is \u201c0x0\u201d)
- WRONG: 0x0400 (no leading zeros allowed)
- WRONG: ff (must be prefixed 0x)
When encoding UNFORMATTED DATA (byte arrays, account addresses, hashes, bytecode arrays): encode as hex, prefix with \u201c0x\u201d, two hex digits per byte. Examples:
- 0x41 (size 1, \u201cA\u201d)
- 0x004200 (size 3, \u201c\\0B\\0\u201d)
- 0x (size 0, \u201c\u201d)
- WRONG: 0xf0f0f (must be even number of digits)
- WRONG: 004200 (must be prefixed 0x)
"},{"location":"api/json-rpc/#eth","title":"eth","text":""},{"location":"api/json-rpc/#eth_accounts","title":"eth_accounts","text":"Returns a list of addresses owned by the client.
Parameters
None
Returns
Empty List
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '\n\n{\"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"eth_accounts\", \"params\": []}'\n
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":[]}\n
"},{"location":"api/json-rpc/#eth_blocknumber","title":"eth_blockNumber","text":"Returns the number of the most recent block.
Parameters
None
Returns
The latest block number.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_blockNumber\",\"params\":[],\"id\":64}'\n
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x20e0cf0\"}\n
"},{"location":"api/json-rpc/#eth_call","title":"eth_call","text":"Executes a message call immediately without creating a transaction on the block chain.
Parameters
1. Object - The transaction call object, the items in it as below.
Item Name Data Type Description from DATA, 20 Bytes Caller address. Hex format address, remove the prefix \"41\" to DATA, 20 Bytes Contract address. Hex format address, remove the prefix \"41\" gas QUANTITY Not supported. The value is 0x0 gasPrice QUANTITY Not supported. The value is 0x0 value QUANTITY Not supported. The value is 0x0 data DATA Hash of the method signature and encoded parameters. 2. QUANTITY|TAG - currently, only \"latest\" is available.
Returns
DATA - the return value of executed contract function.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_call\",\n\n \"params\": [{\n\n \"from\": \"0xF0CC5A2A84CD0F68ED1667070934542D673ACBD8\",\n\n \"to\": \"0x70082243784DCDF3042034E7B044D6D342A91360\",\n\n \"gas\": \"0x0\",\n\n \"gasPrice\": \"0x0\",\n\n \"value\": \"0x0\",\n\n \"data\": \"0x70a08231000000000000000000000041f0cc5a2a84cd0f68ed1667070934542d673acbd8\"\n\n }, \"latest\"],\n\n \"id\": 1\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x\"}\n
### eth_chainId\n\n*Returns the chainId of the TRON network which is the last four bytes of the genesis block hash*\n\n**Parameters** \n\nNone\n\n**Returns** \n\nDATA - The chainId of the TRON network\n\n**Example**\n\n```curl\n\ncurl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_chainId\",\"params\":[],\"id\":79}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":79,\"result\":\"0x2b6653dc\"}\n
"},{"location":"api/json-rpc/#eth_coinbase","title":"eth_coinbase","text":"Returns the super representative address of the current node.
Parameters
None
Returns
DATA - The super representative address of the node. (Note: Return the first address If more than one super representative address is configured, return error if there is no valid address or the address did not generate any block, the error will be \u201cetherbase must be explicitly specified\u201d . )
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"eth_coinbase\", \"params\": []}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"error\":{\"code\":-32000,\"message\":\"etherbase must be explicitly specified\",\"data\":\"{}\"}}\n
"},{"location":"api/json-rpc/#eth_estimategas","title":"eth_estimateGas","text":"Get the required energy through triggerConstantContract.
Parameters
object - The transaction call object, the items in it as below
Item Name Data Type Description from DATA, 20 Bytes address of the sender to DATA, 20 Bytes address of the receiver gas QUANTITY unused. gasPrice QUANTITY unused. value QUANTITY Integer of the value sent with this transaction data DATA Hash of the method signature and encoded parameters. Returns
The amount of energy used.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 1,\n\n \"method\": \"eth_estimateGas\",\n\n \"params\": [{\n\n \"from\": \"0x41F0CC5A2A84CD0F68ED1667070934542D673ACBD8\",\n\n \"to\": \"0x4170082243784DCDF3042034E7B044D6D342A91360\",\n\n \"gas\": \"0x01\",\n\n \"gasPrice\": \"0x8c\",\n\n \"value\": \"0x01\",\n\n \"data\": \"0x70a08231000000000000000000000041f0cc5a2a84cd0f68ed1667070934542d673acbd8\"\n\n }]\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x0\"}\n
"},{"location":"api/json-rpc/#eth_gasprice","title":"eth_gasPrice","text":"Returns the current energy price in sun.
Parameters
None
Returns
Integer of the current energy price in sun.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"eth_gasPrice\", \"params\": []}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x8c\"}\n
"},{"location":"api/json-rpc/#eth_getbalance","title":"eth_getBalance","text":"Returns the balance of the account of the given address.
Parameters
Index Data Type Description 1 DATA, 20 Bytes address to check for balance. 2 QUANTITY only \"latest\" is available now Returns
QUANTITY - integer of the current balance in sun.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getBalance\",\n\n \"params\": [\"0x41f0cc5a2a84cd0f68ed1667070934542d673acbd8\", \"latest\"],\n\n \"id\": 64\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x492780\"}\n
"},{"location":"api/json-rpc/#eth_getblockbyhash","title":"eth_getBlockByHash","text":"Returns information about a block by hash.
Parameters
Index Data Type Description 1 DATA, 32 Bytes hash of a block 2 Boolean If true it returns the full transaction objects, if false only the hashes of the transactions. Returns
object - a block object or null when no block was found. The block includes items as below.
Item Name Data Type Description number QUANTITY block number hash DATA, 32 Bytes hash of the block parentHash DATA, 32 Bytes hash of the parent block nonce QUANTITY unused sha3Uncles DATA, 32 Bytes SHA3 of the uncles data in the block logsBloom DATA, 256 Bytes the bloom filter for the logs of the block. transactionsRoot DATA, 32 Bytes the root of the transaction trie of the block stateRoot DATA, 32 Bytes the root of the final state trie of the block receiptsRoot DATA, 32 Bytes the root of the receipts trie of the block miner DATA, 20 Bytes the address of the beneficiary to whom the mining rewards were given difficulty QUANTITY integer of the difficulty for this block totalDifficulty QUANTITY integer of the total difficulty of the chain until this block extraData DATA the \u201cextra data\u201d field of this block size QUANTITY integer the size of this block in bytes gasLimit QUANTITY the maximum gas allowed in this block gasUsed QUANTITY the total used gas by all transactions in this block timestamp QUANTITY the unix timestamp for when the block was created, the unit is second. transactions Array Array of transaction objects, or 32 Bytes transaction hashes depending on the last given parameter. uncles Array Array of uncle hashes Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getBlockByHash\",\n\n \"params\": [\"0x0000000000f9cc56243898cbe88685678855e07f51c5af91322c225ce3693868\", false],\n\n \"id\": 1\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":null}\n
"},{"location":"api/json-rpc/#eth_getblockbynumber","title":"eth_getBlockByNumber","text":"Returns information about a block by hash.
Parameters
Index Data Type Description 1 QUANTITY|TAG Integer of a block number, or the string \"earliest\", \"latest\" 2 Boolean If true it returns the full transaction objects, if false only the hashes of the transactions. Returns
object - a block object or null when no block was found. See eth_getBlockByHash
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getBlockByNumber\",\n\n \"params\": [\"0xF9CC56\", true],\n\n \"id\": 1\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":null}\n
"},{"location":"api/json-rpc/#eth_getblocktransactioncountbyhash","title":"eth_getBlockTransactionCountByHash","text":"Returns the number of transactions in a block from a block matching the given block hash.
Parameters
DATA, 32 Bytes - hash of a block
Returns
QUANTITY - integer of the number of transactions in this block.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 1,\n\n \"method\": \"eth_getBlockTransactionCountByHash\",\n\n \"params\": [\"0x00000000020ef11c87517739090601aa0a7be1de6faebf35ddb14e7ab7d1cc5b\"]\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x39\"}\n
"},{"location":"api/json-rpc/#eth_getblocktransactioncountbynumber","title":"eth_getBlockTransactionCountByNumber","text":"Returns the number of transactions in a block matching the given block number.
Parameters
QUANTITY|TAG - integer of a block number, or the string \"earliest\" or \"latest\".
Returns
QUANTITY - integer of the number of transactions in this block.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getBlockTransactionCountByNumber\",\n\n \"params\": [\"0xF96B0F\"],\n\n \"id\": 1\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x23\"}\n
"},{"location":"api/json-rpc/#eth_getcode","title":"eth_getCode","text":"Returns runtime code of a given smart contract address.
Parameters
Index Data Type Description 1 DATA, 20 Bytes contract address 2 QUANTITY|TAG currently, only \"latest\" is available Returns
DATA - the runtime code from the given address.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getCode\",\n\n \"params\": [\"0x4170082243784DCDF3042034E7B044D6D342A91360\", \"latest\"],\n\n \"id\": 64\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x\"}\n
"},{"location":"api/json-rpc/#eth_getstorageat","title":"eth_getStorageAt","text":"Returns the value from a storage position at a given address. It can be used to get the value of a variable in a contract.
Parameters
Index Data Type Description 1 DATA, 20 Bytes address 2 QUANTITY integer of the position in the storage 3 QUANTITY|TAG currently only support \"latest\" Returns
DATA - the value at this storage position.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getStorageAt\",\n\n \"params\": [\"0xE94EAD5F4CA072A25B2E5500934709F1AEE3C64B\", \"0x29313b34b1b4beab0d3bad2b8824e9e6317c8625dd4d9e9e0f8f61d7b69d1f26\", \"latest\"],\n\n \"id\": 1\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x0000000000000000000000000000000000000000000000000000000000000000\"}\n
"},{"location":"api/json-rpc/#eth_gettransactionbyblockhashandindex","title":"eth_getTransactionByBlockHashAndIndex","text":"Returns information about a transaction by block hash and transaction index position.
Parameters
Index Data Type Description 1 DATA, 32 Bytes hash of a block 2 QUANTITY the transaction index position Returns
object - a transaction object or null when no transaction was found. The transaction includes items as below.
Item Name Data Type Description blockHash DATA, 32 Bytes hash of the block where this transaction was in. blockNumber QUANTITY block number where this transaction was in. from DATA, 20 Bytes address of the sender gas QUANTITY unused. gasPrice QUANTITY energy price hash DATA, 32 Bytes hash of the transaction input DATA the data sent along with the transaction nonce QUANTITY unused to DATA, 20 Bytes address of the receiver transactionIndex QUANTITY integer of the transactions index position in the block value QUANTITY value transferred in sun v QUANTITY ECDSA recovery id r DATA, 32 Bytes ECDSA signature r s DATA, 32 Bytes ECDSA signature s Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getTransactionByBlockHashAndIndex\",\n\n \"params\": [\"00000000020ef11c87517739090601aa0a7be1de6faebf35ddb14e7ab7d1cc5b\", \"0x0\"],\n\n \"id\": 64\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 64,\n\n \"result\": {\n\n \"blockHash\": \"0x00000000020ef11c87517739090601aa0a7be1de6faebf35ddb14e7ab7d1cc5b\",\n\n \"blockNumber\": \"0x20ef11c\",\n\n \"from\": \"0xb4f1b6e3a1461266b01c2c4ff9237191d5c3d5ce\",\n\n \"gas\": \"0x0\",\n\n \"gasPrice\": \"0x8c\",\n\n \"hash\": \"0x8dd26d1772231569f022adb42f7d7161dee88b97b4b35eeef6ce73fcd6613bc2\",\n\n \"input\": \"0x\",\n\n \"nonce\": null,\n\n \"r\": \"0x6212a53b962345fb8ab02215879a2de05f32e822c54e257498f0b70d33825cc5\",\n\n \"s\": \"0x6e04221f5311cf2b70d3aacfc444e43a5cf14d0bf31d9227218efaabd9b5a812\",\n\n \"to\": \"0x047d4a0a1b7a9d495d6503536e2a49bb5cc72cfe\",\n\n \"transactionIndex\": \"0x0\",\n\n \"type\": \"0x0\",\n\n \"v\": \"0x1b\",\n\n \"value\": \"0x203226\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_gettransactionbyblocknumberandindex","title":"eth_getTransactionByBlockNumberAndIndex","text":"Returns information about a transaction by block number and transaction index position.
Parameters
Index Data Type Description 1 QUANTITY|TAG a block number, or the string \"earliest\", \"latest\", 2 QUANTITY the transaction index position Returns
object - a transaction object or null when no transaction was found. See eth_getTransactionByBlockHashAndIndex
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getTransactionByBlockNumberAndIndex\",\n\n \"params\": [\"0xfb82f0\", \"0x0\"],\n\n \"id\": 64\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":null}\n
"},{"location":"api/json-rpc/#eth_gettransactionbyhash","title":"eth_getTransactionByHash","text":"Returns the information about a transaction requested by transaction hash.
Parameters
DATA, 32 Bytes - hash of a transaction
Returns
object - a transaction object or null when no transaction was found. See eth_getTransactionByBlockHashAndIndex
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getTransactionByHash\",\n\n \"params\": [\"c9af231ad59bcd7e8dcf827afd45020a02112704dce74ec5f72cb090aa07eef0\"],\n\n \"id\": 64\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 64,\n\n \"result\": {\n\n \"blockHash\": \"0x00000000020ef11c87517739090601aa0a7be1de6faebf35ddb14e7ab7d1cc5b\",\n\n \"blockNumber\": \"0x20ef11c\",\n\n \"from\": \"0x6eced5214d62c3bc9eaa742e2f86d5c516785e14\",\n\n \"gas\": \"0x0\",\n\n \"gasPrice\": \"0x8c\",\n\n \"hash\": \"0xc9af231ad59bcd7e8dcf827afd45020a02112704dce74ec5f72cb090aa07eef0\",\n\n \"input\": \"0x\",\n\n \"nonce\": null,\n\n \"r\": \"0x433eaf0a7df3a08c8828a2180987146d39d44de4ac327c4447d0eeda42230ea8\",\n\n \"s\": \"0x6f91f63b37f4d1cd9342f570205beefaa5b5ba18d616fec643107f8c1ae1339d\",\n\n \"to\": \"0x0697250b9d73b460a9d2bbfd8c4cacebb05dd1f1\",\n\n \"transactionIndex\": \"0x6\",\n\n \"type\": \"0x0\",\n\n \"v\": \"0x1b\",\n\n \"value\": \"0x1cb2310\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_gettransactionreceipt","title":"eth_getTransactionReceipt","text":"Returns the transaction info: receipt, transaction fee, block height ... by transaction hash. Please refer to http api: wallet/gettransactioninfobyid
Parameters
DATA, 32 Bytes - hash of a transaction
Returns
object - A transaction receipt object, or null when no receipt was found. The items in transaction receipt as below.
Item Name Data Type Description transactionHash DATA, 32 Bytes hash of the transaction transactionIndex QUANTITY integer of the transactions index position in the block blockHash DATA, 32 Bytes hash of the block where this transaction was in. blockNumber QUANTITY block number where this transaction was in. from DATA, 20 Bytes address of the sender to DATA, 20 Bytes address of the receiver cumulativeGasUsed QUANTITY The total amount of gas used when this transaction was executed in the block. gasUsed QUANTITY The amount of gas used by this specific transaction alone. contractAddress DATA, 20 Bytes The contract address created, if the transaction was a contract creation, otherwise null. logs Array Array of log objects, which this transaction generated. logsBloom DATA, 256 Bytes Bloom filter for light clients to quickly retrieve related logs. root DATA 32 bytes of post-transaction stateroot (pre Byzantium) status QUANTITY either 1 (success) or 0 (failure) Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getTransactionReceipt\",\n\n \"params\": [\"c9af231ad59bcd7e8dcf827afd45020a02112704dce74ec5f72cb090aa07eef0\"],\n\n \"id\": 64\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 64,\n\n \"result\": {\n\n \"blockHash\": \"0x00000000020ef11c87517739090601aa0a7be1de6faebf35ddb14e7ab7d1cc5b\",\n\n \"blockNumber\": \"0x20ef11c\",\n\n \"contractAddress\": null,\n\n \"cumulativeGasUsed\": \"0x646e2\",\n\n \"effectiveGasPrice\": \"0x8c\",\n\n \"from\": \"0x6eced5214d62c3bc9eaa742e2f86d5c516785e14\",\n\n \"gasUsed\": \"0x0\",\n\n \"logs\": [],\n\n \"logsBloom\": \"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\",\n\n \"status\": \"0x1\",\n\n \"to\": \"0x0697250b9d73b460a9d2bbfd8c4cacebb05dd1f1\",\n\n \"transactionHash\": \"0xc9af231ad59bcd7e8dcf827afd45020a02112704dce74ec5f72cb090aa07eef0\",\n\n \"transactionIndex\": \"0x6\",\n\n \"type\": \"0x0\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_getwork","title":"eth_getWork","text":"Returns the hash of the current block
Parameters
None
Returns
Array - Array with the following properties:
Index Data Type Description 1 DATA, 32 Bytes hash of the block 2 DATA unused 3 DATA unused Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getWork\",\n\n \"params\": [],\n\n \"id\": 73\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 73,\n\n \"result\": [\"0x00000000020e73915413df0c816e327dc4b9d17069887aef1fff0e854f8d9ad0\", null, null]\n\n}\n
"},{"location":"api/json-rpc/#eth_protocolversion","title":"eth_protocolVersion","text":"Returns the java-tron block version
Parameters
None
Returns
String - The current java-tron block version
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_protocolVersion\",\"params\":[],\"id\":64}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x16\"}\n
"},{"location":"api/json-rpc/#eth_syncing","title":"eth_syncing","text":"Returns an object with data about the sync status of the node
Parameters
None
Returns
Object|Boolean, An object with sync status data or FALSE, when not syncing, the items in object includes:
startingBlock QUANTITY The block at which the import started (will only be reset, after the sync reached his head) currentBlock QUANTITY The current block highestBlock QUANTITY The estimated highest block Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_syncing\",\"params\":[],\"id\":64}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 64,\n\n \"result\": {\n\n \"startingBlock\": \"0x20e76cc\",\n\n \"currentBlock\": \"0x20e76df\",\n\n \"highestBlock\": \"0x20e76e0\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_newfilter","title":"eth_newFilter","text":"Creates a filter object, based on filter options, to notify when the state changes (logs).
Parameters
Object - The filter options:
Field Type Description fromBlock QUANTITY|TAG Integer block number, or \"latest\" toBlock QUANTITY|TAG Integer block number, or \"latest\" address DATA|Array, 20 Bytes Contract address or a list of addresses from which logs should originate. topics Array of DATA Topics Returns
QUANTITY - A filter id.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_newFilter\",\"params\":[{\"address\":[\"cc2e32f2388f0096fae9b055acffd76d4b3e5532\",\"E518C608A37E2A262050E10BE0C9D03C7A0877F3\"],\"fromBlock\":\"0x989680\",\"toBlock\":\"0x9959d0\",\"topics\":[\"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef\",null,[\"0x0000000000000000000000001806c11be0f9b9af9e626a58904f3e5827b67be7\",\"0x0000000000000000000000003c8fb6d064ceffc0f045f7b4aee6b3a4cefb4758\"]]}],\"id\":1}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x2bab51aee6345d2748e0a4a3f4569d80\"}\n
"},{"location":"api/json-rpc/#eth_newblockfilter","title":"eth_newBlockFilter","text":"Creates a filter in the node, to notify when a new block arrives.
Parameters
None.
Returns
QUANTITY - A filter id.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_newBlockFilter\",\"params\":[],\"id\":1}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x2bab51aee6345d2748e0a4a3f4569d80\"}\n
"},{"location":"api/json-rpc/#eth_getfilterchanges","title":"eth_getFilterChanges","text":"Polling method for a filter, which returns an array of logs which occurred since last poll.
Parameters
QUANTITY - the filter id.
Returns
- For filters created with eth_newFilte, return logs object list, each log object with following params:
Field Type Description removed TAG true when the log was removed, due to a chain reorganization. false if its a valid log. logIndex QUANTITY Integer of the log index position in the block. null when its pending log. transactionIndex QUANTITY Integer of the transactions index position log was created from. null when its pending log. transactionHash DATA, 32Bytes Hash of the transactions this log was created from. blockHash DATA, 32 Bytes Hash of the block where this log was in. null when its pending. blockNumber QUANTITY The block number where this log was in. address DATA, 32 Bytes Address from which this log originated. data DATA Contains one or more 32 Bytes non-indexed arguments of the log. topics DATA[] Event topic and indexed arguments. - For filters created with eth_newBlockFilter the return are block hashes (DATA, 32 Bytes).
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getFilterChanges\",\n\n \"params\": [\n\n \"0xc11a84d5e906ecb9f5c1eb65ee940b154ad37dce8f5ac29c80764508b901d996\"\n\n ],\n\n \"id\": 71\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 71,\n\n \"error\": {\n\n \"code\": -32000,\n\n \"message\": \"filter not found\",\n\n \"data\": \"{}\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_getfilterlogs","title":"eth_getFilterLogs","text":"Returns an array of all logs matching filter with given id.
Parameters
QUANTITY - the filter id.
Returns
See eth_getFilterChanges\u3002
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getFilterLogs\",\n\n \"params\": [\n\n \"0xc11a84d5e906ecb9f5c1eb65ee940b154ad37dce8f5ac29c80764508b901d996\"\n\n ],\n\n \"id\": 71\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 71,\n\n \"error\": {\n\n \"code\": -32000,\n\n \"message\": \"filter not found\",\n\n \"data\": \"{}\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_uninstallfilter","title":"eth_uninstallFilter","text":"Uninstalls a filter with given id. Should always be called when watch is no longer needed. Additionally Filters timeout when they aren't requested with eth_getFilterChanges for a period of time.
Parameters
QUANTITY - the filter id.
Returns
Boolean - true if the filter was successfully uninstalled, otherwise false.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_uninstallFilter\",\n\n \"params\": [\n\n \"0xc11a84d5e906ecb9f5c1eb65ee940b154ad37dce8f5ac29c80764508b901d996\"\n\n ],\n\n \"id\": 71\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 71,\n\n \"result\": true\n\n}\n
"},{"location":"api/json-rpc/#eth_getlogs","title":"eth_getLogs","text":"Returns an array of all logs matching a given filter object.
Parameters
Object - The filter options which include below fields:
Field Type Description fromBlock QUANTITY|TAG (optional, default: \"latest\") Integer block number, or \"latest\" for the last mined block toBlock QUANTITY|TAG (optional, default: \"latest\") Integer block number, or \"latest\" for the last mined block address DATA|Array, 20 Bytes (optional) Contract address or a list of addresses from which logs should originate. topics Array of DATA (optional) Array of 32 Bytes DATA topics. Topics are order-dependent. Each topic can also be an array of DATA with \"or\" options. blockhash DATA, 32 Bytes (optional) Block hash Returns
See eth_getFilterChanges.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getLogs\",\"params\":[{\"address\":[\"cc2e32f2388f0096fae9b055acffd76d4b3e5532\",\"E518C608A37E2A262050E10BE0C9D03C7A0877F3\"],\"fromBlock\":\"0x989680\",\"toBlock\":\"0x9959d0\",\"topics\":[\"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef\",null,[\"0x0000000000000000000000001806c11be0f9b9af9e626a58904f3e5827b67be7\",\"0x0000000000000000000000003c8fb6d064ceffc0f045f7b4aee6b3a4cefb4758\"]]}],\"id\":1}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 71,\n\n \"result\": []\n\n}\n
"},{"location":"api/json-rpc/#net","title":"net","text":""},{"location":"api/json-rpc/#net_listening","title":"net_listening","text":"Returns true if the client is actively listening for network connections.
Parameters
None
Returns
Boolean - true when listening, otherwise false.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"net_listening\",\"params\":[],\"id\":64}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":true}\n
"},{"location":"api/json-rpc/#net_peercount","title":"net_peerCount","text":"Returns number of peers currently connected to the client.
Parameters
None
Returns
QUANTITY - integer of the number of connected peers.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"net_peerCount\",\"params\":[],\"id\":64}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x9\"}\n
"},{"location":"api/json-rpc/#net_version","title":"net_version","text":"Returns the hash of the genesis block.
Parameters
None
Returns
String - The hash of genesis block
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"net_version\",\"params\":[],\"id\":64}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x2b6653dc\"}\n
"},{"location":"api/json-rpc/#web3","title":"web3","text":""},{"location":"api/json-rpc/#web3_clientversion","title":"web3_clientVersion","text":"Returns the current client version.
Parameters
None
Returns
String - The current client version
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"web3_clientVersion\", \"params\": []}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"TRON/v4.3.0/Linux/Java1.8/GreatVoyage-v4.2.2.1-281-gc1d9dfd6c\"}\n
"},{"location":"api/json-rpc/#web3_sha3","title":"web3_sha3","text":"Returns Keccak-256 (not the standardized SHA3-256) of the given data.
Parameters
DATA - the data to convert into a SHA3 hash
Returns
DATA - The SHA3 result of the given string.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"web3_sha3\", \"params\": [\"0x68656c6c6f20776f726c64\"]}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad\"}\n
"},{"location":"api/json-rpc/#buildtransaction","title":"buildTransaction","text":"Create a transaction, different transaction types have different parameters
"},{"location":"api/json-rpc/#transfercontract","title":"TransferContract","text":"Parameters
Object - the items in object as below:
Param Name Data Type Description from DATA, 20 Bytes The address the transaction is sent from. to DATA, 20 Bytes The address the transaction is directed to. value DATA the transfer amount Returns
Object - transaction of TransferContract or an error
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"id\": 1337,\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"buildTransaction\",\n\n \"params\": [\n\n {\n\n \"from\": \"0xC4DB2C9DFBCB6AA344793F1DDA7BD656598A06D8\",\n\n \"to\": \"0x95FD23D3D2221CFEF64167938DE5E62074719E54\",\n\n \"value\": \"0x1f4\"\n\n }]}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1337,\"result\":{\"transaction\":{\"visible\":false,\"txID\":\"ae02a80abd985a6f05478b9bbf04706f00cdbf71e38c77d21ed77e44c634cef9\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"amount\":500,\"owner_address\":\"41c4db2c9dfbcb6aa344793f1dda7bd656598a06d8\",\"to_address\":\"4195fd23d3d2221cfef64167938de5e62074719e54\"},\"type_url\":\"type.googleapis.com/protocol.TransferContract\"},\"type\":\"TransferContract\"}],\"ref_block_bytes\":\"957e\",\"ref_block_hash\":\"3922d8c0d28b5283\",\"expiration\":1684469286000,\"timestamp\":1684469226841},\"raw_data_hex\":\"0a02957e22083922d8c0d28b528340f088c69183315a66080112620a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412310a1541c4db2c9dfbcb6aa344793f1dda7bd656598a06d812154195fd23d3d2221cfef64167938de5e62074719e5418f40370d9bac2918331\"}}}\n
"},{"location":"api/json-rpc/#transferassetcontract","title":"TransferAssetContract","text":"Parameters
Object - the items in object as below:
from DATA, 20 Bytes The address the transaction is sent from to DATA, 20 Bytes The address the transaction is directed to tokenId QUANTITY Token ID tokenValue QUANTITY The transfer amount of TRC10 Returns
Object - transaction of TransferAssetContract or an error
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"method\": \"buildTransaction\",\n\n \"params\": [\n\n {\n\n \"from\": \"0xC4DB2C9DFBCB6AA344793F1DDA7BD656598A06D8\",\n\n \"to\": \"0x95FD23D3D2221CFEF64167938DE5E62074719E54\",\n\n \"tokenId\": 1000016,\n\n \"tokenValue\": 20\n\n }\n\n ],\n\n \"id\": 44,\n\n \"jsonrpc\": \"2.0\"\n\n}\n\n'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":44,\"error\":{\"code\":-32600,\"message\":\"assetBalance must be greater than 0.\",\"data\":\"{}\"}}\n
"},{"location":"api/json-rpc/#createsmartcontract","title":"CreateSmartContract","text":"Parameters
Object - the items in object as below:
from DATA, 20 Bytes The address the transaction is sent from name DATA The name of the smart contract. gas DATA Fee limit abi DATA The ABI of the smart contract. data DATA The byte code of the smart contract. consumeUserResourcePercent QUANTITY The consume user resource percent. originEnergyLimit QUANTITY The origin energy limit. value DATA The data passed through call_value. tokenId QUANTITY Token ID tokenValue QUANTITY The transfer amount of TRC10 Returns
Object - transaction of CreateSmartContract or an error
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"id\": 1337,\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"buildTransaction\",\n\n \"params\": [\n\n {\n\n \"from\": \"0xC4DB2C9DFBCB6AA344793F1DDA7BD656598A06D8\",\n\n \"name\": \"transferTokenContract\",\n\n \"gas\": \"0x245498\",\n\n \"abi\": \"[{\\\"constant\\\":false,\\\"inputs\\\":[],\\\"name\\\":\\\"getResultInCon\\\",\\\"outputs\\\":[{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"trcToken\\\"},{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"uint256\\\"},{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"payable\\\":true,\\\"stateMutability\\\":\\\"payable\\\",\\\"type\\\":\\\"function\\\"},{\\\"constant\\\":false,\\\"inputs\\\":[{\\\"name\\\":\\\"toAddress\\\",\\\"type\\\":\\\"address\\\"},{\\\"name\\\":\\\"id\\\",\\\"type\\\":\\\"trcToken\\\"},{\\\"name\\\":\\\"amount\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"name\\\":\\\"TransferTokenTo\\\",\\\"outputs\\\":[],\\\"payable\\\":true,\\\"stateMutability\\\":\\\"payable\\\",\\\"type\\\":\\\"function\\\"},{\\\"constant\\\":false,\\\"inputs\\\":[],\\\"name\\\":\\\"msgTokenValueAndTokenIdTest\\\",\\\"outputs\\\":[{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"trcToken\\\"},{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"uint256\\\"},{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"payable\\\":true,\\\"stateMutability\\\":\\\"payable\\\",\\\"type\\\":\\\"function\\\"},{\\\"inputs\\\":[],\\\"payable\\\":true,\\\"stateMutability\\\":\\\"payable\\\",\\\"type\\\":\\\"constructor\\\"}]\\n\",\n\n \"data\": \"6080604052d3600055d2600155346002556101418061001f6000396000f3006080604052600436106100565763ffffffff7c010000000000000000000000000000000000000000000000000000000060003504166305c24200811461005b5780633be9ece71461008157806371dc08ce146100aa575b600080fd5b6100636100b2565b60408051938452602084019290925282820152519081900360600190f35b6100a873ffffffffffffffffffffffffffffffffffffffff600435166024356044356100c0565b005b61006361010d565b600054600154600254909192565b60405173ffffffffffffffffffffffffffffffffffffffff84169082156108fc029083908590600081818185878a8ad0945050505050158015610107573d6000803e3d6000fd5b50505050565bd3d2349091925600a165627a7a72305820a2fb39541e90eda9a2f5f9e7905ef98e66e60dd4b38e00b05de418da3154e7570029\",\n\n \"consumeUserResourcePercent\": 100,\n\n \"originEnergyLimit\": 11111111111111,\n\n \"value\": \"0x1f4\",\n\n \"tokenId\": 1000033,\n\n \"tokenValue\": 100000\n\n }\n\n ]\n\n}\n\n'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1337,\"result\":{\"transaction\":{\"visible\":false,\"txID\":\"598d8aafbf9340e92c8f72a38389ce9661b643ff37dd2a609f393336a76025b9\",\"contract_address\":\"41dfd93697c0a978db343fe7a92333e11eeb2f967d\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"token_id\":1000033,\"owner_address\":\"41c4db2c9dfbcb6aa344793f1dda7bd656598a06d8\",\"call_token_value\":100000,\"new_contract\":{\"bytecode\":\"6080604052d3600055d2600155346002556101418061001f6000396000f3006080604052600436106100565763ffffffff7c010000000000000000000000000000000000000000000000000000000060003504166305c24200811461005b5780633be9ece71461008157806371dc08ce146100aa575b600080fd5b6100636100b2565b60408051938452602084019290925282820152519081900360600190f35b6100a873ffffffffffffffffffffffffffffffffffffffff600435166024356044356100c0565b005b61006361010d565b600054600154600254909192565b60405173ffffffffffffffffffffffffffffffffffffffff84169082156108fc029083908590600081818185878a8ad0945050505050158015610107573d6000803e3d6000fd5b50505050565bd3d2349091925600a165627a7a72305820a2fb39541e90eda9a2f5f9e7905ef98e66e60dd4b38e00b05de418da3154e7570029\",\"consume_user_resource_percent\":100,\"name\":\"transferTokenContract\",\"origin_address\":\"41c4db2c9dfbcb6aa344793f1dda7bd656598a06d8\",\"abi\":{\"entrys\":[{\"outputs\":[{\"type\":\"trcToken\"},{\"type\":\"uint256\"},{\"type\":\"uint256\"}],\"payable\":true,\"name\":\"getResultInCon\",\"stateMutability\":\"Payable\",\"type\":\"Function\"},{\"payable\":true,\"inputs\":[{\"name\":\"toAddress\",\"type\":\"address\"},{\"name\":\"id\",\"type\":\"trcToken\"},{\"name\":\"amount\",\"type\":\"uint256\"}],\"name\":\"TransferTokenTo\",\"stateMutability\":\"Payable\",\"type\":\"Function\"},{\"outputs\":[{\"type\":\"trcToken\"},{\"type\":\"uint256\"},{\"type\":\"uint256\"}],\"payable\":true,\"name\":\"msgTokenValueAndTokenIdTest\",\"stateMutability\":\"Payable\",\"type\":\"Function\"},{\"payable\":true,\"stateMutability\":\"Payable\",\"type\":\"Constructor\"}]},\"origin_energy_limit\":11111111111111,\"call_value\":500}},\"type_url\":\"type.googleapis.com/protocol.CreateSmartContract\"},\"type\":\"CreateSmartContract\"}],\"ref_block_bytes\":\"80be\",\"ref_block_hash\":\"ac7c3d59c55ac92c\",\"expiration\":1634030190000,\"fee_limit\":333333280,\"timestamp\":1634030131693},\"raw_data_hex\":\"0a0280be2208ac7c3d59c55ac92c40b0fba79ec72f5ad805081e12d3050a30747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e437265617465536d617274436f6e7472616374129e050a1541c4db2c9dfbcb6aa344793f1dda7bd656598a06d812fc040a1541c4db2c9dfbcb6aa344793f1dda7bd656598a06d81adb010a381a0e676574526573756c74496e436f6e2a0a1a08747263546f6b656e2a091a0775696e743235362a091a0775696e743235363002380140040a501a0f5472616e73666572546f6b656e546f22141209746f416464726573731a0761646472657373220e120269641a08747263546f6b656e22111206616d6f756e741a0775696e743235363002380140040a451a1b6d7367546f6b656e56616c7565416e64546f6b656e4964546573742a0a1a08747263546f6b656e2a091a0775696e743235362a091a0775696e743235363002380140040a0630013801400422e0026080604052d3600055d2600155346002556101418061001f6000396000f3006080604052600436106100565763ffffffff7c010000000000000000000000000000000000000000000000000000000060003504166305c24200811461005b5780633be9ece71461008157806371dc08ce146100aa575b600080fd5b6100636100b2565b60408051938452602084019290925282820152519081900360600190f35b6100a873ffffffffffffffffffffffffffffffffffffffff600435166024356044356100c0565b005b61006361010d565b600054600154600254909192565b60405173ffffffffffffffffffffffffffffffffffffffff84169082156108fc029083908590600081818185878a8ad0945050505050158015610107573d6000803e3d6000fd5b50505050565bd3d2349091925600a165627a7a72305820a2fb39541e90eda9a2f5f9e7905ef98e66e60dd4b38e00b05de418da3154e757002928f40330643a157472616e73666572546f6b656e436f6e747261637440c7e3d28eb0c30218a08d0620e1843d70edb3a49ec72f9001a086f99e01\"}}}\n
"},{"location":"api/json-rpc/#triggersmartcontract","title":"TriggerSmartContract","text":"Parameters
Object - the items in object as below:
from DATA, 20 Bytes The address the transaction is sent from to DATA, 20 Bytes The address of the smart contract data DATA The invoked contract function and parameters gas DATA Fee limit value DATA The data passed through call_value tokenId QUANTITY Token ID tokenValue QUANTITY The transfer amount of TRC10 Returns
Object - transaction of TriggerSmartContract or an error
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"id\": 1337,\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"buildTransaction\",\n\n \"params\": [\n\n {\n\n \"from\": \"0xC4DB2C9DFBCB6AA344793F1DDA7BD656598A06D8\",\n\n \"to\": \"0xf859b5c93f789f4bcffbe7cc95a71e28e5e6a5bd\",\n\n \"data\": \"0x3be9ece7000000000000000000000000ba8e28bdb6e49fbb3f5cd82a9f5ce8363587f1f600000000000000000000000000000000000000000000000000000000000f42630000000000000000000000000000000000000000000000000000000000000001\",\n\n \"gas\": \"0x245498\",\n\n \"value\": \"0xA\",\n\n \"tokenId\": 1000035,\n\n \"tokenValue\": 20\n\n }\n\n ]\n\n }\n\n'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1337,\"result\":{\"transaction\":{\"visible\":false,\"txID\":\"c3c746beb86ffc366ec0ff8bf6c9504c88f8714e47bc0009e4f7e2b1d49eb967\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"amount\":10,\"owner_address\":\"41c4db2c9dfbcb6aa344793f1dda7bd656598a06d8\",\"to_address\":\"41f859b5c93f789f4bcffbe7cc95a71e28e5e6a5bd\"},\"type_url\":\"type.googleapis.com/protocol.TransferContract\"},\"type\":\"TransferContract\"}],\"ref_block_bytes\":\"958c\",\"ref_block_hash\":\"9d8c6bae734a2281\",\"expiration\":1684469328000,\"timestamp\":1684469270364},\"raw_data_hex\":\"0a02958c22089d8c6bae734a22814080d1c89183315a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541c4db2c9dfbcb6aa344793f1dda7bd656598a06d8121541f859b5c93f789f4bcffbe7cc95a71e28e5e6a5bd180a70dc8ec5918331\"}}}\n
"},{"location":"api/rpc/","title":"RPC List","text":"For the specific definition of API, please refer to the following link: api/api.proto
Note
SolidityNode is deprecated. Now a FullNode supports all RPCs of a SolidityNode. New developers should deploy FullNode only.
"},{"location":"api/rpc/#get-account-information","title":"Get account information","text":"rpc GetAccount (Account) returns (Account) {}\n
Nodes: Fullnode and SolidityNode"},{"location":"api/rpc/#trx-transfer","title":"TRX transfer","text":"rpc CreateTransaction (TransferContract) returns (Transaction) {}\n
Nodes: Fullnode"},{"location":"api/rpc/#broadcast-transaction","title":"Broadcast transaction","text":"rpc BroadcastTransaction (Transaction) returns (Return) {}\n
Nodes: Fullnode Description: Transfer, vote, issuance of token, or participation in token offering. Sending signed transaction information to node, and broadcasting it to the entire network after super representatives verification.
"},{"location":"api/rpc/#create-an-account","title":"Create an account","text":"rpc CreateAccount (AccountCreateContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#account-name-update","title":"Account name update","text":"rpc UpdateAccount (AccountUpdateContract) returns (Transaction) {}\n
Nodes: Fullnode"},{"location":"api/rpc/#vote-for-super-representative-candidates","title":"Vote for super representative candidates","text":"rpc VoteWitnessAccount (VoteWitnessContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-ratio-of-brokerage-of-the-super-representative","title":"Query the ratio of brokerage of the super representative","text":"rpc GetBrokerageInfo (BytesMessage) returns (NumberMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-unclaimed-reward","title":"Query unclaimed reward","text":"rpc GetRewardInfo (BytesMessage) returns (NumberMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#update-the-ratio-of-brokerage","title":"Update the ratio of brokerage","text":"rpc UpdateBrokerage (UpdateBrokerageContract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#issue-a-token","title":"Issue a token","text":"rpc CreateAssetIssue (AssetIssueContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-of-list-of-super-representative-candidates","title":"Query of list of super representative candidates","text":"rpc ListWitnesses (EmptyMessage) returns (WitnessList) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#application-for-super-representative","title":"Application for super representative","text":"rpc CreateWitness (WitnessCreateContract) returns (Transaction) {}\n
Nodes: FullNode Description: To apply to become TRON\u2019s Super Representative candidate.
"},{"location":"api/rpc/#information-update-of-super-representative-candidates","title":"Information update of Super Representative candidates","text":"rpc UpdateWitness (WitnessUpdateContract) returns (Transaction) {}\n
Nodes: FullNode Description: Update the website url of the SR.
"},{"location":"api/rpc/#token-transfer","title":"Token transfer","text":"rpc TransferAsset (TransferAssetContract) returns (Transaction){}\n
Node: FullNode"},{"location":"api/rpc/#participate-a-token","title":"Participate a token","text":"rpc ParticipateAssetIssue (ParticipateAssetIssueContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-list-of-nodes-connected-to-the-ip-of-the-api","title":"Query the list of nodes connected to the ip of the api","text":"rpc ListNodes (EmptyMessage) returns (NodeList) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#query-the-list-of-all-issued-tokens","title":"Query the list of all issued tokens","text":"rpc GetAssetIssueList (EmptyMessage) returns (AssetIssueList) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#query-the-token-issued-by-a-given-account","title":"Query the token issued by a given account","text":"rpc GetAssetIssueByAccount (Account) returns (AssetIssueList) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#query-the-token-information-by-token-name","title":"Query the token information by token name","text":"rpc GetAssetIssueByName (BytesMessage) returns (AssetIssueContract) {}\n
Nodes: FullNode and Soliditynode"},{"location":"api/rpc/#query-the-list-of-tokens-by-timestamp","title":"Query the list of tokens by timestamp","text":"rpc GetAssetIssueListByTimestamp (NumberMessage) returns (AssetIssueList){}\n
Nodes: SolidityNode"},{"location":"api/rpc/#get-current-block-information","title":"Get current block information","text":"rpc GetNowBlock (EmptyMessage) returns (Block) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#get-a-block-by-block-height","title":"Get a block by block height","text":"rpc GetBlockByNum (NumberMessage) returns (Block) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#get-the-total-number-of-transactions","title":"Get the total number of transactions","text":"rpc TotalTransaction (EmptyMessage) returns (NumberMessage) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#query-the-transaction-by-transaction-id","title":"Query the transaction by transaction id","text":"rpc getTransactionById (BytesMessage) returns (Transaction) {}\n
Nodes: SolidityNode"},{"location":"api/rpc/#query-the-transaction-by-timestamp","title":"Query the transaction by timestamp","text":"rpc getTransactionsByTimestamp (TimeMessage) returns (TransactionList) {}\n
Nodes: SolidityNode"},{"location":"api/rpc/#stake-trx","title":"Stake TRX","text":"This interface has been deprecated, please use FreezeBalanceV2 to stake TRX to obtain resources.
rpc FreezeBalance (FreezeBalanceContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#unstake-trx","title":"Unstake TRX","text":"Unstake the TRX staked during Stake1.0.
rpc UnfreezeBalance (UnfreezeBalanceContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#block-producing-reward-redemption","title":"Block producing reward redemption","text":"rpc WithdrawBalance (WithdrawBalanceContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#unstake-token-balance","title":"Unstake token balance","text":"rpc UnfreezeAsset (UnfreezeAssetContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-next-maintenance-time","title":"Query the next maintenance time","text":"rpc GetNextMaintenanceTime (EmptyMessage) returns (NumberMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-transaction-fee-block-information","title":"Query the transaction fee & block information","text":"rpc GetTransactionInfoById (BytesMessage) returns (TransactionInfo) {}\n
Nodes: SolidityNode"},{"location":"api/rpc/#query-block-information-by-block-id","title":"Query block information by block id","text":"rpc GetBlockById (BytesMessage) returns (Block) {}\n
Nodes: FullNode"},{"location":"api/rpc/#update-token-information","title":"Update token information","text":"rpc UpdateAsset (UpdateAssetContract) returns (Transaction) {}\n
Nodes: Fullnode Description: Token update can only be initiated by the token issuer to update token description, url, maximum bandwidth consumption by each account and total bandwidth consumption.
"},{"location":"api/rpc/#query-the-list-of-all-the-tokens-by-pagination","title":"Query the list of all the tokens by pagination","text":"rpc GetPaginatedAssetIssueList (PaginatedMessage) returns (AssetIssueList) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#deploy-a-smart-contract","title":"Deploy a smart contract","text":"rpc DeployContract (CreateSmartContract) returns (TransactionExtention) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#trigger-a-smart-contract","title":"Trigger a smart contract","text":"rpc TriggerContract (TriggerSmartContract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-a-shielded-transaction","title":"Create a shielded transaction","text":"rpc CreateShieldedTransaction (PrivateParameters) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-a-merkle-tree-information-of-a-note","title":"Get a Merkle tree information of a note","text":"rpc GetMerkleTreeVoucherInfo (OutputPointInfo) returns (IncrementalMerkleVoucherInfo) {}\n
Nodes: FullNode"},{"location":"api/rpc/#scan-note-by-ivk","title":"Scan note by ivk","text":"rpc ScanNoteByIvk (IvkDecryptParameters) returns (DecryptNotes) {}\n
Nodes: FullNode"},{"location":"api/rpc/#scan-note-by-ovk","title":"Scan note by ovk","text":"rpc ScanNoteByOvk (OvkDecryptParameters) returns (DecryptNotes) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-spending-key","title":"Get spending key","text":"rpc GetSpendingKey (EmptyMessage) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-expanded-spending-key","title":"Get expanded spending key","text":"rpc GetExpandedSpendingKey (BytesMessage) returns (ExpandedSpendingKeyMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-ak-from-ask","title":"Get ak from ask","text":"rpc GetAkFromAsk (BytesMessage) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-nk-from-nsk","title":"Get nk from nsk","text":"rpc GetNkFromNsk (BytesMessage) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-incoming-viewing-key","title":"Get incoming viewing key","text":"rpc GetIncomingViewingKey (ViewingKeyMessage) returns (IncomingViewingKeyMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-diversifier","title":"Get diversifier","text":"rpc GetDiversifier (EmptyMessage) returns (DiversifierMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-zen-payment-address","title":"Get zen payment address","text":"rpc GetZenPaymentAddress (IncomingViewingKeyDiversifierMessage) returns (PaymentAddressMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-rcm","title":"Get rcm","text":"rpc GetRcm (EmptyMessage) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-a-note-status-of-is-spent-or-not","title":"Get a note status of is spent or not","text":"rpc IsSpend (NoteParameters) returns (SpendResult) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-a-shielded-transaction-without-using-ask","title":"Create a shielded transaction without using ask","text":"rpc CreateShieldedTransactionWithoutSpendAuthSig (PrivateParametersWithoutAsk) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-a-shielded-transaction-hash","title":"Create a shielded transaction hash","text":"rpc GetShieldTransactionHash (Transaction) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-a-signature-for-a-shielded-transaction","title":"Create a signature for a shielded transaction","text":"rpc CreateSpendAuthSig (SpendAuthSigParameters) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-a-shield-nullifier","title":"Create a shield nullifier","text":"rpc CreateShieldNullifier (NfParameters) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-new-shielded-address","title":"Get new shielded address","text":"rpc GetNewShieldedAddress (EmptyMessage) returns (ShieldedAddressInfo){}\n
Nodes: FullNode"},{"location":"api/rpc/#create-shielded-contract-parameters","title":"Create shielded contract parameters","text":"rpc CreateShieldedContractParameters (PrivateShieldedTRC20Parameters) returns (ShieldedTRC20Parameters) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-shielded-contract-parameters-without-ask","title":"Create shielded contract parameters without ask","text":"rpc CreateShieldedContractParametersWithoutAsk (PrivateShieldedTRC20ParametersWithoutAsk) returns (ShieldedTRC20Parameters) {}\n
Nodes: FullNode"},{"location":"api/rpc/#scan-shielded-trc20-notes-by-ivk","title":"Scan shielded TRC20 notes by ivk","text":"rpc ScanShieldedTRC20NotesbyIvk (IvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}\n
Nodes: FullNode, SolidityNode"},{"location":"api/rpc/#scan-shielded-trc20-notes-by-ovk","title":"Scan shielded TRC20 notes by ovk","text":"rpc ScanShieldedTRC20NotesbyOvk (OvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}\n
Nodes: FullNode, SolidityNode"},{"location":"api/rpc/#get-the-status-of-shielded-trc20-note-of-spent-or-not","title":"Get the status of shielded TRC20 note of spent or not","text":"rpc IsShieldedTRC20ContractNoteSpent (NfTRC20Parameters) returns (NullifierResult) {}\n
Nodes: FullNode, SolidityNode"},{"location":"api/rpc/#get-the-trigger-input-for-the-shielded-trc20","title":"Get the trigger input for the shielded TRC20","text":" rpc GetTriggerInputForShieldedTRC20Contract (ShieldedTRC20TriggerContractParameters) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-an-market-order","title":"Create an market order","text":"rpc MarketSellAsset (MarketSellAssetContract) returns (TransactionExtention) {};\n
Nodes: FullNode"},{"location":"api/rpc/#cancel-the-order","title":"Cancel the order","text":"rpc MarketCancelOrder (MarketCancelOrderContract) returns (TransactionExtention) {};\n
Nodes: FullNode "},{"location":"api/rpc/#get-all-orders-for-the-account","title":"Get all orders for the account","text":"rpc GetMarketOrderByAccount (BytesMessage) returns (MarketOrderList) {};\n
Nodes: FullNode "},{"location":"api/rpc/#get-all-trading-pairs","title":"Get all trading pairs","text":"rpc GetMarketPairList (EmptyMessage) returns (MarketOrderPairList) {};\n
Nodes: FullNode "},{"location":"api/rpc/#get-all-orders-for-the-trading-pair","title":"Get all orders for the trading pair","text":"rpc GetMarketOrderListByPair (MarketOrderPair) returns (MarketOrderList) {};\n
Nodes: FullNode "},{"location":"api/rpc/#get-all-prices-for-the-trading-pair","title":"Get all prices for the trading pair","text":"rpc GetMarketPriceByPair (MarketOrderPair) returns (MarketPriceList) {};\n
Nodes: FullNode "},{"location":"api/rpc/#get-order-by-id","title":"Get order by id","text":"rpc GetMarketOrderById (BytesMessage) returns (MarketOrder) {}; \n
Nodes: FullNode "},{"location":"api/rpc/#perform-a-historical-balance-lookup","title":"perform a historical balance lookup","text":"rpc GetAccountBalance (AccountBalanceRequest) returns (AccountBalanceResponse){}; \n
Nodes: FullNode "},{"location":"api/rpc/#fetch-all-balance-changing-transactions-in-a-block","title":"fetch all balance-changing transactions in a block","text":"rpc GetBlockBalanceTrace (BlockBalanceTrace.BlockIdentifier) returns (BlockBalanceTrace) {}; \n
Nodes: FullNode "},{"location":"api/rpc/#get-the-burn-trx-amount","title":"get the burn trx amount","text":"rpc GetBurnTrx (EmptyMessage) returns (NumberMessage) {}; \n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#freeze-trx","title":"Freeze TRX","text":"rpc FreezeBalanceV2 (FreezeBalanceV2Contract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#unfreeze-trx","title":"UnFreeze TRX","text":"rpc UnfreezeBalanceV2 (UnfreezeBalanceV2Contract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#withdraw-staked-trx","title":"Withdraw Staked TRX","text":"rpc WithdrawExpireUnfreeze (WithdrawExpireUnfreezeContract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#delegate-resource","title":"Delegate Resource","text":"rpc DelegateResource (DelegateResourceContract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#undelegate-resource","title":"UnDelegate Resource","text":"rpc UnDelegateResource (UnDelegateResourceContract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-transaction-information-in-the-pending-pool","title":"Query transaction information in the pending pool","text":"rpc GetTransactionFromPending (BytesMessage) returns (Transaction) {};\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-pending-pool-transaction-id-list","title":"Query the pending pool transaction id list","text":"rpc GetTransactionListFromPending (EmptyMessage) returns (TransactionIdList) {};\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-size-of-the-pending-pool","title":"Query the size of the pending pool","text":"rpc GetPendingSize (EmptyMessage) returns (NumberMessage) {};\nNodes: FullNode\n
"},{"location":"api/rpc/#cancel-unfreeze","title":"Cancel UnFreeze","text":"rpc CancelAllUnfreezeV2 (CancelAllUnfreezeV2Contract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-bandwidth-unit-price","title":"Get bandwidth unit price","text":"rpc GetBandwidthPrices (EmptyMessage) returns (PricesResponseMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-energy-unit-price","title":"Get energy unit price","text":"rpc GetEnergyPrices (EmptyMessage) returns (PricesResponseMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-transaction-memo-fee","title":"Get transaction memo fee","text":"rpc GetMemoFee (EmptyMessage) returns (PricesResponseMessage) {}\n
Nodes: FullNodes"},{"location":"architecture/database/","title":"Database configuration","text":"java-tron data storage supports LevelDB or RocksDB, and LevelDB is used by default. You can also choose RocksDB, which provides lots of configuration parameters, allowing nodes to be tuned according to their own machine configuration. The node database occupies less disk space than LevelDB. At the same time, RocksDB supports data backup during runtime, and the backup time only takes a few seconds.
The following describes how to set the storage engine of the java-tron node to RocksDB, and how to perform data conversion between leveldb and rocksdb.
"},{"location":"architecture/database/#rocksdb","title":"RocksDB","text":""},{"location":"architecture/database/#configuration","title":"Configuration","text":"Use RocksDB as the data storage engine, need to set db.engine to \"ROCKSDB\".
Note: RocksDB only supports db.version=2, yet does not supports db.version=1
The optimization parameters RocksDB support:
"},{"location":"architecture/database/#use-rocksdbs-data-backup-function","title":"Use RocksDB's data backup function","text":"Choose RocksDB to be the data storage engine, you can use its data backup function while running
Note: FullNode can use data backup function. In order not to affect SuperNode's block producing performance, SuperNode does not support backup service, but SuperNode's backup service node can use this function.
"},{"location":"architecture/database/#convert-leveldb-to-rocksdb","title":"Convert LevelDB to RocksDB","text":"The data storage structure of LevelDB and RocksDB is not compatible, please make sure the node use the same type of data engine all the time. We provide data conversion script which can convert LevelDB data to RocksDB data.
Usage:
> cd /path/to/java-tron/source-code\n> ./gradlew build # build the source code\n> java -jar build/libs/DBConvert.jar # run data conversion command\n
Note: If the node's data storage directory is self-defined, before run DBConvert.jar, you need to add the following parameters:
- src_db_path: specify LevelDB source directory, default output-directory/database
- dst_db_path: specify RocksDb source directory, default output-directory-dst/database
Example, if you run the script like this:
> nohup java -jar FullNode.jar -d your_database_dir </dev/null &>/dev/null &\n
then, you should run DBConvert.jar this way:
> java -jar build/libs/DBConvert.jar your_database_dir/database output-directory-dst/database\n
Note: You have to stop the running of the node, and then to run the data conversion script.
If you do not want to stop the running of the node for too long, after node is shut down, you can copy leveldb's output-directory to the new directory, and then restart the node. Run DBConvert.jar in the previous directory of the new directory, and specify the parameters: src_db_path and dst_db_path.
Example:
> cp -rf output-directory /tmp/output-directory\n> cd /tmp\n> java -jar DBConvert.jar output-directory/database output-directory-dst/database\n
All the whole data conversion process may take 10 hours.
"},{"location":"architecture/database/#leveldb","title":"LevelDB","text":"You can refer to the following documents for detailed information about RocksDB vs LevelDB
"},{"location":"architecture/event/","title":"Event Subscription","text":""},{"location":"architecture/event/#using-event-plugin-for-event-subscription","title":"Using Event Plugin for Event Subscription","text":""},{"location":"architecture/event/#tip","title":"TIP","text":"The TIP: TIP-12:TRON event subscribes model .
"},{"location":"architecture/event/#event-type","title":"Event Type","text":"TRON Event Subscription supports 4 types of event:
"},{"location":"architecture/event/#transaction-event","title":"Transaction Event","text":"The parameters passed to Subscriber:
transactionId: transaction hash\nblockHash: block hash\nblockNumber: block number\nenergyUsage: energy usage\nenergyFee: energy fee\noriginEnergyUsage: origin energy usage\nenergyUsageTotal: total energy usage total\n
"},{"location":"architecture/event/#block-event","title":"Block Event","text":"The parameters passed to Subscriber:
blockHash: block hash\nblockNumber: block number\ntransactionSize: the number of transactions in a block\nlatestSolidifiedBlockNumber: the latest solidified block number\ntransactionList: the transactions hash list\n
"},{"location":"architecture/event/#contract-event","title":"Contract Event","text":"The parameters passed to Subscriber:
transactionId: transaction id\ncontractAddress: contract address\ncallerAddress: contract caller address\nblockNumber: the number of the block contract related events recorded\nblockTimestamp: the block time stamp\neventSignature: event signature\ntopicMap: the map of topic in solidity language\ndata: the data information in solidity language\nremoved: 'true' means the log is removed\n
"},{"location":"architecture/event/#contract-log-event","title":"Contract Log Event","text":"The parameters passed to Subscriber:
transactionId: transaction hash\ncontractAddress: contract address\ncallerAddress: contract caller address\nblockNumber: the number of the block contract related events recorded\nblockTimestamp: the block time stamp\ncontractTopics: the list of topic in solidity language\ndata: the data information in solidity language\nremoved: 'true' means the log is removed\n
Contract Event and Contract Log Even support event filter function which includes:
fromBlock: the start block number\ntoBlock: the end block number\ncontractAddress: contract addresses list\ncontractTopics: contract topics list\n
Note
- Historical data query is not supported.
- When subscribing to non-solidified events, be sure to use the two parameters
blockNumber and blockHash as the criteria to verify that the received events are valid. In special cases such as unstable network connections causing chain reorg, event reorg may occur as well, resulting in stale events.
"},{"location":"architecture/event/#new-features","title":"New Features","text":" - Supporting event plug-ins, kafka & mongodb plug-ins have been released, developers can also customize their own plug-ins according to their own needs.
- Supporting subscription of chain data, such as block, transaction, contract log, contract event and so on. For transaction events, developers can get information such as internal transactions, contract info and so on; for contract events, developers could configure the contract addresses list or contract topic list to receive the specified events, and event subscription has a very low latency. The deployed fullnode can receive event information immediately after the contract is executed.
- Event query service tron-eventquery, online Event query service provided. Developers can query trigger information in the last seven days through https, and the query address is https://api.tronex.io.
"},{"location":"architecture/event/#github-projects","title":"Github projects","text":" - tronprotocol/event-plugin
- tronprotocol/tron-eventquery
"},{"location":"architecture/event/#event-plugin","title":"Event plugin","text":" - Kafka deployment
- MongoDB deployment
"},{"location":"architecture/event/#event-query","title":"Event query","text":"TRON Event Query Service
TronEventQuery is implemented with Tron's new event subscribe model. It uses same query interface with Tron-Grid. Users can also subscribe block trigger, transaction trigger, contract log trigger, and contract event trigger. TronEvent is independent of a particular branch of java-tron, the new event subscribes model will be released on version 3.5 of java-tron.
For more information of TRON event subscribe model, please refer to TIP-12.
- Event query deployment
- Event query HTTP API
"},{"location":"architecture/event/#using-java-trons-built-in-message-queue-for-event-subscription","title":"Using java-tron's Built-in Message Queue for Event Subscription","text":"TRON provides event subscription service. Developers can not only obtain on-chain events through event plugin, but also through java-tron\u2019s built-in ZeroMQ message queue. The difference is that event plugin needs to be additionally deployed, which is used to implement event storage: developers can choose appropriate storage tools according to their needs, such as MongoDB, Kafka, etc., and the plugin help complete the storage of subscribed events. java-tron's built-in ZeroMQ does not require additional deployment operations. Event subscribers can directly connect to the publisher's ip and port, set subscription topics, and receive subscribed events. However, this method does not provide event storage. Therefore, when developers want to subscribe to events directly from nodes for a short period of time, then using the built-in message queue will be a more appropriate choice.
This article will introduce how to subscribe to events through java-tron's built-in message queue in detail.
"},{"location":"architecture/event/#configure-node","title":"Configure node","text":"To use the built-in ZeroMQ of the node for event subscription, you need to set the configuration item useNativeQueue to true in the node configuration file.
event.subscribe = {\n native = {\n useNativeQueue = true // if true, use native message queue, else use event plugin.\n bindport = 5555 // bind port\n sendqueuelength = 1000 //max length of send queue\n }\n\n ......\n\n topics = [\n {\n triggerName = \"block\" // block trigger, the value can't be modified\n enable = true\n topic = \"block\" // plugin topic, the value could be modified\n },\n ......\n ]\n}\n
native.useNativeQueue: true is to use the built-in message queue, false is to use the event pluginnative.bindport: ZeroMQ publisher binding port. In this example, it is 5555, so the publisher address that the subscriber should connect to is \"tcp://127.0.0.1:5555\" native.sendqueuelength: The length of the send queue, that is, when the subscriber receives messages slowly, the maximum number of messages published by the publisher that the TCP buffer can hold. if it exceeds, The message will be discarded if exceeds the capacitytopics: Subscribed event type , including block type, transaction type, etc.
"},{"location":"architecture/event/#start-node","title":"Start node","text":"The event subscription service is disabled by default and needs to be enabled by adding the command line parameter --es. The start command of the node that enables the event subscription service is as follows:
$ java -jar FullNode.jar --es\n
"},{"location":"architecture/event/#prepare-event-subscription-script","title":"Prepare event subscription script","text":"This article takes Nodejs as an example to illustrate how to subscribe to events.
First, install the zeromq library:
$ npm install zeromq@5\n
Then, write the subscriber code: // subscriber.js\nvar zmq = require(\"zeromq\"),\nvar sock = zmq.socket(\"sub\");\n\nsock.connect(\"tcp://127.0.0.1:5555\");\nsock.subscribe(\"block\");\nconsole.log(\"Subscriber connected to port 5555\");\n\nsock.on(\"message\", function(topic, message) {\n console.log(\n \"received a message related to:\",\n Buffer.from(topic).toString(),\n \", containing message:\",\n Buffer.from(message).toString()\n );\n});\n
This example connects the subscriber to the node event publisher and subscribes to block events."},{"location":"architecture/event/#start-subscriber","title":"Start subscriber","text":"Start command of Nodejs is as below:
$ node subscriber.js\n\n> Subscriber connected to port 5555\n
When the node has a new block, the subscriber will receive block event, the output information is as follows: received a message related to: blockTrigger, containing message: {\"timeStamp\":1678343709000,\"triggerName\":\"blockTrigger\",\"blockNumber\":1361,\"blockHash\":\"00000000000005519b3995cd638753a862c812d1bda11de14bbfaa5ad3383280\",\"transactionSize\":0,\"latestSolidifiedBlockNumber\":1361,\"transactionList\":[]}\nreceived a message related to: blockTrigger, containing message: {\"timeStamp\":1678343712000,\"triggerName\":\"blockTrigger\",\"blockNumber\":1362,\"blockHash\":\"0000000000000552d53d1bdd9929e4533a983f14df8931ee9b3bf6d6c74a47b0\",\"transactionSize\":0,\"latestSolidifiedBlockNumber\":1362,\"transactionList\":[]}\n
"},{"location":"clients/wallet-cli/","title":"wallet-cli","text":""},{"location":"clients/wallet-cli/#introduction","title":"Introduction","text":"wallet-cli is an interactive command-line wallet that supports the TRON network for signing and broadcasting transactions in a secure local environment, as well as access to on-chain data. wallet-cli supports key management, you can import the private key into the wallet, wallet-cli will encrypt your private key with a symmetric encryption algorithm and store it in a keystore file. wallet-cli does not store on-chain data locally. It uses gRPC to communicate with a java-tron node. You need to configure the java-tron node to be linked in the configuration file. The following figure shows the process of the use of wallet-cli to sign and broadcast when transferring TRX:
The user first runs the Login command to unlock the wallet, and then runs the SendCoin command to send TRX, wallet-cli will build and sign the transaction locally, and then call the BroadcastTransaction gRPC API of the java-tron node to broadcast the transaction to the network. After the broadcast is successful, the java-tron node will return the transaction hash to wallet-cli, and wallet-cli will display the transaction hash to the user.
Install and run: wallet-cli
"},{"location":"clients/wallet-cli/#commands","title":"Commands","text":"Below, please find all types of wallet-cli commands\uff1a
- Wallet
- Account
- AccountResource
- Transaction
- On-ChainInquire
- SmartContract
- TRC-10
- Governance
- DEX
"},{"location":"clients/wallet-cli/#wallet","title":"Wallet","text":"Here are all the wallet related commands \uff1a
- RegisterWallet
- Login
- BackupWallet
- BackupWallet2Base64
- ChangePassword
- ImportWallet
- ImportWalletByBase64
This section introduces commands related to wallet management. Let's start withregisterwalletto get a new account.
"},{"location":"clients/wallet-cli/#registerwallet","title":"RegisterWallet","text":"To register your wallet, you need to set the wallet password and generate the address and private key. A .json keystore file will be generated under the path of wallet-cli/wallet. The file will be used for login and backupwallet later.
wallet> RegisterWallet \nPlease input password.\npassword: \nPlease input password again.\npassword: \nRegister a wallet successful, keystore file name is UTC--2022-06-27T07-37-47.601000000Z--TWyDBTHsWJFhgywWkTNW7vh7jSUxeBaiAw.json\n
"},{"location":"clients/wallet-cli/#login","title":"Login","text":"When we have a keystore file, we can start to login. After enter the command, choose the keystore file and enter the password.
wallet> login\nuse user defined config file in current dir\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-06-22T08-31-57.735000000Z--TBnPDbw99BLzPUZuW8Rrcc3RGGQT3cnSfF.json\nThe 4th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 5th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 5\n4\nPlease input your password.\npassword: \nLogin successful !!!\n
"},{"location":"clients/wallet-cli/#backupwallet","title":"BackupWallet","text":"This will Back up your wallet. You need to enter your wallet password to export the privat key in hex string format, such as:
721d63b074f18d41c147e04c952ec93467777a30b6f16745bc47a8eae5076545\n
wallet> backupwallet\nPlease input your password.\npassword: \nBackupWallet successful !!\n721d63b074f18d41c147e04c952ec93467777a30b6f16745bc47a8eae5076545\n
"},{"location":"clients/wallet-cli/#backupwallet2base64","title":"BackupWallet2Base64","text":"This will Back up your wallet, you need to enter your wallet password to export the private key in base64 format, as below:
ch1jsHTxjUHBR+BMlS7JNGd3ejC28WdFvEeo6uUHZUU=\n
wallet> backupwallet\nPlease input your password.\npassword: \nBackupWallet successful !!\nch1jsHTxjUHBR+BMlS7JNGd3ejC28WdFvEeo6uUHZUU=\n
"},{"location":"clients/wallet-cli/#changepassword","title":"ChangePassword","text":"Modify the password of an account
wallet> changepassword\nPlease input old password.\npassword: \nPlease input new password.\nPlease input password.\npassword: \nPlease input password again.\npassword: \nThe 1th keystore file name is .DS_Store\nThe 2th keystore file name is UTC--2022-06-27T10-58-59.306000000Z--TBnPDbw99BLzPUZuW8Rrcc3RGGQT3cnSfF.json\nPlease choose between 1 and 2\n2\nChangePassword successful !!\n
"},{"location":"clients/wallet-cli/#importwallet","title":"ImportWallet","text":"Import a wallet, you need to set a password first and then enter your hex string private key.
wallet> importwallet\nPlease input password.\npassword: \nPlease input password again.\npassword: \nPlease input private key. Max retry time:3\nbd1ff0f4f852db45316bf08755bf6eee45d0678bfbf852a00020a13d42a1fb5b\nImport a wallet successful, keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\n
"},{"location":"clients/wallet-cli/#importwalletbybase64","title":"ImportWalletByBase64","text":"To import a wallet, you need to set a password first and then enter your private key in base64 format.
wallet> importwalletbybase64\nPlease input password.\npassword: \nPlease input password again.\npassword: \nPlease input private key by base64. Max retry time:3\nvR/w9PhS20Uxa/CHVb9u7kXQZ4v7+FKgACChPUKh+1s= \nImport a wallet successful, keystore file name is UTC--2022-06-28T06-51-56.154000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\n
"},{"location":"clients/wallet-cli/#account","title":"Account","text":"Here are all the account related commands \uff1a
- GenerateAddress
- GetAccount
- GetAddress
- GetBalance
- UpdateAccountPermission
"},{"location":"clients/wallet-cli/#generateaddress","title":"GenerateAddress","text":"Generate an address and print out the public (address) and private key
wallet> generateaddress\n{\n \"address\": \"TQAvi6bemLa1t1irdV1KuaSC5vKc2EswTj\",\n \"privateKey\": \"610a8a809114a96140e1cb040a7813afc74603e58c3d7824c3f68ccc642c297e\"\n}\n
Note: address and private key generated by this command would not be saved in wallet-cli. Keep properly if you would like to use them."},{"location":"clients/wallet-cli/#getaccount","title":"GetAccount","text":"Get account information by an address
wallet> getaccount [address]\n
wallet> getaccount TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\n{\n \"address\": \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"balance\": 2665198240,\n \"create_time\": 1650363711000,\n \"latest_opration_time\": 1653578769000,\n \"latest_consume_free_time\": 1651228080000,\n \"account_resource\": {\n \"latest_consume_time_for_energy\": 1653578769000\n },\n \"owner_permission\": {\n \"permission_name\": \"owner\",\n \"threshold\": 1,\n \"keys\": [\n {\n \"address\": \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"weight\": 1\n }\n ]\n },\n \"active_permission\": [\n {\n \"type\": \"Active\",\n \"id\": 2,\n \"permission_name\": \"active\",\n \"threshold\": 1,\n \"operations\": \"7fff1fc0033e3b00000000000000000000000000000000000000000000000000\",\n \"keys\": [\n {\n \"address\": \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"weight\": 1\n }\n ]\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#getaddress","title":"GetAddress","text":"Get the address of the current account
wallet> getaddress\nGetAddress successful !!\naddress = TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\n
"},{"location":"clients/wallet-cli/#getbalance","title":"GetBalance","text":"Get the TRX balance of the current account
wallet> getbalance\nBalance = 2665198240\n
"},{"location":"clients/wallet-cli/#updateaccountpermission","title":"UpdateAccountPermission","text":"wallet>UpdateAccountPermission [ownerAddress] [permissions]\n
This command is used to manage account permissions, assign permissions to other accounts, is utilized for multi-signature transactions, which allows other users to access the account with paritcular permission in order to better manage it. There are three types of permissions: - owner: access to the owner of account
- active: access to other features of accounts, and access that authorizes a certain feature. Block production authorization is not included if it's for SR purposes.
- witness: only for super representatives, block production authorization will be granted to one of the other users.
NOTE the parameterPermission must written in JSON format and entered in line. If the owner account is not SR, then do not assign super representative permission.
wallet> updateaccountpermission TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8 {\"owner_permission\":{\"keys\":[{\"address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\"weight\":1}],\"threshold\":1,\"type\":0,\"permission_name\":\"owner\"},\"active_permissions\":[{\"operations\":\"7fff1fc0033e0000000000000000000000000000000000000000000000000000\",\"keys\":[{\"address\":\"TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej\",\"weight\":1},{\"address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\",\"weight\":1}],\"threshold\":2,\"type\":2,\"permission_name\":\"active12323\"}]}\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"owner\":{\n \"keys\":[\n {\n \"address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"weight\":1\n }\n ],\n \"threshold\":1,\n \"permission_name\":\"owner\"\n },\n \"owner_address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"actives\":[\n {\n \"operations\":\"7fff1fc0033e0000000000000000000000000000000000000000000000000000\",\n \"keys\":[\n {\n \"address\":\"TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej\",\n \"weight\":1\n },\n {\n \"address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\",\n \"weight\":1\n }\n ],\n \"threshold\":2,\n \"type\":\"Active\",\n \"permission_name\":\"active12323\"\n }\n ]\n },\n \"type_url\":\"type.googleapis.com/protocol.AccountPermissionUpdateContract\"\n },\n \"type\":\"AccountPermissionUpdateContract\"\n }\n ],\n \"ref_block_bytes\":\"4e88\",\n \"ref_block_hash\":\"11a47859be13f689\",\n \"expiration\":1656423231000,\n \"timestamp\":1656423171818\n },\n \"raw_data_hex\":\"0a024e88220811a47859be13f6894098dc92d49a305aee01082e12e9010a3c747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e4163636f756e745065726d697373696f6e557064617465436f6e747261637412a8010a1541babecec4d9f58f0df77f0728b9c53abb1f21d68412241a056f776e657220013a190a1541babecec4d9f58f0df77f0728b9c53abb1f21d6841001226908021a0b6163746976653132333233200232207fff1fc0033e00000000000000000000000000000000000000000000000000003a190a15410cfaec7164cbfe78dbb8d8fba7e23b4d745ed81310013a190a1541e8bd653015895947cec33d1670a88cf67ab277b9100170ea8d8fd49a30\"\n}\nbefore sign transaction hex string is 0a8d020a024e88220811a47859be13f6894098dc92d49a305aee01082e12e9010a3c747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e4163636f756e745065726d697373696f6e557064617465436f6e747261637412a8010a1541babecec4d9f58f0df77f0728b9c53abb1f21d68412241a056f776e657220013a190a1541babecec4d9f58f0df77f0728b9c53abb1f21d6841001226908021a0b6163746976653132333233200232207fff1fc0033e00000000000000000000000000000000000000000000000000003a190a15410cfaec7164cbfe78dbb8d8fba7e23b4d745ed81310013a190a1541e8bd653015895947cec33d1670a88cf67ab277b9100170ea8d8fd49a30\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 4th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 4\n3\nPlease input your password.\npassword: \nafter sign transaction hex string is 0a8d020a024e88220811a47859be13f6894096bcb5de9a305aee01082e12e9010a3c747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e4163636f756e745065726d697373696f6e557064617465436f6e747261637412a8010a1541babecec4d9f58f0df77f0728b9c53abb1f21d68412241a056f776e657220013a190a1541babecec4d9f58f0df77f0728b9c53abb1f21d6841001226908021a0b6163746976653132333233200232207fff1fc0033e00000000000000000000000000000000000000000000000000003a190a15410cfaec7164cbfe78dbb8d8fba7e23b4d745ed81310013a190a1541e8bd653015895947cec33d1670a88cf67ab277b9100170ea8d8fd49a301241881b00f8e8828d9347469fcbcec730093841c2363561243b7162a9669439266049ab82f20f97a136adc88feff0a4d5aa57b11f762eaa7e05105d27ec5d55a33900\ntxid is 3dce7f18f6cf6962c38904678947b3b32f9e94ba6460874679d8ed063bb1c0eb\nUpdateAccountPermission successful !!!\n
"},{"location":"clients/wallet-cli/#accountresource","title":"AccountResource","text":"Here are all the account resource related commands \uff1a
- FreezeBalance
- UnfreezeBalance
- GetDelegatedResource
- FreezeBalanceV2
- UnfreezeBalanceV2
- DelegateResource
- UndelegateResource
- WithdrawExpireUnfreeze
- GetAvailableUnfreezeCount
- GetCanWithdrawUnfreezeAmount
- GetCanDelegatedMaxsize
- GetDelegatedResourceV2
- GetDelegatedResourceAccountIndexV2
- GetAccountNet
- GetAccountResource
"},{"location":"clients/wallet-cli/#freezebalance","title":"FreezeBalance","text":"This interface has been deprecated, please use freezeBalanceV2 to stake TRX to obtain resources.
wallet> freezeBalance [OwnerAddress] [frozen_balance] [frozen_duration] [ResourceCode:0 BANDWIDTH, 1 ENERGY] [receiverAddress]\n
OwnerAddressis the address of the account that initiated the transaction, optional, default is the address of the login account.frozen_balanceis the amount of frozen TRX, the unit is the smallest unit (Sun), the minimum is 1000000sun.frozen_duration is frozen duration, only be specified as 3 days, indicates that you can unfreeze after 3 days.ResourceCode indicates the type of the acquired resource\uff0c0 BANDWIDTH and 1 ENERGY. receiverAddressis the address that will receive the resource.
ResourceCode and receiverAddress are optional parameters. If ResourceCode is not set\uff0cdefault is 0. If receiverAddress is not set, the TRX is frozen to obtain resources for its OwnerAddress use; if it is not empty, the acquired resources are used by receiverAddress.
Example:
wallet> freezeBalance TWyDBTHsWJFhgywWkTNW7vh7jSUxeBaiAw 1000000 3 1 TCrkRWJuHP4VgQF3xwLNBAjVVXvxRRGpbA\n{\n \"raw_data\":{\n ...\n },\n \"raw_data_hex\":\"0a02a9b822081db2070d39d2316640c095dda19a305a70080b126c0a32747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e6365436f6e747261637412360a1541e65aca838a9e15dd81bd9532d2ad61300e58cf7110c0843d180350017a15411fafb1e96dfe4f609e2259bfaf8c77b60c535b9370c6c8d9a19a30\"\n}\nbefore sign transaction hex string is 0a8e010a02a9b822081db2070d39d2316640c095dda19a305a70080b126c0a32747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e6365436f6e747261637412360a1541e65aca838a9e15dd81bd9532d2ad61300e58cf7110c0843d180350017a15411fafb1e96dfe4f609e2259bfaf8c77b60c535b9370c6c8d9a19a30\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-22T08-21-05.158000000Z--TDQgNvjrE6RH749f8aFGyJqEEGyhV4BDEU.json\nThe 2th keystore file name is UTC--2022-06-27T07-37-47.601000000Z--TWyDBTHsWJFhgywWkTNW7vh7jSUxeBaiAw.json\nPlease choose between 1 and 2\n2\nPlease input your password.\npassword: \nafter sign transaction hex string is 0a8e010a02a9b822081db2070d39d2316640e0f7ffab9a305a70080b126c0a32747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e6365436f6e747261637412360a1541e65aca838a9e15dd81bd9532d2ad61300e58cf7110c0843d180350017a15411fafb1e96dfe4f609e2259bfaf8c77b60c535b9370c6c8d9a19a301241c45742648e6970e01b242c9b6eca2549c8721b860ced71abd331b9fe925f3c0f184768e0d2e3b580ce787cc6f67d186a0d583226fdb69c2cc8cfc6ec42e389f600\ntxid is f45cb5ae425796a492d4a9ecac8d60fd48bf78dbcdbe1d92725047c5dfbffba2\nFreezeBalance successful !!!\n
"},{"location":"clients/wallet-cli/#unfreezebalance","title":"UnfreezeBalance","text":"unstake TRX which staked during stake1.0.
wallet>unfreezeBalance [OwnerAddress] ResourceCode(0 BANDWIDTH,1 ENERGY,2 TRON_POWER) [receiverAddress]\n
OwnerAddressis the address of the account that initiated the transaction, optional, default is the address of the login account. ResourceCodeindicates the type of the acquired resource\uff0c0 stands for BANDWIDTH and 1 stands for ENERGY. receiverAddressis the address that will receive the resource. wallet> unfreezebalance TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8 1 TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"resource\":\"ENERGY\",\n \"receiver_address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\",\n \"owner_address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\"\n },\n \"type_url\":\"type.googleapis.com/protocol.UnfreezeBalanceContract\"\n },\n \"type\":\"UnfreezeBalanceContract\"\n }\n ],\n \"ref_block_bytes\":\"c8b7\",\n \"ref_block_hash\":\"8842722f2845274d\",\n \"expiration\":1656915213000,\n \"timestamp\":1656915154748\n },\n \"raw_data_hex\":\"0a02c8b722088842722f2845274d40c8f5debe9c305a6c080c12680a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e6365436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d68450017a1541e8bd653015895947cec33d1670a88cf67ab277b970bcaedbbe9c30\"\n}\nbefore sign transaction hex string is 0a8a010a02c8b722088842722f2845274d40c8f5debe9c305a6c080c12680a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e6365436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d68450017a1541e8bd653015895947cec33d1670a88cf67ab277b970bcaedbbe9c30\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny \nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 4th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 4\n3\nPlease input your password.\npassword: \nafter sign transaction hex string is 0a8a010a02c8b722088842722f2845274d40e8dd81c99c305a6c080c12680a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e6365436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d68450017a1541e8bd653015895947cec33d1670a88cf67ab277b970bcaedbbe9c301241593a94650274df29619a6a6946258ea32a22f24a33445f943e3d72cd7d9b8ce7234d188f4bf3a6f0c90cb60af36fc77dc8d376afac9ed840f36dfd68c429fb7e00\ntxid is 3ea58b3ac2cb05868e70d40f58916312d927c40fd1e4c549554dc3e520c1efde\nUnfreezeBalance successful !!!\n
"},{"location":"clients/wallet-cli/#getdelegatedresource","title":"GetDelegatedResource","text":"wallet>getdelegatedresource [fromAddress] [toAddress]\n
Get the information from the fromAddress, which is the resource owner's address, to the toAddress, which is the delegated address who is on behalf of the resource owner. wallet> getdelegatedresource TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8 TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\n{\n \"delegatedResource\": [\n {\n \"from\": \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"to\": \"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\",\n \"frozen_balance_for_energy\": 1000000,\n \"expire_time_for_energy\": 1656660447000\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#freezebalancev2","title":"FreezeBalanceV2","text":"Stake 2.0 API: Stake TRX to obtain TRON Power (voting rights) and bandwidth or energy.
wallet> freezeBalanceV2 [OwnerAddress] frozen_balance ResourceCode(0 BANDWIDTH,1 ENERGY,2 TRON_POWER)\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.frozen_balance is the amount of frozen TRX, the unit is the smallest unit (Sun), the minimum is 1000000sun.ResourceCode indicates the type of the acquired resource\uff0c0 BANDWIDTH and 1 ENERGY.
Example:
wallet> freezeBalanceV2 1000000 1\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"resource\":\"ENERGY\",\n \"frozen_balance\":1000000,\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\"\n },\n \"type_url\":\"type.googleapis.com/protocol.FreezeBalanceV2Contract\"\n },\n \"type\":\"FreezeBalanceV2Contract\"\n }\n ],\n \"ref_block_bytes\":\"00bb\",\n \"ref_block_hash\":\"0c237850e9e3c216\",\n \"expiration\":1676620524000,\n \"timestamp\":1676620465372\n },\n \"raw_data_hex\":\"0a0200bb22080c237850e9e3c21640e0d3fbf2e5305a59083612550a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d180170dc89f8f2e530\"\n}\nbefore sign transaction hex string is 0a770a0200bb22080c237850e9e3c21640e0d3fbf2e5305a59083612550a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d180170dc89f8f2e530\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2023-02-17T02-53-57.163000000Z--THLJLytz6UHwpmDFi5RC43D44dmnh4ZTeL.json\nThe 2th keystore file name is UTC--2023-02-17T07-40-47.121000000Z--TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM.json\nPlease choose between 1 and 2\n2\nPlease input your password.\npassword:\nafter sign transaction hex string is 0a770a0200bb22080c237850e9e3c21640dbb89efde5305a59083612550a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d180170dc89f8f2e53012419e46cc7b6706ee6a14a541df5f9c518fae9a71ac7a7cc484c48386eb0997a8ab10c41e09feb905c5cc370fe1d15968d22cec2fd2cdc5916adfd3a78c52f8d47000\ntxid is 1743aa098f5e10ac8b68ccbf0ca6b5f1364a63485e442e6cb03fd33e3331e3fb\nfreezeBalanceV2 successful !!!\n
"},{"location":"clients/wallet-cli/#unfreezebalancev2","title":"UnfreezeBalanceV2","text":"Stake 2.0 API: Unstake TRX to release bandwidth and energy and at the same time TRON Power will be reclaimed and corresponding votes will be revoked.
wallet> unfreezeBalanceV2 [OwnerAddress] unfreezeBalance ResourceCode(0 BANDWIDTH,1 ENERGY,2 TRON_POWER)\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account. unfreezeBalance Amount of TRX to be unstaked. the unit is sun.ResourceCode indicates the type of the acquired resource\uff0c0 stands for BANDWIDTH and 1 stands for ENERGY.
Example:
wallet> unfreezeBalanceV2 1000000 1\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"resource\":\"ENERGY\",\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"unfreeze_balance\":1000000\n },\n \"type_url\":\"type.googleapis.com/protocol.UnfreezeBalanceV2Contract\"\n },\n \"type\":\"UnfreezeBalanceV2Contract\"\n }\n ],\n \"ref_block_bytes\":\"0132\",\n \"ref_block_hash\":\"0772c1a1727e2ef0\",\n \"expiration\":1676620887000,\n \"timestamp\":1676620829314\n },\n \"raw_data_hex\":\"0a02013222080772c1a1727e2ef040d8e791f3e5305a5b083712570a36747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d18017082a58ef3e530\"\n}\nbefore sign transaction hex string is 0a790a02013222080772c1a1727e2ef040d8e791f3e5305a5b083712570a36747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d18017082a58ef3e530\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2023-02-17T02-53-57.163000000Z--THLJLytz6UHwpmDFi5RC43D44dmnh4ZTeL.json\nThe 2th keystore file name is UTC--2023-02-17T07-40-47.121000000Z--TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM.json\nPlease choose between 1 and 2\n2\nPlease input your password.\npassword:\nafter sign transaction hex string is 0a790a02013222080772c1a1727e2ef040ecd2b4fde5305a5b083712570a36747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d18017082a58ef3e530124111bac22e9bc35e1a78c13796893e9f2b81dc99eb26d9ce7a95d0c6a0a9b5588739c52b999acd370b255d178f57bf2abef8881891f23e042ddf83c3551b8bd98e01\ntxid is f9e114347ea89c5d722d20226817bc41c8a39ea36be756ba216cf450ab3f1fb3\nunfreezeBalanceV2 successful !!!\n
"},{"location":"clients/wallet-cli/#delegateresource","title":"DelegateResource","text":"Stake 2.0 API: delegate bandwidth or energy resource to other address.
wallet> delegateResource [OwnerAddress] balance ResourceCode(0 BANDWIDTH,1 ENERGY), ReceiverAddress [lock]\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.balance Amount of TRX staked for resources to be delegated, unit is sun.ResourceCode Resource type, \"BANDWIDTH\" is 0, \"ENERGY\" is 1.ReceiverAddress Receiver address of resource to be delegated to.lock Whether it is locked, if it is set to true, the delegated resources cannot be undelegated within 3 days. When the lock time is not over, if the owner delegates the same type of resources using the lock to the same address, the lock time will be reset to 3 days. optional, default is 0, 0-lock, 1-unlock.
Example:
wallet> delegateResource 1000000 1 TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g 0\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"balance\":1000000,\n \"resource\":\"ENERGY\",\n \"receiver_address\":\"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\"\n },\n \"type_url\":\"type.googleapis.com/protocol.DelegateResourceContract\"\n },\n \"type\":\"DelegateResourceContract\"\n }\n ],\n \"ref_block_bytes\":\"020c\",\n \"ref_block_hash\":\"54e32e95d11894f8\",\n \"expiration\":1676621547000,\n \"timestamp\":1676621487525\n },\n \"raw_data_hex\":\"0a02020c220854e32e95d11894f840f88bbaf3e5305a710839126d0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e70a5bbb6f3e530\"\n}\nbefore sign transaction hex string is 0a8f010a02020c220854e32e95d11894f840f88bbaf3e5305a710839126d0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e70a5bbb6f3e530\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2023-02-17T02-53-57.163000000Z--THLJLytz6UHwpmDFi5RC43D44dmnh4ZTeL.json\nThe 2th keystore file name is UTC--2023-02-17T07-40-47.121000000Z--TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM.json\nPlease choose between 1 and 2\n2\nPlease input your password.\npassword:\nafter sign transaction hex string is 0a8f010a02020c220854e32e95d11894f84093e9dcfde5305a710839126d0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e70a5bbb6f3e5301241414de060e9c104bb45d745e22b7b7a30b4a89a2635c62aab152fff5d2f10b7443023a9aa487be86652b74974ff6a7d82d3dbf94cea9ac1e0a7e48e682175e3f601\ntxid is 0917002d0068dde7ad4ffe46e75303d11192e17bfa78934a5f867c5ae20720ec\ndelegateResource successful !!!\n
"},{"location":"clients/wallet-cli/#undelegateresource","title":"UndelegateResource","text":"Stake 2.0 API: undelegate resource.
wallet> unDelegateResource [OwnerAddress] balance ResourceCode(0 BANDWIDTH,1 ENERGY), ReceiverAddress\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.balance Amount of TRX staked for resource to be undelegated, unit is sun.ResourceCode Resource type, \"BANDWIDTH\" is 0, \"ENERGY\" is 1.ReceiverAddress Receiver address of resource to be delegated to.
Example:
wallet> unDelegateResource 1000000 1 TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"balance\":1000000,\n \"resource\":\"ENERGY\",\n \"receiver_address\":\"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\"\n },\n \"type_url\":\"type.googleapis.com/protocol.UnDelegateResourceContract\"\n },\n \"type\":\"UnDelegateResourceContract\"\n }\n ],\n \"ref_block_bytes\":\"0251\",\n \"ref_block_hash\":\"68ac15256c213e71\",\n \"expiration\":1676621754000,\n \"timestamp\":1676621695001\n },\n \"raw_data_hex\":\"0a020251220868ac15256c213e714090ddc6f3e5305a73083a126f0a37747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e709990c3f3e530\"\n}\nbefore sign transaction hex string is 0a91010a020251220868ac15256c213e714090ddc6f3e5305a73083a126f0a37747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e709990c3f3e530\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2023-02-17T02-53-57.163000000Z--THLJLytz6UHwpmDFi5RC43D44dmnh4ZTeL.json\nThe 2th keystore file name is UTC--2023-02-17T07-40-47.121000000Z--TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM.json\nPlease choose between 1 and 2\n2\nPlease input your password.\npassword:\nafter sign transaction hex string is 0a91010a020251220868ac15256c213e7140febde9fde5305a73083a126f0a37747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e709990c3f3e530124102ebde16d1abaccd976f8ead4b5acf92b05f7d9796c28ca6a26b4e51442e638e5e33e598bb03732da24dc761a39b9d307c045b55323128dc9b07510ffc48933a01\ntxid is 537a3f4461ab55c705b77503bc42f469bfc22c0cb8588b8f3641ab40117ebfd8\nunDelegateResource successful !!!\n
"},{"location":"clients/wallet-cli/#withdrawexpireunfreeze","title":"WithdrawExpireUnfreeze","text":"Stake 2.0 API: withdraw unfrozen balance.
wallet> withdrawExpireUnfreeze [OwnerAddress]\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.
Example:
wallet> withdrawExpireUnfreeze \n
"},{"location":"clients/wallet-cli/#getavailableunfreezecount","title":"GetAvailableUnfreezeCount","text":"Stake 2.0 API: remaining times of executing unstake operation.
wallet> getavailableunfreezecount [OwnerAddress]\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.
Example:
wallet> GetAvailableUnfreezeCount\n{\n \"count\": 30\n}\n
"},{"location":"clients/wallet-cli/#getcanwithdrawunfreezeamount","title":"GetCanWithdrawUnfreezeAmount","text":"Stake 2.0 API: query the withdrawable balance at the specified timestamp.
wallet> getcanwithdrawunfreezeamount ownerAddress timestamp\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.timestamp query cutoff timestamp, in milliseconds.
Example:
wallet> getcanwithdrawunfreezeamount 1776621695001\n{\n \"amount\": 4000000\n}\n
"},{"location":"clients/wallet-cli/#getcandelegatedmaxsize","title":"GetCanDelegatedMaxsize","text":"Stake 2.0 API: query the amount of delegatable resources share of the specified resource type for an address, unit is sun.
wallet> getcandelegatedmaxsize ownerAddress type\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.type resource type, 0 is bandwidth, 1 is energy
Example:
wallet> getcandelegatedmaxsize 1\n{\n \"max_size\": 11000000\n}\n
"},{"location":"clients/wallet-cli/#getdelegatedresourcev2","title":"GetDelegatedResourceV2","text":"Stake 2.0 API\uff1aquery the detail of resource share delegated from fromAddress to toAddress.
wallet> getdelegatedresourcev2 fromAddress toAddress\n
fromAddress resource from address.toAddress resource to address.
Example:
wallet> getdelegatedresourcev2 TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\n{\n \"delegatedResource\": [\n {\n \"from\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"to\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"frozen_balance_for_bandwidth\": 7000000,\n \"frozen_balance_for_energy\": 3000000\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#getdelegatedresourceaccountindexv2","title":"GetDelegatedResourceAccountIndexV2","text":"Stake 2.0 API\uff1aquery the resource delegation index by an account. Two lists will return, one is the list of addresses the account has delegated its resources(toAddress), and the other is the list of addresses that have delegated resources to the account(fromAddress).
wallet> getdelegatedresourceaccountindexv2 ownerAddress\n
OwnerAddress account address.
Example:
wallet> getdelegatedresourceaccountindexv2 TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\n{\n \"account\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"fromAccounts\": [\n \"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\"\n ],\n \"toAccounts\": [\n \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\"\n ]\n}\n
"},{"location":"clients/wallet-cli/#getaccountnet","title":"GetAccountNet","text":"This command shows the usage of bandwidth for a certain account.
wallet> getaccountnet TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\n{\n \"freeNetUsed\": 262,\n \"freeNetLimit\": 1500,\n \"TotalNetLimit\": 43200000000,\n \"TotalNetWeight\": 8725123062\n}\n
"},{"location":"clients/wallet-cli/#getaccountresource","title":"GetAccountResource","text":"This command shows the usage of bandwidth and energy for a certain account.
wallet> getaccountresource TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\n{\n \"freeNetUsed\": 262,\n \"freeNetLimit\": 1500,\n \"TotalNetLimit\": 43200000000,\n \"TotalNetWeight\": 8725123062,\n \"tronPowerLimit\": 1,\n \"TotalEnergyLimit\": 90000000000,\n \"TotalEnergyWeight\": 328098231\n}\n
"},{"location":"clients/wallet-cli/#transaction","title":"Transaction","text":"Here are all the transaction related commands \uff1a
- SendCoin
- AddTransactionSign
- BroadcastTransaction
- BackupWallet2Base64
- GetTransactionApprovedList
"},{"location":"clients/wallet-cli/#sendcoin","title":"SendCoin","text":"> SendCoin [toAddress] [amount]\n
Here is an example of multi-signed transaction. The accounts permission have assigned as in UpdateAccountPermission section, please check for reference. wallet> SendCoin TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE 10\n{\n \"raw_data\":{\n \"contract\":[\n \u00b7\u00b7\u00b7\n \"raw_data_hex\":\"0a029ca12208432ed1fe1357ff7f40c0c484f19a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a708a8481f19a30\"\n}\nbefore sign transaction hex string is 0a83010a029ca12208432ed1fe1357ff7f40c0c484f19a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a708a8481f19a30\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\n2\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 4th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 4\n1\nPlease input your password.\npassword: \nCurrent signWeight is:\n{\n \"result\":{\n \"code\":\"NOT_ENOUGH_PERMISSION\"\n },\n \"approved_list\":[\n \"TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej\"\n ],\n \"permission\":{\n \"operations\":\"7fff1fc0033e0000000000000000000000000000000000000000000000000000\",\n \"keys\":[\n {\n \"address\":\"TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej\",\n \"weight\":1\n },\n {\n \"address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\",\n \"weight\":1\n }\n ],\n \"threshold\":2,\n \"id\":2,\n \"type\":\"Active\",\n \"permission_name\":\"active12323\"\n },\n \"current_weight\":1,\n \"transaction\":{\n \"result\":{\n \"result\":true\n },\n \"txid\":\"ece603ec8ad11578450dc8adf29dd9d9833e733c313fe16a947c8c768f1e4483\",\n \"transaction\":{\n \"signature\":[\n \"990001e909e638bbaa5de9b392121971d25cabde1391f5e164cd8a14608812df01a273e867c2329b8adb233599c5d353c435e789c777fd3e0b9fe83f0737a91101\"\n ],\n \"txID\":\"ece603ec8ad11578450dc8adf29dd9d9833e733c313fe16a947c8c768f1e4483\",\n \"raw_data\":\u00b7\u00b7\u00b7,\n \"raw_data_hex\":\"0a029ca12208432ed1fe1357ff7f40a2b3a7fb9a305a67080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a2802708a8481f19a30\"\n }\n }\n}\nPlease confirm if continue add signature enter y or Y, else any other\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 4th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 4\n4\nPlease input your password.\npassword: \nafter sign transaction hex string is 0a85010a029ca12208432ed1fe1357ff7f40a2b3a7fb9a305a67080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a2802708a8481f19a301241990001e909e638bbaa5de9b392121971d25cabde1391f5e164cd8a14608812df01a273e867c2329b8adb233599c5d353c435e789c777fd3e0b9fe83f0737a91101124141ba3ffe9c7bb1ed184df8bf635d8c987982b2f4b22c447666ac82726f4a97cb2ef4d3fabd64137b8d59239bd7173c74264733ed140ccd04934a88c438de1cab00\ntxid is ece603ec8ad11578450dc8adf29dd9d9833e733c313fe16a947c8c768f1e4483\nSend 10 Sun to TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE successful !!\n
Apermission_id is always required, it is \"0\" by default, which means this transaction only needed to be sign by owner. In the example above, we enter \"2\" to make a multi-signed transaction this time, needs the two accounts assigned actives permission in UpdateAccountPermission section above to sign this transaction. In the example, we picked the account TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej to sign first, after that, it asks you if want to add another sign ,enter y and pick the account TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE to finish multi-signing.
The weight of each account is 1 and the granting threshold is 2. When the requirements are met, the transaction is done successfully! This example shows how to complete a multi-signed transaction using the same client. When using multiple clients, please refer to the following command.
"},{"location":"clients/wallet-cli/#addtransactionsign","title":"AddTransactionSign","text":"Use the instruction addTransactionSign according to the obtained transaction hex string if signing at multiple cli.
wallet> addtransactionsign 0a83010a0241aa2208b2d2c13c86e8bd884098acb1cf9a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a30\nPlease input permission id.\n0\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 4th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 4\n3\nPlease input your password.\npassword: \n{\n \"signature\":[\n \"dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\"\n ],\n \"txID\":\"6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\",\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"amount\":10,\n \"owner_address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"to_address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\"\n },\n \"type_url\":\"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\":\"TransferContract\"\n }\n ],\n \"ref_block_bytes\":\"41aa\",\n \"ref_block_hash\":\"b2d2c13c86e8bd88\",\n \"expiration\":1656434882649,\n \"timestamp\":1656413188328\n },\n \"raw_data_hex\":\"0a0241aa2208b2d2c13c86e8bd8840d9f0d9d99a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a30\"\n}\nTransaction hex string is 0a83010a0241aa2208b2d2c13c86e8bd8840d9f0d9d99a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a301241dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\n
After signing, the users will need to broadcast final transactions manually.
"},{"location":"clients/wallet-cli/#broadcasttransaction","title":"BroadcastTransaction","text":"Broadcast the transaction, where the transaction is in hex string format.
wallet> broadcasttransaction 0a83010a0241aa2208b2d2c13c86e8bd8840d9f0d9d99a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a301241dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\nBroadcastTransaction successful !!!\n
"},{"location":"clients/wallet-cli/#gettransactionapprovedlist","title":"GetTransactionApprovedList","text":"Get signature information according to transactions.
wallet> getTransactionApprovedList\n0a8c010a020318220860e195d3609c86614096eadec79d2d5a6e080112680a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412370a1541a7d8a35b260395c14aa456297662092ba3b76fc01215415a523b449890854c8fc460ab602df9f31fe4293f18808084fea6dee11128027094bcb8bd9d2d1241c18ca91f1533ecdd83041eb0005683c4a39a2310ec60456b1f0075b4517443cf4f601a69788f001d4bc03872e892a5e25c618e38e7b81b8b1e69d07823625c2b0112413d61eb0f8868990cfa138b19878e607af957c37b51961d8be16168d7796675384e24043d121d01569895fcc7deb37648c59f538a8909115e64da167ff659c26101\n{\n \"result\":{\n\n },\n \"approved_list\":[\n \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\"\n ],\n \"transaction\":{\n \"result\":{\n \"result\":true\n },\n \"txid\":\"6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\",\n \"transaction\":{\n \"signature\":[\n \"dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\"\n ],\n \"txID\":\"6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\",\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"amount\":10,\n \"owner_address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"to_address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\"\n },\n \"type_url\":\"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\":\"TransferContract\"\n }\n ],\n \"ref_block_bytes\":\"41aa\",\n \"ref_block_hash\":\"b2d2c13c86e8bd88\",\n \"expiration\":1656434882649,\n \"timestamp\":1656413188328\n },\n \"raw_data_hex\":\"0a0241aa2208b2d2c13c86e8bd8840d9f0d9d99a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a30\"\n }\n }\n}\n
"},{"location":"clients/wallet-cli/#on-chaininquire","title":"On-ChainInquire","text":"Here are all the on-chain inquire commands \uff1a
- GetNextMaintenanceTime
- ListNodes
- GetBlock
- GetBlockbyID
- GetBlockbyLatestNum
- GetBlockbyLimitNext
- GetTransactionbyID
- GetTransactionCountbyBlockNum
- GetTransactionInfobyID
- GetTransactionInfobyBlockNum
- GetTransactionSignWeight
"},{"location":"clients/wallet-cli/#getnextmaintenancetime","title":"GetNextMaintenanceTime","text":"Get the start time of the next maintain period
wallet> GetNextMaintenanceTime\nNext maintenance time is : 2022-06-29 16:40:00\n
"},{"location":"clients/wallet-cli/#listnodes","title":"ListNodes","text":"Get other peers' information
wallet> listnodes\nIP::1.23.456.789\nPort::12345\nIP::2.345.67.89\nPort::12345\nIP::345.678.901.234\nPort::12345\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#getblock","title":"GetBlock","text":"Get the block by block height; if you do not pass the parameter, get the latest block
wallet> getblock\nGet current block !!!\n{\n \"block_header\":{\n \"raw_data\":{\n \"number\":27774469,\n \"txTrieRoot\":\"0000000000000000000000000000000000000000000000000000000000000000\",\n \"witness_address\":\"TQuzjxWcqHSh1xDUw4wmMFmCcLjz4wSCBp\",\n \"parentHash\":\"0000000001a7ce048eb88d7c3c5e9c5f8e93a6cc568f47140e243d00d0f9280a\",\n \"version\":24,\n \"timestamp\":1656919215000\n },\n \"witness_signature\":\"3af25276891b1cf7f9f72e63ad956b50e5819fb3fa6f0b6393ed092e53a90a5438620b92b5d499e0068c6775b723e3c90677157b3e9f7b8933d1e863716145f500\"\n }\n}\n
"},{"location":"clients/wallet-cli/#getblockbyid","title":"GetBlockbyID","text":"Get block based on blockID\uff08block hash\uff09
wallet> getblockbyid [blockID]\n
wallet> getblockbyid 0000000001a7cd54ee2b302cfd443cccec78e55a31902d2e7ea47e737c1a5ede\n{\n \"block_header\":{\n \"raw_data\":{\n \"number\":27774292,\n \"txTrieRoot\":\"a60f8cb160d06d5279cb463925274e18fec37f0414c4d8fdc4fb2299ccb0a8bf\",\n \"witness_address\":\"TGsdxpHNJaxsVNFFdb4R6Rib1TsKGon2Wp\",\n \"parentHash\":\"0000000001a7cd53685867286b17fa0f2389e1d3026bea0a0019c5fc37f873cb\",\n \"version\":24,\n \"timestamp\":1656918678000\n },\n \"witness_signature\":\"a93db1a8d989c6637d587369de2872a008f14d1df8f0aaeda8a54c324a44c269367ea31daf623834fd6a4ef3f6150ab8d370adff1df6c0e8c96af9cf34408d5600\"\n },\n \u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#getblockbylatestnum","title":"GetBlockByLatestNum","text":"Get the latest n blocks, where 0 < n < 100
wallet> getblockbylatestnum [n]\n
"},{"location":"clients/wallet-cli/#getblockbylimitnext","title":"GetBlockByLimitNext","text":"Get the block in a set range by block height. startBlockis the starting block height, endBlockis the ending block height.
wallet> GetBlockByLimitNext [startBlock, endBlock]\n
wallet> getblockbylimitnext 27774670 27774674\n[\n {\n \"block_header\":{\n \"raw_data\":{\n \"number\":27774670,\n \"txTrieRoot\":\"0eb9ba48deda22fafa613c0aefa6d3e0b21261ad82a126ce99a6b80e8b68045c\",\n \"witness_address\":\"TVKfvNUMcZdZbxhPLb2CkQ4nyUUhvwhv1b\",\n \"parentHash\":\"0000000001a7cecd7a2cdc58fdfd2edbfeaeb530958879bf1a299cc30043cd0b\",\n \"version\":24,\n \"timestamp\":1656919824000\n },\n \"witness_signature\":\"ee6653289e24edd24d70f4975e12934573d6e798a2a5c5e26e0b13bc6d25138c49a0f55fb0e9a5c503622b5877811403577a5e278528293d05c5f0b9d5d5542401\"\n },\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#gettransactionbyid","title":"GetTransactionbyID","text":"Get transaction information based on transaction id (hash)
wallet> GetTransactionById [transactionID]\n
"},{"location":"clients/wallet-cli/#gettransactioncountbyblocknum","title":"GetTransactionCountbyBlockNum","text":"Get how many transactions contains in a block based on block height, see below
wallet> gettransactioncountbyblocknum 27633562\nThe block contains 4 transactions\n
"},{"location":"clients/wallet-cli/#gettransactioninfobyid","title":"GetTransactionInfobyID","text":"Get transaction-info based on transaction id, generally used to check the result of a smart contract trigger
wallet> gettransactioninfobyid 6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\n{\n \"id\": \"6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\",\n \"blockNumber\": 27609041,\n \"blockTimeStamp\": 1656417906000,\n \"contractResult\": [\n \"\"\n ],\n \"receipt\": {\n \"net_usage\": 265\n }\n}\n
"},{"location":"clients/wallet-cli/#gettransactioninfobyblocknum","title":"GetTransactionInfobyBlockNum","text":"Get the list of transaction information in the block based on the block height
wallet> gettransactioninfobyblocknum [blockNum]\n
"},{"location":"clients/wallet-cli/#gettransactionsignweight","title":"GetTransactionSignWeight","text":"Get the sign weight by transaction hex string.
>getTransactionSignWeight \n0a83010a0241aa2208b2d2c13c86e8bd8840d9f0d9d99a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a301241dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\n
The information displays as follows: {\n \"result\":{\n\n },\n \"approved_list\":[\n \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\"\n ],\n \"permission\":{\n \"keys\":[\n {\n \"address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"weight\":1\n }\n ],\n \"threshold\":1,\n \"permission_name\":\"owner\"\n },\n \"current_weight\":1,\n \"transaction\":{\n \"result\":{\n \"result\":true\n },\n \"txid\":\"6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\",\n \"transaction\":{\n \"signature\":[\n \"dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\"\n ],\n \u00b7\u00b7\u00b7\n }\n }\n}\n
"},{"location":"clients/wallet-cli/#smartcontract","title":"SmartContract","text":"Below, please find all the commands for smart contract interactions:
- DeployContract
- TriggerContract
- TriggerConstantContract
- EstimateEnergy
- GetContract
- UpdateEnergyLimit
- UpdateSetting
"},{"location":"clients/wallet-cli/#deploycontract","title":"DeployContract","text":"wallet> DeployContract [ownerAddress] [contractName] [ABI] [byteCode] [constructor] [params] [isHex] [fee_limit] [consume_user_resource_percent] [origin_energy_limit] [value] [token_value] [token_id](e.g: TRXTOKEN, use # if don't provided) <library:address,library:address,...> <lib_compiler_version(e.g:v5)> library:address,...>\n
OwnerAddressis the address of the account that initiated the transaction, optional, considered as the address of the login account by default.contractName is the name of smart contract.ABI is ABI code generated when compiling.byteCode is byte code generated when compiling.constructor, params, isHex These three parameters define the format of the bytecode, which determines the way to parse byteCode from parameters.fee_limit determines the limit of consumed TRX for each transaction.consume_user_resource_percent is the percentage of user consumed resource, in the range between [0, 100%].origin_energy_limit is the most amount of developer energy consumed by triggering the contract once.value is the amount of trx transferred to the contract account.token_value is the number of TRC-10 token.token_id is TRC-10 Id.
Example:
wallet> deployContract normalcontract544 [{\"constant\":false,\"inputs\":[{\"name\":\"i\",\"type\":\"uint256\"}],\"name\": \"findArgsByIndexTest\",\"outputs\":[{\"name\":\"z\",\"type\":\"uint256\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"}]\n608060405234801561001057600080fd5b50610134806100206000396000f3006080604052600436106100405763ffffffff7c0100000000000000000000000000000000000000000000000000000000600035041663329000b58114610045575b600080fd5b34801561005157600080fd5b5061005d60043561006f565b60408051918252519081900360200190f35b604080516003808252608082019092526000916060919060208201838038833901905050905060018160008151811015156100a657fe5b602090810290910101528051600290829060019081106100c257fe5b602090810290910101528051600390829060029081106100de57fe5b6020908102909101015280518190849081106100f657fe5b906020019060200201519150509190505600a165627a7a72305820b24fc247fdaf3644b3c4c94fcee380aa610ed83415061ff9e65d7fa94a5a50a00029 # # false 1000000000 75 50000 0 0 #\n
Get the result of the contract execution with the getTransactionInfoById command: wallet> getTransactionInfoById 4978dc64ff746ca208e51780cce93237ee444f598b24d5e9ce0da885fb3a3eb9\n{\n \"id\": \"8c1f57a5e53b15bb0a0a0a0d4740eda9c31fbdb6a63bc429ec2113a92e8ff361\",\n \"fee\": 6170500,\n \"blockNumber\": 1867,\n \"blockTimeStamp\": 1567499757000,\n \"contractResult\": [\n \"6080604052600436106100405763ffffffff7c0100000000000000000000000000000000000000000000000000000000600035041663329000b58114610045575b600080fd5b34801561005157600080fd5b5061005d60043561006f565b60408051918252519081900360200190f35b604080516003808252608082019092526000916060919060208201838038833901905050905060018160008151811015156100a657fe5b602090810290910101528051600290829060019081106100c257fe5b602090810290910101528051600390829060029081106100de57fe5b6020908102909101015280518190849081106100f657fe5b906020019060200201519150509190505600a165627a7a72305820b24fc247fdaf3644b3c4c94fcee380aa610ed83415061ff9e65d7fa94a5a50a00029\"\n ],\n \"contract_address\": \"TJMKWmC6mwF1QVax8Sy2AcgT6MqaXmHEds\",\n \"receipt\": {\n \"energy_fee\": 6170500,\n \"energy_usage_total\": 61705,\n \"net_usage\": 704,\n \"result\": \"SUCCESS\"\n }\n}\n
"},{"location":"clients/wallet-cli/#triggercontract","title":"TriggerContract","text":"The command is used to trigger smart contract that deployed.
wallet> TriggerContract [ownerAddress] [contractAddress] [method] [args] [isHex] [fee_limit] [value] [token_value] [token_id]\n
OwnerAddressThe address of the account that initiated the transaction, optional, default value is the address of the login account.ContractAddress is the smart contract address.method is the name of the function and parameters, please refer to the example below.args is a parameter for placeholding, pass '#' instead when method does not need extra parameters.isHex controls the format of the parameters method and args, whether they are in hex string or not.fee_limit is the most amount of trx allows for consumption.token_value indicate the number of TRC-10 token.token_id the TRC-10 token id, If not, use \u2018#\u2019 instead.
Here is an example:
wallet> triggerContract TGdtALTPZ1FWQcc5MW7aK3o1ASaookkJxG findArgsByIndexTest(uint256) 0 false\n1000000000 0 0 #\n
Get the result of the contract execution with the getTransactionInfoById command, wallet> getTransactionInfoById 7d9c4e765ea53cf6749d8a89ac07d577141b93f83adc4015f0b266d8f5c2dec4\n{\n \"id\": \"de289f255aa2cdda95fbd430caf8fde3f9c989c544c4917cf1285a088115d0e8\",\n \"fee\": 8500,\n \"blockNumber\": 2076,\n \"blockTimeStamp\": 1567500396000,\n \"contractResult\": [\n \"\"\n ],\n \"contract_address\": \"TJMKWmC6mwF1QVax8Sy2AcgT6MqaXmHEds\",\n \"receipt\": {\n \"energy_fee\": 8500,\n \"energy_usage_total\": 85,\n \"net_usage\": 314,\n \"result\": \"REVERT\"\n },\n \"result\": \"FAILED\",\n \"resMessage\": \"REVERT opcode executed\"\n}\n
"},{"location":"clients/wallet-cli/#triggerconstantcontract","title":"TriggerConstantContract","text":"Invoke the readonly function (modified by the view or pure modifier) of a contract for contract data query; or Invoke the non-readonly function of a contract for predicting whether the transaction can be successfully executed or estimating the energy consumption.
wallet> TriggerConstantContract ownerAddress(use # if you own) contractAddress method args isHex [value token_value token_id(e.g: TRXTOKEN, use # if don't provided)]\n
ownerAddress Owner address that triggers the contract. If it is the login account, please input #.contractAddress Smart contract address.method Function call.args Parameters, if there is no parameter of method, please input #. isHex argsis hex string or not\u3002value TRX amount to be transferred. Optional, if no value, # can be inplaced.token_value TRC-10 token amount to be transferred. Optional, if no value, # can be inplaced.token_id TRC-10 token id to be transferred. Optional, if no value, # can be inplaced.
Example:
wallet> TriggerConstantContract TTGhREx2pDSxFX555NWz1YwGpiBVPvQA7e TVSvjZdyDSNocHm7dP3jvCmMNsCnMTPa5W transfer(address,uint256) 0000000000000000000000002ce5de57373427f799cc0a3dd03b841322514a8c00000000000000000000000000000000000000000000000000038d7ea4c68000 true\n\ntransfer(address,uint256):a9059cbb\nExecution result = {\n \"constant_result\": [\n \"0000000000000000000000000000000000000000000000000000000000000001\"\n ],\n \"result\": {\n \"result\": true\n },\n \"energy_used\": 13253,\n \"logs\": [\n {\n \"address\": \"LUijWGF4iFrT7hV37Q2Q45DU5TUBvVZb7\",\n \"topics\": [\n \"ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef\",\n \"000000000000000000000000bdc8ee51fdd1b1e01d71f836481828f88463c838\",\n \"0000000000000000000000002ce5de57373427f799cc0a3dd03b841322514a8c\"\n ],\n \"data\": \"00000000000000000000000000000000000000000000000000038d7ea4c68000\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#estimateenergy","title":"EstimateEnergy","text":"Estimate the energy required for the successful execution of smart contract transactions. But for FullNode, enabling the wallet/estimateEnergy API is optional. So please pay attention that when developers call wallet/estimateEnergy, if the error message shows that the node does not support this function when calling the new API (this node does not support estimate energy), it is recommended to continue using the wallet/triggerconstantcontract API to estimate energy consumption.
wallet> EstimateEnergy ownerAddress contractAddress method args isHex [value token_value token_id]\n
ownerAddress Owner address that triggers the contract. If it is the login account, please input #.contractAddress Smart contract address.method Function call.args Parameters, if there is no parameter of method, please input #. isHex argsis hex string or not\u3002value TRX amount to be transferred. Optional, if no value, # can be inplaced.token_value TRC-10 token amount to be transferred. Optional, if no value, # can be inplaced.token_id TRC-10 token id to be transferred. Optional, if no value, # can be inplaced.
Example:
wallet> EstimateEnergy TTGhREx2pDSxFX555NWz1YwGpiBVPvQA7e TVSvjZdyDSNocHm7dP3jvCmMNsCnMTPa5W transfer(address,uint256) 0000000000000000000000002ce5de57373427f799cc0a3dd03b841322514a8c00000000000000000000000000000000000000000000000000038d7ea4c68000 true\n\ntransfer(address,uint256):a9059cbb\nEstimate energy result = {\n \"result\": {\n \"result\": true\n },\n \"energy_required\": 14910\n}\n
"},{"location":"clients/wallet-cli/#getcontract","title":"GetContract","text":"Get the smart contract info by its address.
wallet> GetContract [contractAddress]\n
Example:
wallet> GetContract TGdtALTPZ1FWQcc5MW7aK3o1ASaookkJxG\n{\n \"origin_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"contract_address\": \"TJMKWmC6mwF1QVax8Sy2AcgT6MqaXmHEds\",\n \"abi\": {\n \"entrys\": [\n {\n \"name\": \"findArgsByIndexTest\",\n \"inputs\": [\n {\n \"name\": \"i\",\n \"type\": \"uint256\"\n }\n ],\n \"outputs\": [\n {\n \"name\": \"z\",\n \"type\": \"uint256\"\n }\n ],\n \"type\": \"Function\",\n \"stateMutability\": \"Nonpayable\"\n }\n ]\n },\n \"bytecode\": \"608060405234801561001057600080fd5b50610134806100206000396000f3006080604052600436106100405763ffffffff7c0100000000000000000000000000000000000000000000000000000000600035041663329000b58114610045575b600080fd5b34801561005157600080fd5b5061005d60043561006f565b60408051918252519081900360200190f35b604080516003808252608082019092526000916060919060208201838038833901905050905060018160008151811015156100a657fe5b602090810290910101528051600290829060019081106100c257fe5b602090810290910101528051600390829060029081106100de57fe5b6020908102909101015280518190849081106100f657fe5b906020019060200201519150509190505600a165627a7a72305820b24fc247fdaf3644b3c4c94fcee380aa610ed83415061ff9e65d7fa94a5a50a00029\",\n \"consume_user_resource_percent\": 75,\n \"name\": \"normalcontract544\",\n \"origin_energy_limit\": 50000,\n \"code_hash\": \"23423cece3b4866263c15357b358e5ac261c218693b862bcdb90fa792d5714e6\"\n}\n
"},{"location":"clients/wallet-cli/#updateenergylimit","title":"UpdateEnergyLimit","text":"Update parameter energy limit\uff0cparameter are the same as above.
wallet> UpdateEnergyLimit [ownerAddress] [contract_address] [energy_limit]\n
"},{"location":"clients/wallet-cli/#updatesetting","title":"UpdateSetting","text":"Update parameter of energy consume percentage per user
wallet> UpdateSetting [ownerAddress] contract_address consume_user_resource_percent\n
"},{"location":"clients/wallet-cli/#trc-10","title":"TRC-10","text":"Below, please find all the commands for TRC-10:
- AssetIssue
- UpdateAsset
- TransferAsset
- ParticipateAssetissue
- UnfreezeAsset
- ListAssetIssue
- GetAssetIssuebyAccount
- GetAssetIssuebyID
- GetAssetIssuebyName
- GetAssetIssueListbyName
"},{"location":"clients/wallet-cli/#assetissue","title":"AssetIssue","text":"Each account is allowed to issue only ONE TRC-10 token.
wallet> AssetIssue [OwnerAddress] [AssetName] [AbbrName] [TotalSupply] [TrxNum] [AssetNum] [Precision] [StartDate] [EndDate] [Description Url] [FreeNetLimitPerAccount] [PublicFreeNetLimit] [FrozenAmount0] [FrozenDays0] [...] [FrozenAmountN] [FrozenDaysN]\n
OwnerAddress (optional) is the address of the account which initiated the transaction. Default: the address of the login account. AssetName is the name of the issued TRC-10 token.
AbbrName is the abbreviation of TRC-10 token you want to issue.
TotalSupply is total issuing amount of TRC-10 token.
- TotalSupply = Account Balance of Issuer + All Frozen Token Amount
- Account Balance Of Issuer: balance at the time of issuance
- All Frozen Token Amount: Before asset transfer and the issuance
TrxNum, AssetNum are two parameters determine the exchange rate when the token is issued.
- Exchange Rate = TrxNum / AssetNum
AssetNum: Unit in the base unit of the issued token TrxNum: Unit in SUN (0.000001 TRX)
Precision indicates how many decimal places there is.
FreeNetLimitPerAccount determines the maximum amount of bandwidth each account is allowed to use. Token issuers can freeze TRX to obtain bandwidth (TransferAssetContract only)
PublicFreeNetLimit is the maximum total amount of bandwidth which is allowed to use for all accounts. Token issuers can freeze TRX to obtain bandwidth (TransferAssetContract only)
StartDate, EndDate is the start and end date of token issuance. Within this period time, other users can participate in token issuance.
FrozenAmount0, FrozenDays0 determines the amount and days of token freeze. FrozenAmount0: Must be bigger than 0. FrozenDays0: Must between 1 and 3652.
Example:
wallet> AssetIssue TestTRX TRX 75000000000000000 1 1 2 \"2019-10-02 15:10:00\" \"2020-07-11\" \"just for test121212\" www.test.com 100 100000 10000 10 10000 1\nwallet> GetAssetIssueByAccount TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ # View published information\n{\n \"assetIssue\": [\n {\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"name\": \"TestTRX\",\n \"abbr\": \"TRX\",\n \"total_supply\": 75000000000000000,\n \"frozen_supply\": [\n {\n \"frozen_amount\": 10000,\n \"frozen_days\": 1\n },\n {\n \"frozen_amount\": 10000,\n \"frozen_days\": 10\n }\n ],\n \"trx_num\": 1,\n \"precision\": 2,\n \"num\": 1,\n \"start_time\": 1570000200000,\n \"end_time\": 1594396800000,\n \"description\": \"just for test121212\",\n \"url\": \"www.test.com\",\n \"free_asset_net_limit\": 100,\n \"public_free_asset_net_limit\": 100000,\n \"id\": \"1000001\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#updateasset","title":"UpdateAsset","text":"wallet> UpdateAsset [OwnerAddress] [newLimit] [newPublicLimit] [description url]\n
Specific meaning of the parameters are the same as they are in AssetIssue. Example:
wallet> UpdateAsset 1000 1000000 \"change description\" www.changetest.com\nwallet> GetAssetIssueByAccount TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ # to check the modified information\n{\n \"assetIssue\": [\n {\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"name\": \"TestTRX\",\n \"abbr\": \"TRX\",\n \"total_supply\": 75000000000000000,\n \"frozen_supply\": [\n {\n \"frozen_amount\": 10000,\n \"frozen_days\": 1\n },\n {\n \"frozen_amount\": 10000,\n \"frozen_days\": 10\n }\n ],\n \"trx_num\": 1,\n \"precision\": 2,\n \"num\": 1,\n \"start_time\": 1570000200000,\n \"end_time\": 1594396800000,\n \"description\": \"change description\",\n \"url\": \"www.changetest.com\",\n \"free_asset_net_limit\": 1000,\n \"public_free_asset_net_limit\": 1000000,\n \"id\": \"1000001\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#transferasset","title":"TransferAsset","text":"> TransferAsset [OwnerAddress] [ToAddress] [AssertID] [Amount]\n
OwnerAddress (optional) is the address of the account which initiated the transaction. By default, the address of the login account. ToAddress is the address of the target account.
AssertName is the TRC-10 token ID. Example: 1000001
Amount is the number of TRC10 token to transfer with.
Example:
wallet> TransferAsset TN3zfjYUmMFK3ZsHSsrdJoNRtGkQmZLBLz 1000001 1000\nwallet> getaccount TN3zfjYUmMFK3ZsHSsrdJoNRtGkQmZLBLz # to check target account information after the transfer\naddress: TN3zfjYUmMFK3ZsHSsrdJoNRtGkQmZLBLz\n assetV2\n {\n id: 1000001\n balance: 1000\n latest_asset_operation_timeV2: null\n free_asset_net_usageV2: 0\n }\n
"},{"location":"clients/wallet-cli/#participateassetissue","title":"ParticipateAssetissue","text":"> ParticipateAssetIssue [OwnerAddress] [ToAddress] [AssetID] [Amount]\n
OwnerAddress (optional) is the address of the account which initiated the transaction. Default: the address of the login account. ToAddress is the account address of TRC10 issuers.
AssertName is the TRC-10 token ID. Example: 1000001
Amount is the number of TRC10 token to transfers with.
The participation process must happen during the release of TRC10, otherwise an error may occur.
Example:
wallet> ParticipateAssetIssue TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ 1000001 1000\nwallet> getaccount TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW # View remaining balance\naddress: TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\nassetV2\n {\n id: 1000001\n balance: 1000\n latest_asset_operation_timeV2: null\n free_asset_net_usageV2: 0\n }\n
"},{"location":"clients/wallet-cli/#unfreezeasset","title":"UnfreezeAsset","text":"To unfreeze all TRC10 token which are supposed to be unfrozen after the freezing period.
wallet> unfreezeasset [OwnerAddress]\n
"},{"location":"clients/wallet-cli/#listassetissue","title":"ListAssetIssue","text":"Obtain all of the published TRC10 token information.
wallet> listassetissue\n{\n \"assetIssue\": [\n {\n \"owner_address\": \"TMWXhuxiT1KczhBxCseCDDsrhmpYGUcoA9\",\n \"name\": \"tronlink_token\",\n \"abbr\": \"tronlink_token\",\n \"total_supply\": 1000000000000000,\n \"frozen_supply\": [\n {\n \"frozen_amount\": 1,\n \"frozen_days\": 1\n }\n ],\n \"trx_num\": 1,\n \"precision\": 6,\n \"num\": 1,\n \"start_time\": 1574757000000,\n \"end_time\": 1757595000000,\n \"description\": \"Description\",\n \"url\": \"https://blog.csdn.net/u010270891/article/details/82978260\",\n \"free_asset_net_limit\": 1000,\n \"public_free_asset_net_limit\": 2000,\n \"id\": \"1000001\"\n },\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#getassetissuebyaccount","title":"GetAssetIssuebyAccount","text":"Obtain TRC10 token information based on owner address.
wallet> getassetissuebyaccount [owneraddress]\n
wallet> getassetissuebyaccount TUwjpfqW7NG6BF3GCTrKy1aDvfchwSG4tN\n{\n \"assetIssue\": [\n {\n \"owner_address\": \"TUwjpfqW7NG6BF3GCTrKy1aDvfchwSG4tN\",\n \"name\": \"h00966\",\n \"abbr\": \"h00966\",\n \"total_supply\": 100000000000,\n \"trx_num\": 1000000,\n \"precision\": 6,\n \"num\": 1000000,\n \"start_time\": 1656374400000,\n \"end_time\": 1656460800000,\n \"description\": \"Automated gaming platform. \nTRC10 token h0966.\nMore info on website. TRC10 token h0966.\nMore info on website. More info on website.\",\n \"url\": \"https://h00966.com\",\n \"id\": \"1004901\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#getassetissuebyid","title":"GetAssetIssuebyID","text":"Obtain TRC10 token Information based on token ID.
wallet> GetAssetIssueById 1004901\n{\n \"owner_address\": \"TUwjpfqW7NG6BF3GCTrKy1aDvfchwSG4tN\",\n \"name\": \"h00966\",\n \"abbr\": \"h00966\",\n \"total_supply\": 100000000000,\n \"trx_num\": 1000000,\n \"precision\": 6,\n \"num\": 1000000,\n \"start_time\": 1656374400000,\n \"end_time\": 1656460800000,\n \"description\": \"Automated gaming platform. \nTRC10 token h0966.\nMore info on website.TRC10 token h0966.\nMore info on website.More info on website.\",\n \"url\": \"https://h00966.com\",\n \"id\": \"1004901\"\n}\n
"},{"location":"clients/wallet-cli/#getassetissuebyname","title":"GetAssetIssuebyName","text":"Obtain TRC10 token Information based on token names.
wallet> GetAssetIssueByname h00966\n{\n \"owner_address\": \"TUwjpfqW7NG6BF3GCTrKy1aDvfchwSG4tN\",\n \"name\": \"h00966\",\n \"abbr\": \"h00966\",\n \"total_supply\": 100000000000,\n \"trx_num\": 1000000,\n \"precision\": 6,\n \"num\": 1000000,\n \"start_time\": 1656374400000,\n \"end_time\": 1656460800000,\n \"description\": \"Automated gaming platform. \nTRC10 token h0966.\nMore info on website.TRC10 token h0966.\nMore info on website.More info on website.\",\n \"url\": \"https://h00966.com\",\n \"id\": \"1004901\"\n}\n
"},{"location":"clients/wallet-cli/#getassetissuelistbyname","title":"GetAssetIssueListbyName","text":"Obtain a list of TRC10 token information based on names.
wallet> GetAssetIssueListByName ROFLOTOKEN\n{\n \"assetIssue\": [\n {\n \"owner_address\": \"TLvQSVH9Hm7kxLFtTP228fN6pCrHmtVjpb\",\n \"name\": \"ROFLOTOKEN\",\n \"abbr\": \"roflotoken\",\n \"total_supply\": 10000000000000000,\n \"trx_num\": 1000000,\n \"precision\": 6,\n \"num\": 100000000,\n \"start_time\": 1656349200000,\n \"end_time\": 1656435600000,\n \"description\": \"roflotoken.com\",\n \"url\": \"https://haxibaibo.com/\",\n \"id\": \"1004898\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#governance","title":"Governance","text":"Any proposal-related operations, except for viewing operations, must be performed by committee members. Please find all the commands for Governance:
- CreateProposal
- ApproveProposal
- DeleteProposal
- ListProposals
- ListProposalsPaginated
- GetProposal
- VoteWitness
- ListWitnesses
- GetBrokerage
- GetReward
- UpdateBrokerage
"},{"location":"clients/wallet-cli/#creatproposal","title":"CreatProposal","text":"Initiate a proposal with createProposal.
wallet> createProposal [OwnerAddress] [id0] [value0] ... [idN] [valueN]\n
OwnerAddress (optional) is the address of the account which initiated the transaction. By default, it is the address of the login account. id0 is the serial number of TRON Network Parameter. Of which, each one has a serial number corresponded. Please refer to http://tronscan.org/#/sr/committee.
Value0 is the modified value.
In the example, modification No.4 (modifying token issuance fee) costs 1000TRX as follows:
wallet> createProposal 4 1000\nwallet> listproposals # to check initiated proposal\n{\n \"proposals\": [\n {\n \"proposal_id\": 1,\n \"proposer_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"parameters\": [\n {\n \"key\": 4,\n \"value\": 1000\n }\n ],\n \"expiration_time\": 1567498800000,\n \"create_time\": 1567498308000\n }\n ]\n}\n
The corresponding id is 1."},{"location":"clients/wallet-cli/#approveproposal","title":"ApproveProposal","text":"Approve or disapprove a proposal using approveProposal.
wallet> approveProposal [OwnerAddress] [id] [is_or_not_add_approval]\n
OwnerAddress (optional) is the address of the account which initiated the transaction. Default: the address of the login account. id is the ID of the initiated proposal. Example: 1.
is_or_not_add_approval is true for approve; is false for disapprove.
Example:
wallet> ApproveProposal 1 true # in favor of the offer\nwallet> ApproveProposal 1 false # Cancel the approved proposal\n
"},{"location":"clients/wallet-cli/#deleteproposal","title":"DeleteProposal","text":"wallet> deleteProposal [OwnerAddress] [proposalId]\n
proposalId is the ID of the initiated proposal. Example: 1. The proposal must be canceled by the supernode that initiated the proposal.
Example\uff1a
wallet> DeleteProposal 1\n
"},{"location":"clients/wallet-cli/#listproposals","title":"ListProposals","text":"Obtain a list of initiated proposals
wallet> listproposals\n{\n \"proposals\": [\n {\n \"proposal_id\": 12732,\n \"proposer_address\": \"TQ4eBJna51sew13DBLd7YjEHHHW7fkNzc2\",\n \"parameters\": [\n {\n \"key\": 65,\n \"value\": 1\n },\n {\n \"key\": 66,\n \"value\": 1\n },\n {\n \"key\": 62,\n \"value\": 432000000\n }\n ],\n \"expiration_time\": 1656491400000,\n \"create_time\": 1656490794000,\n \"approvals\": [\n \"TQ4eBJna51sew13DBLd7YjEHHHW7fkNzc2\"\n ],\n \"state\": \"DISAPPROVED\"\n },\n {\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#listproposalspaginated","title":"ListProposalsPaginated","text":"Use the paging mode to obtain the initiated proposal.
wallet> ListProposalsPaginated [offset] [limit] \n
offset is the number of proposals you want to skip. limit is the number of proposals you want to be listed. By default, all proposals would be listed from proposal_id 1 to date. The parameter in the example below means you want to skip the first 33 proposals and list the 2 proposals right after that. wallet> listproposalspaginated 33 2\n{\n \"proposals\": [\n {\n \"proposal_id\": 34,\n \"proposer_address\": \"TEDguVMSsFw3HSizQXFK1BsrGWeuRMNN7t\",\n \"parameters\": [\n {\n \"key\": 1,\n \"value\": 9997000000\n }\n ],\n \"expiration_time\": 1582381200000,\n \"create_time\": 1582380477000,\n \"state\": \"DISAPPROVED\"\n },\n {\n \"proposal_id\": 35,\n \"proposer_address\": \"TDkSQtBhZx7Ua8qvenM4zuH52u2BsYTwzc\",\n \"parameters\": [\n {\n \"key\": 1,\n \"value\": 9997000000\n }\n ],\n \"expiration_time\": 1582381200000,\n \"create_time\": 1582380498000,\n \"state\": \"DISAPPROVED\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#getproposal","title":"GetProposal","text":"Obtain proposal information based on the proposal ID.
wallet> getproposal 34\n{\n \"proposal_id\": 34,\n \"proposer_address\": \"TEDguVMSsFw3HSizQXFK1BsrGWeuRMNN7t\",\n \"parameters\": [\n {\n \"key\": 1,\n \"value\": 9997000000\n }\n ],\n \"expiration_time\": 1582381200000,\n \"create_time\": 1582380477000,\n \"state\": \"DISAPPROVED\"\n}\n
"},{"location":"clients/wallet-cli/#votewitness","title":"VoteWitness","text":"Voting requires TRON Power, which can be obtained by freezing funds.
wallet> votewitness [SR(Super Representatives) address] [TRON Power Amount]\n
- The share calculation method is: 1 unit of share can be obtained for every 1TRX frozen.
- After unfreezing, previous vote will expire. You can avoid the invalidation of the vote by re-freezing and voting.
NOTE The TRON Network only records the status of your last vote, which means that each of your votes will overwrite all previous voting results.
For example:
wallet> freezeBalance 100000000 3 1 address # Freeze 10TRX and acquire 10 units of TRON Power\n\nwallet> votewitness [SR1] 4 [SR2] 6 # Cast 4 votes for SR1 and 6 votes for SR2 at the same time\n\nwallet> votewitness [SR1] 10 # Voted 10 votes for SR1\n
The final result of the above command was 10 votes for SR1 and 0 vote for SR2."},{"location":"clients/wallet-cli/#listwitnesses","title":"ListWitnesses","text":"Get all miner node information
wallet> listwitnesses\n{\n \"witnesses\": [\n {\n \"address\": \"TPffmvjxEcvZefQqS7QYvL1Der3uiguikE\",\n \"voteCount\": 324999518,\n \"url\": \"http://sr-26.com\",\n \"totalProduced\": 414028,\n \"totalMissed\": 20,\n \"latestBlockNum\": 27638663,\n \"latestSlotNum\": 552169224,\n \"isJobs\": true\n },\n {\n \"address\": \"TFFLWM7tmKiwGtbh2mcz2rBssoFjHjSShG\",\n \"voteCount\": 324759460,\n \"url\": \"http://sr-27.com\",\n \"totalProduced\": 414144,\n \"totalMissed\": 16,\n \"latestBlockNum\": 27638664,\n \"latestSlotNum\": 552169225,\n \"isJobs\": true\n },\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#getbrokerage","title":"GetBrokerage","text":"View the ratio of brokerage of the SR(Super Representatives).
After voting for the super representative, you will receive the rewards. The super representative has the right to decide the ratio of brokerage. The default ratio is 20%, and the super representative can adjust it.
By default, if a super representative is rewarded, he will receive 20% of the whole rewards, and 80% of the rewards will be distributed to his voters.
OwnerAddress is the address of the SR's account, it is a base58check type address.
wallet> getbrokerage TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\nThe brokerage is : 20\n
"},{"location":"clients/wallet-cli/#getreward","title":"GetReward","text":"Query unclaimed reward.
OwnerAddress is the address of the voter's account, it is a base58check type address.
wallet> getreward TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\nThe reward is : 0\n
"},{"location":"clients/wallet-cli/#updatebrokerage","title":"UpdateBrokerage","text":"Update the ratio of brokerage, this command is usually used by a super representative account.
wallet> updateBrokerage [OwnerAddress] [brokerage]\n
OwnerAddress is the address of the super representative's account, it is a base58check type address. brokerage is the ratio of brokerage you want to update to, the limit of it: 0-100.
For example:
wallet> updateBrokerage TZ7U1WVBRLZ2umjizxqz3XfearEHhXKX7h 30\n
"},{"location":"clients/wallet-cli/#dex","title":"DEX","text":"The trading and price fluctuations of trading pairs are in accordance with the Bancor Agreement.
Here are all the commands for DEX:
- ExchangeCreate
- ExchangeInject
- ExchangeTransaction
- ExchangeWithdraw
- ListExchanges
- ListExchangesPaginated
- MarketSellAsset
- MarketCancelOrder
- GetMarketOrderbyAccount
- GetMarketOrderbyID
- GetMarketPairList
- GetMarketOrderListbyPair
- GetMarketPricebyPair
"},{"location":"clients/wallet-cli/#exchangecreate","title":"ExchangeCreate","text":"Create a trading pair
wallet> exchangeCreate [OwnerAddress][first_token_id] [first_token_balance] [second_token_id] [second_token_balance]\n
OwnerAddress is the address of the account which initiated the transaction. Considered as the login account by default. First_token_id, first_token_balance is the ID and amount of the first token.
second_token_id, second_token_balance is the ID and amount of the second token.
The ID is the ID of the issued TRC10 token. If it is TRX, the ID is \"\". The amount must be greater than 0, and less than 1,000,000,000,000,000.
Example:
wallet> exchangeCreate 1000001 10000 _ 10000\n# Create trading pairs with the IDs of 1000001 and TRX, with amount 10000 for both.\n
"},{"location":"clients/wallet-cli/#exchangeinject","title":"ExchangeInject","text":"Capital injection
wallet> exchangeInject [OwnerAddress] [exchange_id] [token_id] [quant]\n
OwnerAddress is the address of the account which initiated the transaction. Default: the address of the login account. exchange_id is the ID of the trading pair to be funded.
token_id, quant is the token Id and quantity (unit in base unit) of capital injection.
When conducting a capital injection, depending on its quantity (quant), a proportion of each token in the trading pair will be withdrawn from the account, and injected into the trading pair. Depending on the difference in the balance of the transaction, the same amount of money for the same token would vary.
"},{"location":"clients/wallet-cli/#exchangetransaction","title":"ExchangeTransaction","text":"Making transaction
wallet> exchangeTransaction [OwnerAddress] [exchange_id] [token_id] [quant] [expected]\n
OwnerAddress is the address of the account which initiated the transaction. Default: the address of the login account. exchange_id is the ID of the trading pair.
token_id, quant is the ID and quantity of tokens being exchanged, equivalent to selling.
expected is the expected quantity of another token. IT must be less than quant, or an error will be reported.
Example\uff1a
wallet> ExchangeTransaction 1 1000001 100 80\n
It is expected to acquire the 80 TRX by exchanging 1000001 from the trading pair ID of 1, and the amount is 100.(Equivalent to selling an amount of 100 tokenID - 1000001, at a price of 80 TRX, in trading pair ID - 1)."},{"location":"clients/wallet-cli/#exchangewithdraw","title":"ExchangeWithdraw","text":"wallet> exchangeWithdraw [OwnerAddress] [exchange_id] [token_id] [quant]\n
OwnerAddress is the address of the account which initiated the transaction. Default: the address of the login account. Exchange_id is the ID of the trading pair to be withdrawn.
Token_id, quant is token Id and quantity (unit in base unit) of capital withdrawal.
When conducting a capital withdrawal, depending on its quantity (quant), a proportion of each token in the transaction pair is withdrawn from the trading pair, and injected into the account. Depending on the difference in the balance of the transaction, the same amount of money for the same token would vary.
You may obtain information on trading pairs by the following commands,
"},{"location":"clients/wallet-cli/#listexchanges","title":"ListExchanges","text":"List trading pairs
wallet> listexchanges\n{\n \"exchanges\": [\n {\n \"exchange_id\": 14,\n \"creator_address\": \"TCjuQbm5yab7ENTYb7tbdAKaiNa9Lrj4mo\",\n \"create_time\": 1654154880000,\n \"first_token_id\": \"1004852\",\n \"first_token_balance\": 91,\n \"second_token_id\": \"_\",\n \"second_token_balance\": 110000000\n },\n {\n \"exchange_id\": 13,\n \"creator_address\": \"TBpbKyKVUB1YLULrbhawUws69Gv33cmKDL\",\n \"create_time\": 1648004214000,\n \"first_token_id\": \"1000575\",\n \"first_token_balance\": 991,\n \"second_token_id\": \"1000184\",\n \"second_token_balance\": 1010\n },\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#listexchangespaginated","title":"ListExchangesPaginated","text":"List trading pairs by page
wallet> ListExchangesPaginated [offset] [limit]\n
offset is the number of exchange pair you want to skip. limit is the number of exchange pair you want to be listed. The parameters in the example below means to skip the first 3 exchange pairs and show the next 2 exchange pairs.
wallet> listexchangespaginated 3 2\n{\n \"exchanges\": [\n {\n \"exchange_id\": 4,\n \"creator_address\": \"TXmHTj3t5LXGvqGkr4jRNw7nf9GjquQ5yf\",\n \"create_time\": 1601458377000,\n \"first_token_id\": \"1000088\",\n \"first_token_balance\": 1,\n \"second_token_id\": \"_\",\n \"second_token_balance\": 1\n },\n {\n \"exchange_id\": 5,\n \"creator_address\": \"TTJJvoPKGVKnbUBPVTn1Zi8o6k3EfFDXVS\",\n \"create_time\": 1602578613000,\n \"first_token_id\": \"1000091\",\n \"first_token_balance\": 456125,\n \"second_token_id\": \"_\",\n \"second_token_balance\": 106968111\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#marketsellasset","title":"MarketSellAsset","text":"Create an order to sell asset
wallet> MarketSellAsset [owner_address] [sell_token_id] [sell_token_quantity] [buy_token_id] [buy_token_quantity]\n
OwnerAddress is the address of the account that initiated the transaction. sell_token_id and sell_token_quantity are the ID and amount of the token want to sell.
buy_token_id, buy_token_quantity determines the ID and amount of the token want to buy.
Example:
wallet> MarketSellAsset TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW 1000001 200 _ 100 \n
Then we use the command getTransactionInfoById to check the result of the contract execution as below, wallet> getTransactionInfoById 10040f993cd9452b25bf367f38edadf11176355802baf61f3c49b96b4480d374 \n\n{\n \"id\": \"10040f993cd9452b25bf367f38edadf11176355802baf61f3c49b96b4480d374\",\n \"blockNumber\": 669,\n \"blockTimeStamp\": 1578983493000,\n \"contractResult\": [\n \"\"\n ],\n \"receipt\": {\n \"net_usage\": 264\n }\n} \n
"},{"location":"clients/wallet-cli/#marketcancelorder","title":"MarketCancelOrder","text":"This command cancels the order.
wallet> MarketCancelOrder [owner_address] [order_id]\n
owner_address is the account address who have created the order. order_id is the order id which want to cancel.
Example:
wallet> MarketCancelOrder TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW fc9c64dfd48ae58952e85f05ecb8ec87f55e19402493bb2df501ae9d2da75db0 \n
Get the result of the contract execution with the getTransactionInfoById command: wallet> getTransactionInfoById b375787a098498623403c755b1399e82910385251b643811936d914c9f37bd27 \n{\n \"id\": \"b375787a098498623403c755b1399e82910385251b643811936d914c9f37bd27\",\n \"blockNumber\": 1582,\n \"blockTimeStamp\": 1578986232000,\n \"contractResult\": [\n \"\"\n ],\n \"receipt\": {\n \"net_usage\": 283\n }\n}\n
"},{"location":"clients/wallet-cli/#getmarketorderbyaccount","title":"GetMarketOrderbyAccount","text":"Use this command to get the order created by account(just include active status).
wallet> GetMarketOrderByAccount [ownerAddress]\n
ownerAddress is the address of the account that created market order. Example:
wallet> GetMarketOrderByAccount TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW \n{\n \"orders\": [\n {\n \"order_id\": \"fc9c64dfd48ae58952e85f05ecb8ec87f55e19402493bb2df501ae9d2da75db0\",\n \"owner_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\",\n \"create_time\": 1578983490000,\n \"sell_token_id\": \"_\",\n \"sell_token_quantity\": 100,\n \"buy_token_id\": \"1000001\",\n \"buy_token_quantity\": 200,\n \"sell_token_quantity_remain\": 100\n }\n ]\n} \n
"},{"location":"clients/wallet-cli/#getmarketorderbyid","title":"GetMarketOrderbyID","text":"Get the specific order by order_id
wallet> GetMarketOrderById [orderId]\n
Example: wallet> GetMarketOrderById fc9c64dfd48ae58952e85f05ecb8ec87f55e19402493bb2df501ae9d2da75db0 \n{\n \"order_id\": \"fc9c64dfd48ae58952e85f05ecb8ec87f55e19402493bb2df501ae9d2da75db0\",\n \"owner_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\",\n \"create_time\": 1578983490000,\n \"sell_token_id\": \"_\",\n \"sell_token_quantity\": 100,\n \"buy_token_id\": \"1000001\",\n \"buy_token_quantity\": 200,\n}\n
"},{"location":"clients/wallet-cli/#getmarketpairlist","title":"GetMarketPairList","text":"This command is to get market pair listed
wallet> getmarketpairlist\n{\n \"orderPair\": [\n {\n \"sell_token_id\": \"1000012\",\n \"buy_token_id\": \"_\"\n },\n {\n \"sell_token_id\": \"1000094\",\n \"buy_token_id\": \"1000095\"\n },\n {\n \"sell_token_id\": \"1000099\",\n \"buy_token_id\": \"1000100\"\n },\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#getmarketorderlistbypair","title":"GetMarketOrderListbyPair","text":"This command is to get market order list by c pair,
wallet> GetMarketOrderListByPair [sell_token_id] [buy_token_id]\n
sell_token_id is the ID of the token want to sell. buy_token_id is the ID of the token want to buy.
Example:
wallet> GetMarketOrderListByPair _ 1000001 \n{\n \"orders\": [\n {\n \"order_id\": \"fc9c64dfd48ae58952e85f05ecb8ec87f55e19402493bb2df501ae9d2da75db0\",\n \"owner_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\",\n \"create_time\": 1578983490000,\n \"sell_token_id\": \"_\",\n \"sell_token_quantity\": 100,\n \"buy_token_id\": \"1000001\",\n \"buy_token_quantity\": 200,\n \"sell_token_quantity_remain\": 100\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#getmarketpricebypair","title":"GetMarketPricebyPair","text":"Use this command to get market price by exchange pair.
wallet> GetMarketPriceByPair [sell_token_id] [buy_token_id]\n
sell_token_id is the ID of the token want to sell. buy_token_id is the ID of the token want to buy.
Example:
wallet> GetMarketPriceByPair _ 1000001 \n{\n \"sell_token_id\": \"_\",\n \"buy_token_id\": \"1000001\",\n \"prices\": [\n {\n \"sell_token_quantity\": 100,\n \"buy_token_quantity\": 200\n }\n ]\n}\n
"},{"location":"contracts/contract/","title":"Contract","text":""},{"location":"contracts/contract/#introduction","title":"Introduction","text":"Smart contract is a computerized transaction protocol that automatically implements its terms. Smart contract is the same as common contract, they all define the terms and rules related to the participants. Once the contract is started, it can runs in the way it is designed.
TRON smart contract support Solidity language in (Ethereum). You can find the latest solidity version in the TRON solidity repository. Write a smart contract, then build the smart contract and deploy it to TRON network. When the smart contract is triggered, the corresponding function will be executed automatically.
"},{"location":"contracts/contract/#features","title":"Features","text":"TRON virtual machine is based on Ethereum solidity language, it also has TRON's own features.
"},{"location":"contracts/contract/#defination-of-smart-contract","title":"Defination of Smart Contract","text":"TRON VM is compatible with Ethereum's smart contract, using protobuf to define the content of the contract:
message SmartContract {\n message ABI {\n message Entry {\n enum EntryType {\n UnknownEntryType = 0;\n Constructor = 1;\n Function = 2;\n Event = 3;\n Fallback = 4;\n Receive = 5;\n Error = 6;\n }\n message Param {\n bool indexed = 1;\n string name = 2;\n string type = 3;\n }\n enum StateMutabilityType {\n UnknownMutabilityType = 0;\n Pure = 1;\n View = 2;\n Nonpayable = 3;\n Payable = 4;\n }\n\n bool anonymous = 1;\n bool constant = 2;\n string name = 3;\n repeated Param inputs = 4;\n repeated Param outputs = 5;\n EntryType type = 6;\n bool payable = 7;\n StateMutabilityType stateMutability = 8;\n }\n repeated Entry entrys = 1;\n }\n bytes origin_address = 1;\n bytes contract_address = 2;\n ABI abi = 3;\n bytes bytecode = 4;\n int64 call_value = 5;\n int64 consume_user_resource_percent = 6;\n string name = 7;\n int64 origin_energy_limit = 8;\n bytes code_hash = 9;\n bytes trx_hash = 10;\n}\n
origin_address: smart contract creator address contract_address: smart contract address abi: the api information of all the function of the smart contract bytecode: smart contract byte code call_value: TRX transferred into smart contract while call the contract consume_user_resource_percent: resource consumption percentage set by the developer name: smart contract name origin_energy_limit: energy consumption of the developer limit in one call, must be greater than 0. For the old contracts, if this parameter is not set, it will be set 0, developer can use updateEnergyLimit api to update this parameter (must greater than 0) Through other two grpc message types CreateSmartContract and TriggerSmartContract to create and use smart contract.
"},{"location":"contracts/contract/#usage-of-the-function-of-smart-contract","title":"Usage of the Function of Smart Contract","text":" - constant function and inconstant function
There are two types of function according to whether any change will be made to the properties on the chain: constant function and inconstant function Constant function uses view/pure/constant to decorate, will return the result on the node it is called and not be broadcasted in the form of a transaction Inconstant function will be broadcasted in the form of a transaction while being called, the function will change the data on the chain, such as transfer, changing the value of the internal variables of contracts, etc.
Note: If you use create command inside a contract (CREATE instruction), even use view/pure/constant to decorate the dynamically created contract function, this function will still be treated as inconstant function, be dealt in the form of transaction.
- message calls
Message calls can call the functions of other contracts, also can transfer TRX to the accounts of contract and none-contract. Like the common TRON triggercontract, Message calls have initiator, recipient, data, transfer amount, fees and return attributes. Every message call can generate a new one recursively. Contract can define the distribution of the remaining energy in the internal message call. If it comes with OutOfEnergyException in the internal message call, it will return false, but not error. In the meantime, only the gas sent with the internal message call will be consumed, if energy is not specified in call.value(energy), all the remaining energy will be used.
- delegate call/call code/library
There is a special type of message call, delegate call. The difference with common message call is the code of the target address will be run in the context of the contract that initiates the call, msg.sender and msg.value remain unchanged. This means a contract can dynamically loadcode from another address while running. Storage, current address and balance all point to the contract that initiates the call, only the code is get from the address being called. This gives Solidity the ability to achieve the 'lib' function: the reusable code lib can be put in the storage of a contract to implement complex data structure library.
- CREATE command
This command will create a new contract with a new address. The only difference with Ethereum is the newly generated TRON address used the smart contract creation transaction id and the hash of nonce called combined. Different from Ethereum, the definition of nonce is the contract sequence number of the creation of the root call. Even there are many CREATE commands calls, contract number in sequence from 1. Refer to the source code for more detail. Note: Different from creating a contract by grpc's deploycontract, contract created by CREATE command does not store contract abi.
- built-in function and built-in function attribute (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)
1)TVM is compatible with solidity language's transfer format, including:\n- accompany with constructor to call transfer\n- accompany with internal function to call transfer\n- use transfer/send/call/callcode/delegatecall to call transfer\n\nNote: TRON's smart contract is different from TRON's system contract, if the transfer to address does not exist it can not create an account by smart contract transfer.\n\n2)Different accounts vote for SuperNode (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n3)SuperNode gets all the reward (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n4)SuperNode approves or disapproves the proposal (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n5)SuperNode proposes a proposal (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n6)SuperNode deletes a proposal (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n7)TRON byte address converts to solidity address (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n8)TRON string address converts to solidity address (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n9)Send token to target address (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n10)Query token amount of target address (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n11)Compatible with all the built-in functions of Ethereum\n
Note: Ethereum's RIPEMD160 function is not recommended, because the return of TRON is a hash result based on TRON's sha256, not an accurate Ethereum RIPEMD160."},{"location":"contracts/contract/#contract-address-used-in-solidity-language","title":"Contract Address Used in Solidity Language","text":"Ethereum VM address is 20 bytes, but TRON's VM address is 21 bytes.
- address conversion
Need to convert TRON's address while using in solidity (recommended):
/**\n * @dev convert uint256 (HexString add 0x at beginning) TRON address to solidity address type\n * @param tronAddress uint256 tronAddress, begin with 0x, followed by HexString\n * @return Solidity address type\n*/\n\nfunction convertFromTronInt(uint256 tronAddress) public view returns(address){\n return address(tronAddress);\n}\n
This is similar with the grammar of the conversion from other types converted to address type in Ethereum. - address judgement
Solidity has address constant judgement, if using 21 bytes address the compiler will throw out an error, so you should use 20 bytes address, like:
function compareAddress(address tronAddress) public view returns (uint256){\n // if (tronAddress == 0x41ca35b7d915458ef540ade6068dfe2f44e8fa733c) { // compile error\n if (tronAddress == 0xca35b7d915458ef540ade6068dfe2f44e8fa733c) { // right\n return 1;\n } else {\n return 0;\n }\n}\n
But if you are using wallet-cli, you can use 21 bytes address, like 0000000000000000000041ca35b7d915458ef540ade6068dfe2f44e8fa733c - variable assignment
Solidity has address constant assignment, if using 21 bytes address the compiler will throw out an error, so you should use 20 bytes address, like:
function assignAddress() public view {\n // address newAddress = 0x41ca35b7d915458ef540ade6068dfe2f44e8fa733c; // compile error\n address newAddress = 0xca35b7d915458ef540ade6068dfe2f44e8fa733c;\n // do something\n}\n
If you want to use TRON address of string type (TLLM21wteSPs4hKjbxgmH1L6poyMjeTbHm) please refer to (2-4-7,2-4-8)."},{"location":"contracts/contract/#special-constants-differ-from-ethereum","title":"Special Constants Differ from Ethereum","text":""},{"location":"contracts/contract/#currency","title":"Currency","text":"Like solidity supports ETH, TRON VM supports trx and sun, 1 trx = 1000000 sun, case sensitive, only support lower case. tron-studio supports trx and sun, remix does not support trx and sun. We recommend to use tron-studio instead of remix to build TRON smart contract.
"},{"location":"contracts/contract/#block-related","title":"Block Related","text":" - block.blockhash (uint blockNumber) returns (bytes32): specified block hash, can only apply to the latest 256 blocks and current block excluded
- block.coinbase (address): SuperNode address that produced the current block
- block.difficulty (uint): current block difficulty, not recommended, set 0
- block.gaslimit (uint): current block gas limit, not supported, set 0
- block.number (uint): current block number
- block.timestamp (uint): current block timestamp
- gasleft() returns (uint256): remaining gas
- msg.data (bytes): complete call data
- msg.gas (uint): remaining gas - since 0.4.21, not recommended, replaced by gesleft()
- msg.sender (address): message sender (current call)
- msg.sig (bytes4): first 4 bytes of call data (function identifier)
- msg.value (uint): the amount of SUN send with message
- now (uint): current block timestamp (block.timestamp)
- tx.gasprice (uint): the gas price of transaction, not recommended, set 0
- tx.origin (address): transaction initiator
Each command of smart contract consume system resource while running, we use 'Energy' as the unit of the consumption of the resource.
"},{"location":"contracts/tools/","title":"Tools","text":""},{"location":"contracts/tools/#tronide","title":"TronIDE","text":"Support the build, debug, run, etc. for solidity language written smart contract. http://www.tronide.io
"},{"location":"contracts/tools/#tronbox","title":"TronBox","text":"Support the build, deploy, transplant, etc. for solidity language written smart contract. https://developers.tron.network/reference/what-is-tronbox
"},{"location":"contracts/tools/#tronweb","title":"TronWeb","text":"Provide javascript api for the usage of smart contract. https://tronweb.network/docu/docs/intro/
"},{"location":"contracts/tools/#trongrid","title":"TronGrid","text":"Provide smart contract event query service. https://developers.tron.network/docs/trongrid
"},{"location":"contracts/tools/#trident-java","title":"Trident-java","text":"Trident-java is a lightweight SDK that includes libraries for working with TRON system contracts and smart contracts. https://tronprotocol.github.io/trident/
"},{"location":"developers/advanced-configuration/","title":"Advanced Configurations","text":"we provide some configuration items for LevelDB and gRPC in config.conf file, for fine-grained performance tuning. You may custom these items only if you have deep understanding on them, otherwise keep them as default.
"},{"location":"developers/advanced-configuration/#leveldb","title":"LevelDB","text":"You can custom LevelDB options in the storage part of config.conf, which looks like:
storage {\n # Directory for storing persistent data\n\n db.directory = \"database\",\n index.directory = \"index\",\n\n # You can custom these 14 databases' configs:\n\n # account, account-index, asset-issue, block, block-index,\n # block_KDB, peers, properties, recent-block, trans,\n # utxo, votes, witness, witness_schedule.\n\n # Otherwise, db configs will remain default and data will be stored in\n # the path of \"output-directory\" or which is set by \"-d\" (\"--output-directory\").\n\n # Attention: name is a required field that must be set !!!\n properties = [\n {\n name = \"account\",\n path = \"/path/to/account\", // relative or absolute path\n createIfMissing = true,\n paranoidChecks = true,\n verifyChecksums = true,\n compressionType = 1, // 0 - no compression, 1 - compressed with snappy\n blockSize = 4096, // 4 KB = 4 * 1024 B\n writeBufferSize = 10485760, // 10 MB = 10 * 1024 * 1024 B\n cacheSize = 10485760, // 10 MB = 10 * 1024 * 1024 B\n maxOpenFiles = 100\n }\n ]\n\n}\n
As shown in the example above, the data of database account will be stored in the path of /path/to/account/database while the index be stored in /path/to/account/index. And, the example also shows our default value of LevelDB options from createIfMissing to maxOpenFiles. You can just refer to the docs of LevelDB to figure out details of these options.
"},{"location":"developers/advanced-configuration/#grpc","title":"gRPC","text":"You can custom gPRC options in the node.rpc part of config.conf, which looks like:
node {\n rpc {\n port = 50051\n\n # Number of gRPC thread, default availableProcessors / 2\n # thread = 16\n\n # The maximum number of concurrent calls permitted for each incoming connection\n # maxConcurrentCallsPerConnection =\n\n # The HTTP/2 flow control window, default 1MB\n # flowControlWindow =\n\n # Connection being idle for longer than which will be gracefully terminated\n maxConnectionIdleInMillis = 60000\n\n # Connection lasting longer than which will be gracefully terminated\n # maxConnectionAgeInMillis =\n\n # The maximum message size allowed to be received on the server, default 4MB\n # maxMessageSize =\n\n # The maximum size of header list allowed to be received, default 8192\n # maxHeaderListSize =\n }\n}\n
"},{"location":"developers/advanced-configuration/#backup","title":"backup","text":"You can custom backup options in the node.backup part of config.conf, which looks like:
node.backup {\n # my priority, each member should use different priority\n priority = \n # members should use same port\n port = \n # peer's ip list, can't contain mine\n members = []\n}\n
policy: 1. the one which synchronized first will become master. 2. if synchronization is completed at the same time, the one with big priority will become master. E.g. create backups for node A(192.168.0.100) and node B(192.168.0.100 ): node A's configuration:
node.backup {\n priority = 8 \n port = 10001\n members = [\n \"192.168.0.101\"\n ]\n}\n
node B's configuration: node.backup {\n priority = 5\n port = 10001\n members = [\n \"192.168.0.100\"\n ]\n}\n
You may refer to the source code of io.grpc.netty.NettyServerBuilder class to see details or just make a decision according to the brief comments above.
"},{"location":"developers/archive-manifest/","title":"Leveldb Startup Optimization Plugins","text":""},{"location":"developers/archive-manifest/#introduction","title":"Introduction","text":"With the operation of levelDB, manifest file will continue to grow, huge manifest file not only affects the node startup speed, but also may cause the problem of system exit with continuous memory growth. For this reason, leveldb startup optimization plugin is introduced since GreatVoyage-v4.3.0(Bacon), which optimizes the file size of manifest and the startup process of LevelDB, reduces the memory occupation and improves the node startup speed.
Remember stop the FullNode process before any operation. This tool provides the ability to reformat the manifest according to the current database.
For more design details, please refer to: TIP298.
"},{"location":"developers/archive-manifest/#usage","title":"Usage","text":""},{"location":"developers/archive-manifest/#options-for-plug-in","title":"Options For Plug-in","text":" -b | --batch-size: [ int ] specify the batch manifest size,default\uff1a80000.-d | --database-directory: [ string ] Specify the database directory to be processed,default\uff1aoutput-directory/database.-m | --manifest-size: [ int ] Specify the minimum required manifest file size \uff0cunit:M\uff0cdefault\uff1a0.-h | --help: [ bool ] for usage help\uff0cdefault\uff1afalse.
"},{"location":"developers/archive-manifest/#how-to-get","title":"How to get","text":" - build by yourself. Under java-tron, execute
. /gradlew build, you can get Toolkit.jar under build/libs/. - Download directly. Links
"},{"location":"developers/archive-manifest/#use-steps","title":"Use Steps","text":" -
- Stop the FullNode service.
-
- Execute the Toolkit command.
-
- Start the FullNode service.
Note: Step ii is not required every time, but it is recommended to run it every time to optimize the experience.
"},{"location":"developers/archive-manifest/#how-to-use","title":"How to use","text":"After FullNode runs, the default database directory: output-directory, the optimization plugin will work with the output-directory/database directory. Developers can choose one of the following two ways according to actual situation.
"},{"location":"developers/archive-manifest/#use-it-independently","title":"Use it Independently","text":""},{"location":"developers/archive-manifest/#1stop-the-fullnode-service","title":"1.Stop the FullNode service","text":"Use kill -15 to shutdown the FullNode.jar .
Query the pid: ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}'
"},{"location":"developers/archive-manifest/#2execute-the-toolkit-command","title":"2.Execute the Toolkit command","text":"# Full command\njava -jar Toolkit.jar [-b batchSize] [-d databaseDirectory] [-m manifestSize] [-h]\n# examples\n java -jar Toolkit.jar #1. use default settings\n java -jar Toolkit.jar -d /tmp/db/database #2. Specify the database directory as /tmp/db/database\n java -jar Toolkit.jar -b 64000 #3. Specify the batch size to 64000 when optimizing Manifest\n java -jar Toolkit.jar -m 128 #4. Specify optimization only when Manifest exceeds 128M\n
After the command is executed, archive.log will be generated in the ./logs directory, you can see the result.
Note: After the command is executed\uff0cIf successful, the log will display something similar to the following, and will run generally within 120s, depending on how long the FullNode service keeps running, and if it fails there will be a corresponding error message
[main] [archive](ArchiveManifest.java:144) DatabaseDirectory:output-directory/database, maxManifestSize:0, maxBatchSize:80000,database reopen use 80 seconds total.
"},{"location":"developers/archive-manifest/#3start-the-fullnode-service","title":"3.Start the FullNode service","text":" #FullNode\nnohup java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c main_net_config.conf </dev/null &>/dev/null &\n #SR Node\nnohup java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -p private key --witness -c main_net_config.conf </dev/null &>/dev/null &\n
"},{"location":"developers/archive-manifest/#integrated-startup-script","title":"Integrated startup script","text":"#!/bin/bash\n\nAPP=$1\n\nMANIFEST_OPT=$2\n\nALL_OPT=$*\n\nNEED_REBUILD=0\n\nif [[ $1 == '--rewrite--manifest' ]] ; then\n APP=''\n NEED_REBUILD=1\n\n elif [[ $2 == '--rewrite--manifest' ]] ; then\n NEED_REBUILD=1\n fi\n\n\nrebuildManifest() {\n\n if [[ $NEED_REBUILD == 1 ]] ; then\n buildManifest\n fi\n\n}\n\n\nbuildManifest() {\n\n ARCHIVE_JAR='Toolkit.jar'\n\n java -jar $ARCHIVE_JAR $ALL_OPT\n\n if [ $? == 0 ] ; then\n\n echo 'rebuild manifest success'\n\n else\n\n echo 'rebuild manifest fail, log in logs/archive.log'\n\n fi\n\n}\n\n\n\nAPP=${APP:-\"FullNode\"}\n\nSTART_OPT=`echo ${@:2}`\n\nJAR_NAME=\"$APP.jar\"\n\nMAX_STOP_TIME=60\n\nMEM_OPT=''\n\n\n\n\n\ncheckpid() {\n\n pid=`ps -ef | grep $JAR_NAME |grep -v grep | awk '{print $2}'`\n\n return $pid\n\n}\n\ncheckPath(){\n path='output-directory/database'\n flag=1\n for p in ${ALL_OPT}\n do\n if [[ $flag == 0 ]] ; then\n path=`echo $p`\n break\n fi\n if [[ $p == '-d' || $p == '--database-directory' ]] ; then\n path=''\n flag=0\n fi\n done\n\n if [[ -z \"${path}\" ]]; then\n echo '-d /path or --database-directory /path'\n return 1\n fi\n\n if [[ -d ${path} ]]; then\n return 0\n else\n echo $path 'not exist'\n return 1\n fi\n}\n\n\n\nstopService() {\n\n count=1\n\n while [ $count -le $MAX_STOP_TIME ]; do\n\n checkpid\n\n if [ $pid ]; then\n\n kill -15 $pid\n\n sleep 1\n\n else\n\n echo \"java-tron stop\"\n\n return\n\n fi\n\n count=$[$count+1]\n\n if [ $count -eq $MAX_STOP_TIME ]; then\n\n kill -9 $pid\n\n sleep 1\n\n fi\n\n done\n\n}\n\nstartService() {\n echo `date` >> start.log\n\n total=16*1024*1024\n\n xmx=`echo \"$total/1024/1024*0.6\" | bc |awk -F. '{print $1\"g\"}'`\n\n directmem=`echo \"$total/1024/1024*0.1\" | bc |awk -F. '{print $1\"g\"}'`\n\n logtime=`date +%Y-%m-%d_%H-%M-%S`\n\n export LD_PRELOAD=\"/usr/lib64/libtcmalloc.so\"\n\n nohup java -Xms$xmx -Xmx$xmx -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -Xloggc:./gc.log\\\n -XX:+PrintGCDateStamps -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m -XX:+UseCodeCacheFlushing\\\n $MEM_OPT -XX:MaxDirectMemorySize=$directmem -XX:+HeapDumpOnOutOfMemoryError -jar $JAR_NAME $START_OPT -c config.conf >> start.log 2>&1 &\n\n pid=`ps -ef |grep $JAR_NAME |grep -v grep |awk '{print $2}'`\n\n echo \"start java-tron with pid $pid on $HOSTNAME\"\n\n}\n\n#1.Stop the FullNode service\nstopService\n\ncheckPath\n\n#2.Execute the Toolkit plugin\nif [[ 0 == $? ]] ; then\n rebuildManifest\nelse\n exit -1\nfi\n\nsleep 5\n# Start the FullNode service\nstartService\n
example Note: Save above script as start.sh, In the above script the --rewrite--manifest argument is fixed in the first or second argument.
OPTIONS
--rewrite--manifest enable leveldb startup optimization plugins\uff0cThe above plug-in option `-d -m -b -h` will take effect iff this option(--rewrite--manifest) is turned on\n
# Full command\n./start.sh [FullNode|SolidityNode] [--rewrite--manifest] [-b batchSize] [-d databaseDirectory] [-m manifestSize]\n# examples\n ./start.sh #1. Start the FullNode.jar service without the plugin\n ./start.sh SolidityNode #2. Start the SolidityNode.jar service without the plugin\n ./start.sh FullNode --rewrite--manifest #3. Execute the optimization plugin with default settings and start the FullNode.jar service\n ./start.sh --rewrite--manifest -d /tmp/db/database #4. Specify the database directory as /tmp/db/database, execute the optimization plugin, and start the FullNode.jar service\n ./start.sh --rewrite--manifest -b 64000 #5. Specify the batch size to 64000 when optimizing Manifest, and start the FullNode.jar service\n ./start.sh --rewrite--manifest -m 128 #6. Specify that optimization is performed only when the Manifest exceeds 128M, and start the FullNode.jar service\n
"},{"location":"developers/code-structure/","title":"java-tron Core Modules","text":""},{"location":"developers/code-structure/#code-structure","title":"Code Structure","text":"java-tron is a TRON network client developed based on the Java language. It implements all the functions mentioned in the TRON white paper, including consensus mechanism, cryptography, database, TVM virtual machine, network management, etc. We can run a TRON node by starting java-tron. In this article, we will describe the code structure of java-tron in detail, and introduce the functions of its various modules, to facilitate the subsequent code analysis and development of developers.
java-tron adopts a modular code structure; the code structure is clear and easy to maintain and expand. Currently java-tron is divided into 7 modules: protocol, common, chainbase, consensus, actuator, crypto, framework, the following introduces the functions of each module and its code organization.
"},{"location":"developers/code-structure/#protocol","title":"protocol","text":"For a distributed network such as blockchain, a concise and efficient data interaction protocol is very important. The protocol module defines:
- Inter-node communication protocol
- Communication protocol between modules within the node
- Agreement for Services Provided Externally
The above protocols adopt the Google Protobuf data exchange format. Compared with JSON and XML, the Google Protobuf format is more efficient and flexible and can be compiled by the ProtoBuf compiler to generate language-specific serialization and deserialization source code for the defined protocol files. Protobuf is the basis for java-tron to achieve cross-language and cross-platform.
protocol module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/protocol , its directory structure is as follows:
|-- protos\n |-- api\n | |-- api.proto\n | |-- zksnark.proto\n |-- core\n |-- Discover.proto\n |-- Tron.proto\n |-- TronInventoryItems.proto\n |-- contract\n
protos/api/ - The gRPC interface and data structure provided by the java-tron node externallyprotos/core/ - Data structure for communication between nodes and between modules within nodes Discover.proto - Node discovers related data structuresTronInventoryItems.proto - Data structure related to block transferring between nodescontract/ - Contract related data structuresTron.proto - Other important data structures, including accounts, blocks, transactions, resources, super representatives, voting, and proposals...
"},{"location":"developers/code-structure/#common","title":"common","text":"The common module encapsulates common components and tools, such as exception handling, metrics monitoring tools, etc which make it easy to use by other modules.
common module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/common, its directory structure is as follows:
|-- /common/src/main/java/org/tron\n |-- common\n | |-- args\n | |-- config\n | |-- entity\n | |-- logsfilter\n | |-- overlay\n | |-- parameter\n | |-- prometheus\n | |-- runtime\n | |-- setting\n | |-- utils\n |-- core\n |-- config\n |-- db\n |-- db2\n |-- exception\n
common/prometheus - Prometheus metrics monitoringcommon/utils - The wrapper class of basic data typecore/config - Node configuration related classescore/exception - All exception handling related classes
"},{"location":"developers/code-structure/#chainbase","title":"chainbase","text":"Chainbase is a database module. For probabilistic consensus algorithms such as PoW, PoS and DPoS, situations of switching to a new chain, however unlikely, are inevitable. Because of this, chainbase defines an interface standard supporting databases that can roll back. This interface requires databases to have a state rollback mechanism, a checkpoint-based disaster tolerant mechanism and so on.
In addition, the chainbase module features a well-designed abstract interface. Any database that implements the interface can be used for underlying storage on the blockchain, granting more flexibility to developers. LevelDB and RocksDB are two default implementations.
chainbase module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/chainbase, its directory structure is as follows:
|-- chainbase.src.main.java.org.tron\n |-- common\n | |-- bloom\n | |-- error\n | |-- overlay\n | |-- runtime\n | |-- storage\n | | |-- leveldb\n | | |-- rocksdb\n | |-- utils\n | |-- zksnark\n |-- core\n |-- actuator\n |-- capsule\n |-- db\n | |-- RevokingDatabase.java\n | |-- TronStoreWithRevoking.java\n | |-- ......\n |-- db2\n | |-- common\n | |-- core\n | |-- SnapshotManager.java\n | |-- ......\n |-- net\n |-- service\n |-- store\n
common/ - Common components, such as exception handling, tools, etc storage/leveldb/ Implemented the use of LevelDB as the underlying storage databasestorage/rocksdb/ Implemented the use of RocksDB as the underlying storage database
-
core/ - The core code of the chainbase module
-
capsule/
The encapsulation class of each data structure, such as AccountCapsule, BlockCapsule, etc. AccountCapsule is the encapsulation class of Account data structure, which provides modification and query of account data; BlockCapsule is the encapsulation class of Block data structure, which provides modification and query of block data.
-
store/
Various databases, such as AccountStore, ProposalStore, etc. AccountStore is the account database, the database name is account, which stores all account information in the TRON network; ProposalStore is the proposal database, and the database name is proposal, which stores all the proposal information in the TRON network.
-
db/ and db2/
Implemented rollbackable databases, including two rollbackable databases: AbstractRevokingStore located in the db/ directory and SnapshotManager located in the db2/ directory. Compared with AbstractRevokingStore, SnapshotManager has a more stable data rollback function and supports the extension of the underlying database. Therefore, java-tron uses SnapshotManager to roll back the database. Several important interfaces and implementation classes are as follows:
RevokingDatabase.java - It is the interface of the database container, used to manage all rollbackable databases, SnapshotManager is an implementation of this interfaceTronStoreWithRevoking.java - It is the base class that supports rollbackable databases. All rollbackable databases are their implementations, such as BlockStore, TransactionStore, etc
"},{"location":"developers/code-structure/#consensus","title":"consensus","text":"The consensus mechanism is a crucial module in blockchains. Common ones are PoW, PoS, DPoS and PBFT, etc. While Paxos, Raft, etc, are applied to consortium blockchains and other trusted networks. The consensus mechanism should match the business scenario. For instance, PoW is not suitable for real-time games that are sensitive to consensus efficiency, while PBFT can make an optimized choice for exchanges demanding high real-time capability. In this sense, a replaceable consensus is a creative innovation and an essential link in building application-specific blockchains. Even star blockchain programs like Cosmos SDK are still at a stage where the application layer provides developers with limited autonomy and the consensus at the base level is subject to Tendermint. Therefore, the ultimate goal of the consensus module is to make consensus switch as easy as configuring parameters for application developers.
consensus module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/consensus, its directory structure is as follows:
|-- consensus/src/main/java/org/tron/consensus\n |-- Consensus.java\n |-- ConsensusDelegate.java\n |-- base\n | |-- ConsensusInterface.java\n | |-- ......\n |-- dpos\n |-- pbft\n
consensus module divides the consensus process into several important parts that are defined in ConsensusInterface: start - start the consensus service with customizable startup parametersstop - stop the consensus servicereceiveBlock - define the consensus logic of receiving blocksvalidBlock - define the consensus logic of validating blocksapplyBlock - define the consensus logic of processing blocks
Currently, java-tron implements DPOS consensus and PBFT consensus based on the ConsensusInterface interface, which is located in the dpos/ and pbft/ directories respectively. Developers can also implement the ConsensusInterface interface according to their own business needs to customize the consensus mechanism.
"},{"location":"developers/code-structure/#actuator","title":"actuator","text":"Ethereum was the first to introduce the virtual machine and define the smart contract. However, smart contracts are constrained in terms of their functions and not flexible enough to accommodate the needs of complex applications. This is one of the reasons why java-tron supports the creation of a chain of applications. For the reasons mentioned, java-tron includes a separate module, Actuator, offering application developers a brand new way of development. They can choose to implant their application codes into a chain instead of running them on virtual machines.
Actuator is the executor of transactions, while applications can be viewed as a cluster of different types of transactions, each of which is executed by a corresponding actuator.
actuator module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/actuator, its directory structure is as follows:
|-- actuator/src/main/java/org/tron/core\n |-- actuator\n | |-- AbstractActuator.java\n | |-- ActuatorCreator.java\n | |-- ActuatorFactory.java\n | |-- TransferActuator.java\n | |-- VMActuator.java\n | |-- ......\n |-- utils\n |-- vm\n
actuator/ - The executors of various types of transactions in the TRON network which define the processing logic of different types of transactions. For example, TransferActuator is the processing class for transferring TRX, and FreezeBalanceV2Actuator is the processing class for staking TRX to obtain resourceutils/ - tools needed to execute transactionvm/ - TRON virtual machine related code
Actuator module defines the Actuator interface, which includes 4 different methods:
execute - execute specific actions of transactions, such as state modification, communication between modules, logic execution, etc.validate - validate authenticity of transactionsgetOwnerAddress - acquire the address of transaction initiatorscalcFee - define the logic of calculating transaction fees
Depending on their businesses, developers may set up Actuator accordingly and customize the processing of different types of transactions.
"},{"location":"developers/code-structure/#crypto","title":"crypto","text":"Crypto is a relatively independent module, but it is also a very important module. Data security in java-tron is almost entirely guaranteed by this module. Currently, SM2 and ECKey encryption algorithms are supported.
crypto module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/crypto, its directory structure is as follows:
|-- crypto/src/main/java/org/tron/common/crypto\n |-- Blake2bfMessageDigest.java\n |-- ECKey.java\n |-- Hash.java\n |-- SignInterface.java\n |-- SignUtils.java\n |-- SignatureInterface.java\n |-- cryptohash\n |-- jce\n |-- sm2\n |-- zksnark\n
sm2 and jce - Provide SM2 and ECKey encryption algorithm and signature algorithmzksnark - Provide a zero-knowledge proof algorithm
"},{"location":"developers/code-structure/#framework","title":"framework","text":"The framework is the core module of java-tron and the entrance of the node. The framework module is responsible for the initialization of each module and business logic. The framework module includes the services provided externally, the node discovery and node management process related to the P2P network, and the block broadcasting and processing procedures.
framework module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/framework, its directory structure is as follows:
|-- framework/src/main/java/org/tron\n |-- common\n | |-- application\n | |-- backup\n | |-- logsfilter\n | |-- net\n | |-- overlay\n | | |-- client\n | | |-- discover\n | | |-- message\n | | |-- server\n | |-- runtime\n | |-- zksnark\n |-- core\n | |-- Wallet.java\n | |-- capsule\n | |-- config\n | |-- consensus\n | |-- db\n | |-- metrics\n | |-- net\n | |-- services\n | |-- trie\n | |-- zen\n |-- keystore\n |-- program\n | |-- FullNode.java\n |-- tool\n
program/FullNode.java - It is the entry point of the program and initializes external HTTP, gRPC and json-rpc interface servicescore/services - Defines the externally provided services, its subdirectory http/ contains all http interface processing classes, json-rpc/ contains all json-rpc interface processing classescommon/overlay/discover - Node discovery logiccommon/overlay/server - Node management and block synchronization logic among nodescore/net - Message processing, its subdirectory /service is transaction and block broadcasting, block fetching and synchronization logiccore/db/Manager.java - Transaction and block verification and processing logic
"},{"location":"developers/code-structure/#summary","title":"Summary","text":"This article mainly introduces the code structure of java-tron, as well as the function, location and directory structure of each functional module. Through this article, you will have a general understanding of the overall structure and key interfaces of java-tron, which is helpful for subsequent code analysis and development.
"},{"location":"developers/code-structure/#chainbase_1","title":"ChainBase","text":""},{"location":"developers/code-structure/#introduction","title":"Introduction","text":"As we all know, the blockchain is essentially a non-tamperable distributed ledger, which is very suitable for solving the problem of trust. In reality, blockchain is often used for bookkeeping and transactions. For example, many applications use BTC, ETH, TRX, and other cryptos to carry out economic activities to ensure the openness and transparency of funds.
The realization of such an immutable distributed ledger is a very complex system engineering, involving many technical fields: such as p2p networks, smart contracts, databases, cryptography, consensus mechanisms, etc. Among them, the database is the basis of the underlying storage, and various blockchain teams are exploring the design and optimization of the database level.
The database module of java-tron is also called the ChainBase module. This article mainly introduces some background knowledge and shows developers the implementation details of the ChainBase module by introducing logic such as transaction processing, state rollback, and data persistence.
"},{"location":"developers/code-structure/#prerequisites","title":"Prerequisites","text":"The database is an important part of the blockchain system. It stores all the data on the blockchain and is the basis for the normal operation of the blockchain system. Each fullnode stores a full amount of data, including block data, state data, etc. java-tron uses the Account model to save the user's account state.
"},{"location":"developers/code-structure/#account-models","title":"Account Models","text":"There are currently two mainstream account models,
- UTXO
- Account Model
The UTXO model is stateless, makes it easier to process transactions concurrently, and has better privacy, but it is not programming-friendly.
In the Account Model, user data is stored in the corresponding account, and smart contracts are also stored in the account in the form of code. This model is more intuitive and easier for developers to understand. For programmability, flexibility, and other considerations, java-tron adopts the Account Model.
"},{"location":"developers/code-structure/#consensus_1","title":"Consensus","text":"The current mainstream consensus is PoW, PoS, DPoS, etc. PoW is proof of work, all nodes participate in the calculation of an expected hash result, and the node that first calculates the result has the right to produce a block, but as the computing power continues to increase, the energy consumption required to calculate the hash is also increasing. Moreover, large mining farms monopolize most of the computing power, which also goes against the original intention of decentralization.
To solve the problems faced by PoW, some people proposed PoS (Proof of Stake), which is simply understood as the more coins that the node holds, the greater the probability of obtaining the right to produce blocks, but this will lead to monopoly problems as well. In order to improve, DPoS (Delegated Proof of Stake) is proposed: the decentralization feature is guaranteed by the elected super representative, and the super representative is responsible for the block production in turn to improve the efficiency. java-tron currently adopts the DPoS consensus mechanism.
To learn more, please refer to Delegated Proof of Stake.
"},{"location":"developers/code-structure/#persistent-storage","title":"Persistent Storage","text":"There are certain differences between blockchain and traditional Internet business. The blockchain does not have particularly complex processing logic at the database level, but there are a large number of key-value read and write operations in the blockchain so there are higher requirements for data read and write performance.
Based on this consideration, java-tron uses LevelDB as the underlying data storage by default, and java-tron has a good architecture design. The interface-oriented programming mode makes the chainbase module have better scalability. All databases implemented the chainbase interface can be used as the underlying storage engine of java-tron. For example, in the chainbase v2 version, a database implementation based on RocksDB is provided.
"},{"location":"developers/code-structure/#transaction-validation","title":"Transaction Validation","text":"As we all know, the blockchain mainly stores transaction data. Before introducing the chainbase module, you need to understand the transaction processing logic in java-tron.
The transaction will be distributed to each node through network broadcast. After receiving the transaction, the node will first validate the signature of the transaction. If successful, the transaction needs to be pre-executed to determine whether the transaction is legal.
Note: The specific implementation of java-tron deviates from the above figure, and for the sake of convenience, this article collectively refers to the FullNode and SR as the nodes.
For example, to process a transfer transaction: user A transfers 100 TRX to user B, and it needs to validate whether user A has enough balance to make the transfer.
The account library in the database stores the account information of all users, including the user's balance information. How to judge whether this transfer transaction is legal? The logic of java-tron is: when a transaction is received from the network, the transaction operation will be executed immediately, that is, the account information will be modified in the local database: (accountA - 100TRX, accountB + 100TRX). If this operation can be executed successfully, it means that the transaction is legal at least in the current state, and can be packed into the block.
"},{"location":"developers/code-structure/#glossary","title":"Glossary","text":"SR\uff1a Super Representative, is responsible for block production.
FullNode\uff1a stores all block data, is responsible for transactions, block broadcasting and validation, and provides query services.
TRX\uff1a TRON native token.
"},{"location":"developers/code-structure/#state-rollback","title":"State Rollback","text":"Above we mentioned that java-tron validates whether the transaction is legal through pre-execution, but what we need to know is that the transaction is successfully validated on a certain node does not mean that the transaction has been successfully chained because the transaction has not been packed into the consensus blocks, there is a risk of being rolled back.
The consensus of java-tron follows a principle: that is, the transactions in the blocks that are approved by more than 2/3 of the SRs are the ones that are really successful on the chain. can also be understood as below,
- transactions are packed into a block
- the block is approved by more than 2/3 of the SRs
A transaction that satisfies the above two points is a successful transaction on the chain. A transaction in java-tron is finally confirmed through three stages,
- transaction validating
- transaction packing into the block
- block being accepted and applied
This also leads to a problem: in the implementation of java-tron, if a node validates the transaction, its database state changes accordingly. If the transaction is not packed into the block yet or the block it is packed into has not been approved by more than 2/3 of SR, the state of this node will be inconsistent with the state of the entire network.
Therefore, except for the processing transaction data in blocks approved by more than 2/3 SRs, all other data state changes resulting from transaction processing may need to be rolled back. There are three kinds of scenarios in total:
- after receiving a new block, roll back the state changes generated by transaction validation
- after producing a block, roll back the state changes generated by transaction validation
- if a forked takes place, roll back the state changes generated by the transactions of the blocks in the forked chain
The data state changes caused by these three scenarios may need to be rolled back and the following section explains why.
"},{"location":"developers/code-structure/#rollback-after-receiving-a-new-block","title":"Rollback after Receiving a New Block","text":"When receiving a new block, the node needs to roll back to the state at the end of the previous block and roll back all transactions validated afterward. As shown below,
If the account balance of accountA is 100 at the block height is 1000, the node receives and validates a transaction 't1', in which accountA transfers 100TRX to accountB. After receiving the new block1001, the block contains a transaction 't2', in which accountA transfers 50TRX to accountC. In theory, t2 has been packed into the block, and the priority is higher than t1. However, if no operation is done, the validation of t2 will fail because accountA does not have enough balance. Therefore, after receiving the new block 1001, the state change generated by transaction t1 needs to be rolled back.
"},{"location":"developers/code-structure/#rollback-after-producing-a-new-block","title":"Rollback after Producing a New Block","text":"First of all, readers may have a question: the validated transaction can be directly packed into the block, and it will not change the database state. Why is there a change in the database state?
Because java-tron does a secondary validation of the transaction when it is packed into the block. The secondary validation is due to the timeliness of the transaction. Still taking the above figure as an example, it can be seen from the figure, that after 1001 is received, the transaction t1 was rolled back, and the balance of accountA was deducted by 50. And then, it was the node's turn to produce a block, but t1 had become an illegal transaction at this time because the balance in accountA was not enough to transfer 100 TRX, it is not advisable to directly pack t1 into the block. So the transaction needs to be validated again, which is why the transaction needs to be validated twice when producing a block.
After the block is packed successfully, the node will broadcast the block to the network and apply the block locally. And the logic of applying will re-check the transactions in the block. So after the block is packed, a rollback operation still needs to be performed.
"},{"location":"developers/code-structure/#rollback-when-forking","title":"Rollback when Forking","text":"This is the last rollback situation, and the blockchain will inevitably fork, especially the blockchain system based on DPoS with a faster block production speed that is more prone to fork.
java-tron maintains a data structure in memory as below,
java-tron holds all blocks that have not reached consensus recently. When a forked chain occurs, according to the longest chain principle: if the block height of the forked chain is greater than the current main chain block height, the forked chain needs to be switched to the main chain. Part of the blocks on the previous main chain needs to roll back up to their common parent blocks when switching, and then apply new main chain blocks sequentially from the parent block.
As shown in the figure, fork A in the dark part was originally the main chain. Because the height of fork B continues to grow and eventually exceeds the height of A, it is necessary to roll back the data in those three blocks with heights 1003, 1002, and 1001 in fork A. Then apply fork blocks 1001', 1002', 1003', and 1004' in B in sequence.
"},{"location":"developers/code-structure/#state-rollback-implementation","title":"State Rollback Implementation","text":"This chapter explains receiving and validating transactions, block production, validating and saving blocks from the perspective of code, to further analyze the chainbase module of java-tron. If there is no further declaration, the default description is dedicated to all the Fullnode (including SR).
"},{"location":"developers/code-structure/#receiving-transactions","title":"Receiving Transactions","text":"After the node receives a transaction, it puts the transaction into the local pushTransactionQueue cache queue by calling the pushTransaction(final TransactionCapsule trx) function of the manager class and validates the transaction at the same time. And the return of this method is sort of elegant:
- if validation is successful, \u2018true' is returned
- for the transaction sent by the user to the node through the API, if the transaction validation fails, an exception will be returned to the user; for transactions received from other nodes through the network, exceptions will only be recorded locally
After the transaction validation is successful, the transactions without problems will be put into the pendingTransactionQueue, and the pendingTransactionQueue is responsible for providing the transaction set when producing blocks. If the node is an SR node, when producing a block, it will take out all or part of it from the pendingTransactionQueue (depending on how many transactions are in the pendingTransactionQueue) to generate a block.
"},{"location":"developers/code-structure/#rollback-when-receiving-blocks","title":"Rollback when Receiving Blocks","text":"A node would receive transactions broadcasted from other nodes before receiving a new block, the transactions need to be validated to determine whether they can be executed correctly. Validation means that the state needs to be changed, and a successful validation does not mean that the transaction will be finally executed, and it will be considered successful after packing into a block and the block become solidified. This step can be considered to filter out those obviously wrong transactions in advance. This is just validation. When a new block arrives, the state changed by transaction validations should be rolled back. Only the state changed when applying new blocks will not be rolled back.
When rolling back, java-tron move the transactions in the pendingTransactionQueue to rePushTransactions, and clear the pendingTransactionQueue, see the figure for a detailed explanation.
Why does the pendingTransactionQueue need to be emptied after a new block arrives? First of all, it is clear that the pendingTransactionQueue queue is responsible for providing transaction data when generating blocks, that is to say, it stores validated transactions that can be directly packed into blocks. Since the new block will also change the account state, those validated transactions in pendingTransactionQueue may not pass the validation after applying the new block (the simplest example: a transaction in the new block is that accountA spends a part of the token, resulting in a transaction amount of accountA in the queue that is not enough to pay ). After the transaction is moved to rePushTransactions, a background thread will be responsible for re-validating the transaction in the queue. If nothing is wrong, it will be put into the pendingTransactionQueue again to provide data for block production.
There is a session object in java-tron. A session represents the change in the state of a block. The session object is mainly used for rollback. For example,rolling back the state to the state of the previous block needs to be operated throughout the session, as shown in the following figure,
In the above figure, you can see that there are many different types of databases in persistent storage. These data are jointly organized into a complete blockchain. For example, blocks are stored in khasodb and blockStore, and account information is stored in accountStore...
The node maintains a session chain table, which stores the change information corresponding to the block/transaction, and the node can roll back through the change information. In the above figure, session1 is the status change of the current highest block. When a transaction is received, a new session2 will be generated. Each transaction that comes later will generate a temporary tmpSession, and after the transaction is validated, the tmpSession corresponded will be merged to session2. Before a new block is received again, all status changes generated by transaction validation will be saved in session2. When a new block arrives, directly execute the reset method of the session2 to roll back the state to the previous block.
"},{"location":"developers/code-structure/#rollback-when-producing-blocks","title":"Rollback when Producing Blocks","text":"SR needs to roll back before producing blocks. The reasons are more complicated. Let's consider a scenario first:
- The pendingTransactionQueue stores the currently validated transactions, so when an SR node produces a block, it only needs to directly pack the transactions in the pendingTransactionQueue into the block, and then roll back the state to the state of the previous block after packing.
However, there is a problem with this scheme: if the SR node has just received and applied a new block, the pendingTransactionQueue will be cleared. At this time, it is the turn of the SR to pack the block, but there is no transaction in pendingTransactionQueue. Therefore, the real implementation is that not only reads transactions from pendingTransactionQueue when generating blocks but also reads transactions from rePushTransactions and puts them into blocks if there are few transactions in pendingTransactionQueue. The above analysis shows that transactions in rePushTransactions may not be possible to pass the validation, so the transactions need to be validated again. Due to this validation logic, the state needs to be rolled back before the block is produced.
In the process of producing the block, the transaction will be validated again, so there will be a state change, but this is just block production, and the block needs to be broadcast as well, and those blocks who received the broadcast will actually change the state, so the state changes incurred by block production also need to be rolled back. As shown in the figure above, when the block production is completed, session2\" needs to be rolled back.
"},{"location":"developers/code-structure/#block-solidity","title":"Block Solidity","text":"java-tron adopts the DPoS consensus mechanism. The DPoS of java-tron is to vote for 27 nodes as block producers (also known as SR), SR has the right and obligation to produce blocks, and blocks approved by more than 2/3 of SR are considered to reach a consensus. These blocks, which are no longer rolled back are called solidified blocks. Only solidified blocks can be written to the database.
SnapshotManager in java-tron is the key entry to the storage module, holds references to all current business databases, and stores database references in a list. Each database instance supports adding a new layer of state set on its own called SnapshotImpl. It is an in-memory hashmap, multiple SnapshotImpl are associated in the form of a linked list, and one SnapshotImpl retains the data modification (in-merging or merging) involved in one state change, and SnapshotImpl is independent of each other. They are separated through this data structure, as shown in the following figure,
The SnapshotRoot in the above figure is the encapsulation class for the persistent database, which is responsible for storing the solidified data.
In the previous chapters, we talked about sessions. A session represents the changes of state in a block. In fact, a session contains the SnapshotImpl corresponding to each database. For example, all SnapshotImpl in the layer of block 5 in the above figure together constitutes the changes of block 5 to the entire database.
The changes generated after the node receives a new block will not be directly stored in the persistent storage (SnapshotRoot), but will first be stored in snapshotImpl. Each block received corresponds to a snapshotImpl. Continuously receiving blocks will lead to more and more snapshotImpl. When will they be written to persistent storage?
There are two variables in SnapshotManager: 'size' and 'maxSize'. Here we simply understand 'size' as how many layers of snapshotImpl are there currently in memory, and 'maxSize' represents the difference between the height of the current solidified block and the latest block.
This is obvious. If 'size' > 'maxSize', it means that the blocks corresponding to the first (size-maxSize) snapshotImpl are already solidified blocks, they can be placed on the disk, and then the snapshotImpl will be merged into the persistent storage. This ensures that snapshotImpl does not occupy too much memory, and also ensures that the solidified block can be persisted in time.
"},{"location":"developers/code-structure/#atomicity","title":"Atomicity","text":"The database storage of java-tron is slightly different from other public chains. For example, the Ethereum persistence layer uses only one database instance, and different types of data in Ethereum are distinguished by prefixes and stored in one database instance. However, java-tron currently stores data of different business types in its own database instances.
The two implementations have their own advantages. A single instance is easy to maintain and can be written uniformly, but the disadvantages are also obvious. For example, the amount of data in a single database continues to grow over time, and frequent access to some business databases may drag down the read-and-write performance of other businesses.
Multi-instance does not have the problem of the mutual influence of each business data read and write, and can configure different parameters according to their respective data volume and performance requirements to maximize performance, and can also independently split the database with a large amount of data. Alleviate data bloat problems. But there is a serious problem with multiple database instances: there is no native tool to support atomic writes among multiple database instances.
In order to ensure the atomic writing of multiple database instances, java-tron has added a checkpoint mechanism, which writes the changed data to the checkpoint uniformly before the multiple instances are placed on the disk. If an accident occurs in writing to multiple database instances, the changed data will be recovered from the checkpoint when the service is restarted to ensure the atomicity of writing.
The process of writing the snapshotImpl of the solidified block to the database in the previous section mainly includes two steps,
- create a checkpoint
- place snapshotImpl on disk
The operation of creating a checkpoint is more critical. A checkpoint is to persistently store the snapshotImpl in memory that needs to be written to the database in a tmp database (currently, the underlying implementation is leveldb and rocksdb). After the checkpoint is successfully created, the snapshotImpl will place on the disk. If the machine is down while placing, it will first search for the existence of tmp checkpoint data when the node restart. And if so, the data in the checkpoint will be played back to snapshotRoot.
A checkpoint data structure,
Checkpoint stores all data of a state change in one database. Different types of data are distinguished by prefixes. In order to ensure that all changed data can be placed on disk this time, the bottom layer of the database calls writeBatch() when writing.
This solution can be summarized as,
- the atomicity of writes cannot be guaranteed among multiple database instances, but a single database (most mainstream databases) supports atomic writes
- the data set that needs to be guaranteed to be written atomically is first written to a temporary database by atomic writing, and then the data is written to different database instances; if an accident occurs, it can be recovered through the data of the temporary database
"},{"location":"developers/code-structure/#summary_1","title":"Summary","text":"This article analyzes the implementation details of rollback and database writing in the chainbase module through the processing flow of transactions and blocks and also analyzes the principle of atomic writing among multiple instances of the database to prevent database damage caused by accidental downtime. We hope that reading this article can help developers to further understand and develop the java-tron database.
"},{"location":"developers/code-structure/#network","title":"Network","text":""},{"location":"developers/code-structure/#overview","title":"Overview","text":"P2P is a distributed network in which participants in the network share a part of the hardware resources they own, such as processing power, storage capacity, network connection capacity, printers, etc. These shared resources need to be provided services and content by the network, which can be accessed by other peers directly without going through an intermediate entity. Participants in this network are both providers and acquirers of service and content.
Different from the traditional Client/Server central server structure, the status of each node in the P2P network is equal. While serving as a client, each node can also serve as a server to provide services to other nodes, which greatly improves the utilization of resources.
"},{"location":"developers/code-structure/#blockchain-network","title":"Blockchain Network","text":"P2P is the network layer in the blockchain structure. The main purpose of the network layer is to realize information broadcast, verification and communication between nodes. The blockchain network is essentially a P2P network, and each node can both receive and generate information. Nodes keep communication by maintaining common blockchain data.
As the foundation of the blockchain, the P2P network brings the following advantages to the blockchain:
- Prevent single-point attack
- High fault tolerance
- Better compatibility and scalability
"},{"location":"developers/code-structure/#tron-network","title":"TRON Network","text":"The architecture diagram of TRON is as follows:
As the most fundamental module of TRON, the P2P network directly determines the stability of the entire blockchain network. The network module can be divided into the following four parts according to the function:
- Node Discovery
- Node Connection
- Block Synchronization
- Block and Transaction Broadcast
Below will separately introduce these four functional parts.
"},{"location":"developers/code-structure/#node-discovery","title":"Node Discovery","text":"Node discovery is the first step for nodes to access the blockchain network. The blockchain network is a structured P2P network which organizes all nodes in an orderly manner, such as forming a ring network or a tree-like network. Structured networks are generally implemented based on the DHT (Distributed Hash Table) algorithm. Specific implementation algorithms include Chord, Pastry, CAN, Kademlia and so on. The TRON network uses the Kademlia algorithm.
"},{"location":"developers/code-structure/#kademlia-algorithm","title":"Kademlia Algorithm","text":"Kademlia is an implementation of Distributed Hash Table (DHT), it is the core routing technology in the decentralized P2P network and can quickly find target nodes in the network without a central server.
For a detailed introduction to the algorithm, please refer to Kademlia.
"},{"location":"developers/code-structure/#kademlia-implementation-by-tron","title":"Kademlia Implementation by TRON","text":"The main points of the Kademlia algorithm implemented by TRON are as follows:
- Node ID: Randomly generated 512bit ID
- Node Distance: The node distance is obtained through the XOR operation of two nodes' ID. The formula is:
Node distance = 256 - the number of leading 0s in the node ID XOR result, if the calculation result is negative, the distance is equal to 0. - K-Bucket: The node routing table. According to the distance between the nodes, the remote nodes are divided into different buckets. The remote nodes with the same distance as the current node are recorded in the same bucket, and each bucket can accommodate up to 16 nodes. According to the calculation formula of node distance, it can be seen that the Kademlia algorithm implemented by TRON maintains a total of 256 buckets.
The node discovery protocol of TRON includes the following four UDP messages:
DISCOVER_PING - used to detect if a node is onlineDISCOVER_PONG - used in response to DISCOVER_PING messageDISCOVER_FIND_NODE - used to find other nodes closest to the target nodeDISCOVER_NEIGHBORS - used in response to DISCOVER_FIND_NODE message, will return one or more nodes, up to 16
"},{"location":"developers/code-structure/#initialize-k-buckets","title":"Initialize K-Buckets","text":"After the node is started, it will read the seed nodes configured in the node configuration file and the peer nodes recorded in the database, and then send DISCOVER_PING message to them respectively. If the reply message DISCOVER_PONG from a peer is received, and at the condition that the K bucket is not full, it will then write the peer node into the K bucket; But if the corresponding bucket has already been full (that is the bucket has reached 16 nodes), it will challenge to the earliest node in the bucket. If the challenge is successful, the old node will be deleted, and the new node will be added to the K bucket. That is the K bucket initialization process, then the node discovery process is performed.
"},{"location":"developers/code-structure/#send-discover_find_node-to-find-more-nodes","title":"Send DISCOVER_FIND_NODE to Find More Nodes","text":"The node discovery service will start two scheduled tasks (DiscoverTask and RefreshTask) to periodically perform the node discovery process to update k buckets.
DiscoverTask is to discover more nodes that are closer to myself. It is executed every 30s. The execution flow is as follows: RefreshTask is to expand the local k-bucket by random node ID, that is, to find nodes that are closer to the random node ID. It is executed every 7.2s. The execution process is as follows:
The node discovery algorithm used in DiscoverTask and RefreshTask will be executed 8 rounds in one call, and each round sends DISCOVER_FIND_NODE message to the 3 nodes closest to the target node ID in the K bucket, and waits for a reply.
"},{"location":"developers/code-structure/#receive-neighbors-messages-and-update-k-bucket","title":"Receive Neighbors' Messages and Update K Bucket","text":"When the local node receives the DISCOVER_NEIGHBORS message replied by the remote node, it will send the DISCOVER_PING message to the received neighbor node in turn, and then if it receives the reply message DISCOVER_PONG, it will judge whether the corresponding K-bucket is full, if the K-bucket is not full, it will add the new node to the K bucket, if the K bucket is full, it will challenge one of the nodes, if the challenge is successful (send a DISCOVER_PING message to the old node, if it fails to receive the reply message DISCOVER_PONG, the challenge is successful, otherwise the challenge fails), the old node will be deleted from the K bucket, and the new node will be added to the K bucket.
Nodes periodically perform node discovery tasks, continuously update K-buckets, and build their own node routing tables. The next step is to establish a connection with nodes.
"},{"location":"developers/code-structure/#node-connection","title":"Node Connection","text":"Before understanding how to establish a TCP connection between nodes, we need to first understand the peer node type.
"},{"location":"developers/code-structure/#peer-node-management","title":"Peer Node Management","text":"The local node needs to manage and classify peer nodes for efficient and stable node connection. Remote nodes can be divided into the following categories:
- Active nodes: specified in the configuration file. After the system starts, it will actively establish connections with the nodes. If the connection fails to be established, it will retry in each scheduled TCP connection task.
- Passive nodes: specified in the configuration file. The local node will passively accept connections from them.
- Trust nodes: specified in the configuration file, both Active nodes and Passive nodes are trusted nodes. When receiving a connection request from a trusted node, some other condition checks are skipped and the request is accepted directly.
- BadNodes: When an abnormal protocol packet is received, the sending node will be added to the badNodes list, valid for 1 hour. When a connection request from badNodes is received, the request will be rejected directly
- RecentlyDisconnectedNodes: When a connection is disconnected, the peer node will be added to the recentlyDisconnectedNodes list, valid for 30s, when a connection request from recentlyDisconnectedNodes is received, the request will be rejected directly
"},{"location":"developers/code-structure/#establish-tcp-connection-with-peers","title":"Establish TCP Connection with Peers","text":"After the node is started, a scheduled task poolLoopExecutor will be created to establish a TCP connection with nodes. It will select nodes and establish connections with them. The working process is as follows:
The TCP connection can be mainly divided into two steps: first, determine the node list which the node will establish a connection with. The list needs to contain the active nodes that have not successfully established a connection, and then calculate the number of connections that also need to be established, and filter out the nodes from discovered neighbors according to the node filtering strategy, then score and sort them according to the node scoring strategy, and the corresponding number of nodes with the highest score is added to the request list. Finally, TCP connections are established with the nodes in the request list.
"},{"location":"developers/code-structure/#node-filtering-strategy","title":"Node Filtering Strategy","text":"When establishing a node connection, it is necessary to filter out the following types of nodes and determine whether the node's own connection number has reached the maximum value.
- Myself
- Nodes in the recentlyDisconnectedNodes list
- Nodes in badNodes list
- Nodes that have already established a connection
- The number of connections established with the node IP has already reached the upper limit (maxConnectionsWithSameIp)
But for trusted nodes, some filtering policies are ignored and connections are always established.
"},{"location":"developers/code-structure/#node-scoring-strategy","title":"Node Scoring Strategy","text":"The node score is used to determine the priority of nodes to establish a connection. The higher the score, the higher the priority. Scoring dimensions include:
- Packet loss rate: The lower the packet loss rate, the better the communication quality. The score is inversely proportional to the packet loss rate. The highest score is 100 and the lowest is 0.
- Network delay: The smaller the network delay, the better the network quality. The score is inversely proportional to the average network latency. The highest score is 20 and the lowest is 0.
- TCP traffic: The larger the TCP traffic, the more active the communication. The score is proportional to the TCP traffic, with a maximum score of 20 and a minimum of 0
- Disconnection times: The fewer disconnection times, the more stable the node is. The score is inversely proportional to the number of disconnections. The score is 10 times the number of disconnections.
- Handshake: Nodes that have been handshake successfully before indicate that they have the same blockchain information, so it is preferred to establish a connection with them. When the number of successful Handshakes is greater than 0, the Handshake score is 20, otherwise, the score is 0.
- Penalty state: A node in the Penalty state has a score of 0 and does not participate in scoring in other dimensions. The following situations will be regarded as in the Penalty state:
- Node disconnection time is less than 60s
- The node is in the badNodes list
- Inconsistent blockchain information
When calculating the node score, first determine whether the node is in the Penalty state, if so, the score is counted as 0, otherwise, the node score is the sum of the scores of each dimension.
"},{"location":"developers/code-structure/#handshake","title":"Handshake","text":"After the TCP connection is successfully established, the node that actively initiates the TCP connection request will send a handshake message P2P_HELLO to the neighbor node, in order to confirm whether the blockchain information between the nodes is consistent and whether it is necessary to initiate the block synchronization process.
When the neighbor node receives P2P_HELLO, it will compare with the local information, such as checking whether the p2p version and the genesis block information are consistent. If all the check conditions are passed, it will reply to the P2P_HELLO message, and then perform the block synchronization or broadcast; otherwise, it will disconnect the connection.
"},{"location":"developers/code-structure/#channel-keep-alive","title":"Channel Keep-Alive","text":"Channel keep-alive is accomplished through P2P_PING, P2P_PONG TCP messages. When a node establishes a TCP connection with a neighbor node and handshakes successfully, the node will open a thread pingTask for the connection and periodically send P2P_PING messages to maintain the TCP connection, which is scheduled every 10s. If the P2P_PONG message replied is not received within the timeout period, the connection will be terminated.
"},{"location":"developers/code-structure/#block-synchronization","title":"Block Synchronization","text":"After completing the handshake with the peer node, if the peer node's blockchain is longer than the local blockchain, the block synchronization process syncService.startSync will be triggered according to the longest chain principle. The message interaction during the synchronization process is as follows:
Node A sends an SYNC_BLOCK_CHAIN message to peer node B to announce the blockchain summary information of the local chain. After the peer node B receives it, it calculates the list of missing blocks of node A, and sends the lost block ID list to node A through the BLOCK_CHAIN_INVENTORY message, carrying a maximum of 2000 block ids at a time.
After node A receives the BLOCK_CHAIN_INVENTORY message, it gets the missing block id, and sends a FETCH_INV_DATA message to node B asynchronously to request the missing block, up to 100 blocks at a time. If there are still blocks that need to be synchronized (that is, the remain_num in the BLOCK_CHAIN_INVENTORY message is greater than 0), a new round of block synchronization process will be triggered.
After node B receives the FETCH_INV_DATA message from node A, it sends the block to node A through the BLOCK message. After node A receives the BLOCK message, it asynchronously processes the block.
"},{"location":"developers/code-structure/#blockchain-summary-and-list-of-missing-blocks","title":"Blockchain Summary and List of Missing Blocks","text":"Below will take several different block synchronization scenarios as examples to illustrate the generation of the blockchain summary and the lost block ID list.
- Blockchain summary: an ordered list of block IDs, including the highest solidified block, the highest non-solidified block, and the blocks corresponding to the dichotomy.
- List of missing blocks: The neighbor node compares its own chain with the received blockchain summary, determines the missing blocks list of peers, and returns a set of consecutive block IDs and the number of remaining blocks.
"},{"location":"developers/code-structure/#normal-synchronization-scene","title":"Normal Synchronization Scene","text":"The height of the local header block is 1018, and the height of the solidified block is 1000. The two nodes have just established a connection, so the height of the common block is 0. The local blockchain summary of node A obtained by the dichotomy is 1000, 1010, 1015, 1017, and 1018.
After node B receives the blockchain summary of node A, combined with the local chain, it can produce the list of blocks that node A lacks: 1018, 1019, 1020, and 1021. Then, node A requests to synchronize blocks 1019, 1020, and 1021 according to the list of missing blocks.
"},{"location":"developers/code-structure/#chain-switching-scene","title":"Chain-Switching Scene","text":"The head block height of the local main chain is 1018, and the height of the solidified block is 1000. The two nodes have just established a connection, so the height of the common block is 0. The local blockchain summary of node A obtained by the dichotomy is 1000, 1010, 1015, 1017, and 1018.
After node B receives the chain summary of node A, it finds that the local main chain is not the same as the main chain of node A, compares the chain summary of node A and finds that the common block height is 1015, then it computes the list of blocks that node A lacks are 1015, 1016', 1017', 1018', and 1019'. Then, node A requests to synchronize blocks 1018' and 1019' according to the list of missing blocks.
In another switching chain scenario, the height of the local main chain header block is 1018, the height of the solidified block is 1000, and the common block is 1017', which is located on the fork chain. The local blockchain summary of node A obtained by the dichotomy is 1000, 1009, 1014, 1016', and 1017'.
After node B receives the chain summary of node A, combined with the local chain, it can produce the list of blocks that node A lacks 1017', 1018', and 1019'. Then, node A requests to synchronize blocks 1018', and 1019' according to the list of missing blocks.
"},{"location":"developers/code-structure/#block-and-transaction-broadcast","title":"Block and Transaction Broadcast","text":"When the super representative node produces a new block, or the fullnode receives a new transaction initiated by the user, the transaction & block broadcasting process will be initiated. When a node receives a new block or new transaction, it will forward the corresponding block or transaction, and the forwarding process is the same as that of broadcasting. The message interaction is shown in the following figure:
The types of messages involved include:
INVENTORY - broadcast list: list of block or transaction idsFETCH_INV_DATA - the list data that the node needs to get: block or transaction id listBLOCK - block dataTRXS - transaction data
Node A sends the transaction or block to be broadcast to Node B via the INVENTORY list message. After node B receives the INVENTORY list message, it needs to check the status of the peer node, and if it can receive the message, it puts the blocks/transactions in the list into the \"to be fetched queue\" invToFetch. If it is a block list, it will also trigger the \"get block & transaction task\" immediately to send a FETCH_INV_DATA message to node A to get the block & transaction.
After node A receives the FETCH_INV_DATA message, it will check whether an \"INVENTORY\" message has been sent to the peer. If it has been sent, it will send a transaction or block message to node B according to the list data. After node B receives the transaction or block message, it processes the message and triggers the forwarding process.
"},{"location":"developers/code-structure/#summary_2","title":"Summary","text":"This article introduces the implementation details related to the P2P network, the lowest level module of TRON, including node discovery, node connection, block synchronization, and the process of block and transaction broadcasting. I hope that reading this article can help developers to further understand and develop java-tron network-related modules.
"},{"location":"developers/demo/","title":"Development Example","text":"This article will take adding a new setPeer HTTP interface as an example to illustrate how to participate in the development of java-tron. Before developing, please configure the InteliJ IDE development environment.
Sometimes java-tron nodes may not be able to connect to peers due to network reasons, if you can add trusted nodes while the node is running, this will allow the node to connect to the peer even if the node discovery function is not working.
"},{"location":"developers/demo/#fork-java-tron-repository","title":"Fork java-tron Repository","text":"Fork a new repository from the https://github.com/tronprotocol/java-tron project to your personal repository, and then use the following command Clone the code locally:
$ git clone https://github.com/yourname/java-tron.git\n$ git remote add upstream https://github.com/tronprotocol/java-tron.git\n
"},{"location":"developers/demo/#sync-repository","title":"Sync Repository","text":"Before developing new features, please synchronize your fork repository with the upstream repository.
$ git fetch upstream \n$ git checkout develop \n$ git merge upstream/develop --no-ff\n
"},{"location":"developers/demo/#create-new-branch","title":"Create New Branch","text":"Pull a new branch from the develop branch of your own repository for local development, please refer to branch naming convention. In this example, the name of the new branch is: feature/ add-new-http-demo.
$ git checkout -b feature/add-new-http-demo develop\n
"},{"location":"developers/demo/#code-development","title":"Code Development","text":"Open the java-tron project in IDEA. Create a new servlet file in the java-tron/framework/src/main/java/org/tron/core/services/http directory to process HTTP requests: SetPeerServlet.java, the file should contain two functions doGet and doPost. doGet is used to handle http get requests and doPost is used to handle http post requests. If one of these types of requests is not supported, the method content can be empty.
@Component\n@Slf4j(topic = \"API\")\npublic class SetPeerServlet extends HttpServlet {\n protected void doGet(HttpServletRequest request, HttpServletResponse response) \n {}\n protected void doPost(HttpServletRequest request, HttpServletResponse response) \n {}\n}\n
In this example, the setPeer request should be sent by post, so you need to add processing logic in the doPost method, and the content of the doGet method keeps empty. The processing logic of the doPost method is:
- Get the incoming parameters
- Add peer information to the list of trusted nodes through the addPeer method
- Return the processing result of addPeer to the front-end user
@Component\n@Slf4j(topic = \"API\")\npublic class SetPeerServlet extends HttpServlet {\n @Autowired\n private ChannelManager channelManager;\n\n protected void doPost(HttpServletRequest request, HttpServletResponse response) {\n try {\n PostParams params = PostParams.getPostParams(request);\n\n JSONObject jsonObject = JSONObject.parseObject(params.getParams());\n String peerIpPort = String.valueOf(jsonObject.get(\"peer\"));\n\n boolean res = addPeer(peerIpPort);\n if (res) {\n response.getWriter().println(\"Success to set trusted peer:\" + peerIpPort);\n } else {\n response.getWriter().println(\"Fail to set the trusted peer:\" + peerIpPort);\n }\n\n } catch (Exception e) {\n logger.error(\"Exception occurs when setting peer: {}\", e.getMessage());\n try {\n response.getWriter().println(Util.printErrorMsg(e));\n } catch (IOException ioe) {\n logger.error(\"IOException occurs when setting peer: {}\", ioe.getMessage());\n }\n }\n }\n ......\n}\n
Put the processing logic of adding trust nodes in the addPeer method, which not only makes the code logic clearer, but also easier to test.
The logic of the addPeer method is:
- Check the parameters the user entered to ensure that the node ip and port are not empty
- Construct node information through
Node.instanceOf(peerIP) - Make sure that the added trust node is not self
- Add the node to the trusted node list
boolean addPeer(String peerIP) {\n try {\n if (peerIP != \"\") {\n Node node = Node.instanceOf(peerIP);\n if (!(CommonParameter.PARAMETER.nodeDiscoveryBindIp.equals(node.getHost())\n || CommonParameter.PARAMETER.nodeExternalIp.equals(node.getHost())\n || Constant.LOCAL_HOST.equals(node.getHost()))\n || CommonParameter.PARAMETER.nodeListenPort != node.getPort()) {\n\n InetAddress address = new InetSocketAddress(node.getHost(), node.getPort()).getAddress();\n channelManager.getTrustNodes().put(address, node);\n return true;\n }\n }\n } catch (Exception e) {\n logger.error(\"addPeer error - {}\", e.getMessage());\n }\n return false;\n }\n}\n
After completing the implementation of SetPeerServlet, you also need to register it in the node HTTP API service, FullNodeHttpApiService is the registration entry for the node HTTP API. Call the context.addServlet method in the start function of the FullNodeHttpApiService class to register the SetPeerServlet to the service. The name of the HTTP interface is defined as /wallet/setpeer.
public class FullNodeHttpApiService implements Service {\n ......\n @Autowired\n private SetPeerServlet setPeerServlet;\n .......\n\n @Override\n public void start() {\n ......\n context.addServlet(new ServletHolder(setPeerServlet), \"/wallet/setpeer\");\n .......\n }\n\n}\n
Then you can debug the above code, start the java-tron node in IDEA, and interact with the node through the below Curl command in the terminal: $ curl --location --request POST 'http://127.0.0.1:16667/wallet/setpeer' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"peer\":\"192.163.3.2:16667\"\n}'\n
Return: Success to set trusted peer:192.163.3.2:16667\n
At this point, the code development is complete, and then you need to write unit tests for the changes. For simple changes, unit tests can be written after the development code is completed, but for larger changes, it is recommended to write unit tests at the same time as development.
"},{"location":"developers/demo/#write-unit-test","title":"Write Unit Test","text":"The unit test of the java-tron project is based on the JUnit framework. For the usage of JUnit, please refer to JUnit official website. The following is a brief introduction to the java-tron unit test case specification and common annotations.
"},{"location":"developers/demo/#java-tron-unit-test-cases-writing-specification","title":"java-tron Unit Test Cases Writing Specification","text":"When writing java-tron unit test cases, please follow the below guidelines:
- All test classes should be placed in the test directory, and the package of the test class should be consistent with the package structure of the tested code. Generally, use
Test as the suffix of a class name - The test method must be decorated with
@Test and it must be public void type. Generally, test is used as the prefix of the method name - Each test method in the test class must be independently testable, and there must be no dependencies between methods
"},{"location":"developers/demo/#common-annotations","title":"Common Annotations","text":"The following are descriptions of some commonly used annotations. For other annotations, please refer to JUnit official website documentation.
@Test - transforms a normal method into a test method@Ignore - the decorated test method will be ignored by the test runner@BeforeClass - the method will be executed before all methods, static method (only executed once globally, and it is the first running one)@AfterClass - the method will be executed after all methods, static methods ( only executed once globally, and it will be the last running one)@Before - it will be executed once before each test method@After - it will be executed once after each test method
"},{"location":"developers/demo/#the-composition-of-the-unit-test-class","title":"The Composition Of The Unit Test Class","text":"A unit test class should contain the following three parts:
@Before or @BeforeClass decorated function, used for initialization before test case execution@After or @BeforeClass decorated function, used to process data cleaning after the test case execution- Test method decorated by
@Test
public class demoTest {\n\n @Before\n public void init() {\n // Initialization work before test case execution\n }\n @After\n public void destroy() {\n // Destroy work after test case execution\n\n }\n @Test\n public void testDemoMethod() { \n }\n}\n
For this example in the article, a new file should be created in the framework/src/test/java/org/tron/core/services/http/ directory: SetPeerServletTest.java used to write test cases.
public class SetPeerServletTest {\n private static TronApplicationContext context;\n private static Application appT;\n public static ChannelManager channelManager;\n @Before\n public void init() {\n\n Args.setParam(new String[]{}, Constant.TEST_CONF);\n context = new TronApplicationContext(DefaultConfig.class);\n channelManager = context.getBean(ChannelManager.class);\n appT = ApplicationFactory.create(context);\n appT.initServices(Args.getInstance());\n appT.startServices();\n appT.startup();\n\n }\n @After\n public void destroy() {\n Args.clearParam();\n appT.shutdownServices();\n appT.shutdown();\n\n }\n @Test\n public void testAddPeer() {\n SetPeerServlet setPeerServlet = new SetPeerServlet();\n Assert.assertFalse(setPeerServlet.addPeer(\"127.0.0.1\"));\n }\n}\n
"},{"location":"developers/demo/#code-style-check","title":"Code Style Check","text":"Check the modified files one by one, and select Check Current File in the right-click menu. If there are code style problems, please modify them one by one according to the prompts.
Fix the code style warning in the picture, and then check the file again until there is no warning.
"},{"location":"developers/demo/#commit-code","title":"Commit Code","text":"Submit the code after development complete, please refer to the commit specification.
git add .\ngit commit -m 'add a new http api setpeer'\n
Push the new branch to the personal remote repository:
git push origin feature/add-new-http-demo\n
"},{"location":"developers/demo/#submit-pull-request","title":"Submit Pull Request","text":"Submit a pull request (PR) from your repository to tronprotocol/java-tron.
"},{"location":"developers/deployment/","title":"Deployment","text":""},{"location":"developers/deployment/#premise","title":"Premise","text":"Create separate directories for fullnode and soliditynode
NOTE: SolidityNode is deprecated. Now a FullNode supports all RPCs of a SolidityNode. New developers should deploy FullNode only.
/deploy/fullnode\n/deploy/soliditynode\n
Create two folders for fullnode and soliditynode.
Clone the latest master branch of https://github.com/tronprotocol/java-tron and extract it to
/deploy/java-tron\n
Make sure you have the proper dependencies.
- JDK 1.8 (JDK 1.9+ is not supported yet)
- On Linux Ubuntu system (e.g. Ubuntu 16.04.4 LTS), ensure that the machine has Oracle JDK 8, instead of having Open JDK 8 in the system. If you are building the source code by using Open JDK 8, you will get Build Failed result.
- Open UDP ports for connection to the network
- MINIMUM 2 CPU Cores
"},{"location":"developers/deployment/#deployment-guide","title":"Deployment Guide","text":"1.\u00a0Build the java-tron project
cd /deploy/java-tron\n./gradlew build\n
2.\u00a0Copy the FullNode.jar and SolidityNode.jar along with configuration files into the respective directories
download your needed configuration file from https://github.com/tronprotocol/TronDeployment.\n\nmain_net_config.conf is the configuration for MainNet, and test_net_config.conf is the configuration for TestNet.\n\nplease rename the configuration file to `config.conf` and use this config.conf to start FullNode and SolidityNode.\n\ncp build/libs/FullNode.jar ../fullnode\n\ncp build/libs/SolidityNode.jar ../soliditynode\n
3.\u00a0You can now run your FullNode using the following command
java -jar FullNode.jar -c config.conf // make sure that your config.conf is downloaded from https://github.com/tronprotocol/TronDeployment\n
4.\u00a0Configure the SolidityNode configuration file
You need to edit config.conf to connect to your local FullNode. Change trustNode in node to local 127.0.0.1:50051, which is the default rpc port. Set listen.port to any number within the range of 1024-65535. Please don't use any ports between 0-1024 since you'll most likely hit conflicts with other system services. Also change rpc port to 50052 or something to avoid conflicts. Please forward the UDP port 18888 for FullNode.
rpc {\n port = 50052\n }\n
5.\u00a0You can now run your SolidityNode using the following command\uff1a
java -jar SolidityNode.jar -c config.conf //make sure that your config.conf is downloaded from https://github.com/tronprotocol/TronDeployment\n
6.\u00a0Running a Super Representative Node for mainnet
java -jar FullNode.jar -p your private key --witness -c your config.conf(Example\uff1a/data/java-tron/config.conf)\nExample:\njava -jar FullNode.jar -p 650950B193DDDDB35B6E48912DD28F7AB0E7140C1BFDEFD493348F02295BD812 --witness -c /data/java-tron/config.conf\n
This is similar to running a private testnet, except that the IPs in the config.conf are officially declared by TRON.
7.\u00a0Running a Super Representative Node for private testnet
You should modify the config.conf:
- Replace existing entry in genesis.block.witnesses with your address
- Replace existing entry in seed.node ip.list with your ip list
- The first Super Node start, needSyncCheck should be set false
- Set p2pversion to 61
cd build/libs\njava -jar FullNode.jar -p your private key --witness -c your config.conf (Example\uff1a/data/java-tron/config.conf)\nExample:\njava -jar FullNode.jar -p 650950B193DDDDB35B6E48912DD28F7AB0E7140C1BFDEFD493348F02295BD812 --witness -c /data/java-tron/config.conf\n
"},{"location":"developers/deployment/#logging-and-network-connection-verification","title":"Logging and Network Connection Verification","text":"Logs for both nodes are located in /deploy/\\*/logs/tron.log. Use tail -f /logs/tron.log/ to follow along with the block syncing.
You should see something similar to this in your logs for block synchronization:
FullNode
12:00:57.658 INFO [pool-7-thread-1] [o.t.c.n.n.NodeImpl](NodeImpl.java:830) Success handle block Num:236610,ID:0000000000039c427569efa27cc2493c1fff243cc1515aa6665c617c45d2e1bf\n
SolidityNode 12:00:40.691 INFO [pool-17-thread-1] [o.t.p.SolidityNode](SolidityNode.java:88) sync solidity block, lastSolidityBlockNum:209671, remoteLastSolidityBlockNum:211823\n
"},{"location":"developers/deployment/#stop-node-gracefully","title":"Stop Node Gracefully","text":"Create file stop.sh\uff0cuse kill -15 to close FullNode.jar(or SolidityNode.jar). You need to modify pid=ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}' to find the correct pid.
#!/bin/bash\nwhile true; do\n pid=`ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}'`\n if [ -n \"$pid\" ]; then\n kill -15 $pid\n echo \"The java-tron process is exiting, it may take some time, forcing the exit may cause damage to the database, please wait patiently...\"\n sleep 1\n else\n echo \"java-tron killed successfully!\"\n break\n fi\ndone\n
"},{"location":"developers/deployment/#fullnode-and-soliditynode-fast-deployment","title":"FullNode and SolidityNode Fast Deployment","text":"Download fast deployment script, run the script according to different types of node.
Scope of use This script could be used on Linux/MacOS, but not on Windows. Just Support FullNode and SolidityNode.
Download and run script wget https://raw.githubusercontent.com/tronprotocol/TronDeployment/master/deploy_tron.sh -O deploy_tron.sh\n
Parameter Illustration bash deploy_tron.sh --app [FullNode|SolidityNode] --net [mainnet|testnet|privatenet] --db [keep|remove|backup] --heap-size <heapsize>\n\n--app Optional, Running application. The default node is Fullnode and it could be FullNode or SolidityNode.\n--net Optional, Connecting network. The default network is mainnet and it could be mainnet, testnet.\n--db Optional, The way of data processing could be keep, remove and backup. Default is keep. If you launch two different networks, like from mainnet to testnet or from testnet to mainnet, you need to delete database.\n--trust-node Optional, It only works when deploying SolidityNode. Default is 127.0.0.1:50051. The specified gRPC service of Fullnode, like 127.0.0.1:50051 or 13.125.249.129:50051.\n--rpc-port Optional, Port of grpc. Default is 50051. If you deploy SolidityNode and FullNode on the same host\uff0cyou need to configure different ports.\n--commit Optional, commitid of project.\n--branch Optional, branch of project. Mainnet default is latest release and Testnet default is master.\n--heap-size Optional, jvm option: Xmx. The default heap-size is 0.8 * memory size.\n--work_space Optional, default is current directory.\n
Deployment of FullNode on the one host wget https://raw.githubusercontent.com/tronprotocol/TronDeployment/master/deploy_tron.sh -O deploy_tron.sh\nbash deploy_tron.sh\n
Deployment of SolidityNode on the one host wget https://raw.githubusercontent.com/tronprotocol/TronDeployment/master/deploy_tron.sh -O deploy_tron.sh\n# User can self-configure the IP and Port of GRPC service in the trust-node field of SolidityNode. trust-node is the fullnode you just deploy.\nbash deploy_tron.sh --app SolidityNode --trust-node <grpc-ip:grpc-port>\n
Deployment of FullNode and SolidityNode on the same host # You need to configure different gRPC ports on the same host because gRPC port is available on SolidityNode and FullNodeConfigure and it cannot be set as default value 50051. In this case the default value of rpc port is set as 50041.\nwget https://raw.githubusercontent.com/tronprotocol/TronDeployment/master/deploy_tron.sh -O deploy_tron.sh\nbash deploy_tron.sh --app FullNode\nbash deploy_tron.sh --app SolidityNode --rpc-port 50041\n
"},{"location":"developers/deployment/#grpc-gateway-deployment","title":"Grpc Gateway Deployment","text":"Summary This script helps you download the code from https://github.com/tronprotocol/grpc-gateway and deploy the code on your environment.
Pre-requests Please follow the guide on https://github.com/tronprotocol/grpc-gateway Install Golang, Protoc, and set $GOPATH environment variable according to your requirement.
Download and run script wget https://raw.githubusercontent.com/tronprotocol/TronDeployment/master/deploy_grpc_gateway.sh -O deploy_grpc_gateway.sh\n
Parameter Illustration bash deploy_grpc_gateway.sh --rpchost [rpc host ip] --rpcport [rpc port number] --httpport [http port number]\n\n--rpchost The fullnode or soliditynode IP where the grpc service is provided. Default value is \"localhost\".\n--rpcport The fullnode or soliditynode port number grpc service is consuming. Default value is 50051.\n--httpport The port intends to provide http service provided by grpc gateway. Default value is 18890.\n
Example Use default configuration\uff1a
bash deploy_grpc_gateway.sh\n
Use customized configuration\uff1a bash deploy_grpc_gateway.sh --rpchost 127.0.0.1 --rpcport 50052 --httpport 18891\n
"},{"location":"developers/deployment/#event-subscribe-plugin-deployment","title":"Event Subscribe plugin Deployment","text":"This is an implementation of TRON eventsubscribe model.
- api module defines IPluginEventListener, a protocol between java-tron and event plugin.
- app module is an example for loading plugin, developers could use it for debugging.
- kafkaplugin module is the implementation for kafka, it implements IPluginEventListener, it receives events subscribed from java-tron and relay events to kafka server.
- mongodbplugin mongodbplugin module is the implementation for mongodb.
Setup/Build - Clone the repo
git clone https://github.com/tronprotocol/event-plugin.git - Go to eventplugin
cd event-plugin -
run ./gradlew build
-
This will produce one plugin zip, named plugin-kafka-1.0.0.zip, located in the event-plugin/build/plugins/ directory.
Edit **config.conf** of java-tron\uff0c add the following fields: event.subscribe = {\n path = \"\" // absolute path of plugin\n server = \"\" // target server address to receive event triggers\n dbconfig=\"\" // dbname|username|password\n topics = [\n {\n triggerName = \"block\" // block trigger, the value can't be modified\n enable = false\n topic = \"block\" // plugin topic, the value could be modified\n },\n {\n triggerName = \"transaction\"\n enable = false\n topic = \"transaction\"\n },\n {\n triggerName = \"contractevent\"\n enable = true\n topic = \"contractevent\"\n },\n {\n triggerName = \"contractlog\"\n enable = true\n topic = \"contractlog\"\n }\n ]\n\n filter = {\n fromblock = \"\" // the value could be \"\", \"earliest\" or a specified block number as the beginning of the queried range\n toblock = \"\" // the value could be \"\", \"latest\" or a specified block number as end of the queried range\n contractAddress = [\n \"\" // contract address you want to subscribe, if it's set to \"\", you will receive contract logs/events with any contract address.\n ]\n\n contractTopic = [\n \"\" // contract topic you want to subscribe, if it's set to \"\", you will receive contract logs/events with any contract topic.\n ]\n }\n}\n
* path: is the absolute path of \"plugin-kafka-1.0.0.zip\" * server: Kafka server address * topics: each event type maps to one Kafka topic, we support four event types subscribing, block, transaction, contractlog and contractevent. * dbconfig: db configuration information for mongodb, if using kafka, delete this one; if using Mongodb, add like that dbname|username|password * triggerName: the trigger type, the value can't be modified. * enable: plugin can receive nothing if the value is false. * topic: the value is the kafka topic to receive events. Make sure it has been created and Kafka process is running * filter: filter condition for process trigger. note: if the server is not 127.0.0.1, pls set some properties in config/server.properties file remove comment and set listeners=PLAINTEXT://:9092 remove comment and set advertised.listeners to PLAINTEXT://host_ip:9092"},{"location":"developers/deployment/#kafka","title":"Install Kafka Run Kafka Create topics to receive events, the topic is defined in config.conf Kafka consumer Load plugin in java-tron Event filter","text":"On Mac:
brew install kafka\n
On Linux:
cd /usr/local\nwget http://archive.apache.org/dist/kafka/0.10.2.2/kafka_2.10-0.10.2.2.tgz\ntar -xzvf kafka_2.10-0.10.2.2.tgz\nmv kafka_2.10-0.10.2.2 kafka\n\nadd \"export PATH=$PATH:/usr/local/kafka/bin\" to end of /etc/profile\nsource /etc/profile\n\n\nkafka-server-start.sh /usr/local/kafka/config/server.properties &\n
Note: make sure the version of Kafka is the same as the version set in build.gradle of eventplugin project.(kafka_2.10-0.10.2.2 kafka) On Mac:
zookeeper-server-start /usr/local/etc/kafka/zookeeper.properties & kafka-server-start /usr/local/etc/kafka/server.properties\n
On Linux:
zookeeper-server-start.sh /usr/local/kafka/config/zookeeper.properties &\nSleep about 3 seconds\nkafka-server-start.sh /usr/local/kafka/config/server.properties &\n
On Mac:
kafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic block\nkafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic transaction\nkafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic contractlog\nkafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic contractevent\n
On Linux:
kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic block\nkafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic transaction\nkafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic contractlog\nkafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic contractevent\n
On Mac:
kafka-console-consumer --bootstrap-server localhost:9092 --topic block\nkafka-console-consumer --bootstrap-server localhost:9092 --topic transaction\nkafka-console-consumer --bootstrap-server localhost:9092 --topic contractlog\nkafka-console-consumer --bootstrap-server localhost:9092 --topic contractevent\n
On Linux:
kafka-console-consumer.sh --zookeeper localhost:2181 --topic block\nkafka-console-consumer.sh --zookeeper localhost:2181 --topic transaction\nkafka-console-consumer.sh --zookeeper localhost:2181 --topic contractlog\nkafka-console-consumer.sh --zookeeper localhost:2181 --topic contractevent\n
- add --es to command line, for example:
java -jar FullNode.jar -p privatekey -c config.conf --es\n
which is defined in config.conf, path: event.subscribe
filter = {\n fromblock = \"\" // the value could be \"\", \"earliest\" or a specified block number as the beginning of the queried range\n toblock = \"\" // the value could be \"\", \"latest\" or a specified block number as end of the queried range\n contractAddress = [\n \"TVkNuE1BYxECWq85d8UR9zsv6WppBns9iH\" // contract address you want to subscribe, if it's set to \"\", you will receive contract logs/events with any contract address.\n ]\n\n contractTopic = [\n \"f0f1e23ddce8a520eaa7502e02fa767cb24152e9a86a4bf02529637c4e57504b\" // contract topic you want to subscribe, if it's set to \"\", you will receive contract logs/events with any contract topic.\n ]\n }\n
"},{"location":"developers/deployment/#mongo","title":"Download and install MongoDB","text":"** Suggested Configuration **
- CPU/ RAM: 16Core / 32G
- DISK: 500G
- System: CentOS 64
The version of MongoDB is 4.0.4, below is the command:
- cd /home/java-tron
- curl -O https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-4.0.4.tgz
- tar zxvf mongodb-linux-x86_64-4.0.4.tgz
- mv mongodb-linux-x86_64-4.0.4 mongodb
** Set environment ** - export MONGOPATH=/home/java-tron/mongodb/ - export PATH=PATH:MONGOPATH/bin
** Create mongodb config ** The path is : /etc/mongodb/mgdb.conf
- cd /etc/mongodb
- touch mgdb.conf
Create data&log folder for mongodb Create data, log subfolder in mongodb directory, and add their absolute path to mgdb.conf
** Example: **
- dbpath=/home/java-tron/mongodb/data
- logpath=/home/java-tron/mongodb/log/mongodb.log
- port=27017
- logappend=true
- fork=true
- bind_ip=0.0.0.0
- auth=true
- wiredTigerCacheSizeGB=2
** Note: ** - bind_ip must be configured to 0.0.0.0\uff0cotherwise remote connection will be refused. - wiredTigerCacheSizeGB, must be configured to prevent OOM
** Launch MongoDB ** - mongod --config /etc/mongodb/mgdb.conf
** Create admin account: ** - mongo - use admin - db.createUser({user:\"root\",pwd:\"admin\",roles:[{role:\"root\",db:\"admin\"}]})
** Create eventlog and its owner account **
- db.auth(\"root\", \"admin\")
- use eventlog
- db.createUser({user:\"tron\",pwd:\"123456\",roles:[{role:\"dbOwner\",db:\"eventlog\"}]})
database: eventlog, username:tron, password: 123456
** Firewall rule: ** - iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 27017 -j ACCEPT
** Remote connection via mongo: **
- mongo 47.90.245.68:27017
- use eventlog
- db.auth(\"tron\", \"123456\")
- show collections
- db.block.find()
** Query block trigger data: **
- db.block.find({blockNumber: {$lt: 1000}}); // return records whose blockNumber less than1000
** Set database index to speedup query: **
cd /{projectPath} sh insertIndex.sh
"},{"location":"developers/deployment/#event-query-service-deployment","title":"Event query service deployment","text":"Download sourcecode Download sourcecode
git clone https://github.com/tronprotocol/tron-eventquery.git cd troneventquery
Build - mvn package
After the build command is executed successfully, troneventquery jar to release will be generated under troneventquery/target directory.
Configuration of mongodb \"config.conf\" should be created for storing mongodb configuration, such as database name, username, password, and so on. We provided an example in sourcecode, which is \" troneventquery/config.conf \". Replace with your specified configuration if needed.
Note:
Make sure the relative path of config.conf and troneventquery jar. The config.conf 's path is the parent of troneventquery jar.
- mongo.host=IP
- mongo.port=27017
- mongo.dbname=eventlog
- mongo.username=tron
- mongo.password=123456
- mongo.connectionsPerHost=8
- mongo.threadsAllowedToBlockForConnectionMultiplier=4
Any configuration could be modified except mongo.dbname, \"eventlog\" is the specified database name for event subscribe.
Run - troneventquery/deploy.sh is used to deploy troneventquery
- troneventquery/insertIndex.sh is used to setup mongodb index to speedup query.
"},{"location":"developers/deployment/#advanced-configurations","title":"Advanced Configurations","text":"Read the Advanced Configuration
"},{"location":"developers/governance/","title":"Governance","text":"The governance of the TRON network is accomplished by modifying the network parameters. The modification of network parameters is also called a network upgrade. Anyone can propose a discussion on modifying one or several network parameters, however, only super representatives or super representative partners can submit voting requests on-chain. Before the voting deadline, 27 super representatives can vote on the proposal. After the voting deadline arrives and the number of votes meets the requirement, the proposal will take effect.
You can view the list of the past completed proposals here.
Please according to the following process to propose a voting request:
- Initiate a discussion on proposal
- Community discussion
- Initiate a voting request
- Voting and taking effective
"},{"location":"developers/governance/#initiate-a-discussion-on-a-proposal","title":"Initiate a discussion on a proposal","text":"Any TRON network participant can initiate a discussion on a proposal. Please create a proposal discussion issue in TIP repository. The Issue is used to introduce the proposal in detail, including the motivation of this proposal, the TRON network parameters to be modified and their values, technical specifications, and the impact of the modification, etc. for a new proposal, please refer to this example to create an issue for discussion.
Below are the specifications of how to write an issue for proposal discussion.
"},{"location":"developers/governance/#title","title":"Title","text":"We hope that all users of the TRON ecosystem can participate in network governance. In order to be able to better publicize in the community, it is recommended to name the proposal and put the name at the beginning of the title. Here is an example:
Palma Upgrade: proposal to change the unit price of energy to 210 sun\n
"},{"location":"developers/governance/#body","title":"Body","text":"In the issue body, the content of the proposal should be introduced in detail, including motivation, estimated time to initiate the proposal vote and effective time of the proposal, how to initiate a proposal vote, technical specifications or background information of the proposal, etc.
# Simple Summary\nBriefly introduce the parameters to be modified by this proposal and their values, and summarize the issue it wants to solve\n\n# Motivation\nDescribe the motivation for the proposal, what is the problem encountered now, that is, why one or some dynamic parameters need to be modified.\n\n# Timeline\nIndicate when to initiate the proposal voting request, and the estimated effective date of the proposal. After the issue is proposed, two weeks are generally reserved for community discussion. Therefore, the proposal initiation time set in the Issue should be two weeks after the issue is proposed.\n\n# How to Initialize the Voting Request\nIndicates the command to initiate the proposal voting request.\n\n# Technical Specification / Background\nThe specific technical specifications or background information of the proposal\n
"},{"location":"developers/governance/#community-discussion","title":"Community discussion","text":"After the proposal issue is initiated, the initiator of the issue should try his best to promote it in the community, attract community users to participate in the discussion on the proposal, and update the proposal according to the results of the discussion.
"},{"location":"developers/governance/#initiate-a-voting-request","title":"Initiate a voting request","text":"Generally, the initiation time of the voting request set in the proposal is two weeks after the proposed issue is initiated. When the community has already fully discussed on the proposal and formed a community consensus, the super representative or super representative partner will initiate a voting request on the chain.
"},{"location":"developers/governance/#vote-and-take-effect","title":"Vote and take effect","text":"The validity period of the voting request initiated on-chain is 3 days. During the validity period, all 27 super representatives can vote for the proposal. When the voting deadline is reached, if the number of votes obtained is equal to or greater than 18 votes, the proposal will take effect.
"},{"location":"developers/issue-workflow/","title":"Issue Work Flow","text":"We encourage community contributors to participate in the submission and discussion of java-tron issues. You can submit your questions or ideas in the form of issues, or participate in issue discussions or help to provide solutions. Your every question or comment is driving java-tron's development. We thank you for your contribution to java-tron.
"},{"location":"developers/issue-workflow/#submit-an-issue","title":"Submit an Issue","text":"If you encounter java-tron related problems or find related bugs, you are welcome to submit an Issue, but please respect the following rules:
-
Search for existing issues
Please check to see if someone has already reported your issue or requested your idea, this will not only solve your problem quickly but also avoid duplicate issues.
-
Submit an issue
Please select the type of issue you want to report and fill in the issue content according to the template requirements.
Ask a question - Please elaborate on the problem you encountered, the results you expected, and the results you actually saw, so community participants can better understand your problem and come up with a solution faster.Report a bug - In addition to clarifying the problem, the expected behaviour, and the actual behaviour, the steps to reproduce the bug should also be described, and the java-tron log and backtrace when the problem occurs should be attached.Request a feature - Please clarify why should this feature exist\uff0cwhat are the use-cases\uff0cdo you have ideas regarding the implementation of this feature and are you willing to implement this feature.
"},{"location":"developers/issue-workflow/#issue-handling-process","title":"Issue Handling Process","text":"The issue handling process is as follows:
- Tag Issues - We hold weekly meetings to categorize Issues and tag Issues with appropriate Labels.
- Assign an Issue - Assign an Issue to one or several community core developers, and the core developers will participate in Issue investigations and discussions.
- Community Discussion - anyone can participate in the investigation and discussion of the Issue, and write their thoughts or opinions in the comments, and the solution to the problem can be obtained from the community discussion.
- Close the Issue - Issue submitters can close the Issue at any time. When the issue is resolved, or it has not been discussed by the community for a long time, we will close the Issue. Issue submitters or other users can also reopen the Issue as needed.
"},{"location":"developers/issue-workflow/#issue-labels","title":"Issue Labels","text":"Use the following labels according to the Issue feature:
- topic
topic: Block/Transactiontopic: Buildtopic: Consensustopic: DBtopic: Deploymenttopic: Documentationtopic: Event subscribetopic: gRPC/HTTP apitopic: Nettopic: Performancetopic: Resource managetopic: Shielded Transactiontopic: Smart contracttopic: Soliditytopic: Testnet/Privatenet
-
type
type: Announcementtype: Bugtype: Enhancementtype: Feature Requesttype: Manualtype: Othertype: Question
-
resolution
resolution: Duplicatedresolution: Needs More Informationresolution: Wontfix
improvement
"},{"location":"developers/java-tron/","title":"Developer Guide","text":"Thank you for considering to help out with the source code! We welcome contributions from anyone, and are grateful for even the smallest of fixes!
GitHub is used to track issues and contribute code, suggestions, feature requests or documentation. If you want to participate in java-tron development, please follow the Github code submission process as follows:
- Fork java-tron repository
- Fix the code
- Commit the code
- Send a pull request
- The maintainers review and merge into the main code base
For small fixes, you can send a pull request (PR) directly, but make sure the PR includes a detailed description. For more complex changes, you need to submit an issue to the TIP repository detailing your motivations, implementation plans, etc. For how to submit a TIP issue, please refer to TIP Specification.
We encourage java-tron developers to submit PRs as soon as possible. Even if they are not fully developed, you can submit a PR first, so that other developers can know that the TIP Issue corresponding to this PR is in the state of In Progress.
Developers should develop and submit a PR based on the develop branch, reviewers will review the PR according to Code Review Guidelines.
"},{"location":"developers/java-tron/#key-branches","title":"Key Branches","text":"java-tron only has master, develop, release-*, feature-*, and hotfix-* branches, which are described below:
-
develop branch
The develop branch only accepts merge requests from other forked branches orrelease_* branches. It is not allowed to directly push changes to the develop branch. A release_* branch has to be pulled from the develop branch when a new build is to be released.
-
master branch
release_* branches and hotfix/* branches should only be merged into the master branch when a new build is released.
-
release branch
release_* is a branch pulled from the develop branch for release. It should be merged into master after a regression test and will be permanently kept in the repository. If a bug is identified in a release_* branch, its fixes should be directly merged into the release_* branch. After the fixes passing the regression test, the release_* branch should be merged back into the develop branch. Essentially, a release_* branch serves as a snapshot for each release.
-
feature branch
feature/* is an important feature branch pulled from the develop branch. After the feature/* branch is code-complete, it should be merged back to the develop branch. The feature/* branch is maintainable.
-
hotfix branch
It is pulled from the master branch and should be merged back into the master branch and the develop branch. Only pull requests of the fork repository (pull requests for bug fixes) should be merged into the hotfix/ branch. hotfix/ branches are used only for fixing bugs found after release.
"},{"location":"developers/java-tron/#submitting-code","title":"Submitting Code","text":"If you want to contribute codes to java-tron, please follow the following steps:
-
Fork java-tron repository
Fork a new repository from tronprotocol/java-tron to your personal code repository
$ git clone https://github.com/yourname/java-tron.git\n\n$ git remote add upstream https://github.com/tronprotocol/java-tron.git (\"upstream\" refers to upstream projects repositories, namely tronprotocol's repositories, and can be named as you like it. We usually call it \"upstream\" for convenience) \n
-
Edit the code in the fork repository
Before developing new features, please synchronize your fork repository with the upstream repository.
git fetch upstream \ngit checkout develop \ngit merge upstream/develop --no-ff (Add --no-ff to turn off the default fast merge mode)\n
Pull a new branch from the develop branch of your repository for local development. Please refer to Branch Naming Conventions\u3002
git checkout -b feature/branch_name develop\n
Write and commit the new code when it is completed. Please refer to Commit Messages
git add .\ngit commit -m 'commit message'\n
Commit the new branch to your personal remote repository
git push origin new_feature\n
-
Push code
Submit a pull request (PR) from your repository to tronprotocol/java-tron. Please be sure to click on the link in the red box shown below. Select the base branch for tronprotocol and the compare branch for your personal fork repository.
"},{"location":"developers/java-tron/#code-review-guidelines","title":"Code Review Guidelines","text":"The only way to get code into java-tron is to send a pull request. Those pull requests need to be reviewed by someone. The following guide explains our expectations around PRs for both authors and reviewers.
"},{"location":"developers/java-tron/#the-process","title":"The Process","text":"The first decision to make for any PR is whether it\u2019s worth including at all. To make the decision we must understand what the PR is about. If there isn\u2019t enough description content or the diff is too large, request an explanation. Anyone can do this part.
We expect that reviewers check the style and functionality of the PR, providing comments to the author using the GitHub review system. Reviewers should follow up with the PR until it is in good shape, then approve the PR. Approved PRs can be merged by the code maintainer.
When communicating with authors, be polite and respectful.
"},{"location":"developers/java-tron/#functional-checks","title":"Functional Checks","text":"For PRs that fix an issue, reviewers should try reproduce the issue and verify that the pull request actually fixes it. Authors can help with this by including a unit test that fails without (and passes with) the change.
For PRs adding new features, reviewers should attempt to use the feature and comment on how it feels to use it. For example: if a PR adds a new command line flag, use the program with the flag and comment on whether the flag feels useful.
We expect appropriate unit test coverage. Reviewers should verify that new code is covered by unit tests.
"},{"location":"developers/java-tron/#code-style","title":"Code Style","text":"We would like all developers to follow a standard development flow and coding style. Therefore, we suggest the following:
- Review the code with coding style checkers.
- Review the code before submission.
- Run standardized tests.
Sonar-scanner and Travis CI continuous integration scanner will be automatically triggered when a pull request has been submitted. When a PR passes all the checks, the java-tron maintainers will then review the PR and offer feedback and modifications when necessary. Once adopted, the PR will be closed and merged into the develop branch.
We are glad to receive your pull requests and will try our best to review them as soon as we can. Any pull request is welcome, even if it is for a typo.
Please kindly address the issue you find. We would appreciate your contribution.
Please do not be discouraged if your pull request is not accepted, as it may be an oversight. Please explain your code as detailed as possible to make it easier to understand.
Please make sure your submission meets the following code style:
- The code must conform to Google Code Style.
- The code must have passed the Sonar scanner test.
- The code has to be pulled from the
develop branch.
"},{"location":"developers/java-tron/#branch-naming-conventions","title":"Branch Naming Conventions","text":"Branch naming should follow the following guidelines:
- Always name the
master branch and develop branch as \"master\" and \"develop\". - Name the
release_* branch using version numbers, which are assigned by the project lead (e.g., Odyssey-v3.1.3, 3.1.3, etc.). - Use
hotfix/ as the prefix of the hotfix branch, briefly describe the bug in the name, and connect words with underline (e.g., hotfix/typo, hotfix/null_point_exception, etc.). - Use
feature/ as the prefix of the feature branch, briefly describe the feature in the name, and connect words with underline (e.g., feature/new_resource_model, etc.).
"},{"location":"developers/java-tron/#pull-request-guidelines","title":"Pull Request Guidelines","text":"Pull Requests should follow the following specifications:
- Create one PR for one issue.
- Avoid massive PRs.
- Write an overview of the purpose of the PR in its title.
- Write a description of the PR for future reviewers.
- Elaborate on the feedback you need (if any).
"},{"location":"developers/java-tron/#commit-messages","title":"Commit Messages","text":"Commit messages should follow the rule below, we provide a template with corresponding instructions.
Template:
<commit type>(<scope>): <subject>\n<BLANK LINE>\n<body>\n<BLANK LINE>\n<footer>\n
The message header is a single line that contains a succinct description of the change containing a commit type, an optional scope and a subject.
commit type describes the kind of change that this commit is providing: * feat (new feature) * fix (bug fix) * docs (changes to documentation) * style (formatting, missing semi colons, etc. no code change) * refactor (refactoring production code) * test (adding or refactoring tests. no production code change) * chore (updating grunt tasks etc. no production code change)
The scope can be anything specifying place of the commit change. For example:protobuf,api,test,docs,build,db,net.You can use * if there isn't a more fitting scope.
The subject contains a succinct description of the change: 1. Limit the subject line, which briefly describes the purpose of the commit, to 50 characters. 2. Start with a verb and use first-person present-tense (e.g., use \"change\" instead of \"changed\" or \"changes\"). 3. Do not capitalize the first letter. 4. Do not end the subject line with a period. 5. Avoid meaningless commits. It is recommended to use the git rebase command.
Message body use the imperative, present tense: \"change\" not \"changed\" nor \"changes\". The body should include the motivation for the change and contrast this with previous behavior.
Here is an example:
feat(block): optimize the block-producing logic\n\n1. increase the priority that block producing thread acquires synchronization lock\n2. add the interruption exception handling in block-producing thread\n\nCloses #1234\n
If the purpose of this submission is to modify one issue, you need to refer to the issue in the footer, starting with the keyword Closes, such as Closes #1234, if multiple bugs have been modified, separate them with commas, such as Closes #123, #245, #992."},{"location":"developers/java-tron/#special-situations-and-how-to-deal-with-them","title":"Special Situations And How To Deal With Them","text":"As a reviewer, you may find yourself in one of the situations below. Here\u2019s how to deal with those:
- The author doesn\u2019t follow up: ping them after a while (i.e. after a few days). If there is no further response, close the PR or complete the work yourself.
- Author insists on including refactoring changes alongside bug fixes: We can tolerate small refactorings alongside any change. If you feel lost in the diff, ask the author to submit the refactoring as an independent PR, or at least as an independent commit in the same PR.
- Author keeps rejecting your feedback: You may close the PR.
"},{"location":"developers/java-tron/#conduct","title":"Conduct","text":"While contributing, please be respectful and constructive, so that participation in our project is a positive experience for everyone.
Examples of behavior that contributes to creating a positive environment include:
- Using welcoming and inclusive language Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members
Examples of unacceptable behavior include:
- The use of sexualized language or imagery and unwelcome sexual attention or advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others\u2019 private information, such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
"},{"location":"developers/run-in-idea/","title":"Configure the IntelliJ IDEA IDE","text":"For Java development, in order to reduce development difficulty and improve development efficiency, developers should first select and configure a Java integrated development environment, such as IntelliJ IDEA, NetBeans or Eclipse, etc. This article will take InteliJ IDEA as an example to introduce how to configure java-tron integration development environment.
This article describes the configuration of the java-tron integrated development environment in InteliJ IDEA. java-tron nodes support to be deployed on Linux or MacOS operating systems, and rely on Oracle JDK 1.8, other versions of JDK are not supported. Before configuring the InteliJ IDE development environment, please ensure the following prerequisites:
- Configure the development environment on
Linux or MacOS operating system Oracle JDK 1.8, git, InteliJ IDEA are installed
"},{"location":"developers/run-in-idea/#configure-intelij-idea","title":"Configure InteliJ IDEA","text":"The IntelliJ IDEA configuration steps are as follows:
-
Install Lombok plugin
Search for lombok in [IDEA]->[Preferences]->[Plugins] to install Lombok plugin, Lombok makes java-tron code more concise by adding annotations.
-
Enable Enable annotation processing configuration item
-
Check the JDK version and make sure that Oracle JDK 1.8 is used in IntelliJ IDEA
-
Download java-tron source code
Clone the java-tron source code locally and switch to the develop branch.
$ git clone https://github.com/tronprotocol/java-tron.git\n$ git checkout -t origin/develop\n
"},{"location":"developers/run-in-idea/#configure-the-code-style-check-plugin","title":"Configure the code style check plugin","text":"The java-tron code style needs to meet the Google check style specification. In IDEA, you can use the Checkstyle plugin to check whether the code conforms to the Google check style specification. The installation and configuration process of the plugin is as follows:
-
Search for checkstyle in [IDEA]->[Preferences]->[Plugins] to install the plugin
-
Code style configuration
First, download the java-tron code style check configuration file, then in the Checkstyle configuration page, click \"+ \", choose to use the \"checkStyleAll.xml\" just downloaded, after adding that, you can see this file in the \"Configuration Files\" list, and finally click \"Apply\" to complete the configuration.
After configuring the Checkstyle plugin, you can use Checkstyle to check the code. Checkstyle can check a module or the whole project, and can also check a single file. Select \"Check Current File\" in the right-click menu of the file editor, and Checkstyle will check the file. If a code problem is detected, you need to modify it according to the prompts. Code can only be submitted when there are no code problems.
"},{"location":"developers/run-in-idea/#compile-java-tron","title":"Compile java-tron","text":"You can use the terminal to compile java-tron with the following command in the java-tron project directory:
$ ./gradlew clean build\n
The above compile command will execute all test cases, you can use -x test to skip the execution of test cases: $ ./gradlew clean build -x test\n
You can also compile java-tron in IDEA: Open the java-tron project in IDEA and click \"Build\" -> \"Build Project\" to compile the project.
"},{"location":"developers/run-in-idea/#run-and-debug","title":"Run and Debug","text":"Before running java-tron, you need to create a working directory to store the database files and log files generated when the node is running.
$ mkdir /Users/javatrondeploy\n
In the \"Run/Debug Configurations\" configuration panel, specify the JDK version running java-tron as java 8, and then configure the command parameters for running java-tron, for example, specify the node configuration file through the -c parameter as config.conf.
\"Working directory\" is configured as the working directory of java-tron created earlier. When java-tron starts, it will look for the config.conf configuration file in this directory. Please make sure that config.conf has already been in this directory.
After the setting, click the \"Apply\" button to complete the configuration. Then you can click \"Run\"->\"Run FullNode\" in IDEA to start the java-tron node or click \"Run\"->\"Debug FullNode\" to start the node in debug mode. After the node is started, java-tron logs are stored in the working directory.
If you want to debug the java-tron code, you can set breakpoints in the java-tron code and start it in debug mode, so that you can trace the debug code line by line.
"},{"location":"developers/tips/","title":"TRON Improvement Proposals (TIPs)","text":"TIP stands for TRON Improvement Proposal. TIPs record the entire process of TRON improvement, including the process of community making suggestions, discussions, and adoption. A TIP is a design document about a proposal, including the rationale and technical specifications of the proposal. Community users can read the TIP document to learn more about the proposal.
TIPs are the unit around which governance happens in TRON\uff0canyone is free to propose one, and then community participants will debate to determine if it should be adopted as a standard or included in a network upgrade. The TIP author is responsible for building consensus within the community and documenting dissenting opinions.
"},{"location":"developers/tips/#tip-types","title":"TIP Types","text":"TIPs are mainly divided into Standard Track and Informational:
-
Standard Track : Describes any change that affects most or all TRON implementations, such as a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using TRON. Furthermore, Standard TIPs can be broken down into the following categories.
Core: Improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to \"core dev\" discussions.Networking: Improvements around network protocol.Interface: Improvements around client API/RPC specifications and standards.TRC\uff1aApplication-level standards and conventions, including contract standards such as token standards (TRC-20).TVM\uff1amprovements around TRON Virtual Machine.
-
Informational: Describes a TRON design issue, or provides general guidelines or information to the TRON community, but does not propose a new feature.
"},{"location":"developers/tips/#tip-work-flow","title":"TIP Work Flow","text":"Before you submit a TIP, you need to create an issue for comment and add the issue URL to your TIP header. The format of a TIP issue is consistent with the content of TIP. The process of submitting TIP is as follows:
- Fork the TIP repository by clicking \"Fork\" in the top right.
- Add your TIP to your fork of the repository. There is a TIP template here.
- Submit a Pull Request to TRON's TIPs repository.
Please use markdown to write TIP in strict accordance with the requirements of template. Make sure you include a discussions-to header with the URL to a discussion forum or open GitHub issue where people can discuss the TIP as a whole. If a TIP is about the feature development of java-tron, and a PR of the development exists, in your TIP and your java-tron's PR you need to refer each other's github link to make the requirements analysis of new features and development code traceable.
Your first PR for a new TIP will be in the state of draft. It must meet the formatting criteria enforced by the build. An editor will manually review it and assign it a number before merging it.
When you believe your TIP is mature and ready to progress past the draft phase, you should do one of two things:
- For a Standards Track TIP of type Core, ask to have your issue added to the agenda of an upcoming All Core Devs meeting, where it can be discussed for inclusion in a future hard fork. If core devs agree to include it, the TIP editors will update the state of your TIP to
Accepted. - For all other TIPs, open a PR changing the state of your TIP to
Final(non-Core). An editor will review your draft and ask if anyone objects to its being finalized. If the editor decides there is no rough consensus, they may close the PR and request you fix the issues in the draft before trying again.
"},{"location":"developers/tips/#tip-status","title":"TIP Status","text":"A TIP may go through the following states:
Draft: A TIP that is undergoing rapid iteration and changes.Last Call: A TIP that is done with its initial iteration and ready for review by a wide audience.Accepted: A core TIP that has been in the Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode a TIP into their clients as part of a hard fork is not part of the TIP process. If such a decision is made, the TIP will move to the final.Final (non-Core): A TIP that has been in the Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. Final (Core): A TIP that the Core Devs have decided to implement and release in a future version or has already been released.Active: If the TIPs are never meant to be completed, the TIPs may have a status of Active.Abandoned: If a TIP is no longer pursued by the original authors or it may not be a (technically) preferred option anymore.Rejected: A TIP that is fundamentally broken or a Core TIP that was rejected by the Core Devs and will not be implemented.Superseded: A TIP which was previously Final but is no longer considered state-of-the-art. Another TIP will be in the Final status and cite the Superseded TIP.Deferred: A TIP which isn't accepted now, may be accepted in the future.
"},{"location":"developers/tips/#tip-structure","title":"TIP Structure","text":"A TIP consists of a title preamble and body content.
"},{"location":"developers/tips/#tip-header-preamble","title":"TIP Header Preamble","text":"The TIP header preamble contains the TIP number, a short descriptive title (limited to a maximum of 44 characters), author details, discussion link, TIP status, TIP type, creation time, etc. Please refer to the specific format:
---\ntip: <to be assigned>\ntitle: <TIP title>\nauthor: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s), e.g. (use with the parentheses or triangular brackets): FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>\ndiscussions-to: <URL>\nstatus: <Draft | Last Call | Accepted | Final | Deferred>\ntype: <Standards Track (Core, Networking, Interface, TRC, VM) | Informational>\ncategory (*only required for Standard Track): <Core | Networking | Interface | TRC | VM>\ncreated: <date created on, in ISO 8601 (yyyy-mm-dd) format>\nrequires (*optional): <TIP number(s)>\nreplaces (*optional): <TIP number(s)>\n--- \n
"},{"location":"developers/tips/#tip-body","title":"TIP Body","text":"TIP body should have the following parts:
Simple Summary\uff1aProvide a simplified explanation of the TIP.Abstract\uff1a A short (~200 word) description of the technical issue being addressed. It should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.Motivation: (optional) A motivation section is critical for TIPs. It should clearly explain why the existing protocol specification is inadequate to address the problem that the TIP solves. This section may be omitted if the motivation is evident.Specification\uff1aThe technical specification should detail the syntax and semantics of any new feature.Rationale\uff1aThe rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should discuss important objections or concerns raised during the discussion around the TIP.Backwards Compatibility \uff1a(optional) All TIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their consequences. The TIP must explain how the author proposes to deal with these incompatibilities. Test Cases \uff1a(optional) Test cases for an implementation are mandatory for TIPs that are affecting consensus changes. This section may be omitted for non-Core proposals.Implementation\uff1aThe implementations must be completed before any TIP is given the status Final, but it need not be completed before the TIP is accepted. The principle of \"rough consensus and running code\" is still useful when it comes to resolving many discussions of API details.
"},{"location":"developers/tips/#linking-to-external-resources","title":"Linking to External Resources","text":"Links to external resources SHOULD NOT be included. External resources may disappear, move, or change unexpectedly.
"},{"location":"developers/tips/#linking-to-other-tips","title":"Linking to other TIPs","text":"References to other TIPs should follow the format TIP-N where N is the TIP number you are referring to. Each TIP that is referenced in a TIP MUST be accompanied by a relative markdown link. The link MUST always be done via relative paths so that the links work in TIP GitHub repository and forks of TIP repository. For example, you would link to TIP-1 with [TIP-1](/TIPS/tip-1).
"},{"location":"developers/tips/#auxiliary-files","title":"Auxiliary Files","text":"Images, diagrams and auxiliary files should be included in a subdirectory of the assets folder for that TIP as follows: assets/tip-N (where N is to be replaced with the TIP number). When linking to an image in the TIP, use relative links such as ../assets/tip-1/image.png.
"},{"location":"getting_started/getting_started_with_javatron/","title":"Getting Started with java-tron","text":"This page mainly explains how to start the java-tron node and use the command line tool wallet-cli to execute basic commands to interact with the java-tron node. Regarding the installation of java-tron, you can download the runnable file directly or build it from source code. Instructions for installing java-tron can be found on the Install and Build page. This tutorial on this page assumes java-tron and associated developer tools have been successfully installed.
This page covers the basics of using java-tron, which includes generating accounts, joining the TRON Nile testnet, and sending TRX between accounts. wallet-cli is also used in this document. wallet-cli is a command-line tool of the TRON network. This tool provides user interactive commands, which can be used to interact with java-tron more conveniently.
java-tron is a TRON network client written in Java. This means a computer running java-tron will become a TRON network node. TRON is a distributed network where information is shared directly between nodes rather than being managed by a central server. After the super representative's node generates a new block, it will send the block to its peers. On receiving a new block, each node checks that it is valid and adds it to their database. java-tron uses the information provided by each block to update its \"state\" - the balance of each account on the TRON network. There are two types of accounts on the TRON network: externally owned accounts and contract accounts. The contract account executes the contract code when a transaction is received. An external account is an account that a user manages locally in order to sign and submit transactions. Each external account is a public-private key pair, where the public key is used to derive a unique address for the user, and the private key is used to protect the account and securely sign messages. Therefore, in order to use the TRON network, it is first necessary to generate an external account (hereinafter referred to as \"account\"). This tutorial will guide users on how to create an account, deposit TRX tokens, and transfer TRX.
"},{"location":"getting_started/getting_started_with_javatron/#generat-account","title":"Generat account","text":"There are various ways to generate a TRON network account, here we will demonstrate how to generate an account using wallet-cli. An account is a pair of keys (public and private keys).
Enter the command java -jar wallet-cli.jar in the terminal to start a wallet-cli:
$ java -jar wallet-cli.jar\n\nWelcome to TRON wallet-cli\nPlease type one of the following commands to proceed.\nLogin, RegisterWallet or ImportWallet\n\nYou may also use the Help command at anytime to display a full list of commands.\n\nwallet> \n
Enter the command: registerwallet, and then enter the password as prompted. This command will generate a TRON network account and register it with wallet-cli, that is, wallet-cli will save the private key of this account, and then you can use the private key to sign transactions.
wallet> registerwallet\nPlease input password.\npassword: \nuser defined config file doesn't exists, use default config file in jar\nWalletApi getRpcVsersion: 2\nPlease input password again.\npassword: \nRegister a wallet successful, keystore file name is UTC--2022-07-04T06-35-35.304000000Z--TQXjm2J8K2DKTV49MdfT2anjUehbU3WDJz.json\nwallet> \n
"},{"location":"getting_started/getting_started_with_javatron/#login-wallet-cli","title":"Login wallet-cli","text":"After the registration is complete, enter the login command to log in to wallet-cli.
wallet> login\n
Select the account you want to login, and then enter the password. If the password is entered correctly, you will see the following result to the terminal: \"Login successful !!!\".
Please choose between 1 and 3\n2\nPlease input your password.\npassword: \nLogin successful !!!\nwallet> \n
After logging in, you can view the login account address through the getaddress command:
wallet> getaddress\nGetAddress successful !!\naddress = TQXjm2J8K2DKTV49MdfT2anjUehbU3WDJz\nwallet> \n
Then you can use the backupwallet command to view the private key of the account, you need to enter the password according to the prompt. It is recommended to save the private key."},{"location":"getting_started/getting_started_with_javatron/#run-a-java-tron-node","title":"Run a java-tron node","text":"java-tron is a TRON network client that enables computers to connect to the TRON network. The network in this tutorial refers to the TRON Nile testnet. To start java-tron, you need first obtain the java-tron executable file, please refer to the Installation and Deployment chapter, and then run the following command to start java-tron.
$ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c nile_net_config.conf\n
After java-tron starts, the logs will include the following: 11:07:58.758 INFO [main] [app](Args.java:1143) ************************ Net config ************************\n11:07:58.758 INFO [main] [app](Args.java:1144) P2P version: 201910292\n11:07:58.758 INFO [main] [app](Args.java:1145) Bind IP: 192.168.20.101\n11:07:58.758 INFO [main] [app](Args.java:1146) External IP: 203.12.203.3\n11:07:58.758 INFO [main] [app](Args.java:1147) Listen port: 18888\n11:07:58.758 INFO [main] [app](Args.java:1148) Discover enable: true\n
The above logs indicate that java-tron has started and connected to the Nile testnet, then it will look for peers to connect to. Once it has found peers, it can request blocks from them, and the logs confirm this:
11:08:42.547 INFO [TronJClientWorker-1] [net](Channel.java:116) Finish handshake with /123.56.3.74:18888.\n11:08:42.547 INFO [TronJClientWorker-1] [net](ChannelManager.java:161) Add active peer /123.56.3.74:18888 | fea80a0298b465a54fd332ff36819545d850115e77b327858b5306c9a58c6b8c2e7c08df76ab508a7594ed3577a8f4157727108442877077ab499b102b488467, total active peers: 1\n11:08:42.549 INFO [TronJClientWorker-1] [net](Channel.java:208) Peer /123.56.3.74:18888 status change to SYNCING.\n11:08:42.566 INFO [TronJClientWorker-1] [DB](Manager.java:1636) headNumber:23113867\n11:08:42.566 INFO [TronJClientWorker-1] [DB](Manager.java:1638) syncBeginNumber:23113867\n11:08:42.567 INFO [TronJClientWorker-1] [DB](Manager.java:1642) solidBlockNumber:23113849\n11:08:42.567 INFO [TronJClientWorker-1] [net](SyncService.java:179) Get block chain summary, low: 23113867, highNoFork: 23113867, high: 23113867, realHigh: 23113867\n11:08:42.572 INFO [TronJClientWorker-1] [net](MessageQueue.java:106) Send to /123.56.3.74:18888, type: SYNC_BLOCK_CHAIN\nsize: 1, start block: Num:23113867,ID:000000000160b08b510b6c501c980a2567bff1229eed62ca79874c9ca7828e9c \n11:08:42.631 INFO [TronJClientWorker-1] [net](MessageQueue.java:121) Receive from /123.56.3.74:18888, type: BLOCK_CHAIN_INVENTORY\nsize: 2001, first blockId: Num:23113867,ID:000000000160b08b510b6c501c980a2567bff1229eed62ca79874c9ca7828e9c, end blockId: Num:23115867,ID:000000000160b85b587ef18d00a1905d8022ec0a8fd174f3980b78f6aacf0ede\n\n......\n\n11:08:43.478 INFO [pool-49-thread-1] [net](MessageQueue.java:106) Send to /123.56.3.74:18888, type: FETCH_INV_DATA\ninvType: BLOCK, size: 100, First hash: 000000000160b08c6eeba60eced4fb13d7c56e46a3c5220a67bb2801a05e5679, End hash: 000000000160b0efd90560e389d1f6e5b3c8d3877709ce375a8e063f5db73af9 \n11:08:43.502 INFO [TronJClientWorker-1] [net](MessageQueue.java:121) Receive from /123.56.3.74:18888, type: BLOCK\nNum:23113868,ID:000000000160b08c6eeba60eced4fb13d7c56e46a3c5220a67bb2801a05e5679, trx size: 1\n\n11:08:43.504 INFO [TronJClientWorker-1] [net](MessageQueue.java:121) Receive from /123.56.3.74:18888, type: BLOCK\nNum:23113869,ID:000000000160b08d231e450ae1993a72ba19eb8f3c748fa70d105dadd0c9fd5f, trx size: 0\n\n11:08:43.504 INFO [TronJClientWorker-1] [net](MessageQueue.java:121) Receive from /123.56.3.74:18888, type: BLOCK\nNum:23113870,ID:000000000160b08e37cb9951d31a4233f106c7e77e0535c597dbb6a16f163699, trx size: 0\n
These logs show that java-tron is running as expected. You can determine whether the node has been started and check the status of the node by sending the following http request to the java-tron node:
$ curl http://127.0.0.1:16887/wallet/getnodeinfo\n
If no error messages are reported in the node logs, everything is fine. In order for users to interact with the TRON network, the java-tron node must be running and in a normal state of synchronization. Whether the node is synchronized with other nodes in the network, you can query the current block height in Tronscan and compare it with the result of the local java-tron node /wallet/getnowblock. If they are equal, it means that the synchronization status of the local node is normal. If you want to shut down java-tron node, please use this command: kill -15 process id.
"},{"location":"getting_started/getting_started_with_javatron/#obtain-trx","title":"Obtain TRX","text":"In order to make some transactions, the user must fund their account with TRX. On TRON mainnet, TRX can only be obtained in three ways: 1. Rewards for block production by SRs/rewards for voting for SRs\uff1b 2. Another TRON account transfers TRX to it; 3. Obtained from the exchange.
In the TRON testnet, TRX has no real value and can be obtained for free through faucet.
"},{"location":"getting_started/getting_started_with_javatron/#interact-with-java-tron-node","title":"Interact with java-tron node","text":""},{"location":"getting_started/getting_started_with_javatron/#interact-by-using-wallet-cli","title":"Interact by using wallet-cli","text":"java-tron provides http interface and grpc interface externally, which is convenient for users to interact with TRON network. wallet-cli uses the grpc interface.
"},{"location":"getting_started/getting_started_with_javatron/#get-account-information","title":"Get account information","text":"After entering the getaccount command in wallet-cli, it will request account information data from the java-tron node, and then display the result in the terminal.
wallet> getaccount TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\n
Result: {\n \"address\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"balance\": 93643857919,\n \"create_time\": 1619681898000,\n \"latest_opration_time\": 1655358327000,\n \"is_witness\": true,\n \"asset_issued_name\": \"TestTRC10T\",\n \"latest_consume_free_time\": 1652948766000,\n \"account_resource\": {\n \"latest_consume_time_for_energy\": 1655358327000\n },\n\n ......\n}\n
"},{"location":"getting_started/getting_started_with_javatron/#get-account-balance","title":"Get account balance","text":"Get the balance of an account with the getbalance command:
wallet> getbalance\nBalance = 93642857919\nwallet> \n
"},{"location":"getting_started/getting_started_with_javatron/#transferring-trx","title":"Transferring TRX","text":"To transfer TRX through the sendcoin command, enter the transfer address, and the amount:
wallet> sendcoin TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf 1000000\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"amount\":1000000,\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"to_address\":\"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\"\n },\n \"type_url\":\"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\":\"TransferContract\"\n }\n ],\n \"ref_block_bytes\":\"cbc3\",\n \"ref_block_hash\":\"8581ae7e29258a52\",\n \"expiration\":1656917577000,\n \"timestamp\":1656917518232\n },\n \"raw_data_hex\":\"0a02cbc322088581ae7e29258a5240a89aefbf9c305a67080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca121541d0b69631440f0a494bb51f7eee68ff5c593c00f018c0843d7098cfebbf9c30\"\n}\nbefore sign transaction hex string is 0a85010a02cbc322088581ae7e29258a5240a89aefbf9c305a67080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca121541d0b69631440f0a494bb51f7eee68ff5c593c00f018c0843d7098cfebbf9c30\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\n
This command returns the transaction of transferring TRX. After confirmation, enter y to confirm, and other letters indicate to cancel the transaction. If you enter y, then according to the prompt, choose which account's private key to use for signing, and finally enter the password to complete the signing of the transaction, and wallet-cli will send the signed transaction to the java-tron node.
Please confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is .DS_Store\nThe 2th keystore file name is UTC--2022-07-04T06-35-35.304000000Z--TQXjm2J8K2DKTV49MdfT2anjUehbU3WDJz.json\nThe 3th keystore file name is UTC--2022-06-21T09-51-26.367000000Z--TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM.json\nPlease choose between 1 and 3\n3\nPlease input your password.\npassword: \nafter sign transaction hex string is 0a85010a02cbc322088581ae7e29258a5240dbfc91ca9c305a67080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca121541d0b69631440f0a494bb51f7eee68ff5c593c00f018c0843d7098cfebbf9c301241241a3ce4797ccc2fedf49ae41af28b49df1e15a476e4948af4df5aadf23a1e940ad5cc2133f501c08f2bab6a2231cdc82a745fed0fc6a012dc19310532d9138600\ntxid is 21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4\nSend 1000000 Sun to TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf successful !!\nwallet> \n
"},{"location":"getting_started/getting_started_with_javatron/#query-transaction-by-transaction-id","title":"Query transaction by transaction id","text":"The above step sends a transferring TRX transaction through the sendcoin command, and prints the id of the transaction on the wallet-cli terminal:21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4. Next, you can query the transaction through gettransactionbyid, or query the result of the transaction through gettransactioninfobyid.
wallet> gettransactionbyid 21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4\n{\n \"ret\":[\n {\n \"contractRet\":\"SUCCESS\"\n }\n ],\n \"signature\":[\n \"241a3ce4797ccc2fedf49ae41af28b49df1e15a476e4948af4df5aadf23a1e940ad5cc2133f501c08f2bab6a2231cdc82a745fed0fc6a012dc19310532d9138600\"\n ],\n \"txID\":\"21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4\",\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"amount\":1000000,\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"to_address\":\"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\"\n },\n \"type_url\":\"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\":\"TransferContract\"\n }\n ],\n \"ref_block_bytes\":\"cbc3\",\n \"ref_block_hash\":\"8581ae7e29258a52\",\n \"expiration\":1656939118171,\n \"timestamp\":1656917518232\n },\n \"raw_data_hex\":\"0a02cbc322088581ae7e29258a5240dbfc91ca9c305a67080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca121541d0b69631440f0a494bb51f7eee68ff5c593c00f018c0843d7098cfebbf9c30\"\n}\nwallet> \n
wallet> gettransactioninfobyid 21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4\n{\n \"id\": \"21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4\",\n \"blockNumber\": 27773932,\n \"blockTimeStamp\": 1656917586000,\n \"contractResult\": [\n \"\"\n ],\n \"receipt\": {\n \"net_usage\": 267\n }\n}\nwallet> \n
"},{"location":"getting_started/getting_started_with_javatron/#interact-by-using-curl","title":"Interact by using Curl","text":"The above describes how to use wallet-cli to interact with java-tron. Compared with sending grpc/http commands directly, this tool provides more friendly interactive commands, allowing users to send commands to java-tron more conveniently. But, how to send HTTP requests directly to the java-tron node? Curl is a command line tool for sending HTTP requests. This chapter will explain how to check account balances and send transactions through Curl.
"},{"location":"getting_started/getting_started_with_javatron/#get-account-balance_1","title":"Get account balance","text":"You can query the TRX balance information of the account through the node HTTP interface wallet/getaccount. The balance field in the returned result is the TRX balance, in sun:
curl -X POST http://127.0.0.1:16887/wallet/getaccount -d \n '{\"address\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"visible\": true\n }'\n
Result\uff1a {\"account_name\": \"testacc2\",\"address\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\"balance\": 1000000000000000,\"account_resource\": {}}\n
"},{"location":"getting_started/getting_started_with_javatron/#send-transactions","title":"Send transactions","text":"Sending a transaction through the http interface requires a total of three steps:
- Create a transaction
- Sign the transaction
- Broadcast transaction
The following takes the transferring TRX as an example to illustrate how to send a transaction to java-tron node.
Create an unsigned TRX transferring transaction through the fullnode HTTP interface wallet/createtransaction:
curl -X POST http://127.0.0.1:16887/wallet/createtransaction -d \n '{\n \"to_address\": \"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\", \n \"owner_address\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\", \n \"amount\": 10000000,\n \"visible\":true\n }'\n
Returns an unsigned TRX transferring transaction: {\n \"visible\": true,\n \"txID\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\",\n \"raw_data\": {\n \"contract\": [\n {\n \"parameter\": {\n \"value\": {\n \"amount\": 10000000,\n \"owner_address\": \"TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1\",\n \"to_address\": \"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\"\n },\n \"type_url\": \"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\": \"TransferContract\"\n }\n ],\n \"ref_block_bytes\": \"193b\",\n \"ref_block_hash\": \"aaecd88e4e0e7528\",\n \"expiration\": 1656580476000,\n \"timestamp\": 1656580418228\n },\n \"raw_data_hex\": \"0a02193b2208aaecd88e4e0e752840e098909f9b305a68080112640a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412330a154198927ffb9f554dc4a453c64b2e553a02d6df514b121541d0b69631440f0a494bb51f7eee68ff5c593c00f01880ade20470b4d58c9f9b30\"\n}\n
Then sign the transaction offline. Finally, Broadcast the signed transaction to the java-tron node through the wallet/broadcasttransaction interface to complete the sending of the TRX transferring transaction.
curl --location --request POST 'http://127.0.0.1:16887/wallet/broadcasttransaction' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"visible\": true,\n \"signature\": [\n \"e12996cfaf52f8b49e64400987f9158a87b1aa809a11a75e01bb230722db97a26204334aea945b1ece0851a89c96459872e56229b0bd725c4f6a0577bfe331c301\"\n ],\n \"txID\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\",\n \"raw_data\": {\n \"contract\": [\n {\n \"parameter\": {\n \"value\": {\n \"amount\": 10000000,\n \"owner_address\": \"TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1\",\n \"to_address\": \"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\"\n },\n \"type_url\": \"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\": \"TransferContract\"\n }\n ],\n \"ref_block_bytes\": \"193b\",\n \"ref_block_hash\": \"aaecd88e4e0e7528\",\n \"expiration\": 1656580476000,\n \"timestamp\": 1656580418228\n },\n \"raw_data_hex\": \"0a02193b2208aaecd88e4e0e752840e098909f9b305a68080112640a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412330a154198927ffb9f554dc4a453c64b2e553a02d6df514b121541d0b69631440f0a494bb51f7eee68ff5c593c00f01880ade20470b4d58c9f9b30\"\n}'\n
Result\uff1a {\n \"result\": true,\n \"txid\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\"\n}\n
The return result is true, indicating that the transaction broadcast was successful."},{"location":"getting_started/getting_started_with_javatron/#query-transaction-by-transaction-id_1","title":"Query transaction by transaction id","text":"Query the content of the transaction through the http interface wallet/gettransactionbyid:
curl --location --request POST 'http://127.0.0.1:16887/wallet/gettransactionbyid' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"value\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\"\n}'\n
Result: {\n \"ret\": [\n {\n \"contractRet\": \"SUCCESS\"\n }\n ],\n \"signature\": [\n \"e12996cfaf52f8b49e64400987f9158a87b1aa809a11a75e01bb230722db97a26204334aea945b1ece0851a89c96459872e56229b0bd725c4f6a0577bfe331c301\"\n ],\n \"txID\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\",\n \"raw_data\": {\n \"contract\": [\n {\n \"parameter\": {\n \"value\": {\n \"amount\": 10000000,\n \"owner_address\": \"4198927ffb9f554dc4a453c64b2e553a02d6df514b\",\n \"to_address\": \"41d0b69631440f0a494bb51f7eee68ff5c593c00f0\"\n },\n \"type_url\": \"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\": \"TransferContract\"\n }\n ],\n \"ref_block_bytes\": \"193b\",\n \"ref_block_hash\": \"aaecd88e4e0e7528\",\n \"expiration\": 1656580476000,\n \"timestamp\": 1656580418228\n },\n \"raw_data_hex\": \"0a02193b2208aaecd88e4e0e752840e098909f9b305a68080112640a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412330a154198927ffb9f554dc4a453c64b2e553a02d6df514b121541d0b69631440f0a494bb51f7eee68ff5c593c00f01880ade20470b4d58c9f9b30\"\n}\n
Query transaction results and transaction receipts through the http interface wallet/gettransactioninfobyid:
curl --location --request POST 'http://127.0.0.1:16887/wallet/gettransactioninfobyid' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"value\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\"\n}'\n
Result: {\n \"id\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\",\n \"blockNumber\": 27662687,\n \"blockTimeStamp\": 1656580470000,\n \"contractResult\": [\n \"\"\n ],\n \"receipt\": {\n \"net_usage\": 268\n }\n}\n
"},{"location":"mechanism-algorithm/account/","title":"Account Model","text":""},{"location":"mechanism-algorithm/account/#introduction","title":"Introduction","text":"TRON uses the account model. The address is the unique identifier of an account, and a private key signature is required to operate an account. An account has many attributes, including TRX & TRC10 token balances, bandwidth, energy, Etc. An account can send transactions to increase or reduce its TRX or TRC10 token balances, deploy smart contracts, and trigger the smart contracts released by itself or others. All TRON accounts can apply to be Super Representatives or vote for the elected Super Representatives. Accounts are the basis of all activities on TRON.
"},{"location":"mechanism-algorithm/account/#how-to-create-an-account","title":"How to Create an Account","text":" - Use a wallet application(TronLink is recommended) to generate a pair of address and private key. To active the account, you need to transfer TRX or other token to it.
- Use an account already existed in TRON network to create an account
If you have enough staked BandWidth Points, creating an account only consume your staked BandWidth Points, otherwise, it burns 0.1 TRX.
"},{"location":"mechanism-algorithm/account/#key-pair-generation","title":"Key-pair Generation","text":"TRON signature algorithm is ECDSA, curve used is SECP256K1. Private key is a random number, public key is a point in the elliptic curve. The process is: first generate a random number d to be the private key, then calculate P = d * G as the public key, G is the elliptic curve base point.
"},{"location":"mechanism-algorithm/account/#address-format","title":"Address Format","text":"Use the public key P as the input, by SHA3 get the result H. The length of the public key is 64 bytes, SHA3 uses Keccak256. Use the last 20 bytes of H, and add a byte of 0x41 in front of it, then the address come out. Do basecheck to address, here is the final address. All addresses start with 'T'.
basecheck process: first do sha256 calculation to address to get h1, then do sha256 to h1 to get h2, use the first 4 bytes as check to add it to the end of the address to get address||check, do base58 encode to address||check to get the final result.
character map: ALPHABET = \"123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz\"
"},{"location":"mechanism-algorithm/account/#signature","title":"Signature","text":""},{"location":"mechanism-algorithm/account/#steps","title":"Steps","text":" - Get the rawdata of the transaction, then transfer it to
byte[] - Do sha256 calculation to the rawdata
- Use the private key to sign the result gained from step 2
- Add the signature back into the transaction
"},{"location":"mechanism-algorithm/account/#algorithm","title":"Algorithm","text":" - ECDSA, SECP256K
-
Example:
priKey:::8e812436a0e3323166e1f0e8ba79e19e217b2c4a53c970d4cca0cfb1078979df\npubKey::04a5bb3b28466f578e6e93fbfd5f75cee1ae86033aa4bbea690e3312c087181eb366f9a1d1d6a437a9bf9fc65ec853b9fd60fa322be3997c47144eb20da658b3d1\nhash:::159817a085f113d099d3d93c051410e9bfe043cc5c20e43aa9a083bf73660145\nr:::38b7dac5ee932ac1bf2bc62c05b792cd93c3b4af61dc02dbb4b93dacb758123f\ns:::08bf123eabe77480787d664ca280dc1f20d9205725320658c39c6c143fd5642d\nv:::0\n
Note: The size of the signature result is 65 bytes. r 32 bytes, s 32 bytes, v 1 bytes.
-
fullnode will verify the signature, it generates an address with the value of hash and r\u3001s\u3001v, then it compares with the address in the transaction.
"},{"location":"mechanism-algorithm/account/#demo","title":"Demo","text":"public static Transaction sign(Transaction transaction, ECKey myKey) {\n Transaction.Builder transactionBuilderSigned = transaction.toBuilder();\n byte[] hash = sha256(transaction.getRawData().toByteArray());\n List<Contract> listContract = transaction.getRawData().getContractList();\n\n for (int i = 0; i < listContract.size(); i++) {\n ECDSASignature signature = myKey.sign(hash);\n ByteString bsSign = ByteString.copyFrom(signature.toByteArray());\n\n // Each contract may be signed with a different private key in the future.\n transactionBuilderSigned.addSignature(bsSign);\n }\n}\n
"},{"location":"mechanism-algorithm/dex/","title":"Decentralized Exchange(DEX)","text":"TRON network supports decentralized exchange(DEX) using Bancor protocol. DEX is composed of many exchange pairs. You can find the api below in HTTP API.
"},{"location":"mechanism-algorithm/dex/#what-is-an-exchange-pair","title":"What is an Exchange Pair","text":"The term of 'Exchange Pair' describes a trade between one token with another, like A/B, A/TRX.
"},{"location":"mechanism-algorithm/dex/#exchange-pair-creation","title":"Exchange Pair Creation","text":"Any account can create an exchange pair, it burns 1024 TRX.
Please refer to 'wallet/exchangecreate'.
"},{"location":"mechanism-algorithm/dex/#exchange-pair-transaction","title":"Exchange Pair Transaction","text":"Any account can trade in the DEX. The trade follows Bancor protocol.
Please refer to 'wallet/exchangetransaction'.
"},{"location":"mechanism-algorithm/dex/#exchange-pair-injection","title":"Exchange Pair Injection","text":"The exchange pair creator can inject more tokens into the exchange pair. Injection can decrease the range of ratio fluctuation. If one token is injected, the other one will be injected automatically to keep the current ratio of the two tokens unchanged.
Please refer to 'wallet/exchangeinject'.
"},{"location":"mechanism-algorithm/dex/#exchange-pair-withdrawal","title":"Exchange Pair Withdrawal","text":"The exchange pair creator can withdraw tokens from the exchange pair. Withdrawal can increase the range of ratio fluctuation. If one token is withdrawn, the other one will be withdrawn automatically to keep the current ratio of the two tokens unchanged.
Please refer to 'wallet/exchangewithdraw'.
"},{"location":"mechanism-algorithm/dex/#query","title":"Query","text":""},{"location":"mechanism-algorithm/dex/#transaction-query","title":"Transaction Query","text":"ListExchanges: Query the list of all the exchange pairs.
GetPaginatedExchangeList: Query the list of all the exchange pairs by pagination.
GetExchangeById: Query an exchange pair by exchange pair id.
"},{"location":"mechanism-algorithm/dex/#price-calculation","title":"Price Calculation","text":"The token price is determined by the ratio of the balance of the two tokens.
"},{"location":"mechanism-algorithm/dex/#calculate-the-amount-of-token-you-can-get","title":"Calculate the Amount of Token You Can Get","text":"sellTokenQuant is the amount of the first_token you want to sell.
buyTokenQuant is the amount of second_token you can get.
supply = 1,000,000,000,000,000,000L\n\nsupplyQuant = -supply * (1.0 - Math.pow(1.0 + (double) sellTokenQuant/(firstTokenBalance + sellTokenQuant, 0.0005))\n\nbuyTokenQuant = (long)balance * (Math.pow(1.0 + (double) supplyQuant / supply, 2000.0) - 1.0)\n
"},{"location":"mechanism-algorithm/dpos/","title":"DPoS","text":""},{"location":"mechanism-algorithm/dpos/#overview","title":"Overview","text":"Blockchain is a distributed accounting system. In a blockchain system, there can be thousands of nodes, each of which independently stores the same ledger. If new transaction data is to be written into the ledger, approvals from these nodes are needed. Achieving this goal in an untrusted distributed environment is a complicated systematic quest. The blockchain system operates normally means each node in the blockchain can always keep the same ledger, provided that most nodes in the system are honest and reliable. In order to ensure that honest and reliable nodes can jointly supervise the transaction data written into the ledgers, each blockchain system needs to build its own consensus, which is equivalent to the constitution of the blockchain. As long as the vast majority of nodes comply with the consensus requirements, it is able to guarantee the results will certainly be credible, even in an untrusted distributed environment. Therefore, the significance of the consensus is that the honest nodes in the blockchain can ultimately achieve the agreement of the ledgers as long as they strictly abide by this consensus.
There are several types of consensus, and the most commonly used are POW, POS, and DPoS. Definitely, different blockchain systems will have a unique way of implementation. This article will mainly introduce the DPoS consensus on which TRON based. We will also explain the basic components and mechanisms of DPoS.
The role of consensus is to select SRs(Super Representatives) in the blockchain system. SRs(Super Representatives) verify the transaction data and keep it in a leger, then broadcast the leger to other nodes in the network and obtain the approval of the leger from other nodes. As a specific implementation of consensus, DPoS works in the following way:
The DPoS consensus selects some nodes as SRs(Super Representatives) in the blockchain system based on the number of votes they obtain. First, when the blockchain system starts to operate, a certain number of tokens will be issued, and then the tokens will be given to nodes in the blockchain system. A node can apply to be a super representative candidate in the blockchain system with a portion of the tokens. Any token-holding node in the blockchain system can vote for these candidates. Every t period of time, the votes for all the candidates will be counted. Top N candidate nodes with the most votes will become SR(Super Representatives) for the next t period. After t period of time, the votes will be counted again to elect the new SR(Super Representatives), and the cycle continues.
Let's see how it's implemented in the context of TRON:
"},{"location":"mechanism-algorithm/dpos/#definition","title":"Definition","text":" -
TRON: refers to the TRON network. The document does not distinguish between TRON, TRON blockchain, TRON blockchain system, etc.
-
TRON token: refers to the equity token issued by and circulating in TRON, known as TRX.
-
super representative candidates: nodes eligible for becoming super representatives in TRON.
-
SR(Super Representatives): nodes in TRON qualified for book-keeping. They are usually called super representatives in DPoS consensus. In TRON, there will be 27 super representatives, which are also called super nodes (or SR). Here, we will not distinguish between bookkeeper, witness, supernode, SR, etc.
-
Bookkeeping: the process of verifying transactions and recording them in a ledger. Because ledgers in TRON are carried by blocks, the bookkeeping process is also called block generation. We will not distinguish between bookkeeping and block generation in the document.
-
Bookkeeping order: block generation order. The descending order of the 27 super representatives based on the number of votes they receive.
-
Slot: In TRON, every 3 seconds is regarded as one slot. Under normal circumstances, each SR will produce a block within the corresponding slot time. Therefore, the average block interval of TRON is approximately 3 seconds. If an SR fails to produce a block for some reasons, the corresponding slot will be vacant and the next SR will produce a block in the following slot. During the maintenance period, block production will skip two slots.
-
Epoch: TRON sets an Epoch to be 6 hours. The last 2 block time of an Epoch is the maintenance period, during which block generating order for the next Epoch will be decided.
-
The maintenance period: TRON sets the period to be 2 block time, which is 6 seconds. This period of time is used to count the votes for candidates. There are 4 Epochs in 24 hours, and naturally, 4 maintenance periods. During the maintenance period, no block is generated and block generation order for the next Epoch is decided.
"},{"location":"mechanism-algorithm/dpos/#block-production-process","title":"Block Production Process","text":"The SR(Super Representatives) of the blockchain network collect the newly generated transactions in the blockchain network and verify the legality of these transactions, then package the transactions in a block, record them as a new page on the ledger, and broadcast the page to the entire blockchain network. Other nodes will receive the new page and verify the legality of the transaction data on the page and add it to their own ledger. The SR(Super Representatives) will repeat this process so all new transaction data in the blockchain system can be recorded in the ledger.
"},{"location":"mechanism-algorithm/dpos/#sr-election-mechanism","title":"SR Election Mechanism","text":" - Vote
In TRON, 1 TRX equals 1 vote.
- Voting process
In TRON, voting for candidates is a special transaction. Nodes can vote for candidates through generating a voting transaction.
- Vote counting
During each maintenance period, the votes for candidates will be counted. The top 27 candidates with the most votes will be the super representatives for the next Epoch.
"},{"location":"mechanism-algorithm/dpos/#block-generation-mechanism","title":"Block Generation Mechanism","text":"During each Epoch, the 27 super representatives will take turns to generate blocks according to the bookkeeping order. Each super representative can only generate blocks when it is their turn. Super representatives package the data of multiple verified transactions into each block. The hash of the previous block will be included in each new block as the parentHash. The super representative will sign the data of this block with his/her private key and fill in witness_signature, along with the address of the super representative, the block height, and the time that block is generated, etc.
Through storing the hash of the previous block, blocks are logically connected. Eventually, they form a chain. A typical blockchain structure is shown in the following picture:
In ideal circumstances, the bookkeeping process in a DPoS consensus-based blockchain system proceeds according to the bookkeeping order calculated in advance. Blocks are generated by super representatives in turn (see figure a). However, in reality, the blockchain network is a distributed and untrusted complex system in the following three ways. - Due to poor network environment, blocks generated by some super representatives cannot be received by other super representatives in valid time (see figure b1 and b2). - The normal operation of a certain super representative cannot always be guaranteed (see figure c). - Some malicious super representatives will generate fork blocks in order to fork the chain (see figure d).
As mentioned above, the basis for the blockchain system to operate normally is that most of the nodes in the system are honest and reliable. Furthermore, the primary guarantee for the security of the blockchain system is the security of the ledger, meaning that illegal data cannot be written into the ledger maliciously and ledger copies saved on each node should be consistent as well. Based on the DPoS consensus, the bookkeeping process is carried out by super representatives. Therefore, the safety of TRON depends on the reliability of the majority of the super representatives. TRON has put confirmed blocks in the system which are irreversible. At the same time, in order to resist the malicious behaviors of a small number of super representatives nodes, TRON recognizes the longest chain as the main chain based on \"the longest chain principle\".
"},{"location":"mechanism-algorithm/dpos/#the-confirmed-block-principle","title":"The Confirmed Block Principle","text":"The newly produced blocks are in unconfirmed state, and only those blocks that are \"approved\" by at least 70% of the 27 super representatives(i.e. 27 * 70% = 19, rounded up)) are considered to be irreversible blocks, commonly referred to as solidified blocks, and the transactions contained in the solidified blocks have been confirmed by the entire blockchain network. The way to \"approve\" the unconfirmed state block is that the SR producing subsequent blocks after it, as shown in Figure d, the SR C produces block 103, the SR E produces 104' on the basis of block 103, the block 105', 106', and 107' produced respectively by the SR G, A and B, are also subsequent blocks of the 103rd block, which means these four blocks approve the 103rd block. It can be seen that when the block of height 121 is produced, the 103rd block becomes a solidified block, since by this time the 103rd block has 19 subsequent blocks, and the point to be emphasized here is that the super representatives producing these 19 blocks must be different from each other and from the super representatives producing the 103rd block.
"},{"location":"mechanism-algorithm/dpos/#the-longest-chain-principle","title":"The Longest Chain Principle","text":"When a fork occurs, an honest super representative would always choose to produce blocks on the longest chain.
"},{"location":"mechanism-algorithm/dpos/#incentive-model","title":"Incentive Model","text":"To ensure the safe and efficient operation of the blockchain system, TRON sets up an incentive model to encourage more nodes to join the network, thereby expanding the scale of the network. Every time a block is generated by the TRON network, a block reward of 16 TRX will be awarded to the super representative who produced the block, and a voting reward of 160 TRX will be awarded to all super representatives and super partners (super representative candidates who ranking 28th~ 127th are also called super partners), and they share the voting rewards proportionally according to the number of votes they get. At the same time, super representatives and partners will also deduct the rewards according to their commission ratio, and distribute the remaining part to voters according to the voter voting ratio.
"},{"location":"mechanism-algorithm/dpos/#proposal-based-parameter-adjustment","title":"Proposal-based Parameter Adjustment","text":"An important characteristic of DPoS is that any parameter adjustment can be proposed on the chain, and super representatives will decide whether to approve the proposal by starting a vote. The advantage of this method is that it avoids hard fork upgrades when adding new features. For the current dynamic parameters and values \u200b\u200bof the TRON network, as well as past proposals, please refer to here.
"},{"location":"mechanism-algorithm/dpos/#reference-documentations","title":"Reference Documentations","text":" - The Basics of TRON\u2019s DPoS Consensus Algorithm
"},{"location":"mechanism-algorithm/multi-signatures/","title":"Account Permission Management","text":""},{"location":"mechanism-algorithm/multi-signatures/#background","title":"Background","text":"Account permission management functions allow for permission grading, and each permission can correspond to multiple private keys. This makes it possible to achieve multi-person joint control of accounts. This guide walks the user through TRON's account permission management implementation and design.
"},{"location":"mechanism-algorithm/multi-signatures/#concept","title":"Concept","text":"There are three types of permission: owner\u3001witness and active. Owner permission has the right to execute all the contracts. Witness permission is for SR. Active permission contains a set of contracts selected execution permissions.
"},{"location":"mechanism-algorithm/multi-signatures/#protocol-definition","title":"Protocol Definition","text":""},{"location":"mechanism-algorithm/multi-signatures/#account","title":"Account","text":"message Account {\n // ...\n Permission owner_permission = 31;\n Permission witness_permission = 32;\n repeated Permission active_permission = 33;\n}\n
Three attributes are added, owner_permission\u3001witness_permission and active_permission. active_permission is a list, the length can not be bigger than 8.
"},{"location":"mechanism-algorithm/multi-signatures/#contracttype","title":"ContractType","text":"message Transaction {\n message Contract {\n enum ContractType {\n AccountCreateContract = 0;\n // ...\n AccountPermissionUpdateContract = 46;\n }\n }\n}\n
The definition of ContractType can be found here. AccountPermissionUpdateContract is a ContractType used to update the account permission.
"},{"location":"mechanism-algorithm/multi-signatures/#accountpermissionupdatecontract","title":"AccountPermissionUpdateContract","text":"message AccountPermissionUpdateContract {\n bytes owner_address = 1;\n Permission owner = 2;\n Permission witness = 3;\n repeated Permission actives = 4;\n}\n
owner_address: The address of the account whose permissions are to be modifiedowner: Owner permissionwitness: Witness permission (only used by witness)actives: Active permission
This will override the Original account permission. Therefore, if you only want to modify the owner permission, witness (if it is a SR account) and active permission also need to be set
"},{"location":"mechanism-algorithm/multi-signatures/#permission","title":"Permission","text":"message Permission {\n enum PermissionType {\n Owner = 0;\n Witness = 1;\n Active = 2;\n }\n PermissionType type = 1;\n int32 id = 2;\n string permission_name = 3;\n int64 threshold = 4;\n int32 parent_id = 5;\n bytes operations = 6;\n repeated Key keys = 7;\n}\n
PermissionType: Permission typeid: Generated by system. Owner id=0, Witness id=1, Active id increases from 2. Specifying using which permission to execute a contract by setting id. For instance, using owner permission, set id=0permission_name: Permission name, 32 bytes length limitthreshold: The threshold of the signature weightparent_id: Current 0-
operations: used by active permission, a hexadecimal coded sequence (little-endian byte order), 32 bytes (256 bits), and each bit represents the authority of a ContractType. The nth bit indicates the authority of the ContractType with ID n, its value 1 means that it has the authority to execute the ContractType, its value 0 means it doesn't have the authority. To make it easier for users to read, start with the binary big-endian byte order to illustrate how to calculate the value of operations. The number of digits starts from 0, and corresponds to the ID of the ContractType from left to right. Convert a binary big-endian byte sequence to a hexadecimal little-endian byte sequence, that will be the value of operations. Below is an example of how to calculate the operations of active permission with operation TransferContract(ID=1) and operation VoteWitnessContract(ID=4) allowed. The mapping between ContractType and its ID can be seen in the above definition link of ContractType.
Operations Allowed Binary Code(big-endian) Binary Code(little-endian) Hex Code(little-endian) TransferContract(1) & VoteWitnessContract(4) 01001000 00000000 00000000 ... 00010010 00000000 00000000 ... 12 00 00 ... -
keys: The accounts and weights that all own the permission, 5 keys at most.
"},{"location":"mechanism-algorithm/multi-signatures/#key","title":"Key","text":"message Key {\n bytes address = 1;\n int64 weight = 2;\n}\n
address: The account addressweight: The signature weight
"},{"location":"mechanism-algorithm/multi-signatures/#transaction","title":"Transaction","text":"message Transaction {\n // ...\n int32 Permission_id = 5;\n}\n
Permission_id is added. It is corresponding to Permission.id 1 is not allowed, because witness permission is only used to produce blocks, not for transaction signature.
"},{"location":"mechanism-algorithm/multi-signatures/#owner-permission","title":"Owner Permission","text":"Owner permission is the top permission of an account. It is used to control account ownership, adjust permission structure. Owner Permission has the right to execute all the contracts.
Owner permission's features:
- The account that has owner permission can change the owner permission
- When owner permission is null, the default owner of the account owns the owner permission
- When you create a new account, the address will be insert into owner permission automatically, default weight is 1, keys field only contains this address and also weight is 1.
- If a permissionId is not specified when a contract is executed, using owner permission by default.
"},{"location":"mechanism-algorithm/multi-signatures/#witness-permission","title":"Witness Permission","text":"Super representatives can use this permission to manage block producing. Only SR(Super Representative) account has this permission.
Usage scenario example: A super representative deploys a witness node on cloud server. In order to keep the account on the cloud server safe, you can only give the block producing permission to the account you put on cloud server. Because this account only owns block producing permission, no TRX transfer permission, so even if the account on the cloud server is leaked, the TRX will not be lost.
Witness node configuration: when start a fullnode as witness, localwitness in the config file is filled in with the private key of the witness account and localWitnessAccountAddress is commented on as below:
# config.conf\n//localWitnessAccountAddress = \nlocalwitness = [\n xxx // private key of the witness account\n]\n
- If witness permission is not modified, there is no need to change config file.
-
If witness permission is modified, two modifications are required as follows:
localwitness needs to be changed to the private key of the account authorized with witness permissionlocalWitnessAccountAddress shoule be explicitly set as the address of the witness account
Below is an example of how to configure witness account TCbxHgibJutCjVZUprvexKZZ4Rc6sJ4Xrk which authorize its witness permission to account TSwCH45gi2HvtqDYX3Ff39yHeu5moEqQDJ.
#config.conf\nlocalWitnessAccountAddress = TCbxHgibJutCjVZUprvexKZZ4Rc6sJ4Xrk\nlocalwitness = [\n yyy // private key of TSwCH45gi2HvtqDYX3Ff39yHeu5moEqQDJ\n]\n
Notice: Only one private key can be added to localwitness when witness permission is modified.
"},{"location":"mechanism-algorithm/multi-signatures/#active-permission","title":"Active Permission","text":"Active permission is composed of a set of contract execution permission, like creating an account, transfer function, etc.
Active permission's features:
- the account owns owner permission can change active permission
- the account owns the execution permission of AccountPermissionUpdateContract can also change active permission
- 8 permissions at most
- permissionId increases from 2 automatically
- when a new account is created, an active permission will be created automatically, and the address will be inserted into it, default weight is 1, keys field only contains this address and weight is 1
"},{"location":"mechanism-algorithm/multi-signatures/#fee","title":"Fee","text":" - Using AccountPermissionUpdateContract costs 100TRX
- If a transaction contains 2 or more than 2 signatures, it charges an extra 1 TRX besides the transaction fee
- The fee can be modified by proposing
"},{"location":"mechanism-algorithm/multi-signatures/#api","title":"API","text":""},{"location":"mechanism-algorithm/multi-signatures/#change-permission","title":"Change Permission","text":"AccountPermissionUpdateContract, steps:
- call
getaccount to query the account, get the original permission - change permission
- build transaction and sign
- send transaction
Demo HTTP request:
// POST to http://{{host}}:{{port}}/wallet/accountpermissionupdate\n\n{\n \"owner_address\": \"41ffa9466d5bf6bb6b7e4ab6ef2b1cb9f1f41f9700\",\n \"owner\": {\n \"type\": 0,\n \"id\": 0,\n \"permission_name\": \"owner\",\n \"threshold\": 2,\n \"keys\": [{\n \"address\": \"41F08012B4881C320EB40B80F1228731898824E09D\",\n \"weight\": 1\n },\n {\n \"address\": \"41DF309FEF25B311E7895562BD9E11AAB2A58816D2\",\n \"weight\": 1\n },\n {\n \"address\": \"41BB7322198D273E39B940A5A4C955CB7199A0CDEE\",\n \"weight\": 1\n }\n ]\n },\n \"witness\": {\n \"type\": 1,\n \"id\": 1,\n \"permission_name\": \"witness\",\n \"threshold\": 1,\n \"keys\": [{\n \"address\": \"41F08012B4881C320EB40B80F1228731898824E09D\",\n \"weight\": 1\n }\n ]\n },\n \"actives\": [{\n \"type\": 2,\n \"id\": 2,\n \"permission_name\": \"active0\",\n \"threshold\": 3,\n \"operations\": \"7fff1fc0037e0000000000000000000000000000000000000000000000000000\",\n \"keys\": [{\n \"address\": \"41F08012B4881C320EB40B80F1228731898824E09D\",\n \"weight\": 1\n },\n {\n \"address\": \"41DF309FEF25B311E7895562BD9E11AAB2A58816D2\",\n \"weight\": 1\n },\n {\n \"address\": \"41BB7322198D273E39B940A5A4C955CB7199A0CDEE\",\n \"weight\": 1\n }\n ]\n }]\n}\n
"},{"location":"mechanism-algorithm/multi-signatures/#calculate-the-active-permissions-operations","title":"Calculate the Active Permission's Operations","text":"public static void main(String[] args) {\n\n //you need to specify the id of the contract you need to give permission to by referring to the definition of Transaction.ContractType in proto to get the id of the contract, below includes all the contract except AccountPermissionUpdateContract(id=46)\n\n Integer[] contractId = {0, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 30, 31,\n 32, 33, 41, 42, 43, 44, 45};\n List<Integer> list = new ArrayList<>(Arrays.asList(contractId));\n byte[] operations = new byte[32];\n list.forEach(e -> {\n operations[e / 8] |= (1 << e % 8);\n });\n\n //7fff1fc0033e0000000000000000000000000000000000000000000000000000\n System.out.println(ByteArray.toHexString(operations));\n}\n
"},{"location":"mechanism-algorithm/multi-signatures/#contract-execution","title":"Contract Execution","text":"(1). Create transaction, the same as none multi-signatures
(2). Specify Permission_id, default 0, represent owner permission, demo
(3). User A sign the transaction, and then send it to user B
(4). User B sign the transaction gets from A, and then send it to user C
......
(n). The last users that signs the transaction broadcast it to the node
(n+1). The node will verify if the sum of the weight of all signatures is bigger than threshold, if true, the transaction is accepted, otherwise, is rejected
"},{"location":"mechanism-algorithm/multi-signatures/#other-apis","title":"Other APIs","text":"Please refer to HTTP API and RPC API for more information.
-
query the addresses that already signed a transaction
> curl -X POST http://127.0.0.1:8090/wallet/getapprovedlist -d '{\"transaction\"}'\n
rpc GetTransactionApprovedList(Transaction) returns (TransactionApprovedList) { }\n
-
query the signature weight of a transaction
> curl -X POST http://127.0.0.1:8090/wallet/getsignweight -d '{\"transaction\"}'\n
rpc GetTransactionSignWeight (Transaction) returns (TransactionSignWeight) {}\n
"},{"location":"mechanism-algorithm/resource/","title":"Resource Model","text":""},{"location":"mechanism-algorithm/resource/#introduction","title":"Introduction","text":"Voting Right, bandwidth and energy are important system resources of the TRON network. Among them, voting rights are used to vote for super representatives; Bandwidth is the unit that measures the size of the transaction bytes stored in the blockchain database. The larger the transaction, the more bandwidth resources will be consumed. Energy is the unit that measures the amount of computation required by the TRON virtual machine to perform specific operations on the TRON network. Since smart contract transactions require computing resources to execute, each smart contract transaction requires to pay for the energy fee.
Note
- Ordinary transaction only consumes Bandwidth points
- Smart contract related transaction not only consumes Bandwidth points, but also Energy
"},{"location":"mechanism-algorithm/resource/#voting-right","title":"Voting Right","text":"Before any account can vote for super representatives, it needs to obtain voting rights, that is, TRON Power (TP). Voting rights can be obtained by staking TRX. In addition to obtaining bandwidth or energy, staking TRX will also obtain voting rights at the same time. Voters who stake 1TRX will receive 1TP. For how to stake, please refer to the Staking on TRON Network chapter.
Voters can stake multiple times, and the voting rights obtained by multiple stake will be added to the voter's account. Voters can query the total number of voting rights owned by the account and the number of used voting rights through the wallet/getaccountresource interface.
"},{"location":"mechanism-algorithm/resource/#bandwidth-points","title":"Bandwidth Points","text":"The transaction information is stored and transmitted in the form of byte array, Bandwidth Points consumed = the number of bytes of the transaction * Bandwidth Points rate. Currently Bandwidth Points rate = 1.
Such as if the number of bytes of a transaction is 200, so this transaction consumes 200 Bandwidth Points.
Note
Due to the change of the total amount of the staked TRX in the network and the self-staked TRX amount, the Bandwidth Points an account possesses is not fixed.
"},{"location":"mechanism-algorithm/resource/#1-how-to-get-bandwidth-points","title":"1. How to Get Bandwidth Points","text":" - By staking TRX to get Bandwidth Points, Bandwidth Points = the amount of TRX self-staked / the total amount of TRX staked for Bandwidth Points in the network * 43,200,000,000
- Every account has a fixed amount of free Bandwidth Points(600) every day
"},{"location":"mechanism-algorithm/resource/#2-bandwidth-points-consumption","title":"2. Bandwidth Points Consumption","text":"Except for query operation, any transaction consumes Bandwidth points.
Bandwidth points consumption sequence for TRC-10 transfer:
-
Free Bandwidth points.
-
TRC-10 issuer's Bandwidth points(if possible.)
-
Bandwidth points TRX staking.
-
Bandwidth points obtained by TRX burning, the rate = the number of bytes of the transaction * 1,000 SUN;
Bandwidth points consumption sequence for other transactions:
-
Free Bandwidth points.
-
Bandwidth points TRX staking.
-
Bandwidth points obtained by TRX burning, the rate = the number of bytes of the transaction * 1,000 SUN;
"},{"location":"mechanism-algorithm/resource/#3-bandwidth-points-recovery","title":"3. Bandwidth Points Recovery","text":"After the account's free bandwidth and the bandwidth obtained by staking TRX are consumed, they will gradually recover within 24 hours.
"},{"location":"mechanism-algorithm/resource/#4-account-bandwidth-balance-query","title":"4. Account Bandwidth Balance Query","text":"First, call the node HTTP interface wallet/getaccountresource to obtain the current resource status of the account, and then calculate the bandwidth balance by the following formula:
Free bandwidth balance = freeNetLimit - freeNetUsed\n\nBandwidth balance obtained by staking TRX = NetLimit - NetUsed\n
Note: If the result returned by the interface does not contain the parameters in the above formula, it means that the parameter value is 0.
"},{"location":"mechanism-algorithm/resource/#energy","title":"Energy","text":"Each command of smart contract consume system resource while running, we use 'Energy' as the unit of the consumption of the resource.
"},{"location":"mechanism-algorithm/resource/#1-how-to-get-energy","title":"1. How to Get Energy","text":"Stake TRX to get energy.
Example (Using wallet-cli):
freezeBalanceV2 frozen_balance [ResourceCode:0 BANDWIDTH,1 ENERGY]\n
stake TRX to get energy, energy obtained = user's TRX staked amount / total amount of staked TRX in TRON * 180,000,000,000.
Example:
If there are only two users, A stakes 2 TRX, B stakes 2 TRX\nthe energy they can get is:\nA: 75,000,000,000 and energy_limit is 90,000,000,000\nB: 75,000,000,000 and energy_limit is 90,000,000,000\n\nwhen C stakes 1 TRX:\nthe energy they can get is:\nA: 60,000,000,000 and energy_limit is 72,000,000,000\nB: 60,000,000,000 and energy_limit is 72,000,000,000\nC: 30,000,000,000 and energy_limit is 36,000,000,000\n
"},{"location":"mechanism-algorithm/resource/#energy-consumption","title":"Energy Consumption","text":"When the contract is executed, Energy is calculated and deducted according to instruction one by one. The priority of account energy consumption is as follows:
- Energy obtained by staking TRX
- Burn TRX
First, the energy obtained by staking TRX will be consumed. If this part of energy is not enough, the account's TRX will continue to be burned to pay for the energy resources required for the transaction, according to the unit price of 0.00021TRX per energy.
If the contract exits due to throwing a revert exception while execution, only the energy consumed by instructions that have already been executed will be deducted. But for abnormal contracts, such as contract execution timeout, or abnormal exit due to bug, the maximum available energy of this transaction will be deducted. You can limit the maximum energy cost of this transaction by setting the fee_limit parameter of the transaction.
"},{"location":"mechanism-algorithm/resource/#energy-recovery","title":"Energy Recovery","text":"After the energy resource of the account is consumed, it will gradually recover within 24 hours.
"},{"location":"mechanism-algorithm/resource/#account-energy-balance-query","title":"Account Energy Balance Query","text":"First call the node HTTP interface wallet/getaccountresource to obtain the current resource status of the account, and then calculate the energy balance by the following formula:
Energy Balance = EnergyLimit - EnergyUsed\n
Note: If the result returned by the interface does not contain the parameters in the above formula, it means that the parameter value is 0.
"},{"location":"mechanism-algorithm/resource/#2-how-to-set-fee-limit-caller-must-read","title":"2. How to Set Fee Limit (Caller Must Read)","text":"Within the scope of this section, the smart contract developer will be called \"developer\", the users or other contracts which call the smart contract will be called \"caller\"
The amount of energy consumed while call the contract can be converted to TRX or SUN, so within the scope of this section, when refer to the consumption of the resource, there's no strict difference between Energy, TRX and SUN, unless they are used as a number unit.
Set a rational fee limit can guarantee the smart contract execution. And if the execution of the contract cost great energy, it will not consume too much energy from the caller. Before you set fee limit, you need to know several conception:
- The legal fee limit is a integer between 0 - 15*10^9, unit is SUN.
- Different smart contracts consume different amount of energy due to their complexity. The same trigger in the same contract almost consumes the same amount of energy[^1], however, due to the dynamic energy model mechanism, for popular contracts, different energy may be required for execution at different times. For details, please refer to the Dynamic Energy Model Chapter. When the contract is triggered, the commands will be executed one by one and consume energy. If it reaches the fee limit, commands will fail to be executed, and energy is not refundable.
- Currently fee limit only refers to the energy converted to SUN that will be consumed from the caller[^2]. The energy consumed by triggering contract also includes developer's share.
- For a vicious contract, if it encounters execution timeout or bug crash, all it's energy will be consumed.
- Developer may undertake a proportion of energy consumption(like 90%). But if the developer's energy is not enough for consumption, the rest of the energy consumption will be undertaken by caller completely. Within the fee limit range, if the caller does not have enough energy, then it will burn equivalent amount of TRX [^2].
To encourage caller to trigger the contract, usually developer has enough energy.
"},{"location":"mechanism-algorithm/resource/#example","title":"Example","text":"How to estimate the fee limit:
- Assume contract C's last execution consumes 18000 Energy, so estimate the energy consumption limit to be 20000 Energy.
- When to burn TRX, since the unit price of energy is currently 210sun, 21 trx can be exchanged for 100,000 Energy.
Assume developer undertake 90% energy consumption, and developer has enough energy.
Then the way to estimate the fee limit is:
- A = 20000 energy * 210sun = 4,200,000 sun = 4.2 trx
- Developer undertakes 90% energy consumption, caller undertakes 10% energy consumption,
So, the caller is suggested to set fee limit to 4,200,000 sun * 10% = 420,000 sun.
"},{"location":"mechanism-algorithm/resource/#3-energy-calculation-developer-must-read","title":"3. Energy Calculation (Developer Must Read)","text":" -
In order to punish the vicious developer, for the abnormal contract, if the execution times out (more than 80ms) or quits due to bug (revert not included), the maximum available energy will be deducted. If the contract runs normally or revert, only the energy needed for the execution of the commands will be deducted.
-
Developer can set the proportion of the energy consumption it undertakes during the execution, this proportion can be changed later. If the developer's energy is not enough, it will consume the caller's energy.
-
Currently, the total energy available when trigger a contract is composed of caller fee limit and developer's share
Note
- If the developer is not sure about whether the contract is normal, do not set caller's energy consumption proportion to 0%, in case all developer's energy will be deducted due to vicious execution[^1].
- We recommend to set caller's energy consumption proportion to 10% ~ 100%[^2].
** Example 1 **
A has an account with a balance of 90 TRX(90000000 SUN) and 10 TRX staked for 100000 energy.
Smart contract C set the caller energy consumption proportion to 100% which means the caller will pay for the energy consumption completely.
A triggers C, the fee limit set is 30000000 (unit SUN, 30 TRX)
So during this trigger the energy A can use is from two parts:
- A's energy by staking TRX;
- The energy converted from the amount of TRX burning according to a fixed rate;
If fee limit is greater than the energy obtained from staking TRX, then it will burn TRX to get energy. The fixed rate is: 1 Energy = 210 SUN, fee limit still has (30 - 10) TRX = 20 TRX available, so the energy it can keep consuming is 20 TRX / 210 SUN = 95238 energy.
Finally, in this call, the energy A can use is (100000 + 95238) = 195238 energy.
If contract executes successfully without any exception, the energy needed for the execution will be deducted. Generally, it is far more less than the amount of energy this trigger can use.
If Assert-style error come out, it will consume the whole number of energy set for fee limit.
** Example 2 **
A has an account with a balance of 90 TRX(90000000 SUN) and 10 TRX staked for 100000 energy.
Smart contract C set the caller energy consumption proportion to 40% which means the developer will pay for the rest 60% energy consumption.
Developer D stakes 50 TRX to get 500000 energy.
A triggers C, the fee limit set is 200000000 (unit SUN, 200 TRX).
So during this trigger the energy A can use is from three parts:
- A's energy by staking TRX -- X;
-
The energy converted from the amount of TRX burning according to a fixed rate -- Y;
If fee limit is greater than the energy obtained from staking TRX, then it will burn TRX to get energy. The fixed rate is: 1 Energy = 210 sun, fee limit still has (200 - 10) TRX = 190 TRX available, but A only has 90 TRX left, so the energy it can keep consuming is 90 TRX / 210 sun = 428571 energy;
-
D's energy by staking TRX -- Z;
There are two situation: if (X + Y) / 40% >= Z / 60%, the energy A can use is X + Y + Z if (X + Y) / 40% < Z / 60%, the energy A can use is (X + Y) / 40%
If contract executes successfully without any exception, the energy needed for the execution will be deducted. Generally, it is far more less than the amount of energy this trigger can use.
If Assert-style error comes out, it will consume the whole number of energy set for fee limit.
Note: when developer create a contract, do not set consume_user_resource_percent to 0, which means developer will undertake all the energy consumption. If Assert-style error comes out, it will consume all energy from the developer itself. To avoid unnecessary lost, 10 - 100 is recommended for consume_user_resource_percent.
"},{"location":"mechanism-algorithm/resource/#dynamic-energy-model","title":"Dynamic Energy Model","text":"The dynamic energy model is a resource balancing mechanism of the TRON network, which can dynamically adjust the energy consumption of each contract according to the resource occupancy of the contract, so as to make the allocation of energy resources on the chain more reasonable and prevent excessive concentration of network resources on a few popular contracts. For more details, please refer to Introduction to Dynamic Energy Model.
"},{"location":"mechanism-algorithm/resource/#principle","title":"Principle","text":"If a contract uses too many resources in one maintenance cycle, then in the next maintenance cycle, 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.
Each contract has an energy_factor field, which indicates the increase ratio of the energy consumption of the smart contract transaction relative to the base energy consumption and the initial value is 0. When the energy_factor of the contract is 0, it means that the contract is using resources reasonably, and there will be no additional energy consumption for calling the contract. When the energy_factor is greater than 0, it means that the contract is already a popular contract, and additional energy will be consumed when calling the contract. The energy_factor of a contract can be queried through the getcontractinfo API.
The calculation formula for the final energy consumed by the contract invocation transaction is as follows:
energy consumption by a contract invocation transaction = the basic energy consumption generated by the transaction * \uff081 + energy_factor\uff09\n
The dynamic energy model introduces the following three parameters of the TRON network , which jointly control the energy_factor field of the contract:
threshold: The threshold of contract basic energy consumption. In a maintenance cycle, if the basic energy consumption of the contract exceeds this threshold, the energy consumption of the contract will increase at the next maintenance cycle.increase_factor: If the basic energy consumption of the contract exceeds the threshold during a certain maintenance cycle, the energy_factor will increase by a certain percentage according to the increase_factor in the next maintenance cycle.max_factor: the maximum value of energy_factor.
There is also a variable decrease_factor used to reduce the energy_factor of the contract:
decrease_factor: 1/4 of increase_factor. After the basic energy consumption of the contract falls below the threshold, energy_factor will be reduced by a certain percentage according to decrease_factor.
When the basic energy consumption of the contract exceeds threshold during a maintenance cycle, its energy_factor will increase in the next maintenance cycle, but the maximum will not be Exceeding max_factor, the calculation formula is:
energy_factor = min((1 + energy_factor) * (1 + increaese_factor)-1, max_factor)\n
When the basic energy consumption of the contract drops below the threshold in a maintenance cycle, the energy_factor will decrease in the next maintenance cycle, but the minimum value will not be lower than 0. The calculation formula is as follows:
energy_factor = max((1 + energy_factor) * (1 - decrease_factor)- 1, 0)\n
The dynamic energy model has been enabled on the main network, and the relevant parameters are set as follows:
threshold\uff1a5,000,000,000increase_factor\uff1a0.2max_factor\uff1a3.4
Since the energy consumption of popular contracts is different in different maintenance cycles, it is necessary to set the appropriate feelimit parameter for the transaction when calling the contract.
"},{"location":"mechanism-algorithm/resource/#staking-on-tron-network","title":"Staking on TRON network","text":""},{"location":"mechanism-algorithm/resource/#how-to-stake-to-obtain-system-resources","title":"How to stake to obtain system resources","text":"Energy and bandwidth resources are obtained by the account owner through staking, please use wallet/freezebalancev2 to complete the stake operation through HTTP API, use Stake2.0 Solidity API to complete the stake operation through the contract.
TRON allocates resources through the staking mechanism. In addition to obtaining bandwidth or energy resources, staking TRX will also obtain voting rights (TRON Power, TP for short) equal to the amount staked. Staking 1 TRX, you will get 1TP. The energy or bandwidth resources obtained by staking are used to pay transaction fees, and the obtained voting rights are used to vote for super representatives to obtain voting rewards.
The unstaking operation will release the corresponding resources.
"},{"location":"mechanism-algorithm/resource/#how-to-delegate-resources","title":"How to delegate resources","text":"After the account obtains energy or bandwidth resources through staking, it can delegate resources to other addresses through delegateresource, and can also take back allocated resources through undelegateresource. Please pay attention to the following situations when delegating resource:
- Only energy and bandwidth can be delegated to other addresses, voting rights cannot be delegated
- Only unused resources obtained by staking through Stake2.0 can be delegated to other addresses
- Energy/Bandwidth can only be delegated to an activated external account address, not to a contract address
You can use the wallet/getcandelegatedmaxsize interface to query the available delegation share of a certain resource type in the account. Time lock can be used when delegating resources. If time lock is used, after the resource delegating is completed, the resource delegation for the address only can be canceled after 3 days. During the locking period, if the user performs resource delegating for the same address again, it will Reset the 3-days waiting period. If the time lock is not used, the delegation can be canceled immediately after the resource is delegated.
"},{"location":"mechanism-algorithm/resource/#how-to-unstake-trx","title":"How to unstake TRX","text":"After completing the TRX staking, you can unstake at any time. After unstaking, you need to wait for 14 days before you can withdraw the unstaked TRX into your account. 14 days is the No.70 parameter of TRON network which can be voted on by network governance proposals. Please use unfreezebalancev2 to complete unfreeze balance through HTTP API.
The staked TRX can be partially unstaked multiple times, but only a maximum of 32 unstaking operations are allowed at the same time. That is to say, when a user initiates the first unstake operation, before the TRX of the first unstaking arrives and is ready to be withdrawn to his or her account, he or she can only initiate another 31 unstake operations. The remaining counts of unfreeze can be queried through the getavailableunfreezecount interface.
The TRX that have been delegated cannot be unstaked. In addition to losing the same amount of resource shares, the unstaking will also lose the same amount of TP resources.
When unstaking, if there are unclaimed voting rewards, the voting rewards will be automatically withdrawn to the account. If there is a previously unstaked principal that has passed the lock-up period, then this unstake operation will also withdraw the unstaked principal that has passed the lock-up period to the account at the same time. You can use the gettransactioninfobyidAPI to query the voting reward extracted in this transaction in withdraw_amount field and the withdrawn amount of unstaked TRX that has expired the lock-up period in withdraw_expire_amount field.
"},{"location":"mechanism-algorithm/resource/#tron-power-reclaim","title":"TRON Power Reclaim","text":"After unstaking the TRX staked in the Stake2.0 stage, the same amount of voting rights will be lost. The system will first reclaim the idle voting rights in the account. If the idle TP is insufficient, it will continue to reclaim the used TP. If the user has voted for multiple super representatives, a certain number of votes will be withdrawn in proportion from each super representative, and the corresponding voting rights will be recovered. The calculation formula for withdrawing votes for each SR is,
The number of votes withdrawn from the current super representative = total number of votes to be withdrawn * (number of votes for the current super representative / total number of votes of this account)\n
For example, Suppose A staked 2,000TRX and obtained 2,000 TRON Power, of which 1,000 TRON Power voted for 2 super representatives, 600 votes and 400 votes respectively, and 1,000 TRON Power remained in the account. At this time, A unstakes 1,500TRX, which means that 1,500 TRON Power needs to be reclaimed from A\u2019 account. In this case, the idle 1,000 TP in A\u2019s account will be withdrawn first, and the spared 500 TP will be withdrawn from the voted TP, which is 300 TP and 200 TP respectively from the two super representatives. Here's how the votes are calculated:
- Number of votes withdrawn by Super Representative 1 = 500 * (600 / 1,000) = 300
- Number of votes withdrawn by Super Representative 2 = 500 * (400 / 1,000) = 200
At present, the TRON network uses the Stake2.0 stake mechanism, but the resources and votes obtained by Stake1.0 are still valid. The TRX staked at Stake1.0 can still be withdrawal through Stake1.0 API unfreezebalance, but it should be noted that if the TRX staked in Stake 1.0 is unstaked, all votes in the account will be revoked.
"},{"location":"mechanism-algorithm/resource/#how-to-cancel-unstaking","title":"How to cancel unstaking","text":"Stake2.0 supports canceling all unstakes after the user unstakes TRX, which will make the assets be used for stake again to obtain corresponding resources, without having to wait for the unstaked funds to pass the lock-up period before withdrawing the funds to the account , and then stake them again. Please use cancelallunfreezev2 to cancel all unstaking operations.
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\u2019s account. Users can query the canceled unstaked principal amount cancel_unfreezeV2_amount, and the withdrawn principal amount that has expired the lock-up period withdraw_expire_amount through the gettransactioninfobyid interface.
"},{"location":"mechanism-algorithm/resource/#api","title":"API","text":"The following table shows the relevant interfaces of the stake model and their descriptions:
API Description freezebalancev2 Stake TRX unfreezebalancev2 Unstake TRX delegateresource Delegate resources undelegateresource Undelegate resources withdrawexpireunfreeze Withdraw unfrozen balance getavailableunfreezecount Query the remaining times of executing unstake operation getcanwithdrawunfreezeamount Query the withdrawable balance getcandelegatedmaxsize Query the amount of delegatable resources share of the specified resource Type getdelegatedresourcev2 Query the amount of resource delegated by fromAddress to toAddress getdelegatedresourceaccountindexv2 Query the resource delegation index by an account getaccount Query the account stake status, resource share, unstake status, and voting status getaccountresource Query the total amount of resources, the amount of used, and the amount of available cancelallunfreezev2 Cancel unstaking"},{"location":"mechanism-algorithm/shielded-transaction/","title":"Shielded Transaction","text":""},{"location":"mechanism-algorithm/shielded-transaction/#introduction","title":"Introduction","text":"TRON shielded transaction uses zk-SNARK(Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) to implement a completely anonymous transaction. TronZ is the name of shielded trc10 token.
In shielded transaction of transferring TronZ, the sender and the receiver's address and transfer amount can both be completely confidential.
In shielded transaction of transferring TronZ, there are two types of address:
- \"t-addr\" (Transparent Address)
- \"z-addr\" (Shielded Address)
\"t-addr\" address uses TRON account model. \"z-addr\" address uses Anonymous account model.
In shielded transaction of transferring TronZ, there are three types of transfer transaction: - From \"t-addr\" to \"z-addr\": The transaction information of \"t-addr\" can be tracked, \"z-addr\" can not be tracked.
-
From \"z-addr\" to \"z-addr\": The transaction information of both \"z-addr\" can not be tracked.
-
From \"z-addr\" to \"t-addr\": The transaction information of both \"t-addr\" can be tracked, \"z-addr\" can not be tracked.
From \"t-addr\" to \"t-addr\" are not supported.
"},{"location":"mechanism-algorithm/shielded-transaction/#usage-guide","title":"Usage Guide","text":"1.\u00a0The sender can only spend one note in each transfer. The receiver can receive two notes in each transfer at most.
2.\u00a0When you transfer from \"z-addr\" to \"t-addr\", if no note returns to \"z-addr\" as a change, it will generate a note of zero value automatically, and send it to a random black hole address.
3.\u00a0The fee for each shielded transaction is xx.
The doc below describes how to use TRON Shielded Transaction with http api.
"},{"location":"mechanism-algorithm/shielded-transaction/#transfer-from-transparent-address-to-shielded-address","title":"Transfer from transparent address to shielded address","text":"Step 1. Call api: wallet/createshieldedtransaction to build the transaction Method: Post Parameters:
{\n \"transparent_from_address\":\"41A7D8A35B260395C14AA456297662092BA3B76FC0\",\n \"from_amount\":100000000,\n \"ovk\":\"798ba79bfec55e154fa69b4e6a96247288f727b5e4ecc5cd848aefc0afab02b6\",\n \"shielded_receives\":[{\n \"note\":\n {\n \"value\": 500000000,\n \"payment_address\": \"ztron1jld8fmvujrz2vgkc867zuwklmewy4ypw0wtwgweqs2paee0uhc8f3azy90el770arksa2kunl02\",\n \"rcm\": \"723053bcbfecdf5da66c18ab0376476ef308c61b7abe891b2c01e903bcb87c0e\"\n }\n }]\n}\n
Return: {\"txID\":\"1967c40954e8c6c4761c377a021ec3a6ad0545d8b4443f0ccdd1bec4dcbaa497\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"transparent_from_address\":\"41a7d8a35b260395c14aa456297662092ba3b76fc0\",\"binding_signature\":\"5407f7f7d43ae313bf54b8d6a8cf716f65390171e39c11c07b4c90e5ae7d5d114b1729d44a3bc58f6e40c413b972e8ab61a8e66502b30df35937f64957c0da0a\",\"from_amount\":100000000,\"fee\":10000000,\"receive_description\":[{\"value_commitment\":\"5a1cd384edab9c38901d0250ebdf96d4f29889094b7096a7ce2dd6af919afd21\",\"note_commitment\":\"f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b62\",\"epk\":\"e7ff2357376eafdabc6db3fdabc079e42dd14c61a9a08c6cd38405d086086b4b\",\"c_enc\":\"d1aaf220f531f31bd2d9ff6f6d59998e78f3f0d30c852258441c5d54fc6790af7620b8860f6ec48d93fedb4c9bbb0e43c8144a9e304ceee399ac6da0bb91dbace3c8a93e03f1d2a5a88b0998704a09a51ab147096a994420741e87168cda4f45f8ed03c816e947909f2997d48e2ceaed45c539463e5e8caf6a0a1529615afbfa01df0a89c6360512519aea8a1b30a367a8749b24946fcd2fbbc6cfbbb6562ed6aa16db5d9e76b1872683a841ebda3a16dda6083474c2ea5a81f4e5c04e6af6ed582f58cab36bc016cfcf03337bc64b5411c7cb6f6f55e17d96bfead8becb0b7661768e122c943159ff2854c0e6efdd408b5bd5afc9d629645bfff8d4a240591fa9adc37e4a5bc046fcf31f8088f3616dd2f69860e401221585fd1a5ebe88080742802ae4696b8ba5e826ddd42841dce71b4b3ebe47b1f254103ae49f0bd9d61f5c0193441c471d29535247c26ab9297975497f6051466dbc591c4cd7b4246604e445d7d3a1dd77538c1989a8c48f829c6a1ce0dee84019ef68b7407def2492f5c867f659b0f8f58cc1081706453bf3a1ec719927c6b3defdcc002e9f2f63b4bdb7f69a00db742d2571d7293bae3faffc43ea0ff032e1b262a3597290c6c9117a006c91074a455c80a3a8089d93aed5bd48bd04bb30ad68fc87ff2bb4e5c20fe4bc0ad1b586aef3d1183170dec490c6bc82ec85d4031e292782f8778f21252a7cb6730da2d8fb175017e213eb10527b104bf333767cfed23c7c993391d9029f404947a793c37c1880a6be5cc26cc447ea020db8832239aa09aad9876ec17c4095857971ae\",\"c_out\":\"8e3df70e1feaf8da5da72062d13c5200ab09f43e45d2ba1aac8a56c8e9d033d786cfe3ed7d2b30d8b6124afe2646c7af25b60ed02c3a50b2cb62637461e00b153b92f868f2194b46c49e9a1c9e987d5a\",\"zkproof\":\"8b338777245e733183101027436ea41ea15f61537f38a35109fe6e53806c7913c69f186a86ba1d63997c5301c650089aa888cdf939573b0e7aceefff59757f8ba2275bd4469de04174f1b450a53017260b4bbc4a27cd8aac45d5ff2e5f5ab0eb14ffc59cf0fa10cd32363ef9a9fb9bf68431c4ee1c2ca15797ba4c18dbde24ae451797b25f13a73a231783f72b6f7a429026e191a49619057b250fab6b7010fc58dfcf922b04ad83756e2b8780100dccaafc65e4ef0357c6aae57f4f5c790607\"}]},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"0245\",\"ref_block_hash\":\"b1ea272768028540\",\"expiration\":1558691289000,\"timestamp\":1558691230861},\"raw_data_hex\":\"0a0202452208b1ea27276802854040a8aff6c9ae2d5ae708083312e2080a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e747261637412a8080a1541a7d8a35b260395c14aa456297662092ba3b76fc01080c2d72f22c2070a205a1cd384edab9c38901d0250ebdf96d4f29889094b7096a7ce2dd6af919afd211220f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b621a20e7ff2357376eafdabc6db3fdabc079e42dd14c61a9a08c6cd38405d086086b4b22c404d1aaf220f531f31bd2d9ff6f6d59998e78f3f0d30c852258441c5d54fc6790af7620b8860f6ec48d93fedb4c9bbb0e43c8144a9e304ceee399ac6da0bb91dbace3c8a93e03f1d2a5a88b0998704a09a51ab147096a994420741e87168cda4f45f8ed03c816e947909f2997d48e2ceaed45c539463e5e8caf6a0a1529615afbfa01df0a89c6360512519aea8a1b30a367a8749b24946fcd2fbbc6cfbbb6562ed6aa16db5d9e76b1872683a841ebda3a16dda6083474c2ea5a81f4e5c04e6af6ed582f58cab36bc016cfcf03337bc64b5411c7cb6f6f55e17d96bfead8becb0b7661768e122c943159ff2854c0e6efdd408b5bd5afc9d629645bfff8d4a240591fa9adc37e4a5bc046fcf31f8088f3616dd2f69860e401221585fd1a5ebe88080742802ae4696b8ba5e826ddd42841dce71b4b3ebe47b1f254103ae49f0bd9d61f5c0193441c471d29535247c26ab9297975497f6051466dbc591c4cd7b4246604e445d7d3a1dd77538c1989a8c48f829c6a1ce0dee84019ef68b7407def2492f5c867f659b0f8f58cc1081706453bf3a1ec719927c6b3defdcc002e9f2f63b4bdb7f69a00db742d2571d7293bae3faffc43ea0ff032e1b262a3597290c6c9117a006c91074a455c80a3a8089d93aed5bd48bd04bb30ad68fc87ff2bb4e5c20fe4bc0ad1b586aef3d1183170dec490c6bc82ec85d4031e292782f8778f21252a7cb6730da2d8fb175017e213eb10527b104bf333767cfed23c7c993391d9029f404947a793c37c1880a6be5cc26cc447ea020db8832239aa09aad9876ec17c4095857971ae2a508e3df70e1feaf8da5da72062d13c5200ab09f43e45d2ba1aac8a56c8e9d033d786cfe3ed7d2b30d8b6124afe2646c7af25b60ed02c3a50b2cb62637461e00b153b92f868f2194b46c49e9a1c9e987d5a32c0018b338777245e733183101027436ea41ea15f61537f38a35109fe6e53806c7913c69f186a86ba1d63997c5301c650089aa888cdf939573b0e7aceefff59757f8ba2275bd4469de04174f1b450a53017260b4bbc4a27cd8aac45d5ff2e5f5ab0eb14ffc59cf0fa10cd32363ef9a9fb9bf68431c4ee1c2ca15797ba4c18dbde24ae451797b25f13a73a231783f72b6f7a429026e191a49619057b250fab6b7010fc58dfcf922b04ad83756e2b8780100dccaafc65e4ef0357c6aae57f4f5c7906072a405407f7f7d43ae313bf54b8d6a8cf716f65390171e39c11c07b4c90e5ae7d5d114b1729d44a3bc58f6e40c413b972e8ab61a8e66502b30df35937f64957c0da0a4080ade204708de9f2c9ae2d\"}\n
Step 2. Sign the transaction using SDK Step 3. Call api: wallet/broadcasttransaction to broadcast the transaction Method: Post Parameters:
{\"signature\":[\"5c1939e2e1177f44a6d168b5e473bd193ea099aa369ffe27727d560f1c72a3226dd4be61c19a09cabbe3f4a7433932df11cf3e54c4fc04cff0eea6906f04c32a00\"],\"txID\":\"1967c40954e8c6c4761c377a021ec3a6ad0545d8b4443f0ccdd1bec4dcbaa497\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"transparent_from_address\":\"41a7d8a35b260395c14aa456297662092ba3b76fc0\",\"binding_signature\":\"5407f7f7d43ae313bf54b8d6a8cf716f65390171e39c11c07b4c90e5ae7d5d114b1729d44a3bc58f6e40c413b972e8ab61a8e66502b30df35937f64957c0da0a\",\"from_amount\":100000000,\"fee\":10000000,\"receive_description\":[{\"value_commitment\":\"5a1cd384edab9c38901d0250ebdf96d4f29889094b7096a7ce2dd6af919afd21\",\"note_commitment\":\"f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b62\",\"epk\":\"e7ff2357376eafdabc6db3fdabc079e42dd14c61a9a08c6cd38405d086086b4b\",\"c_enc\":\"d1aaf220f531f31bd2d9ff6f6d59998e78f3f0d30c852258441c5d54fc6790af7620b8860f6ec48d93fedb4c9bbb0e43c8144a9e304ceee399ac6da0bb91dbace3c8a93e03f1d2a5a88b0998704a09a51ab147096a994420741e87168cda4f45f8ed03c816e947909f2997d48e2ceaed45c539463e5e8caf6a0a1529615afbfa01df0a89c6360512519aea8a1b30a367a8749b24946fcd2fbbc6cfbbb6562ed6aa16db5d9e76b1872683a841ebda3a16dda6083474c2ea5a81f4e5c04e6af6ed582f58cab36bc016cfcf03337bc64b5411c7cb6f6f55e17d96bfead8becb0b7661768e122c943159ff2854c0e6efdd408b5bd5afc9d629645bfff8d4a240591fa9adc37e4a5bc046fcf31f8088f3616dd2f69860e401221585fd1a5ebe88080742802ae4696b8ba5e826ddd42841dce71b4b3ebe47b1f254103ae49f0bd9d61f5c0193441c471d29535247c26ab9297975497f6051466dbc591c4cd7b4246604e445d7d3a1dd77538c1989a8c48f829c6a1ce0dee84019ef68b7407def2492f5c867f659b0f8f58cc1081706453bf3a1ec719927c6b3defdcc002e9f2f63b4bdb7f69a00db742d2571d7293bae3faffc43ea0ff032e1b262a3597290c6c9117a006c91074a455c80a3a8089d93aed5bd48bd04bb30ad68fc87ff2bb4e5c20fe4bc0ad1b586aef3d1183170dec490c6bc82ec85d4031e292782f8778f21252a7cb6730da2d8fb175017e213eb10527b104bf333767cfed23c7c993391d9029f404947a793c37c1880a6be5cc26cc447ea020db8832239aa09aad9876ec17c4095857971ae\",\"c_out\":\"8e3df70e1feaf8da5da72062d13c5200ab09f43e45d2ba1aac8a56c8e9d033d786cfe3ed7d2b30d8b6124afe2646c7af25b60ed02c3a50b2cb62637461e00b153b92f868f2194b46c49e9a1c9e987d5a\",\"zkproof\":\"8b338777245e733183101027436ea41ea15f61537f38a35109fe6e53806c7913c69f186a86ba1d63997c5301c650089aa888cdf939573b0e7aceefff59757f8ba2275bd4469de04174f1b450a53017260b4bbc4a27cd8aac45d5ff2e5f5ab0eb14ffc59cf0fa10cd32363ef9a9fb9bf68431c4ee1c2ca15797ba4c18dbde24ae451797b25f13a73a231783f72b6f7a429026e191a49619057b250fab6b7010fc58dfcf922b04ad83756e2b8780100dccaafc65e4ef0357c6aae57f4f5c790607\"}]},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"0245\",\"ref_block_hash\":\"b1ea272768028540\",\"expiration\":1558691289000,\"timestamp\":1558691230861},\"raw_data_hex\":\"0a0202452208b1ea27276802854040a8aff6c9ae2d5ae708083312e2080a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e747261637412a8080a1541a7d8a35b260395c14aa456297662092ba3b76fc01080c2d72f22c2070a205a1cd384edab9c38901d0250ebdf96d4f29889094b7096a7ce2dd6af919afd211220f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b621a20e7ff2357376eafdabc6db3fdabc079e42dd14c61a9a08c6cd38405d086086b4b22c404d1aaf220f531f31bd2d9ff6f6d59998e78f3f0d30c852258441c5d54fc6790af7620b8860f6ec48d93fedb4c9bbb0e43c8144a9e304ceee399ac6da0bb91dbace3c8a93e03f1d2a5a88b0998704a09a51ab147096a994420741e87168cda4f45f8ed03c816e947909f2997d48e2ceaed45c539463e5e8caf6a0a1529615afbfa01df0a89c6360512519aea8a1b30a367a8749b24946fcd2fbbc6cfbbb6562ed6aa16db5d9e76b1872683a841ebda3a16dda6083474c2ea5a81f4e5c04e6af6ed582f58cab36bc016cfcf03337bc64b5411c7cb6f6f55e17d96bfead8becb0b7661768e122c943159ff2854c0e6efdd408b5bd5afc9d629645bfff8d4a240591fa9adc37e4a5bc046fcf31f8088f3616dd2f69860e401221585fd1a5ebe88080742802ae4696b8ba5e826ddd42841dce71b4b3ebe47b1f254103ae49f0bd9d61f5c0193441c471d29535247c26ab9297975497f6051466dbc591c4cd7b4246604e445d7d3a1dd77538c1989a8c48f829c6a1ce0dee84019ef68b7407def2492f5c867f659b0f8f58cc1081706453bf3a1ec719927c6b3defdcc002e9f2f63b4bdb7f69a00db742d2571d7293bae3faffc43ea0ff032e1b262a3597290c6c9117a006c91074a455c80a3a8089d93aed5bd48bd04bb30ad68fc87ff2bb4e5c20fe4bc0ad1b586aef3d1183170dec490c6bc82ec85d4031e292782f8778f21252a7cb6730da2d8fb175017e213eb10527b104bf333767cfed23c7c993391d9029f404947a793c37c1880a6be5cc26cc447ea020db8832239aa09aad9876ec17c4095857971ae2a508e3df70e1feaf8da5da72062d13c5200ab09f43e45d2ba1aac8a56c8e9d033d786cfe3ed7d2b30d8b6124afe2646c7af25b60ed02c3a50b2cb62637461e00b153b92f868f2194b46c49e9a1c9e987d5a32c0018b338777245e733183101027436ea41ea15f61537f38a35109fe6e53806c7913c69f186a86ba1d63997c5301c650089aa888cdf939573b0e7aceefff59757f8ba2275bd4469de04174f1b450a53017260b4bbc4a27cd8aac45d5ff2e5f5ab0eb14ffc59cf0fa10cd32363ef9a9fb9bf68431c4ee1c2ca15797ba4c18dbde24ae451797b25f13a73a231783f72b6f7a429026e191a49619057b250fab6b7010fc58dfcf922b04ad83756e2b8780100dccaafc65e4ef0357c6aae57f4f5c7906072a405407f7f7d43ae313bf54b8d6a8cf716f65390171e39c11c07b4c90e5ae7d5d114b1729d44a3bc58f6e40c413b972e8ab61a8e66502b30df35937f64957c0da0a4080ade204708de9f2c9ae2d\"}\n
Return: {\"result\": true}\n
"},{"location":"mechanism-algorithm/shielded-transaction/#transfer-from-shielded-address-to-shielded-address","title":"Transfer from shielded address to shielded address","text":"Step 1. Call api: wallet/getmerkletreevoucherinfo to get the voucher of the shield address, this info will be used when create shielded transaction Method: Post Parameter:
{\n \"out_points\":[{\n \"hash\":\"1967c40954e8c6c4761c377a021ec3a6ad0545d8b4443f0ccdd1bec4dcbaa497\",\n \"index\":0\n }],\n \"block_num\":1\n}\n
Return: {\"vouchers\": [{\"tree\": {\"left\": {\"content\": \"7efdc58818923de35ec35b4ef8e6a508f6952b9dd2a86af30a93dcd67e13ed35\"},\"right\": {\"content\": \"f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b62\"}},\"rt\": \"72eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e\"}],\"paths\": [\"2020b2eed031d4d6a4f02a097f80b54cc1541d4163c6b6f5971f88b6e41d35c538142012935f14b676509b81eb49ef25f39269ed72309238b4c145803544b646dca62d20e1f34b034d4a3cd28557e2907ebf990c918f64ecb50a94f01d6fda5ca5c7ef722028e7b841dcbc47cceb69d7cb8d94245fb7cb2ba3a7a6bc18f13f945f7dbd6e2a20a5122c08ff9c161d9ca6fc462073396c7d7d38e8ee48cdb3bea7e2230134ed6a20d2e1642c9a462229289e5b0e3b7f9008e0301cbb93385ee0e21da2545073cb582016d6252968971a83da8521d65382e61f0176646d771c91528e3276ee45383e4a20fee0e52802cb0c46b1eb4d376c62697f4759f6c8917fa352571202fd778fd712204c6937d78f42685f84b43ad3b7b00f81285662f85c6a68ef11d62ad1a3ee0850200769557bc682b1bf308646fd0b22e648e8b9e98f57e29f5af40f6edb833e2c492008eeab0c13abd6069e6310197bf80f9c1ea6de78fd19cbae24d4a520e6cf3023208d5fa43e5a10d11605ac7430ba1f5d81fb1b68d29a640405767749e841527673206aca8448d8263e547d5ff2950e2ed3839e998d31cbc6ac9fd57bc6002b15921620cd1c8dbf6e3acc7a80439bc4962cf25b9dce7c896f3a5bd70803fc5a0e33cf00206edb16d01907b759977d7650dad7e3ec049af1a3d875380b697c862c9ec5d51c201ea6675f9551eeb9dfaaa9247bc9858270d3d3a4c5afa7177a984d5ed1be245120d6acdedf95f608e09fa53fb43dcd0990475726c5131210c9e5caeab97f0e642f20bd74b25aacb92378a871bf27d225cfc26baca344a1ea35fdd94510f3d157082c201b77dac4d24fb7258c3c528704c59430b630718bec486421837021cf75dab65120ec677114c27206f5debc1c1ed66f95e2b1885da5b7be3d736b1de98579473048204777c8776a3b1e69b73a62fa701fa4f7a6282d9aee2c7a6b82e7937d7081c23c20ba49b659fbd0b7334211ea6a9d9df185c757e70aa81da562fb912b84f49bce722043ff5457f13b926b61df552d4e402ee6dc1463f99a535f9a713439264d5b616b207b99abdc3730991cc9274727d7d82d28cb794edbc7034b4f0053ff7c4b68044420d6c639ac24b46bd19341c91b13fdcab31581ddaf7f1411336a271f3d0aa52813208ac9cf9c391e3fd42891d27238a81a8a5c1d3a72b1bcbea8cf44a58ce738961320912d82b2c2bca231f71efcf61737fbf0a08befa0416215aeef53e8bb6d23390a20e110de65c907b9dea4ae0bd83a4b0a51bea175646a64c12b4c9f931b2cb31b4920d8283386ef2ef07ebdbb4383c12a739a953a4d6e0d6fb1139a4036d693bfbb6c20ffe9fc03f18b176c998806439ff0bb8ad193afdb27b2ccbc88856916dd804e3420817de36ab2d57feb077634bca77819c8e0bd298c04f6fed0e6a83cc1356ca155207efdc58818923de35ec35b4ef8e6a508f6952b9dd2a86af30a93dcd67e13ed350100000000000000\"]}\n
Step 2. Call api: wallet/createshieldedtransaction to create transaction Method: Post Parameter: {\n \"ask\": \"f9302122162221f59a7668e0d740245dcabaeb51dd157ba995eecd02f4b60b06\",\n \"nsk\": \"050fc9a42909e60fefb9d548fe12718cb759e3ee28d1b92ceaeaffc23d200a0d\",\n \"ovk\": \"a0da0cc6294dc900e93887b9f08ac42a162234359fdaf523b98382602c92513c\",\n\n \"shielded_spends\": [\n {\n \"note\": {\n \"value\": 90000000,\n \"payment_address\": \"ztron1jld8fmvujrz2vgkc867zuwklmewy4ypw0wtwgweqs2paee0uhc8f3azy90el770arksa2kunl02\",\n \"rcm\": \"e48836a3cfae0e1b27b5230460199b46ebd88ad650fa9db5ac1eafb20b516302\"\n },\n\n\n \"alpha\": \"2608999c3a97d005a879ecdaa16fd29ae434fb67b177c5e875b0c829e6a1db04\",\n \"voucher\": {\"tree\": {\"left\": {\"content\": \"7efdc58818923de35ec35b4ef8e6a508f6952b9dd2a86af30a93dcd67e13ed35\"},\"right\": {\"content\": \"f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b62\"}},\"rt\": \"72eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e\"},\n \"path\": \"2020b2eed031d4d6a4f02a097f80b54cc1541d4163c6b6f5971f88b6e41d35c538142012935f14b676509b81eb49ef25f39269ed72309238b4c145803544b646dca62d20e1f34b034d4a3cd28557e2907ebf990c918f64ecb50a94f01d6fda5ca5c7ef722028e7b841dcbc47cceb69d7cb8d94245fb7cb2ba3a7a6bc18f13f945f7dbd6e2a20a5122c08ff9c161d9ca6fc462073396c7d7d38e8ee48cdb3bea7e2230134ed6a20d2e1642c9a462229289e5b0e3b7f9008e0301cbb93385ee0e21da2545073cb582016d6252968971a83da8521d65382e61f0176646d771c91528e3276ee45383e4a20fee0e52802cb0c46b1eb4d376c62697f4759f6c8917fa352571202fd778fd712204c6937d78f42685f84b43ad3b7b00f81285662f85c6a68ef11d62ad1a3ee0850200769557bc682b1bf308646fd0b22e648e8b9e98f57e29f5af40f6edb833e2c492008eeab0c13abd6069e6310197bf80f9c1ea6de78fd19cbae24d4a520e6cf3023208d5fa43e5a10d11605ac7430ba1f5d81fb1b68d29a640405767749e841527673206aca8448d8263e547d5ff2950e2ed3839e998d31cbc6ac9fd57bc6002b15921620cd1c8dbf6e3acc7a80439bc4962cf25b9dce7c896f3a5bd70803fc5a0e33cf00206edb16d01907b759977d7650dad7e3ec049af1a3d875380b697c862c9ec5d51c201ea6675f9551eeb9dfaaa9247bc9858270d3d3a4c5afa7177a984d5ed1be245120d6acdedf95f608e09fa53fb43dcd0990475726c5131210c9e5caeab97f0e642f20bd74b25aacb92378a871bf27d225cfc26baca344a1ea35fdd94510f3d157082c201b77dac4d24fb7258c3c528704c59430b630718bec486421837021cf75dab65120ec677114c27206f5debc1c1ed66f95e2b1885da5b7be3d736b1de98579473048204777c8776a3b1e69b73a62fa701fa4f7a6282d9aee2c7a6b82e7937d7081c23c20ba49b659fbd0b7334211ea6a9d9df185c757e70aa81da562fb912b84f49bce722043ff5457f13b926b61df552d4e402ee6dc1463f99a535f9a713439264d5b616b207b99abdc3730991cc9274727d7d82d28cb794edbc7034b4f0053ff7c4b68044420d6c639ac24b46bd19341c91b13fdcab31581ddaf7f1411336a271f3d0aa52813208ac9cf9c391e3fd42891d27238a81a8a5c1d3a72b1bcbea8cf44a58ce738961320912d82b2c2bca231f71efcf61737fbf0a08befa0416215aeef53e8bb6d23390a20e110de65c907b9dea4ae0bd83a4b0a51bea175646a64c12b4c9f931b2cb31b4920d8283386ef2ef07ebdbb4383c12a739a953a4d6e0d6fb1139a4036d693bfbb6c20ffe9fc03f18b176c998806439ff0bb8ad193afdb27b2ccbc88856916dd804e3420817de36ab2d57feb077634bca77819c8e0bd298c04f6fed0e6a83cc1356ca155207efdc58818923de35ec35b4ef8e6a508f6952b9dd2a86af30a93dcd67e13ed350100000000000000\"\n\n }\n ],\n \"shielded_receives\": [\n {\n \"note\": {\n \"value\": 80000000,\n \"payment_address\": \"ztron1wd46s6fwmz99gulqpxul6zffqtevzfpl93ng3s5834fhwf6e7w5l6zmjhmpvtwsc4wxa7dusmvr\",\n \"rcm\": \"ccced07d36641fc93cba33cddda7064cb82f6962a0bdf15a4240a4a742770e03\"\n }\n }\n ]\n}\n
Return: {\"txID\":\"5a057fde4a1add0da38eda9978f6c3d035f7ca4807adae4b8c57e34499dfedfb\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"binding_signature\":\"b77c81fdb8af64075a7d95e8f04ef28660bb2f3f2bfb884baf17abd87ae7f212de091016ae6147edbff280b52515a1a52515bd1fa118de2964412f87b6a5790c\",\"spend_description\":[{\"value_commitment\":\"ddc8138f73323eff8d2f0367070c63f5e2659538fa431d6aa06d62696845e529\",\"anchor\":\"72eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e\",\"nullifier\":\"29269506e140e7cc70699443c9b80eb161048ec0126e308d458245991242478c\",\"rk\":\"c76c88d21edb0f5b2b04c960668cf1053feda5954a00d70e7d329025323bf463\",\"spend_authority_signature\":\"518def6477325d78b77b00aac6142bfc7b9a5f3eaaff5b8b4b8f2c46114ed85d1cc15a314028f58ce0c42e9f030f465063bbc0c41d01c92edd639d02575f6b08\",\"zkproof\":\"82eda1b9baeaa5b08b3b33f157ae7a117e2561c702520e615a92e65098615eba1809a20e0b518fef286268d4c6f15a8eaa1b2a15630dd673fcfdde503a12daf80dfc157e6a0ea9333dedc2c365368847f2e7d8e3e648cc65cf5e805cd2343077051d70fcd140a8c665760f8cf066edb32036de7421e6755f3b64f44621aaa47d7e0f2012069ad374a7addb00b841b759b9e567c7b8b2642110eabd22358d22f4d3b4002a1ba4e9f6c018c58a5c1242acbc0169cf4aa0bf1423ed4a0b688928ad\"}],\"fee\":10000000,\"receive_description\":[{\"value_commitment\":\"6b082c7b9d01338d60fc4f5d434a152f9d8bf5c05c22422e23d3c74d36c2b925\",\"note_commitment\":\"e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f02\",\"epk\":\"36b1cb275228b3ab8275d6b04b3e2e93c04d5c0cc0ab1f41421093228b94f758\",\"c_enc\":\"1f91dd5cdf0731c99318a2a87b169b7159230c4dee4e47e8b0717fc51c604ccc7a2df9c873a91903e59528756e2c2f3bd07ec5aa9b994ae5d8492ad779d6a00d4a71e7cb742c1ae416e4d983554fade0e04b0213880da2e96be402a5351ca3a5d78e5a975d20cb5ec1475c7ed35dc09c0b04a3a2e8a65595d8d77652f2881a4b93ed99cff007b3923b36967be6819721ed3daea2190fca744423ffb77d1a579f569bfb30c77ad0dadc0ca484a7a89318e15d50e540744927e19c5f6f08be2e97e77cd9c6ce3e05bdbeeb6f6d7b53f83a2283f56786ea8544c98b648300dfb8554e7a2611204598ddc37c4e61ce5881e63ab171ec83c1aedf97166596d014b1fc8193ff30d4e1c7aff8a3c3638e3a41b2a4040828a8d9568ab0fe4aef08a97872ca84c6c247635a1774efde8b8ed16177393879c8626a8ea0075fa2db5af58754d712ccd5a94dcf87c019faffa2c8f3143a9a9d540de4a705c87fc16dc5efa0c387f1e6ed9dad12b84f2ca7bb09cd95a10a2e412fc410aa7ebf676f6a74f03a7334a0a1697067cc88ccd968bdf6d8c20ed7d7bd9687bda89fb28c2849e45734d30395fead9f955649a3e3f1deb15eb02f28dad608d6d0ef2943ae9fd9e14f2507e9b871a3bebe5d15ba41a8dafc7dd18cd594eb69ad89192e776fc35a3d6eb48c2446d78258fed12cbb61200ddf0c3d2dbbf73fc82a4a2e96f619fa1ad479e6da108ddab453c02fa2fa8e96721585b791f6478966e36d2d75a6677858a64672dde9bb72feb64b58b7723c13c75f70cf7333c3331d46951633a2686b108e48215eb5d56653\",\"c_out\":\"bbbf78f926fa2cae70ed68ef644487c32a82da230b5b8e2be26aa3102627ffc2db26f45f29c2379b20595ef26c60801f33508e17f03f66694cfdf15f606e5fabfe1d76593c1a8543593c10160f4ae4a0\",\"zkproof\":\"b5597534076320a98ef1a546253185011f17cc7d175a8937736bfe1daee1c33e25411346996e64d0bf1887c4553b49bb815cc8ef57b6811e7213b8c7f81c9853a4663703bf2b2989688a9ae5cabcc56c2316d411f6b910722169609d76890a2b0fc9b3fb536c3be378eb4100b925d9ae6a4a9e08eee591066f881c726a0416861ad41f69148619d187ee4d8f0f8b111da8f0d5bd4f781c2ddfdd7e4b3544b09ec2c9548cef85c28cd1129bf60f1f421c9ac7ed7f36b20984038fb33fcb409956\"}]},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"029b\",\"ref_block_hash\":\"027c45a7dc0875f7\",\"expiration\":1558691547000,\"timestamp\":1558691489292},\"raw_data_hex\":\"0a02029b2208027c45a7dc0875f740f88e86caae2d5adb0b083312d60b0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e7472616374129c0b1a8d030a20ddc8138f73323eff8d2f0367070c63f5e2659538fa431d6aa06d62696845e529122072eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e1a2029269506e140e7cc70699443c9b80eb161048ec0126e308d458245991242478c2220c76c88d21edb0f5b2b04c960668cf1053feda5954a00d70e7d329025323bf4632ac00182eda1b9baeaa5b08b3b33f157ae7a117e2561c702520e615a92e65098615eba1809a20e0b518fef286268d4c6f15a8eaa1b2a15630dd673fcfdde503a12daf80dfc157e6a0ea9333dedc2c365368847f2e7d8e3e648cc65cf5e805cd2343077051d70fcd140a8c665760f8cf066edb32036de7421e6755f3b64f44621aaa47d7e0f2012069ad374a7addb00b841b759b9e567c7b8b2642110eabd22358d22f4d3b4002a1ba4e9f6c018c58a5c1242acbc0169cf4aa0bf1423ed4a0b688928ad3240518def6477325d78b77b00aac6142bfc7b9a5f3eaaff5b8b4b8f2c46114ed85d1cc15a314028f58ce0c42e9f030f465063bbc0c41d01c92edd639d02575f6b0822c2070a206b082c7b9d01338d60fc4f5d434a152f9d8bf5c05c22422e23d3c74d36c2b9251220e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f021a2036b1cb275228b3ab8275d6b04b3e2e93c04d5c0cc0ab1f41421093228b94f75822c4041f91dd5cdf0731c99318a2a87b169b7159230c4dee4e47e8b0717fc51c604ccc7a2df9c873a91903e59528756e2c2f3bd07ec5aa9b994ae5d8492ad779d6a00d4a71e7cb742c1ae416e4d983554fade0e04b0213880da2e96be402a5351ca3a5d78e5a975d20cb5ec1475c7ed35dc09c0b04a3a2e8a65595d8d77652f2881a4b93ed99cff007b3923b36967be6819721ed3daea2190fca744423ffb77d1a579f569bfb30c77ad0dadc0ca484a7a89318e15d50e540744927e19c5f6f08be2e97e77cd9c6ce3e05bdbeeb6f6d7b53f83a2283f56786ea8544c98b648300dfb8554e7a2611204598ddc37c4e61ce5881e63ab171ec83c1aedf97166596d014b1fc8193ff30d4e1c7aff8a3c3638e3a41b2a4040828a8d9568ab0fe4aef08a97872ca84c6c247635a1774efde8b8ed16177393879c8626a8ea0075fa2db5af58754d712ccd5a94dcf87c019faffa2c8f3143a9a9d540de4a705c87fc16dc5efa0c387f1e6ed9dad12b84f2ca7bb09cd95a10a2e412fc410aa7ebf676f6a74f03a7334a0a1697067cc88ccd968bdf6d8c20ed7d7bd9687bda89fb28c2849e45734d30395fead9f955649a3e3f1deb15eb02f28dad608d6d0ef2943ae9fd9e14f2507e9b871a3bebe5d15ba41a8dafc7dd18cd594eb69ad89192e776fc35a3d6eb48c2446d78258fed12cbb61200ddf0c3d2dbbf73fc82a4a2e96f619fa1ad479e6da108ddab453c02fa2fa8e96721585b791f6478966e36d2d75a6677858a64672dde9bb72feb64b58b7723c13c75f70cf7333c3331d46951633a2686b108e48215eb5d566532a50bbbf78f926fa2cae70ed68ef644487c32a82da230b5b8e2be26aa3102627ffc2db26f45f29c2379b20595ef26c60801f33508e17f03f66694cfdf15f606e5fabfe1d76593c1a8543593c10160f4ae4a032c001b5597534076320a98ef1a546253185011f17cc7d175a8937736bfe1daee1c33e25411346996e64d0bf1887c4553b49bb815cc8ef57b6811e7213b8c7f81c9853a4663703bf2b2989688a9ae5cabcc56c2316d411f6b910722169609d76890a2b0fc9b3fb536c3be378eb4100b925d9ae6a4a9e08eee591066f881c726a0416861ad41f69148619d187ee4d8f0f8b111da8f0d5bd4f781c2ddfdd7e4b3544b09ec2c9548cef85c28cd1129bf60f1f421c9ac7ed7f36b20984038fb33fcb4099562a40b77c81fdb8af64075a7d95e8f04ef28660bb2f3f2bfb884baf17abd87ae7f212de091016ae6147edbff280b52515a1a52515bd1fa118de2964412f87b6a5790c4080ade204708ccc82caae2d\"}\n
Step 3. Call api: wallet/broadcasttransaction to broadcast this transaction(no need to sign this transaction) Method: Post Parameter: {\"txID\":\"791d30b7123448a54c56407a11857d4f3885cb699a071ee5f265f7db408dec6c\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"binding_signature\":\"231cc2ddbf2715b51d07ed63e142ad874e7e173ec0c5d681b49e3060ca33bd65cf39921355dfaacc62dac7aa810c49daafbf8db8a1adc168da4a833eba0d7504\",\"spend_description\":[{\"value_commitment\":\"f4c543df8f0fe9b71b1bbd6aa2f06f87e07605dcd339b0eaa48afd9e2488b140\",\"anchor\":\"72eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e\",\"nullifier\":\"29269506e140e7cc70699443c9b80eb161048ec0126e308d458245991242478c\",\"rk\":\"c76c88d21edb0f5b2b04c960668cf1053feda5954a00d70e7d329025323bf463\",\"spend_authority_signature\":\"2f50449f92e4bf541c9ba7d82b93f6dd416208449ea8996dc45614c1cb90a7911264fece30446da875d8a864224f1a3870e3654ec8a4005305faa329224f4c08\",\"zkproof\":\"984779ad18c87d71dd79b78564e49c1c18d6f871ef45f79bdb012f73439d6402593dd7cda308d9d5412e2b64b0be461192eb2a8d2ffdcc700475a1c8b8912220f628af41bf44a7c010a8dda2a65f98b4aaf8c375c4046afd1af3e6bbe4b33b9210c68298f46999322174b9ba76b0be4d6ef2c74ff5d16370a8c30fa17c5c3bbeab217610de5cc680b1d64d557c4d53a4a3f73294699ac6a00b37c3d8076a20362ab09c77c94f08bb00db2648ade72f224821ecc190627222cf58130b9bcf639b\"}],\"fee\":10000000,\"receive_description\":[{\"value_commitment\":\"3f4465801b357f9b8334eb3025bd8b3cd84247355c099133c08d53a8cffd3595\",\"note_commitment\":\"e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f02\",\"epk\":\"3ece31615aec76e7711e25b05b05f5b7fb99d75f3812fe56702291633e5f474c\",\"c_enc\":\"4fc57e65bfdd91e2ae0284cfc2926d5df63d51b8f864e9191f368404db390e28ce15fefc9bd210aca4e7f42b30140bc4b1650d9a79bcbfb1670288c68d4678ba5c34266ce1bd4fd1f4e4040508b072cdca87d69e4921af8c8305f982aa7f37897a29c69cce06c311eafb2ef5928f07d5b8f207e5f46c32237f6e9b0eadc2597e0cd8d884cd3f4a35d86145e75565913b9d4a2e613523c9f377fe3bdf6f1d9e6789605e6bdaf9526412632e52a1994fec98dd086596c62ba028508d45933943f3446c83f463f56e860f29d2ea0eb3b87a55a0602974b7df6b58905872cb97a757f24515f05d2b12d932a0ac038e0c0b15b9c8b324c8e31d4ddf8bf39bfb65bd9d495eac1818b281822c9ad85adbe8a90f62adfbb6723fae7a7d91760a5b2d146f180d5ca4d85653449089f4788459752e899abd4abd395842e8b5315dd3738eee0b4e0f758698aabb92df587b703e85774048f290ea366696de3dde665eefb6fce6c2776e4e9ad18662b8d95af4203a10e9af54085ee498c77ad7e7b5824f91aaeb8f138d8c90d95f57e71dc15c177b602c45e38f12e402cc65c2c55b80c9a7d908332baa30b2871a0d6cf417bcaf0be6ae5c451c2468e945273151da500aaccd7235a29c7fcd0da4ac4d6ceefda59cf568f7a362b49654a5793c552bd970681a6489a1951ad75e22215b22d5cd511a030d751892b4b5746d66f048d6b6889c2ddcd5da908417b91ef52c0507b2ce8b1214567b71963c5d6ace1f6e858ce02b11fcf0f839cbe8183fa71b9a239f70c5e98642f6e9b9b6eb31f12a752829ebecf0f12df040\",\"c_out\":\"5fc1926bb6501f8ec4dc796d56786d7f019db9e43ccde07bbbddd95444df4f099310ef3f8d86a0a25ff72de0385563e44b9cb9e5e477299891959d24060a3b08b41aa36c29ce7297f0806a74f11aa99e\",\"zkproof\":\"b924ae84aba3af2c4d6529c22ebd6ba900ac63c629723e035ab843295d41aec1e9ebb2906fa7471473dbdae7e182fbd7a9f14a2f599a79456a3dbb949203d9923c3c3600225f12217e38b69b88a080b5b5751d78ac84375c9a03ad0bc61492850c49488a654c376c49701abdde20d5658bce851e9a6fd1bee5429b9b4d4b55ed1eb888a43f435740b8f063ea6e2e7e81b53f12e67e3eac60020aab5c3ff45d34ff2c3dde4eb76ed2893df22232993deb1b9397d1d4f9cc1eb8405f7cbef5a24b\"}]},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"0328\",\"ref_block_hash\":\"833c24d9f1019cd0\",\"expiration\":1558691970000,\"timestamp\":1558691911355},\"raw_data_hex\":\"0a0203282208833c24d9f1019cd040d0f79fcaae2d5adb0b083312d60b0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e7472616374129c0b1a8d030a20f4c543df8f0fe9b71b1bbd6aa2f06f87e07605dcd339b0eaa48afd9e2488b140122072eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e1a2029269506e140e7cc70699443c9b80eb161048ec0126e308d458245991242478c2220c76c88d21edb0f5b2b04c960668cf1053feda5954a00d70e7d329025323bf4632ac001984779ad18c87d71dd79b78564e49c1c18d6f871ef45f79bdb012f73439d6402593dd7cda308d9d5412e2b64b0be461192eb2a8d2ffdcc700475a1c8b8912220f628af41bf44a7c010a8dda2a65f98b4aaf8c375c4046afd1af3e6bbe4b33b9210c68298f46999322174b9ba76b0be4d6ef2c74ff5d16370a8c30fa17c5c3bbeab217610de5cc680b1d64d557c4d53a4a3f73294699ac6a00b37c3d8076a20362ab09c77c94f08bb00db2648ade72f224821ecc190627222cf58130b9bcf639b32402f50449f92e4bf541c9ba7d82b93f6dd416208449ea8996dc45614c1cb90a7911264fece30446da875d8a864224f1a3870e3654ec8a4005305faa329224f4c0822c2070a203f4465801b357f9b8334eb3025bd8b3cd84247355c099133c08d53a8cffd35951220e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f021a203ece31615aec76e7711e25b05b05f5b7fb99d75f3812fe56702291633e5f474c22c4044fc57e65bfdd91e2ae0284cfc2926d5df63d51b8f864e9191f368404db390e28ce15fefc9bd210aca4e7f42b30140bc4b1650d9a79bcbfb1670288c68d4678ba5c34266ce1bd4fd1f4e4040508b072cdca87d69e4921af8c8305f982aa7f37897a29c69cce06c311eafb2ef5928f07d5b8f207e5f46c32237f6e9b0eadc2597e0cd8d884cd3f4a35d86145e75565913b9d4a2e613523c9f377fe3bdf6f1d9e6789605e6bdaf9526412632e52a1994fec98dd086596c62ba028508d45933943f3446c83f463f56e860f29d2ea0eb3b87a55a0602974b7df6b58905872cb97a757f24515f05d2b12d932a0ac038e0c0b15b9c8b324c8e31d4ddf8bf39bfb65bd9d495eac1818b281822c9ad85adbe8a90f62adfbb6723fae7a7d91760a5b2d146f180d5ca4d85653449089f4788459752e899abd4abd395842e8b5315dd3738eee0b4e0f758698aabb92df587b703e85774048f290ea366696de3dde665eefb6fce6c2776e4e9ad18662b8d95af4203a10e9af54085ee498c77ad7e7b5824f91aaeb8f138d8c90d95f57e71dc15c177b602c45e38f12e402cc65c2c55b80c9a7d908332baa30b2871a0d6cf417bcaf0be6ae5c451c2468e945273151da500aaccd7235a29c7fcd0da4ac4d6ceefda59cf568f7a362b49654a5793c552bd970681a6489a1951ad75e22215b22d5cd511a030d751892b4b5746d66f048d6b6889c2ddcd5da908417b91ef52c0507b2ce8b1214567b71963c5d6ace1f6e858ce02b11fcf0f839cbe8183fa71b9a239f70c5e98642f6e9b9b6eb31f12a752829ebecf0f12df0402a505fc1926bb6501f8ec4dc796d56786d7f019db9e43ccde07bbbddd95444df4f099310ef3f8d86a0a25ff72de0385563e44b9cb9e5e477299891959d24060a3b08b41aa36c29ce7297f0806a74f11aa99e32c001b924ae84aba3af2c4d6529c22ebd6ba900ac63c629723e035ab843295d41aec1e9ebb2906fa7471473dbdae7e182fbd7a9f14a2f599a79456a3dbb949203d9923c3c3600225f12217e38b69b88a080b5b5751d78ac84375c9a03ad0bc61492850c49488a654c376c49701abdde20d5658bce851e9a6fd1bee5429b9b4d4b55ed1eb888a43f435740b8f063ea6e2e7e81b53f12e67e3eac60020aab5c3ff45d34ff2c3dde4eb76ed2893df22232993deb1b9397d1d4f9cc1eb8405f7cbef5a24b2a40231cc2ddbf2715b51d07ed63e142ad874e7e173ec0c5d681b49e3060ca33bd65cf39921355dfaacc62dac7aa810c49daafbf8db8a1adc168da4a833eba0d75044080ade20470bbad9ccaae2d\"}\n
Return: {\"result\": true}\n
"},{"location":"mechanism-algorithm/shielded-transaction/#transfer-from-shielded-address-to-transparent-address","title":"Transfer from shielded address to transparent address","text":"Step 1. Call api: wallet/getmerkletreevoucherinfo to get the voucher of the shield address, this info will be used when create shielded transaction Method: Post Parameter:
{\n \"out_points\":[{\n \"hash\":\"791d30b7123448a54c56407a11857d4f3885cb699a071ee5f265f7db408dec6c\",\n \"index\":0\n }],\n \"block_num\":1\n}\n
Return: {\"vouchers\": [{\"tree\": {\"left\": {\"content\": \"e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f02\"},\"parents\": [{\"content\": \"c835053e32be73852e67a65f4cd40407a11f4a7a38bb84b8d3e8a1f57acdbf61\"}]},\"rt\": \"8bdf96ac1241f30d5cd54d4ece7f10867d9eef854121ef77d1015f0ab2a26b1b\"}],\"paths\": [\"2020b2eed031d4d6a4f02a097f80b54cc1541d4163c6b6f5971f88b6e41d35c538142012935f14b676509b81eb49ef25f39269ed72309238b4c145803544b646dca62d20e1f34b034d4a3cd28557e2907ebf990c918f64ecb50a94f01d6fda5ca5c7ef722028e7b841dcbc47cceb69d7cb8d94245fb7cb2ba3a7a6bc18f13f945f7dbd6e2a20a5122c08ff9c161d9ca6fc462073396c7d7d38e8ee48cdb3bea7e2230134ed6a20d2e1642c9a462229289e5b0e3b7f9008e0301cbb93385ee0e21da2545073cb582016d6252968971a83da8521d65382e61f0176646d771c91528e3276ee45383e4a20fee0e52802cb0c46b1eb4d376c62697f4759f6c8917fa352571202fd778fd712204c6937d78f42685f84b43ad3b7b00f81285662f85c6a68ef11d62ad1a3ee0850200769557bc682b1bf308646fd0b22e648e8b9e98f57e29f5af40f6edb833e2c492008eeab0c13abd6069e6310197bf80f9c1ea6de78fd19cbae24d4a520e6cf3023208d5fa43e5a10d11605ac7430ba1f5d81fb1b68d29a640405767749e841527673206aca8448d8263e547d5ff2950e2ed3839e998d31cbc6ac9fd57bc6002b15921620cd1c8dbf6e3acc7a80439bc4962cf25b9dce7c896f3a5bd70803fc5a0e33cf00206edb16d01907b759977d7650dad7e3ec049af1a3d875380b697c862c9ec5d51c201ea6675f9551eeb9dfaaa9247bc9858270d3d3a4c5afa7177a984d5ed1be245120d6acdedf95f608e09fa53fb43dcd0990475726c5131210c9e5caeab97f0e642f20bd74b25aacb92378a871bf27d225cfc26baca344a1ea35fdd94510f3d157082c201b77dac4d24fb7258c3c528704c59430b630718bec486421837021cf75dab65120ec677114c27206f5debc1c1ed66f95e2b1885da5b7be3d736b1de98579473048204777c8776a3b1e69b73a62fa701fa4f7a6282d9aee2c7a6b82e7937d7081c23c20ba49b659fbd0b7334211ea6a9d9df185c757e70aa81da562fb912b84f49bce722043ff5457f13b926b61df552d4e402ee6dc1463f99a535f9a713439264d5b616b207b99abdc3730991cc9274727d7d82d28cb794edbc7034b4f0053ff7c4b68044420d6c639ac24b46bd19341c91b13fdcab31581ddaf7f1411336a271f3d0aa52813208ac9cf9c391e3fd42891d27238a81a8a5c1d3a72b1bcbea8cf44a58ce738961320912d82b2c2bca231f71efcf61737fbf0a08befa0416215aeef53e8bb6d23390a20e110de65c907b9dea4ae0bd83a4b0a51bea175646a64c12b4c9f931b2cb31b4920d8283386ef2ef07ebdbb4383c12a739a953a4d6e0d6fb1139a4036d693bfbb6c20ffe9fc03f18b176c998806439ff0bb8ad193afdb27b2ccbc88856916dd804e3420c835053e32be73852e67a65f4cd40407a11f4a7a38bb84b8d3e8a1f57acdbf612001000000000000000000000000000000000000000000000000000000000000000200000000000000\"]}\n
Step 2. Call api: wallet/createshieldedtransaction to create transaction Method: Post Parameter:
{\n \"ask\": \"653b3a3fdd40b60d2f53ba121df8840f6590384993f8fa9a0ecb0dfb23496604\",\n \"nsk\": \"428ff3c9e101dc1fca08f7b0e3387b23b68016746ae565aefc19d112b696db01\",\n \"ovk\": \"1274dcc5c7307bf0fd0ead466e9dd5641fed4a51391f681862370e2f2654cc61\",\n \"shielded_spends\": [\n {\n \"note\": {\n \"value\": 80000000,\n \"payment_address\": \"ztron1wd46s6fwmz99gulqpxul6zffqtevzfpl93ng3s5834fhwf6e7w5l6zmjhmpvtwsc4wxa7dusmvr\",\n \"rcm\": \"ccced07d36641fc93cba33cddda7064cb82f6962a0bdf15a4240a4a742770e03\"\n },\n \"alpha\": \"3ad5406efd6efcd81d27696d5f91efc07ba5c98ea6fb0f787b93e557b51df405\",\n \"voucher\": {\n \"tree\": {\n \"left\": {\n \"content\": \"f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b62\"\n },\n \"right\": {\n \"content\": \"e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f02\"\n }\n },\n \"rt\": \"774d05ec02749475672a94a8fb2daaa11c323defa09df121b7359353f0c3a567\"\n },\n \"path\": \"2020b2eed031d4d6a4f02a097f80b54cc1541d4163c6b6f5971f88b6e41d35c538142012935f14b676509b81eb49ef25f39269ed72309238b4c145803544b646dca62d20e1f34b034d4a3cd28557e2907ebf990c918f64ecb50a94f01d6fda5ca5c7ef722028e7b841dcbc47cceb69d7cb8d94245fb7cb2ba3a7a6bc18f13f945f7dbd6e2a20a5122c08ff9c161d9ca6fc462073396c7d7d38e8ee48cdb3bea7e2230134ed6a20d2e1642c9a462229289e5b0e3b7f9008e0301cbb93385ee0e21da2545073cb582016d6252968971a83da8521d65382e61f0176646d771c91528e3276ee45383e4a20fee0e52802cb0c46b1eb4d376c62697f4759f6c8917fa352571202fd778fd712204c6937d78f42685f84b43ad3b7b00f81285662f85c6a68ef11d62ad1a3ee0850200769557bc682b1bf308646fd0b22e648e8b9e98f57e29f5af40f6edb833e2c492008eeab0c13abd6069e6310197bf80f9c1ea6de78fd19cbae24d4a520e6cf3023208d5fa43e5a10d11605ac7430ba1f5d81fb1b68d29a640405767749e841527673206aca8448d8263e547d5ff2950e2ed3839e998d31cbc6ac9fd57bc6002b15921620cd1c8dbf6e3acc7a80439bc4962cf25b9dce7c896f3a5bd70803fc5a0e33cf00206edb16d01907b759977d7650dad7e3ec049af1a3d875380b697c862c9ec5d51c201ea6675f9551eeb9dfaaa9247bc9858270d3d3a4c5afa7177a984d5ed1be245120d6acdedf95f608e09fa53fb43dcd0990475726c5131210c9e5caeab97f0e642f20bd74b25aacb92378a871bf27d225cfc26baca344a1ea35fdd94510f3d157082c201b77dac4d24fb7258c3c528704c59430b630718bec486421837021cf75dab65120ec677114c27206f5debc1c1ed66f95e2b1885da5b7be3d736b1de98579473048204777c8776a3b1e69b73a62fa701fa4f7a6282d9aee2c7a6b82e7937d7081c23c20ba49b659fbd0b7334211ea6a9d9df185c757e70aa81da562fb912b84f49bce722043ff5457f13b926b61df552d4e402ee6dc1463f99a535f9a713439264d5b616b207b99abdc3730991cc9274727d7d82d28cb794edbc7034b4f0053ff7c4b68044420d6c639ac24b46bd19341c91b13fdcab31581ddaf7f1411336a271f3d0aa52813208ac9cf9c391e3fd42891d27238a81a8a5c1d3a72b1bcbea8cf44a58ce738961320912d82b2c2bca231f71efcf61737fbf0a08befa0416215aeef53e8bb6d23390a20e110de65c907b9dea4ae0bd83a4b0a51bea175646a64c12b4c9f931b2cb31b4920d8283386ef2ef07ebdbb4383c12a739a953a4d6e0d6fb1139a4036d693bfbb6c20ffe9fc03f18b176c998806439ff0bb8ad193afdb27b2ccbc88856916dd804e3420817de36ab2d57feb077634bca77819c8e0bd298c04f6fed0e6a83cc1356ca15520f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b620100000000000000\"\n }\n ],\n \"transparent_to_address\": \"41A7D8A35B260395C14AA456297662092BA3B76FC0\",\n \"to_amount\": 70000000\n}\n
Return: {\"txID\":\"4dbdc95574a155434baeaf5e690e2d0c77a2b883a048d8d0103ab5c7fed8d866\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"to_amount\":70000000,\"binding_signature\":\"780be5a118c7b96847a6b1932f1ab6f559ce3648e321821f22570dbde7d59c58559aae93a2f334537544b6c85218c83397b0779926247848560c3e9ef5ba8203\",\"spend_description\":[{\"value_commitment\":\"086c712a60d5aa0d16276fb18b5504a875d97cecb2a0afa8219c8031aec94bd9\",\"anchor\":\"774d05ec02749475672a94a8fb2daaa11c323defa09df121b7359353f0c3a567\",\"nullifier\":\"fa07f704bd34a8a7c1804601f322e6c1415247bfaa2f0d04715b9b4ac65b3587\",\"rk\":\"41132c4e6bc24faae1cb8cdee2c7f84bd4b3aa27e50c099ca205c1c0538ca2d4\",\"spend_authority_signature\":\"b928f855d397ab758b60251ee3ce40f951df51a6111064ad90fe4aa467cd69ec649c55ebb59c034c0c72daca0e9063da72383108942c79f7bd1b0f6b22f30207\",\"zkproof\":\"b3552325eb9212097ba3f56a4e0770c92cd28a8d6974e3a30436115b2a49adae7e1f49a0f2920042145bfe4a127ada22b3000ba0faa15b408340ca5c377943e3b3c8566ad471d84321b9d24c0a47b6b42b83d562523b07a16401cb5f4e51aa040b1300f443d963150db7f08b2606f3e17ba386d1308720c20901d74e8b94b47a78c00f416c71b4fffed1fd6d7b41ebb0993bbd1fa05754514d05575e09ce8f6a6438b8b158a1067d01b195c6631b25434f64360aedcdcfacb163efe866a05ee1\"}],\"fee\":10000000,\"transparent_to_address\":\"41a7d8a35b260395c14aa456297662092ba3b76fc0\"},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"00dc\",\"ref_block_hash\":\"a45c748f93fa2854\",\"expiration\":1558928754000,\"timestamp\":1558928695327},\"raw_data_hex\":\"0a0200dc2208a45c748f93fa285440d08a94bbaf2d5ab204083312ad040a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e747261637412f3031a8d030a20086c712a60d5aa0d16276fb18b5504a875d97cecb2a0afa8219c8031aec94bd91220774d05ec02749475672a94a8fb2daaa11c323defa09df121b7359353f0c3a5671a20fa07f704bd34a8a7c1804601f322e6c1415247bfaa2f0d04715b9b4ac65b3587222041132c4e6bc24faae1cb8cdee2c7f84bd4b3aa27e50c099ca205c1c0538ca2d42ac001b3552325eb9212097ba3f56a4e0770c92cd28a8d6974e3a30436115b2a49adae7e1f49a0f2920042145bfe4a127ada22b3000ba0faa15b408340ca5c377943e3b3c8566ad471d84321b9d24c0a47b6b42b83d562523b07a16401cb5f4e51aa040b1300f443d963150db7f08b2606f3e17ba386d1308720c20901d74e8b94b47a78c00f416c71b4fffed1fd6d7b41ebb0993bbd1fa05754514d05575e09ce8f6a6438b8b158a1067d01b195c6631b25434f64360aedcdcfacb163efe866a05ee13240b928f855d397ab758b60251ee3ce40f951df51a6111064ad90fe4aa467cd69ec649c55ebb59c034c0c72daca0e9063da72383108942c79f7bd1b0f6b22f302072a40780be5a118c7b96847a6b1932f1ab6f559ce3648e321821f22570dbde7d59c58559aae93a2f334537544b6c85218c83397b0779926247848560c3e9ef5ba8203321541a7d8a35b260395c14aa456297662092ba3b76fc03880bbb0214080ade204709fc090bbaf2d\"}\n
Step 3. Call api: wallet/broadcasttransaction to broadcast this transaction(no need to sign this transaction) Method: Post Parameter:
{\"txID\":\"4dbdc95574a155434baeaf5e690e2d0c77a2b883a048d8d0103ab5c7fed8d866\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"to_amount\":70000000,\"binding_signature\":\"780be5a118c7b96847a6b1932f1ab6f559ce3648e321821f22570dbde7d59c58559aae93a2f334537544b6c85218c83397b0779926247848560c3e9ef5ba8203\",\"spend_description\":[{\"value_commitment\":\"086c712a60d5aa0d16276fb18b5504a875d97cecb2a0afa8219c8031aec94bd9\",\"anchor\":\"774d05ec02749475672a94a8fb2daaa11c323defa09df121b7359353f0c3a567\",\"nullifier\":\"fa07f704bd34a8a7c1804601f322e6c1415247bfaa2f0d04715b9b4ac65b3587\",\"rk\":\"41132c4e6bc24faae1cb8cdee2c7f84bd4b3aa27e50c099ca205c1c0538ca2d4\",\"spend_authority_signature\":\"b928f855d397ab758b60251ee3ce40f951df51a6111064ad90fe4aa467cd69ec649c55ebb59c034c0c72daca0e9063da72383108942c79f7bd1b0f6b22f30207\",\"zkproof\":\"b3552325eb9212097ba3f56a4e0770c92cd28a8d6974e3a30436115b2a49adae7e1f49a0f2920042145bfe4a127ada22b3000ba0faa15b408340ca5c377943e3b3c8566ad471d84321b9d24c0a47b6b42b83d562523b07a16401cb5f4e51aa040b1300f443d963150db7f08b2606f3e17ba386d1308720c20901d74e8b94b47a78c00f416c71b4fffed1fd6d7b41ebb0993bbd1fa05754514d05575e09ce8f6a6438b8b158a1067d01b195c6631b25434f64360aedcdcfacb163efe866a05ee1\"}],\"fee\":10000000,\"transparent_to_address\":\"41a7d8a35b260395c14aa456297662092ba3b76fc0\"},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"00dc\",\"ref_block_hash\":\"a45c748f93fa2854\",\"expiration\":1558928754000,\"timestamp\":1558928695327},\"raw_data_hex\":\"0a0200dc2208a45c748f93fa285440d08a94bbaf2d5ab204083312ad040a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e747261637412f3031a8d030a20086c712a60d5aa0d16276fb18b5504a875d97cecb2a0afa8219c8031aec94bd91220774d05ec02749475672a94a8fb2daaa11c323defa09df121b7359353f0c3a5671a20fa07f704bd34a8a7c1804601f322e6c1415247bfaa2f0d04715b9b4ac65b3587222041132c4e6bc24faae1cb8cdee2c7f84bd4b3aa27e50c099ca205c1c0538ca2d42ac001b3552325eb9212097ba3f56a4e0770c92cd28a8d6974e3a30436115b2a49adae7e1f49a0f2920042145bfe4a127ada22b3000ba0faa15b408340ca5c377943e3b3c8566ad471d84321b9d24c0a47b6b42b83d562523b07a16401cb5f4e51aa040b1300f443d963150db7f08b2606f3e17ba386d1308720c20901d74e8b94b47a78c00f416c71b4fffed1fd6d7b41ebb0993bbd1fa05754514d05575e09ce8f6a6438b8b158a1067d01b195c6631b25434f64360aedcdcfacb163efe866a05ee13240b928f855d397ab758b60251ee3ce40f951df51a6111064ad90fe4aa467cd69ec649c55ebb59c034c0c72daca0e9063da72383108942c79f7bd1b0f6b22f302072a40780be5a118c7b96847a6b1932f1ab6f559ce3648e321821f22570dbde7d59c58559aae93a2f334537544b6c85218c83397b0779926247848560c3e9ef5ba8203321541a7d8a35b260395c14aa456297662092ba3b76fc03880bbb0214080ade204709fc090bbaf2d\"}\n
Return: {\"result\": true}\n
"},{"location":"mechanism-algorithm/sr/","title":"Super Representative","text":""},{"location":"mechanism-algorithm/sr/#how-to-become-a-super-representative","title":"How to Become a Super Representative","text":"Block producers in the TRON network, also called super representatives, are elected by voting. Any account can apply to become a super representative candidate by paying 9999 TRX and then participate in the super representative election. Any account can vote for super representative candidates, and the top 27 candidates with the most votes become super representatives, and they have the right to produce blocks. Super representative needs to run a TRON node to participate in block production, and will also receive block rewards and voting rewards. Voters who vote to super representatives will receive voting rewards.
The super representative candidates ranked 28th to 127th are also called super representative partners. Super representative partners do not participate in block production and packaging transactions, but will receive voting rewards. Voters who vote to super representative partners will also receive voting rewards.
The votes will be counted every 6 hours, so super representatives and super representative partners will be changed every 6 hours.
"},{"location":"mechanism-algorithm/sr/#super-representative-election","title":"Super Representative Election","text":"To vote, you need to have TRON Power(TP). To get TRON Power, you need to stake TRX. Every 1 staked TRX accounts for one TRON Power(TP). Every account in TRON network has the right to vote for a super representative candidate. After you unstake your staked TRX, you will lose the corresponding TRON Power(TP), so your previous vote will be invalid.
Note: Only your latest vote will be counted in TRON network which means your previous vote will be over written by your latest vote.
Example (Using wallet-cli):
> freezebalancev2 10,000,000 3 // Stake 10 TRX to get 10 TRON Power(TP)\n> votewitness SR1 4 SR2 6 // Vote 4 votes for SR1, 6 votes for SR2\n> votewitness SR1 3 SR2 7 // Vote 3 votes for SR1, 7 votes for SR2\n
The final output above is: Vote 3 votes for SR1, 7 votes for SR2.
"},{"location":"mechanism-algorithm/sr/#super-representatives-brokerage","title":"Super Representatives Brokerage","text":"The default ratio is 20%. Super representatives and super representative partners can query the brokerage ratio through the wallet/getBrokerage interface, and can also modify the brokerage ratio through the wallet/updateBrokerage interface.
If a SR(Super Representatives) get 20% of the rewards, and the other 80% will be awarded to the voters. If the brokerage ratio is set to 100%, the rewards are all obtained by the SR; if set to 0, the rewards are all sent to the voters.
"},{"location":"mechanism-algorithm/sr/#rewards-for-srsuper-representatives","title":"Rewards for SR(Super Representatives)","text":"The following calculations are all based on the situation where brokerage ratio is equal to 20%.
"},{"location":"mechanism-algorithm/sr/#vote-rewards","title":"Vote Rewards","text":"Vote rewards are 160 TRX for every block, with a block generated every 3 seconds, the total vote rewards per day is 4,608,000 TRX.
For each SR and Partner, the daily vote rewards = 4,608,000 * ( votes / total votes) x 20% TRX
"},{"location":"mechanism-algorithm/sr/#block-producing-rewards","title":"Block Producing Rewards","text":"Every time after a super representative produces a block, it will be rewarded 16 TRX. The 27 super representatives take turns to produce blocks every 3 seconds. The annual block producing rewards is 168,192,000 TRX in total.
Every time after a super representative produces a block, the 16 TRX block producing rewards will be sent to it's sub-account. The sub-account is a read-only account, it allows a withdraw action from sub-account to super representative account every 24 hours.
The daily total block producing rewards = 16 (TRX/block) * 28,800 (blocks/day) = 460,800 (TRX/day)
For each super representative, the daily block producing rewards = (460,800 / 27) * 20%TRX.
Rewards may be less than the theoretical number due to missed blocks and maintenance period.
"},{"location":"mechanism-algorithm/sr/#rewards-for-voter","title":"Rewards for Voter","text":"If you vote for a SR(Super Representative), you will have both vote rewards and block producing rewards:
vote rewards = ((the number of votes you vote to a SR / total votes) * 4,608,000 * 80%) TRX
block producing rewards = ((the number of votes you vote to a SR) / (the total number of votes a SR receives) * ((460,800 / 27) * 80%)) TRX
daily rewards for voter = vote rewards + block producing rewards
If you vote for a SR Partner, you will only have vote rewards:
daily rewards for voter = (((the number of votes you vote to a SR Partner) * 4,608,000 / total votes) * 80%) TRX
Notice: the above total votes refers to the combined votes of SRs and SR Partners, not including SR Candidates
"},{"location":"mechanism-algorithm/sr/#committee","title":"Committee","text":""},{"location":"mechanism-algorithm/sr/#what-is-committee","title":"What is Committee","text":"Committee can modify the TRON network parameters, like transacton fees, block producing reward amount, etc. Committee is composed of the current 27 super representatives. Every SR has the right to create and vote a proposal. The proposal will be passed after it gets at least 18 approves from the super representatives and will become valid in the next maintenance period.
"},{"location":"mechanism-algorithm/sr/#create-a-proposal","title":"Create a Proposal","text":"In addition to SR, SR Partner and SR Candidate also have the right to create a proposal, and only they have this right.
Please refer to here for TRON network dynamic parameters and their values.
Example (Using wallet-cli):
> createproposal id value\n# id: the serial number\n# value: the parameter value\n
"},{"location":"mechanism-algorithm/sr/#vote-for-a-proposal","title":"Vote for a Proposal","text":"Proposal only support YES vote. Since the creation time of the proposal, the proposal is valid within 3 days. If the proposal does not receive enough YES votes within the period of validity, the proposal will be invalid beyond the period of validity. Yes vote can be cancelled.
Example (Using wallet-cli):
> approveProposal id is_or_not_add_approval\n# id: proposal id\n# is_or_not_add_approval: YES vote or cancel YES vote\n
"},{"location":"mechanism-algorithm/sr/#cancel-proposal","title":"Cancel Proposal","text":"Proposal creator can cancel the proposal before it is passed.
Example (Using wallet-cli):
> deleteProposal id\n# id: proposal id\n
"},{"location":"mechanism-algorithm/sr/#query-proposal","title":"Query Proposal","text":" - Query all the proposals list (ListProposals)
- Query all the proposals list by pagination (GetPaginatedProposalList)
- Query a proposal by proposal id (GetProposalById)
For more API detail, please refer to HTTP API.
"},{"location":"mechanism-algorithm/system-contracts/","title":"System Contracts","text":"The TRON network supports many different types of transactions, such as TRX transfer transactions, TRC10 transfer transactions, creating smart contract transactions, triggering smart contract transactions, staking TRX transactions, and more. To create different types of transactions, you need to call different API. For example, the type of smart contract deployment transaction is CreateSmartContract, you need to call wallet/deploycontractAPI to create a transaction; the type of stake TRX transactions is FreezeBalanceV2Contract, you need to callwallet/freezebalancev2API to create transactions, we collectively refer to the implementation of these different transaction types as system contracts, the following are the types of system contracts and their contents:
"},{"location":"mechanism-algorithm/system-contracts/#accountcreatecontract","title":"AccountCreateContract","text":" message AccountCreateContract {\n bytes owner_address = 1;\n bytes account_address = 2;\n AccountType type = 3;\n }\n
owner_address: The owner of the current account.account_address: The target address to create.type: Account type. 0 means normal account; 1 means the Genesis account; 2 means smart contract account.
"},{"location":"mechanism-algorithm/system-contracts/#transfercontract","title":"TransferContract","text":" message TransferContract {\n bytes owner_address = 1;\n bytes to_address = 2;\n int64 amount = 3;\n }\n
owner_address: The owner of the current account.to_address: The target address to transfer.amount: The amount of TRX to transfer.
"},{"location":"mechanism-algorithm/system-contracts/#transferassetcontract","title":"TransferAssetContract","text":" message TransferAssetContract {\n bytes asset_name = 1;\n bytes owner_address = 2;\n bytes to_address = 3;\n int64 amount = 4;\n }\n
asset_name: The token id to transfer.owner_address: The owner of the current account.to_address: The target address to transfer.amount: The amount of token to transfer.
"},{"location":"mechanism-algorithm/system-contracts/#votewitnesscontract","title":"VoteWitnessContract","text":" message VoteWitnessContract {\n message Vote {\n bytes vote_address = 1;\n int64 vote_count = 2;\n }\n bytes owner_address = 1;\n repeated Vote votes = 2;\n bool support = 3;\n }\n
owner_address: The owner of the current account.vote_address: The SR or candidate's address.vote_count: The votes number.support: Constant true, not used.
"},{"location":"mechanism-algorithm/system-contracts/#witnesscreatecontract","title":"WitnessCreateContract","text":" message WitnessCreateContract {\n bytes owner_address = 1;\n bytes url = 2;\n }\n
owner_address: The owner of the current account.url: The website url of the witness.
"},{"location":"mechanism-algorithm/system-contracts/#assetissuecontract","title":"AssetIssueContract","text":" message AssetIssueContract {\n message FrozenSupply {\n int64 frozen_amount = 1;\n int64 frozen_days = 2;\n }\n bytes owner_address = 1;\n bytes name = 2;\n bytes abbr = 3;\n int64 total_supply = 4;\n repeated FrozenSupply frozen_supply = 5;\n int32 trx_num = 6;\n int32 num = 8;\n int64 start_time = 9;\n int64 end_time = 10;\n int64 order = 11; // the order of tokens of the same name\n int32 vote_score = 16;\n bytes description = 20;\n bytes url = 21;\n int64 free_asset_net_limit = 22;\n int64 public_free_asset_net_limit = 23;\n int64 public_free_asset_net_usage = 24;\n int64 public_latest_free_net_time = 25;\n }\n
owner_address: The owner of the current account.name: The token name to issue.abbr: The abbreviation of the token name.total_supply: The amount of token to issue.frozen_supply: The amount of token and staked days to stake.trx_num: trx_num/num defines the token price.num: trx_num/num defines the token price.start_time: ICO starts time.end_time: ICO ends time.order: Deprecated.vote_score: Deprecated.description: The description of the token.url: The website url of the token.free_asset_net_limit: The free bandwidth limit each account owns when transfers asset.public_free_asset_net_limit: The free bandwidth limit all the accounts can use.public_free_asset_net_usage: The free bandwidth usage of all the accounts.public_latest_free_net_time: The latest bandwidth consumption time of token transfer.
"},{"location":"mechanism-algorithm/system-contracts/#witnessupdatecontract","title":"WitnessUpdateContract","text":" message WitnessUpdateContract {\n bytes owner_address = 1;\n bytes update_url = 12;\n }\n
owner_address: The owner of the current account.update_url: The website url of the witness.
"},{"location":"mechanism-algorithm/system-contracts/#participateassetissuecontract","title":"ParticipateAssetIssueContract","text":" message ParticipateAssetIssueContract {\n bytes owner_address = 1;\n bytes to_address = 2;\n bytes asset_name = 3;\n int64 amount = 4;\n }\n
owner_address: The owner of the current account.to_address: The token owner address.account_name: The token id.amount: The amount of token to purchase.
"},{"location":"mechanism-algorithm/system-contracts/#accountupdatecontract","title":"AccountUpdateContract","text":" // Update account name. Account name is unique now.\n message AccountUpdateContract {\n bytes account_name = 1;\n bytes owner_address = 2;\n }\n
owner_address: The owner of the current account.account_name: Account name.
"},{"location":"mechanism-algorithm/system-contracts/#deprecatedfreezebalancecontract","title":"(Deprecated)FreezeBalanceContract","text":" message FreezeBalanceContract {\n bytes owner_address = 1;\n int64 frozen_balance = 2;\n int64 frozen_duration = 3;\n ResourceCode resource = 10;\n bytes receiver_address = 15;\n }\n
owner_address: The owner of the current account.frozen_balance: The amount of TRX to stake.frozen_duration: The stake duration.resource: The type of resource get by staking TRX.receiver_address: The account address to receive resource.
"},{"location":"mechanism-algorithm/system-contracts/#unfreezebalancecontract","title":"UnfreezeBalanceContract","text":" message UnfreezeBalanceContract {\n bytes owner_address = 1;\n ResourceCode resource = 10;\n bytes receiver_address = 13;\n }\n
owner_address: The owner of the current account.resource: The type of resource to unfree.receiver_address: The account address to receive resource.
"},{"location":"mechanism-algorithm/system-contracts/#withdrawbalancecontract","title":"WithdrawBalanceContract","text":" message WithdrawBalanceContract {\n bytes owner_address = 1;\n }\n
owner_address: The owner of the current account.
"},{"location":"mechanism-algorithm/system-contracts/#unfreezeassetcontract","title":"UnfreezeAssetContract","text":" message UnfreezeAssetContract {\n bytes owner_address = 1;\n }\n
owner_address: The owner of the current account.
"},{"location":"mechanism-algorithm/system-contracts/#updateassetcontract","title":"UpdateAssetContract","text":" message UpdateAssetContract {\n bytes owner_address = 1;\n bytes description = 2;\n bytes url = 3;\n int64 new_limit = 4;\n int64 new_public_limit = 5;\n }\n
owner_address: The owner of the current account.description: The description of the token.url: The website url of the token.new_limit: The bandwidth consumption limit of each account when transfers asset.new_public_limit: The bandwidth consumption limit of the accounts.
"},{"location":"mechanism-algorithm/system-contracts/#proposalcreatecontract","title":"ProposalCreateContract","text":" message ProposalCreateContract {\n bytes owner_address = 1;\n map<int64, int64> parameters = 2;\n }\n
owner_address: The owner of the current account.parameters: The proposal.
"},{"location":"mechanism-algorithm/system-contracts/#proposalapprovecontract","title":"ProposalApproveContract","text":" message ProposalApproveContract {\n bytes owner_address = 1;\n int64 proposal_id = 2;\n bool is_add_approval = 3; // add or remove approval\n }\n
owner_address: The owner of the current account.proposal_id: The proposal id.is_add_approval: Whether to approve.
"},{"location":"mechanism-algorithm/system-contracts/#proposaldeletecontract","title":"ProposalDeleteContract","text":" message ProposalDeleteContract {\n bytes owner_address = 1;\n int64 proposal_id = 2;\n }\n
owner_address: The owner of the current account.proposal_id: The proposal id.
"},{"location":"mechanism-algorithm/system-contracts/#setaccountidcontract","title":"SetAccountIdContract","text":" // Set account id if the account has no id. Account id is unique and case insensitive.\n message SetAccountIdContract {\n bytes account_id = 1;\n bytes owner_address = 2;\n }\n
owner_address: The owner of the current account.account_id: The account id.
"},{"location":"mechanism-algorithm/system-contracts/#createsmartcontract","title":"CreateSmartContract","text":" message CreateSmartContract {\n bytes owner_address = 1;\n SmartContract new_contract = 2;\n int64 call_token_value = 5;\n int64 token_id = 6;\n }\n
owner_address: The owner of the current account.new_contract: the smart contract.call_token_value : The amount of TRC-10 token to send to the contract when triggers.token_id : The id of the TRC-10 token to be sent to the contract.
"},{"location":"mechanism-algorithm/system-contracts/#triggersmartcontract","title":"TriggerSmartContract","text":" message TriggerSmartContract {\n bytes owner_address = 1;\n bytes contract_address = 2;\n int64 call_value = 3;\n bytes data = 4;\n int64 call_token_value = 5;\n int64 token_id = 6;\n }\n
owner_address: The owner of the current account.contract_address: The contract address.call_value: The amount of TRX to send to the contract when triggers.data: The parameters to trigger the contract.call_token_value : The amount of TRC-10 token to send to the contract when triggers.token_id : The id of the TRC-10 token to be sent to the contract.
"},{"location":"mechanism-algorithm/system-contracts/#updatesettingcontract","title":"UpdateSettingContract","text":" message UpdateSettingContract {\n bytes owner_address = 1;\n bytes contract_address = 2;\n int64 consume_user_resource_percent = 3;\n }\n
owner_address: The owner of the current account.contract_address: The address of the smart contract.consume_user_resource_percent: The percentage of resource consumption ratio.
"},{"location":"mechanism-algorithm/system-contracts/#exchangecreatecontract","title":"ExchangeCreateContract","text":" message ExchangeCreateContract {\n bytes owner_address = 1;\n bytes first_token_id = 2;\n int64 first_token_balance = 3;\n bytes second_token_id = 4;\n int64 second_token_balance = 5;\n }\n
owner_address: The owner of the current account.first_token_id: First token id.first_token_balance: First token balance.second_token_id: Second token id.second_token_balance: Second token balance.
"},{"location":"mechanism-algorithm/system-contracts/#exchangeinjectcontract","title":"ExchangeInjectContract","text":" message ExchangeInjectContract {\n bytes owner_address = 1;\n int64 exchange_id = 2;\n bytes token_id = 3;\n int64 quant = 4;\n }\n
owner_address: The owner of the current account.exchange_id: The token pair id.token_id: The token id to inject.quant: The token amount to inject.
"},{"location":"mechanism-algorithm/system-contracts/#exchangewithdrawcontract","title":"ExchangeWithdrawContract","text":" message ExchangeWithdrawContract {\n bytes owner_address = 1;\n int64 exchange_id = 2;\n bytes token_id = 3;\n int64 quant = 4;\n }\n
owner_address: The owner of the current account.exchange_id: The token pair id.token_id: The token id to withdraw.quant: The token amount to withdraw.
"},{"location":"mechanism-algorithm/system-contracts/#exchangetransactioncontract","title":"ExchangeTransactionContract","text":" message ExchangeTransactionContract {\n bytes owner_address = 1;\n int64 exchange_id = 2;\n bytes token_id = 3;\n int64 quant = 4;\n }\n
owner_address: The owner of the current account.exchange_id: The token pair id.token_id: The token id to sell.quant: The token amount to sell.
"},{"location":"mechanism-algorithm/system-contracts/#shieldedtransfercontract","title":"ShieldedTransferContract","text":" message ShieldedTransferContract {\n bytes transparent_from_address = 1;\n int64 from_amount = 2;\n repeated SpendDescription spend_description = 3;\n repeated ReceiveDescription receive_description = 4;\n bytes binding_signature = 5;\n bytes transparent_to_address = 6;\n int64 to_amount = 7;\n }\n
transparent_from_address: The transparent address of the sender.from_amount: The amount to send.spend_description: Shielded spend information.receive_description: Shielded receive information.binding_signature: The binding signature.transparent_to_address: The transparent address of the receiver.to_amount: The amount to receive.
message SpendDescription {\n bytes value_commitment = 1;\n bytes anchor = 2;\n bytes nullifier = 3;\n bytes rk = 4;\n bytes zkproof = 5;\n bytes spend_authority_signature = 6;\n}\n
value_commitment: value commitment of spender's transfer amount.anchor: root of the note commitment Merkle tree at some block.nullifier: nullifier of spender's note, to prevent double-spent.rk: public key, to verify spender's Spend Authorization Signature.zkproof: zero-knowledge proof of spender's note, prove that this note exists and could be spent.spend_authority_signature: the spender's Spend Authorization Signature.
message ReceiveDescription {\n bytes value_commitment = 1;\n bytes note_commitment = 2;\n bytes epk = 3;\n bytes c_enc = 4;\n bytes c_out = 5;\n bytes zkproof = 6;\n}\n
value_commitment: value commitment of receiver's transfer amount.note_commitment: commitment of the receiver's not.epk: ephemeral public key, in order to generate note's decryption key.c_enc: part of note ciphertext, encryption of diversifier, receiver's transfer amount, rcm, and memo.c_out: part of note ciphertext, encryption of the receiver's public key and ephemeral private key.zkproof: zero-knowledge proof of the receiver's note.
"},{"location":"mechanism-algorithm/system-contracts/#account-permission-management","title":"Account Permission Management","text":"Account Permission Management
"},{"location":"mechanism-algorithm/system-contracts/#clearabicontract","title":"ClearABIContract","text":" message ClearABIContract {\n bytes owner_address = 1;\n bytes contract_address = 2;\n }\n
owner_address: The owner of the current account.account_address: The target contract address to clear ABI.
"},{"location":"mechanism-algorithm/system-contracts/#updatebrokeragecontract","title":"UpdateBrokerageContract","text":" message UpdateBrokerageContract {\n bytes owner_address = 1;\n int32 brokerage = 2;\n }\n
owner_address: The owner of the current account.brokerage: Commission rate, from 0 to 100,1 mean 1%.
"},{"location":"mechanism-algorithm/system-contracts/#updateenergylimitcontract","title":"UpdateEnergyLimitContract","text":" message UpdateEnergyLimitContract {\n bytes owner_address = 1;\n bytes contract_address = 2;\n int64 origin_energy_limit = 3;\n }\n
owner_address: The owner of the current account.contract_address: The contract address.origin_energy_limit: The target energy limit to change.
"},{"location":"mechanism-algorithm/system-contracts/#freezebalancev2contract","title":"FreezeBalanceV2Contract","text":" message FreezeBalanceV2Contract {\n bytes owner_address = 1;\n int64 frozen_balance = 2;\n ResourceCode resource = 3;\n }\n
owner_address\uff1aOwner addressfrozen_balance\uff1aTRX stake amount, the unit is sunresource\uff1a Resource type
"},{"location":"mechanism-algorithm/system-contracts/#unfreezebalancev2contract","title":"UnfreezeBalanceV2Contract","text":" message UnfreezeBalanceV2Contract {\n bytes owner_address = 1;\n int64 unfreeze_balance = 2;\n ResourceCode resource = 3;\n }\n
owner_address\uff1aOwner addressunfreeze_balance\uff1aThe amount of TRX to unstake, in sunresource\uff1a Resource type
"},{"location":"mechanism-algorithm/system-contracts/#withdrawexpireunfreezecontract","title":"WithdrawExpireUnfreezeContract","text":" message WithdrawExpireUnfreezeContract {\n bytes owner_address = 1;\n }\n
owner_address\uff1aOwner address
"},{"location":"mechanism-algorithm/system-contracts/#delegateresourcecontract","title":"DelegateResourceContract","text":" message DelegateResourceContract {\n bytes owner_address = 1;\n ResourceCode resource = 2;\n int64 balance = 3;\n bytes receiver_address = 4;\n bool lock = 5;\n }\n
owner_address\uff1aOwner addressresource\uff1a Resource typebalance\uff1a Amount of TRX staked for resources to be delegated, unit is sunreceiver_address\uff1aResource receiver addresslock\uff1aWhether it is locked, if it is set to true, the delegated resources cannot be undelegated within 3 days. When the lock time is not over, if the owner delegates the same type of resources using the lock to the same address, the lock time will be reset to 3 days
"},{"location":"mechanism-algorithm/system-contracts/#undelegateresourcecontract","title":"UnDelegateResourceContract","text":" message UnDelegateResourceContract {\n bytes owner_address = 1;\n ResourceCode resource = 2;\n int64 balance = 3;\n bytes receiver_address = 4;\n }\n
owner_address\uff1aOwner addressresource\uff1a Resource typebalance\uff1aundelegated TRX, unit is sunreceiver_address\uff1aResource receiver address
"},{"location":"releases/history/","title":"History","text":"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"},{"location":"releases/history/#greatvoyage-480kant","title":"GreatVoyage-4.8.0(Kant)","text":"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.
"},{"location":"releases/history/#ethereum-cancun-upgrade-support","title":"Ethereum Cancun Upgrade Support","text":""},{"location":"releases/history/#1-tip-650-implement-eip-1153-transient-storage-instructions","title":"1. TIP-650: Implement EIP-1153 Transient Storage Instructions","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-650.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/6185 https://github.com/tronprotocol/java-tron/pull/6195 https://github.com/tronprotocol/java-tron/pull/6214
"},{"location":"releases/history/#2-tip-651-implement-eip-5656-mcopy-memory-copying-instruction","title":"2. TIP-651: Implement EIP-5656 MCOPY - Memory Copying Instruction","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-651.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/6185 https://github.com/tronprotocol/java-tron/pull/6194
"},{"location":"releases/history/#3-tip-745-introduce-eip-4844-instruction-and-eip-7516-instruction","title":"3. TIP-745: Introduce EIP-4844 Instruction and EIP-7516 Instruction","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-745.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/6232 https://github.com/tronprotocol/java-tron/pull/6247 https://github.com/tronprotocol/java-tron/pull/6270 https://github.com/tronprotocol/java-tron/pull/6283
"},{"location":"releases/history/#core","title":"Core","text":""},{"location":"releases/history/#1-enhanced-consensus-layer-verification","title":"1. Enhanced Consensus Layer Verification","text":""},{"location":"releases/history/#11-tip-694-enhance-verification-of-transaction-limitations-at-consensus-layer","title":"1.1 TIP-694: Enhance Verification of Transaction Limitations at Consensus Layer","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-694.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/6172 https://github.com/tronprotocol/java-tron/pull/6221
"},{"location":"releases/history/#12-enhanced-validation-of-block-production-during-maintenance-periods","title":"1.2 Enhanced Validation of Block Production during Maintenance Periods","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6187
"},{"location":"releases/history/#13-enhanced-block-header-validation","title":"1.3 Enhanced Block Header Validation","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6186
"},{"location":"releases/history/#14-optimized-super-representative-election-ranking-algorithm","title":"1.4 Optimized Super Representative Election Ranking Algorithm","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6173
"},{"location":"releases/history/#tvm","title":"TVM","text":""},{"location":"releases/history/#1-tip-652-announce-eip-6049-deprecate-selfdestruct","title":"1. TIP-652: Announce EIP-6049 Deprecate SELFDESTRUCT","text":"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
"},{"location":"releases/history/#net","title":"Net","text":""},{"location":"releases/history/#1-optimized-block-synchronization-logic","title":"1. Optimized Block Synchronization Logic","text":"Kant introduces two key optimizations to the block synchronization logic, significantly improving synchronization efficiency:
"},{"location":"releases/history/#11-optimized-p2p-protocol-discarding-solidified-block-lists-to-conserve-network-bandwidth","title":"1.1 Optimized P2P Protocol: Discarding Solidified Block Lists to Conserve Network Bandwidth","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6184
"},{"location":"releases/history/#12-faster-block-synchronization-task-scheduling-for-enhanced-efficiency","title":"1.2 Faster Block Synchronization Task Scheduling for Enhanced Efficiency","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6183
"},{"location":"releases/history/#2-enhanced-transaction-validity-verification-by-early-discarding-zero-contract-transactions","title":"2. Enhanced Transaction Validity Verification by Early Discarding Zero-Contract Transactions","text":"Kant strengthens transaction validity verification. Upon receiving a transaction message, the node will discard transactions with zero contracts and disconnect from the sender.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6181
"},{"location":"releases/history/#other-changes","title":"Other Changes","text":""},{"location":"releases/history/#1-enhanced-event-service-framework-v20-provision","title":"1. Enhanced Event Service Framework (V2.0) Provision","text":"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 \u2264 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\n
* 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 "},{"location":"releases/history/#2-cross-platform-consistent-javalangstrictmath-replacement-for-javalangmath","title":"2. Cross-Platform Consistent java.lang.StrictMath Replacement for java.lang.Math","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-697.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/6182 https://github.com/tronprotocol/java-tron/pull/6210
"},{"location":"releases/history/#3-optimized-node-exit-and-startup-logic","title":"3. Optimized Node Exit and Startup Logic","text":""},{"location":"releases/history/#31-optimized-node-exit-logic","title":"3.1 Optimized Node Exit Logic","text":"Kant standardizes the code logic for process termination while preserving original functionalities, enhancing code consistency and system stability.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6170 https://github.com/tronprotocol/java-tron/pull/6177 https://github.com/tronprotocol/java-tron/pull/6205
"},{"location":"releases/history/#32-optimized-node-startup-logic","title":"3.2 Optimized Node Startup Logic","text":"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\nnode.rpc.solidityEnable = true\nnode.rpc.PBFTEnable = true\nnode.http.PBFTEnable = true\n
* 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"},{"location":"releases/history/#4-dependency-library-security-upgrade","title":"4. Dependency Library Security Upgrade","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6180 https://github.com/tronprotocol/java-tron/pull/6207 https://github.com/tronprotocol/java-tron/pull/6257
"},{"location":"releases/history/#5-gradle-764-upgrade-with-dependency-integrity-verification","title":"5. Gradle 7.6.4 Upgrade with Dependency Integrity Verification","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5869 https://github.com/tronprotocol/java-tron/pull/5903 https://github.com/tronprotocol/java-tron/pull/6229
"},{"location":"releases/history/#6-null-pointer-exception-fix-during-startup","title":"6. Null Pointer Exception Fix During Startup","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6216
"},{"location":"releases/history/#7-internal-transaction-details-logging-for-cancelallunfreezev2-opcode","title":"7. Internal Transaction Details Logging for CANCELALLUNFREEZEV2 Opcode","text":"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}.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6191
"},{"location":"releases/history/#api","title":"API","text":""},{"location":"releases/history/#1-enhanced-compatibility-for-ethereum-json-rpc-interface","title":"1. Enhanced Compatibility for Ethereum JSON-RPC Interface","text":""},{"location":"releases/history/#11-support-for-querying-solidified-data-via-finalized-block-parameter-in-json-rpc-api","title":"1.1 Support for Querying Solidified Data via finalized Block Parameter in JSON-RPC API","text":"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\u201d 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:
- eth_getBalance
- eth_getCode
- eth_getStorageAt
- eth_call
-
eth_newFilter
-
Source Code: https://github.com/tronprotocol/java-tron/pull/6007 https://github.com/tronprotocol/java-tron/pull/6238 https://github.com/tronprotocol/java-tron/pull/6239
"},{"location":"releases/history/#12-new-limits-on-block-range-and-topics-quantity-for-json-rpc-log-queries","title":"1.2 New Limits on Block Range and \u201cTopics\u201d Quantity for JSON-RPC Log Queries","text":"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 \u201csub topics\u201d that can be set. The default value is 1000, meaning that a maximum of 1000 \u201csub topics\u201d 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\nnode.jsonrpc.maxSubTopics = 1000\n
Interfaces supporting maxBlockRange:
- eth_getLogs
Interfaces supporting maxSubTopics:
- eth_getLogs
-
eth_newFilter
-
Source Code: https://github.com/tronprotocol/java-tron/pull/6271 https://github.com/tronprotocol/java-tron/pull/6275
"},{"location":"releases/history/#13-optimized-eth_getlogs-to-resolve-data-retrieval-issue-in-rare-hash-collisions","title":"1.3 Optimized eth_getLogs to Resolve Data Retrieval Issue in Rare Hash Collisions","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6203
"},{"location":"releases/history/#2-non-null-payment-address-validation-in-shielded-transaction-creation-api","title":"2. Non-Null Payment Address Validation in Shielded Transaction Creation API","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6174
Science is organized knowledge. Wisdom is organized life.
---Immanuel Kant
"},{"location":"releases/history/#greatvoyage-477epicurus","title":"GreatVoyage-4.7.7(Epicurus)","text":"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.
"},{"location":"releases/history/#core_1","title":"Core","text":""},{"location":"releases/history/#1-migrate-pow-operation-from-javalangmath-to-javalangstrictmath-for-cross-platform-computational-consistency","title":"1. Migrate pow operation from java.lang.Math to java.lang.StrictMath for cross-platform computational consistency","text":"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
"},{"location":"releases/history/#other-changes_1","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-event-subscription-processing-logic","title":"1. Optimize event subscription processing logic","text":"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
"},{"location":"releases/history/#2-support-graceful-shutdown-with-signal-15-sigterm-for-nodes-enabling-backup","title":"2. Support graceful shutdown with signal -15 (SIGTERM) for nodes enabling backup.","text":"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
"},{"location":"releases/history/#3-improve-duration-metrics-accuracy-of-grpc-interfaces","title":"3. Improve duration metrics accuracy of gRPC interfaces","text":"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
"},{"location":"releases/history/#greatvoyage-v476anaximander","title":"GreatVoyage-v4.7.6(Anaximander)","text":"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.
"},{"location":"releases/history/#other-changes_2","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-the-statistical-logic-of-node-http-request-monitoring-metric","title":"1. Optimize the statistical logic of node HTTP request monitoring metric","text":"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
"},{"location":"releases/history/#2-improve-stability-of-gradle-test-task","title":"2. Improve stability of Gradle test task","text":"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
"},{"location":"releases/history/#3-add-tcp-outflow-monitoring-metric-for-prometheus-and-add-udp-inflow-traffic-statistic-to-monitorgetstatsinfo-api","title":"3. Add TCP outflow monitoring metric for Prometheus and add UDP inflow traffic statistic to /monitor/getstatsinfo API","text":"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
"},{"location":"releases/history/#4-optimize-peer-node-idle-judgment-logic","title":"4. Optimize peer node idle judgment logic","text":"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
"},{"location":"releases/history/#5-optimize-peer-sorting-logic","title":"5. Optimize peer sorting logic","text":"Anaximander optimizes the peers\u2019 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
"},{"location":"releases/history/#6-optimize-check-logic-for-fetching-block-inventory-message","title":"6. Optimize check logic for fetching block inventory message","text":"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
"},{"location":"releases/history/#7-optimize-block-processing-logic","title":"7. Optimize block processing logic","text":"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
"},{"location":"releases/history/#8-optimize-random-disconnection-strategy","title":"8. Optimize random disconnection strategy","text":"When a node\u2019s latest block height is higher than all peers\u2019 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
"},{"location":"releases/history/#greatvoyage-v475cleobulus","title":"GreatVoyage-v4.7.5(Cleobulus)","text":"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.
"},{"location":"releases/history/#core_2","title":"Core","text":""},{"location":"releases/history/#1-optimize-block-synchronization-and-production-logic","title":"1. Optimize block synchronization and production logic","text":"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
"},{"location":"releases/history/#2-strengthen-size-check-of-account-creation-transactions","title":"2. Strengthen size check of account creation transactions","text":"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
"},{"location":"releases/history/#tvm_1","title":"TVM","text":""},{"location":"releases/history/#1-adjust-energy-cost-for-some-opcodes-in-tvm","title":"1. Adjust energy cost for some opcodes in TVM","text":"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
"},{"location":"releases/history/#other-changes_3","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-synchronization-logic-among-threads","title":"1. Optimize synchronization logic among threads","text":"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
"},{"location":"releases/history/#2-remove-redundant-code","title":"2. Remove redundant code","text":"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
"},{"location":"releases/history/#greatvoyage-v474bias","title":"GreatVoyage-v4.7.4(Bias)","text":"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.
"},{"location":"releases/history/#core_3","title":"Core","text":""},{"location":"releases/history/#1-optimize-voting-reward-withdrawal-performance","title":"1. Optimize voting reward withdrawal performance","text":"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
"},{"location":"releases/history/#2-add-check-function-for-the-number-of-unsolidified-blocks","title":"2. Add check function for the number of unsolidified blocks","text":"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\nnode.maxUnsolidifiedBlocks = 54\n
Source Code: https://github.com/tronprotocol/java-tron/pull/5643
"},{"location":"releases/history/#api_1","title":"API","text":""},{"location":"releases/history/#1-supply-block_unsolidified-in-code-for-walletbroadcasttransaction-api","title":"1. Supply BLOCK_UNSOLIDIFIED in code for /wallet/broadcasttransaction API","text":"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
"},{"location":"releases/history/#other-changes_4","title":"Other Changes","text":""},{"location":"releases/history/#1-add-field-codeversion-to-hellomessage-to-declare-code-version","title":"1. Add field codeVersion to HelloMessage to declare code version","text":"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
"},{"location":"releases/history/#2-bump-libp2p-to-version-221","title":"2. Bump libp2p to version 2.2.1","text":"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
"},{"location":"releases/history/#3-bump-jetty-to-9453v20231009","title":"3. Bump jetty to 9.4.53.v20231009","text":"The Bias version bumps the jetty dependency library to v9.4.53.v20231009.
Source Code: https://github.com/tronprotocol/java-tron/pull/5571
"},{"location":"releases/history/#4-refactor-gradle-dependencies","title":"4. Refactor Gradle dependencies","text":"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
"},{"location":"releases/history/#5-provide-grpc-reflection-service","title":"5. Provide gRPC reflection service","text":"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\n
Source Code: https://github.com/tronprotocol/java-tron/pull/5583 "},{"location":"releases/history/#6-delete-the-litefullnodetool-related-code-under-the-framework-module","title":"6. Delete the LiteFullNodeTool related code under the framework module","text":"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 \n
Source Code: https://github.com/tronprotocol/java-tron/pull/5711
"},{"location":"releases/history/#7-remove-configuration-item-nodediscoverybindip","title":"7. Remove configuration item node.discovery.bind.ip","text":"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
"},{"location":"releases/history/#8-remove-redundant-ci-scripts","title":"8. Remove redundant CI scripts","text":"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
"},{"location":"releases/history/#9-initialize-the-api-service-first-during-the-node-startup","title":"9. Initialize the API service first during the node startup","text":"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
"},{"location":"releases/history/#10-optimize-log","title":"10. Optimize log","text":"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
"},{"location":"releases/history/#11-add-synchronization-control-when-writing-to-zeromq","title":"11. Add synchronization control when writing to ZeroMQ","text":"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
"},{"location":"releases/history/#12optimize-unexpected-exception-capture-process-of-scalingfactor-in-walletcreateshieldedcontractparameters-api","title":"12.Optimize unexpected exception capture process of scalingFactor in /wallet/createshieldedcontractparameters API.","text":"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
"},{"location":"releases/history/#greatvoyage-v4731solon","title":"GreatVoyage-v4.7.3.1(Solon)","text":"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.
"},{"location":"releases/history/#other-changes_5","title":"Other Changes","text":""},{"location":"releases/history/#1-more-stable-walletgetnodeinfo-interface","title":"1. More stable /wallet/getnodeinfo interface","text":"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
"},{"location":"releases/history/#2-optimize-lite-fullnode-data-pruning-tool","title":"2. Optimize Lite FullNode data pruning tool","text":"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
"},{"location":"releases/history/#greatvoyage-v473chilon","title":"GreatVoyage-v4.7.3(Chilon)","text":"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.
"},{"location":"releases/history/#core_4","title":"Core","text":""},{"location":"releases/history/#1-add-grpc-interfaces-for-resource-price-and-transaction-memo-fee-query","title":"1. Add gRPC interfaces for resource price and transaction memo fee query","text":"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
"},{"location":"releases/history/#2-supplement-disconnect-reasons","title":"2. Supplement disconnect reasons","text":"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
"},{"location":"releases/history/#3-discard-transactions-from-bad-peers-instead-of-disconnected-peers","title":"3. Discard transactions from bad peers instead of disconnected peers","text":"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
"},{"location":"releases/history/#4-optimize-stake-20-codes-and-error-messages","title":"4. Optimize Stake 2.0 codes and error messages","text":"The Chilon version standardizes Stake 2.0-related code and simplifies complex functions\uff0c improving the simplicity and readability of the code.
Source Code: https://github.com/tronprotocol/java-tron/pull/5426
"},{"location":"releases/history/#5-accelerate-bloomfilter-initialization-for-transaction-cache","title":"5. Accelerate bloomFilter initialization for transaction cache","text":"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
"},{"location":"releases/history/#6-fix-concurrency-issues-when-generating-chain-inventory","title":"6. Fix concurrency issues when generating chain inventory","text":"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
"},{"location":"releases/history/#7-correct-resource-disorder-closure-behavior-on-kill-15","title":"7. Correct resource disorder closure behavior on kill -15","text":"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
"},{"location":"releases/history/#api_2","title":"API","text":""},{"location":"releases/history/#1-optimize-http-interface-monitoring","title":"1. Optimize HTTP interface monitoring","text":"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
"},{"location":"releases/history/#2-provide-uniform-rate-limitation-configuration-for-all-http-and-grpc-apis","title":"2. Provide uniform rate limitation configuration for all HTTP and gRPC APIs","text":"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\n
Source Code: https://github.com/tronprotocol/java-tron/pull/5502
"},{"location":"releases/history/#3-optimize-http-interface-parameter-parsing","title":"3. Optimize HTTP interface parameter parsing","text":"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
"},{"location":"releases/history/#4-add-solidity-query-interfaces-of-resource-unit-price","title":"4. Add solidity query interfaces of resource unit price","text":"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
"},{"location":"releases/history/#5-optimize-the-processing-logic-of-some-http-interfaces","title":"5. Optimize the processing logic of some HTTP interfaces","text":"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
"},{"location":"releases/history/#other-changes_6","title":"Other Changes","text":""},{"location":"releases/history/#1-add-check-for-expired-transactions-when-fetching-transactions","title":"1. Add check for expired transactions when fetching transactions","text":"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
"},{"location":"releases/history/#2-fix-concurrency-issue-of-getheadblockid-method","title":"2. Fix concurrency issue of getHeadBlockId method","text":"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
"},{"location":"releases/history/#3-delete-unused-network-configurations","title":"3. Delete unused network configurations","text":"Chilon deleted four unused network parameters, including the three configuration items below, simplifying the complexity of using for developers.
node.discovery.public.home.node\nnode.discovery.ping.timeout\nnode.p2p.pingInterval\n
Source Code: https://github.com/tronprotocol/java-tron/pull/5441
"},{"location":"releases/history/#4-obtain-external-ip-through-libp2p","title":"4. Obtain external IP through Libp2p","text":"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
"},{"location":"releases/history/#5-add-address-parsing-for-stake-related-transactions-in-event-subscription","title":"5. Add address parsing for stake-related transactions in event subscription","text":"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
"},{"location":"releases/history/#6-adjust-default-number-of-cpu-cores-used-in-signature-validation","title":"6. Adjust default number of CPU cores used in signature validation","text":"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
"},{"location":"releases/history/#7-migrate-litefullnode-tool-related-unit-test-cases-to-plugins-module","title":"7. Migrate LiteFullNode tool related unit test cases to Plugins module","text":"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
"},{"location":"releases/history/#8-enhance-query-performance-of-properties-db","title":"8. Enhance query performance of properties DB","text":"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
"},{"location":"releases/history/#greatvoyage-v472periander","title":"GreatVoyage-v4.7.2(Periander)","text":"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.
"},{"location":"releases/history/#core_5","title":"Core","text":""},{"location":"releases/history/#1-upgrade-libp2p-to-v120","title":"1. Upgrade Libp2p to v1.2.0","text":"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\uff1a
-
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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-549.md
-
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 {\n # enable or disable dns publish, default false\n publish = true\n\n # dns domain to publish nodes, required if publish is enable\n dnsDomain = \"...\"\n\n # dns private key used to publish, required if publish is enable, hex string of length 64\n dnsPrivate = \"...\"\n\n # dns server to publish, required if publish is enable, only \u201daws\u201d or \u201caliyun\u201d is support\n serverType = \"...\"\n\n # access key id of aws or aliyun api, required if publish is enable, string\n accessKeyId = \"...\"\n\n # access key secret of aws or aliyun api, required if publish is enable, string\n accessKeySecret = \"...\"\n\n # if publish is enable and serverType is aliyun, it's endpoint of aws dns server, string\n aliyunDnsEndpoint = \"...\"\n\n # if publish is enable and serverType is aws, it's region of aws api, such as \"eu-south-1\", string\n awsRegion = \"...\"\n # if publish is enable and serverType is aws, it's host zone id of aws's domain, string\n awsHostZoneId = \"...\"\n\n # static nodes to published on dns\n staticNodes = [\n # Sample entries:\n # \"ip:port\",\n # \"ip:port\"\n ]\n\n # the range is from 1 to 5\n maxMergeSize = 2\n\n changeThreshold = 0.001\n}\n
Node discovery via DNS
To use the function of node discovery via DNS, you need to configure the following configuration items:
node.dns {\n # DNS URL to get nodes, URL format tree://{pubkey}@{domain}, default empty\n treeUrls = [......]\n}\n
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-548.md
-
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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-547.md
-
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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-550.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/5017
"},{"location":"releases/history/#2-support-canceling-unstaking-in-stake-20","title":"2. Support canceling unstaking in Stake 2.0","text":"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\u2019s 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 \\\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"visible\": true\n}'\n
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-541.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/5230 https://github.com/tronprotocol/java-tron/pull/5260 https://github.com/tronprotocol/java-tron/pull/5279
"},{"location":"releases/history/#3-resource-delegating-supports-customizable-lock-period","title":"3. Resource delegating supports customizable lock period","text":"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 \\\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"receiver_address\": \"TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1\",\n \"balance\": 1000000,\n \"resource\": \"ENERGY\",\n \"lock\": true,\n \"lock_period\": 86400,\n \"visible\": true\n}'\n
- 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: \u201cThe 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!.\u201d
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-542.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/5255
"},{"location":"releases/history/#4-optimize-effective-peer-acquiring-strategy","title":"4. Optimize effective peer-acquiring strategy","text":"When the latest block heights of all connected remote nodes are lower than a node\u2019s, 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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5088
"},{"location":"releases/history/#tvm_2","title":"TVM","text":""},{"location":"releases/history/#1-implement-eip-3855-push0-instruction","title":"1. Implement EIP-3855 PUSH0 Instruction","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-543.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/5175
"},{"location":"releases/history/#api_3","title":"API","text":""},{"location":"releases/history/#1-add-api-global-rate-limiter","title":"1. Add API global rate limiter","text":"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\nrate.limiter.global.qps =10 \n# QPS rate limit to all interfaces from the same IP address\nrate.limiter.global.ip.qps = 5 \n
- Source Code: https://github.com/tronprotocol/java-tron/pull/5093
"},{"location":"releases/history/#2-add-data-to-http-interfaces-for-smart-contract-interaction","title":"2. Add data to HTTP Interfaces for Smart Contract Interaction","text":"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 \\\n --url https://api.shasta.trongrid.io/wallet/triggersmartcontract \\\n --header 'accept: application/json' \\\n --header 'content-type: application/json' \\\n --data '\n{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"contract_address\": \"TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs\",\n \"function_selector\": \"balanceOf(address)\",\n \"parameter\": \"000000000000000000000000a614f803b6fd780986a42c78ec9c7f77e6ded13c\",\n \"visible\": true\n}\n'\n
-
Calling contract through data
curl --request POST \\\n --url https://api.shasta.trongrid.io/wallet/triggersmartcontract \\\n --header 'accept: application/json' \\\n --header 'content-type: application/json' \\\n --data '\n{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"contract_address\": \"TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs\",\n \"data\": \"70a08231000000000000000000000000a614f803b6fd780986a42c78ec9c7f77e6ded13c\",\n \"visible\": true\n}'\n
-
Estimate energy consumption of contract deployment transaction
curl --request POST \\\n --url https://api.shasta.trongrid.io/wallet/triggerconstantcontract \\\n --header 'accept: application/json' \\\n --header 'content-type: application/json' \\\n --data '\n{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"data\": \"608060405234801561001057600080fd5b50d3801561001d57600080fd5b50d2801561002a57600080fd5b506101c18061003a6000396000f3fe608060405234801561001057600080fd5b50d3801561001d57600080fd5b50d2801561002a57600080fd5b50600436106100455760003560e01c8063f8b2cb4f1461004a575b600080fd5b610064600480360381019061005f919061012a565b61007a565b6040516100719190610170565b60405180910390f35b60008173ffffffffffffffffffffffffffffffffffffffff16319050919050565b600080fd5b600074ffffffffffffffffffffffffffffffffffffffffff82169050919050565b6100ca816100a0565b81146100d557600080fd5b50565b600073ffffffffffffffffffffffffffffffffffffffff82169050919050565b6000610103826100d8565b9050919050565b600081359050610119816100c1565b610122816100f8565b905092915050565b6000602082840312156101405761013f61009b565b5b600061014e8482850161010a565b91505092915050565b6000819050919050565b61016a81610157565b82525050565b60006020820190506101856000830184610161565b9291505056fea26474726f6e58221220839f9be3efc349a3efd6bb491d0bee7bc34d86313c73f6e6eeddc4719ec69c0064736f6c63430008120033\",\n \"visible\": true\n}'\n
-
TIP: https://github.com/tronprotocol/tips/blob/master/tip-544.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/5079
"},{"location":"releases/history/#3-optimize-getstorageat-interface","title":"3. Optimize getStorageAt interface","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5061
"},{"location":"releases/history/#other-changes_7","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-event-forwarding-logic-in-event-subscription","title":"1. Optimize event forwarding logic in event subscription","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5031
"},{"location":"releases/history/#2-support-dynamic-loading-according-to-nodeactive-and-nodepassive","title":"2. Support dynamic loading according to node.active and node.passive","text":"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\nnode.dynamicConfig.checkInterval = 600\n
- Source Code: https://github.com/tronprotocol/java-tron/pull/5090
"},{"location":"releases/history/#3-optimize-block-synchronization-logic","title":"3. Optimize block synchronization logic","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5094 https://github.com/tronprotocol/java-tron/pull/5097 https://github.com/tronprotocol/java-tron/pull/5102
"},{"location":"releases/history/#4-normalize-http-urls","title":"4. Normalize HTTP URLs","text":"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= [\n \"getaccount\",\n \"getnowblock2\"\n]\n
- Source Code: https://github.com/tronprotocol/java-tron/pull/5085
"},{"location":"releases/history/#5-optimize-block-fetching-logic","title":"5. Optimize block fetching logic","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5106
"},{"location":"releases/history/#6-add-a-new-node-startup-mode","title":"6. Add a new node startup mode","text":"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 \n
- Source Code: https://github.com/tronprotocol/java-tron/pull/5011
"},{"location":"releases/history/#7-upgrade-junit-to-4132","title":"7. Upgrade JUnit to 4.13.2","text":"The Periander version upgrades the unit testing framework and upgrades the JUnit dependency library from v4.12 to v4.13.2.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5244
"},{"location":"releases/history/#8-add-monitoring-metrics-for-json-rpc","title":"8. Add monitoring metrics for JSON-RPC","text":"The Periander version supports JSON-RPC interface latency monitoring metrics, allowing node deployers to monitor the latency of all types of interfaces.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5222
"},{"location":"releases/history/#9-optimize-the-database-module","title":"9. Optimize the database module","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5223
"},{"location":"releases/history/#10-optimize-checkpoint-v2-recovery-process","title":"10. Optimize checkpoint v2 recovery process","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5224
Forethought in all things.
---Periander
"},{"location":"releases/history/#greatvoyage-v4711-pittacus","title":"GreatVoyage-v4.7.1.1 (Pittacus)","text":"GreatVoyage-v4.7.1.1 (Pittacus) version optimized multiple interfaces and removed APIs involving sensitive information.
Please see the details below.
"},{"location":"releases/history/#api_4","title":"API","text":""},{"location":"releases/history/#1-remove-apis-involving-sensitive-information","title":"1. Remove APIs involving sensitive information","text":"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 passwordgenerateaddress: Create address randomlyeasytransfer: Transfer TRX with passwordeasytransferbyprivate: Transfer TRX with private keyeasytransferasset: Transfer TRC10 token with passwordeasytransferassetbyprivate: Transfer TRC10 token with private keygettransactionsign: Sign transaction with private keyaddtransactionsign: Sign transaction with private key which is mainly used to sign multi-signature transactions
- gRPC
CreateAddress: Create an address based on the specified passwordGenerateAddress: Create address randomlyEasyTransfer: Transfer TRX with passwordEasyTransferByPrivate: Transfer TRX with private keyEasyTransferAsset: Transfer TRC10 token with passwordEasyTransferAssetByPrivate: Transfer TRC10 token with private keyGetTransactionSign: Sign transaction with private keyGetTransactionSign2: Sign transaction with private keyAddSign: 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
"},{"location":"releases/history/#2-optimize-resource-delegate-information-query-interface","title":"2. Optimize resource delegate information query interface","text":"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
"},{"location":"releases/history/#other-changes_8","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-the-update-logic-of-the-origin_energy_usage-field-in-the-transaction-receipt","title":"1. Optimize the update logic of the origin_energy_usage field in the transaction receipt","text":"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
"},{"location":"releases/history/#greatvoyage-v471sartre","title":"GreatVoyage-v4.7.1(Sartre)","text":"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.
"},{"location":"releases/history/#cores","title":"Cores","text":""},{"location":"releases/history/#1-optimize-the-node-ip-setting","title":"1. Optimize the node IP setting","text":"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
"},{"location":"releases/history/#2-optimize-block-synchronization-logic","title":"2. Optimize block synchronization logic","text":"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\uff0cand 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
"},{"location":"releases/history/#api_5","title":"API","text":""},{"location":"releases/history/#1-optimize-the-list-of-solidified-block-apis","title":"1. Optimize the list of solidified block APIs","text":"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
"},{"location":"releases/history/#2-optimize-resource-delegation-relationship-api","title":"2. Optimize resource delegation relationship API","text":"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.
"},{"location":"releases/history/#other-changes_9","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-litefullnode-detection-logic","title":"1. Optimize LiteFullNode detection logic","text":"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
"},{"location":"releases/history/#2-optimize-node-log-output","title":"2. Optimize node log output","text":"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
"},{"location":"releases/history/#greatvoyage-v4701aristotle","title":"GreatVoyage-v4.7.0.1(Aristotle)","text":"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 \u2018Toolkit.jar\u2019 toolbox to bring users a more convenient development experience.
Please see the details below.
"},{"location":"releases/history/#cores_1","title":"Cores","text":""},{"location":"releases/history/#1-a-new-stake-model-stake-20","title":"1. A new stake model - Stake 2.0","text":"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\u2019s 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 \u2019N\u2019 days. After the \u2019N\u2019 days delay, the TRX released could be withdrawn to the owner\u2019s account. \u2019N\u2019 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.
- TIP: https://github.com/tronprotocol/tips/issues/467
- Source code: https://github.com/tronprotocol/java-tron/pull/4838
"},{"location":"releases/history/#2enhance-database-query-performance","title":"2.Enhance database query performance","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4740
"},{"location":"releases/history/#3-optimize-block-production-process","title":"3. Optimize block production process","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4756
"},{"location":"releases/history/#4-add-transaction-hash-cache","title":"4. Add transaction hash cache","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4792
"},{"location":"releases/history/#5-add-libp2p-module-as-java-tron-p2p-network-protocol-implementation","title":"5. Add libp2p module as java-tron p2p network protocol implementation","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4791
"},{"location":"releases/history/#tvm_3","title":"TVM","text":""},{"location":"releases/history/#1-add-new-instructions-to-support-stake-20","title":"1. Add new instructions to support Stake 2.0","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/467
- Source code: https://github.com/tronprotocol/java-tron/pull/4872
"},{"location":"releases/history/#2-dynamic-energy-model","title":"2. Dynamic energy model","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/491
- Source code: https://github.com/tronprotocol/java-tron/pull/4873
"},{"location":"releases/history/#3-optimize-the-return-value-of-the-chainid-opcode","title":"3. Optimize the return value of the chainId opcode","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/474
- Source code: https://github.com/tronprotocol/java-tron/pull/4863
"},{"location":"releases/history/#api_6","title":"API","text":""},{"location":"releases/history/#1-add-apis-to-support-stake-20","title":"1. Add APIs to support Stake 2.0","text":"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?
- TIP: https://github.com/tronprotocol/tips/issues/467
- Source code: https://github.com/tronprotocol/java-tron/pull/4838
"},{"location":"releases/history/#2-add-energy-estimation-api","title":"2. Add energy estimation API","text":"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' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"owner_address\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"contract_address\": \"TXLAQ63Xg1NAzckPwKHvzw7CSEmLMEqcdj\",\n \"function_selector\": \"transfer(address,uint256)\",\n \"parameter\": \"0000000000000000000000002EEF13ADA48F286066F9066CE84A9AD686A3EA480000000000000000000000000000000000000000000000000000000000000004\",\n \"visible\": true\n}'\n
- Source code: https://github.com/tronprotocol/java-tron/pull/4873
"},{"location":"releases/history/#other-changes_10","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-gradle-compilation-parameters","title":"1. Optimize Gradle compilation parameters","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4837
"},{"location":"releases/history/#2-optimize-node-conditional-stop-function","title":"2. Optimize node conditional stop function","text":"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\u2019 settings.
- Source code: https://github.com/tronprotocol/java-tron/pull/4853 https://github.com/tronprotocol/java-tron/pull/4858
"},{"location":"releases/history/#3-delete-code-related-to-database-v1","title":"3. Delete code related to database v1","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4836
"},{"location":"releases/history/#4-optimize-database-log-output","title":"4. Optimize database log output","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4833
"},{"location":"releases/history/#5-make-snapshot-flush-speed-configurable","title":"5. Make snapshot flush speed configurable","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4834
"},{"location":"releases/history/#6-toolkitjar-integration","title":"6. Toolkit.jar Integration","text":"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\njava -jar Toolkit.jar db convert -h\n// convert FullNode data into LiteFullNode data\njava -jar Toolkit.jar db lite -h\n// Database copy\njava -jar Toolkit.jar db copy -h\n
- Source code: https://github.com/tronprotocol/java-tron/pull/4813
Courage is the first of human qualities because it is the quality that guarantees others.
--- Aristotle
"},{"location":"releases/history/#greatvoyage-v460-socrates","title":"GreatVoyage-v4.6.0 (Socrates)","text":"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.
"},{"location":"releases/history/#core_6","title":"Core","text":""},{"location":"releases/history/#1-optimize-delegate-relationship-index-structure","title":"1. Optimize delegate relationship index structure","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/476
- Source code: https://github.com/tronprotocol/java-tron/pull/4788
"},{"location":"releases/history/#2-add-transaction-memo-fee-proposal","title":"2. Add transaction memo fee proposal","text":"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 \u20180\u2019, and the unit is \u2018sun\u2019. It can be enabled by specifying a non-zero value by initiating a proposal, for example, \u20181000000\u2019, indicating that the transaction with memo will require an additional 1 TRX fee.
- TIP: https://github.com/tronprotocol/tips/issues/387
- Source code: https://github.com/tronprotocol/java-tron/pull/4758
"},{"location":"releases/history/#3-add-optimized-reward-algorithm-proposal","title":"3. Add optimized reward algorithm proposal","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/465
- Source code: https://github.com/tronprotocol/java-tron/pull/4694
"},{"location":"releases/history/#4-upgrade-checkpoint-mechanism-to-v2-in-database-module","title":"4. Upgrade checkpoint mechanism to v2 in database module","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/461
- Source code: https://github.com/tronprotocol/java-tron/pull/4614
"},{"location":"releases/history/#5-optimize-block-production-priority-between-active-and-backup-nodes","title":"5. Optimize block production priority between active and backup nodes","text":"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.
- Source code\uff1ahttps://github.com/tronprotocol/java-tron/pull/4630
"},{"location":"releases/history/#6optimize-the-kademlia-algorithm-for-the-network-module","title":"6.Optimize the Kademlia algorithm for the network module","text":"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 \u2018distance\u2019 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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4620 https://github.com/tronprotocol/java-tron/pull/4622
"},{"location":"releases/history/#other-changes_11","title":"Other Changes","text":""},{"location":"releases/history/#1-merge-archivemanifestjar-into-toolkitjar","title":"1. Merge ArchiveManifest.jar into Toolkit.jar","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4603
"},{"location":"releases/history/#2-add-prometheus-metrics-for-network-module","title":"2. Add prometheus metrics for network module","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4626
"},{"location":"releases/history/#3-add-the-help-command-option","title":"3. Add the --help command option","text":"GreatVoyage-v4.6.0(Socrates) adds \u2018help\u2019 command line options to check all parameters and instructions. Please check the example below,
$ java -jar FullNode.jar --help\n\nName:\n FullNode - the java-tron command line interface\n\nUsage: java -jar FullNode.jar [options] [seedNode <seedNode> ...]\n\nVERSION:\n4.5.2-d05f766\n\nTRON OPTIONS:\n-v, --version Output code version\n-h, --help Show help message\n-c, --config Config file (default:config.conf)\n--log-config Logback config file\n--es Start event subscribe server\n\nDB OPTIONS:\n-d, --output-directory Data directory for the databases (default:output-directory)\n\nWITNESS OPTIONS:\n-w, --witness Is witness node\n-p, --private-key Witness private key\n\nVIRTUAL MACHINE OPTIONS:\n--debug Switch for TVM debug mode. In debug model, TVM will not check for timeout. (default: false)\n
- Source code: https://github.com/tronprotocol/java-tron/pull/4606
"},{"location":"releases/history/#4-optimize-litefullnodetooljar","title":"4. Optimize LiteFullNodeTool.jar","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4607
"},{"location":"releases/history/#5-optimize-the-return-value-of-eth_getblockbyhash-and-eth_getblockbynumber-apis","title":"5. Optimize the return value of eth_getBlockByHash and eth_getBlockByNumber APIs","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4642
To move the world we must move ourselves.
--- Socrates
"},{"location":"releases/history/#greatvoyage-v452aurelius","title":"GreatVoyage-v4.5.2(Aurelius)","text":"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.
"},{"location":"releases/history/#core_7","title":"Core","text":""},{"location":"releases/history/#1-optimize-block-processing","title":"1. Optimize block processing","text":"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
"},{"location":"releases/history/#2-optimize-transaction-cache","title":"2. Optimize transaction cache","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4538
"},{"location":"releases/history/#3-optimize-nodes-connection-strategy","title":"3. Optimize nodes connection strategy","text":"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
"},{"location":"releases/history/#4-optimize-block-generating-logic","title":"4. Optimize block generating logic","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4387
"},{"location":"releases/history/#5-optimize-fork-switching-logic","title":"5. Optimize fork switching logic","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4583
"},{"location":"releases/history/#6-add-database-storage-partition-tool","title":"6. Add database storage partition tool","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4545 https://github.com/tronprotocol/java-tron/pull/4559 https://github.com/tronprotocol/java-tron/pull/4563
"},{"location":"releases/history/#api_7","title":"API","text":""},{"location":"releases/history/#1-new-block-header-query-api","title":"1. New block header query API","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4492 https://github.com/tronprotocol/java-tron/pull/4552
"},{"location":"releases/history/#2-new-historical-bandwidth-unit-price-query-api","title":"2. New historical bandwidth unit price query API","text":"According to the bandwidth consumption rules, if the transaction initiator\u2019s 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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4556
"},{"location":"releases/history/#other-changes_12","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-block-synchronization-logic","title":"1. Optimize block synchronization logic","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4542 https://github.com/tronprotocol/java-tron/pull/4540
"},{"location":"releases/history/#2-optimize-eth_estimategas-and-eth_call-api","title":"2. Optimize eth_estimateGas and eth_call API","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4570
"},{"location":"releases/history/#3-enhance-the-fault-tolerance-of-the-interface","title":"3. Enhance the fault tolerance of the interface","text":"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\uff1ahttps://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
"},{"location":"releases/history/#greatvoyage-v451tertullian","title":"GreatVoyage-v4.5.1(Tertullian)","text":"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.
"},{"location":"releases/history/#core_8","title":"Core","text":""},{"location":"releases/history/#1-optimize-transaction-cache-loading","title":"1. Optimize transaction cache loading","text":"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
"},{"location":"releases/history/#2-optimize-account-trc-10-asset-storage-structure","title":"2. Optimize account TRC-10 asset storage structure","text":"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
"},{"location":"releases/history/#3-optimize-light-node-synchronization","title":"3. Optimize light node synchronization","text":"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
"},{"location":"releases/history/#4-optimize-block-broadcasting","title":"4. Optimize block broadcasting","text":"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
"},{"location":"releases/history/#5-optimize-fetch-block-process","title":"5. Optimize fetch block process","text":"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
"},{"location":"releases/history/#6-support-prometheus-metric-protocol-interface","title":"6. Support prometheus metric protocol interface","text":"Starting from the GreatVoyage-v4.5.1 (Tertullian) version, the node provides an open source system monitoring tool - prometheus\u2019s 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
"},{"location":"releases/history/#7-support-node-stop-at-specified-condition","title":"7. Support node stop at specified condition","text":"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\u2019s 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
"},{"location":"releases/history/#tvm_4","title":"TVM","text":""},{"location":"releases/history/#1-adjust-the-upper-limit-that-can-be-set-for-the-maximum-execution-time-of-tvm","title":"1. Adjust the upper limit that can be set for the maximum execution time of TVM","text":"\"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
"},{"location":"releases/history/#2-optimize-the-cache-structure-of-tvm","title":"2. Optimize the cache structure of TVM","text":"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
"},{"location":"releases/history/#greatvoyage-v446david","title":"GreatVoyage-v4.4.6(David)","text":"GreatVoyage-v4.4.6 (David) updated the version of the dependency library fastjson to ensure the security of using fastjson.
"},{"location":"releases/history/#other-changes_13","title":"Other Changes","text":""},{"location":"releases/history/#1-update-the-fastjson-dependency-library-to-the-latest-version","title":"1. Update the fastjson dependency library to the latest version","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4393
*Beauty in things exists in the mind which contemplates them. *
---David Hume
"},{"location":"releases/history/#greatvoyage-445cicero","title":"GreatVoyage-4.4.5(Cicero)","text":"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.
"},{"location":"releases/history/#other-changes_14","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-the-query-interface-of-the-node","title":"1. Optimize the query interface of the node","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4349
No one can give you better advice than yourself.
---Cicero
"},{"location":"releases/history/#greatvoyage-444plotinus","title":"GreatVoyage-4.4.4(Plotinus)","text":"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.
"},{"location":"releases/history/#core_9","title":"Core","text":""},{"location":"releases/history/#1-optimize-node-startup-time","title":"1. Optimize node startup time","text":"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
"},{"location":"releases/history/#2-optimize-memory-usage","title":"2. Optimize memory usage","text":"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
"},{"location":"releases/history/#3-optimize-the-block-producing-thread","title":"3. Optimize the block-producing thread","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4219
"},{"location":"releases/history/#tvm_5","title":"TVM","text":""},{"location":"releases/history/#1-tvm-support-multi-version-program-executors","title":"1. TVM support multi-version program-executors","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4257 https://github.com/tronprotocol/java-tron/pull/4259
"},{"location":"releases/history/#other-changes_15","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-log-storage","title":"1. Optimize log storage","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4245
"},{"location":"releases/history/#2-optimize-network-service-shutdown-logic","title":"2. Optimize network service shutdown logic","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4220
"},{"location":"releases/history/#3-improve-the-java-tron-upgrade-mechenism","title":"3. improve the java-tron upgrade mechenism","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4218
The world is knowable, harmonious, and good.
--- Plotinus
"},{"location":"releases/history/#greatvoyage-442augustinus","title":"GreatVoyage-4.4.2(Augustinus)","text":"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.
"},{"location":"releases/history/#tvm_6","title":"TVM","text":""},{"location":"releases/history/#1-tvm-opcode-execution-model-optimization","title":"1. TVM Opcode Execution Model Optimization","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4157
"},{"location":"releases/history/#api_8","title":"API","text":""},{"location":"releases/history/#1-newly-adding-eth-compatible-log-filter-for-json-rpc-apis","title":"1. Newly Adding ETH compatible log filter for JSON-RPC APIs.","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4153
"},{"location":"releases/history/#other-changes_16","title":"Other Changes","text":""},{"location":"releases/history/#1-leveldb-databases-performance-optimization","title":"1. LevelDB Databases Performance Optimization","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4154
Patience is the companion of wisdom.
--- Augustinus
"},{"location":"releases/history/#greatvoyage-440rousseau","title":"GreatVoyage-4.4.0(Rousseau)","text":"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.
"},{"location":"releases/history/#core_10","title":"Core","text":""},{"location":"releases/history/#1-optimize-the-block-broadcasting","title":"1. Optimize the block broadcasting","text":"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
"},{"location":"releases/history/#2-optimize-the-query-performance-of-dynamic-store","title":"2. Optimize the query performance of dynamic store","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/3993
"},{"location":"releases/history/#3-optimize-the-transaction-broadcasting-interface","title":"3. Optimize the transaction broadcasting interface","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4000
"},{"location":"releases/history/#4-optimize-the-parameters-of-the-database","title":"4. Optimize the parameters of the database","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4018 https://github.com/tronprotocol/java-tron/pull/3992
"},{"location":"releases/history/#tvm_7","title":"TVM","text":""},{"location":"releases/history/#1-provide-compatibility-with-evm","title":"1. Provide compatibility with EVM","text":"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 \u201cTransferContract\u201d to transfer TRX to the smart contract account.
TIP: https://github.com/tronprotocol/tips/blob/master/tip-272.md Source Code\uff1ahttps://github.com/tronprotocol/java-tron/pull/4032
NOTICE\uff1a By default, this feature is disabled, and the super representative or super partner will initiate a vote request to enable it in the future.
"},{"location":"releases/history/#2-adapt-to-ethereum-london-release","title":"2. Adapt to Ethereum London Release","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4032
NOTICE\uff1a By default, this feature is disabled, and the super representative or super partner will initiate a vote request to enable it in the future.
"},{"location":"releases/history/#3-in-constant-mode-energy-limit-supports-customization-and-the-default-value-is-increased","title":"3. In constant mode, Energy limit supports customization and the default value is increased","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4032
"},{"location":"releases/history/#api_9","title":"API","text":""},{"location":"releases/history/#1-support-ethereum-compatible-json-rpc-api","title":"1. Support Ethereum compatible JSON-RPC API","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4046
"},{"location":"releases/history/#2-fullnode-supports-disabling-apis","title":"2. FullNode supports disabling APIs","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4045
"},{"location":"releases/history/#3-optimize-the-triggerconstantcontract-api","title":"3. Optimize the TriggerConstantContract API","text":"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\uff1a https://github.com/tronprotocol/java-tron/pull/4032
"},{"location":"releases/history/#changes","title":"Changes","text":""},{"location":"releases/history/#1-upgrade-event-plugin-to-support-bttc-data","title":"1. Upgrade event plugin to support BTTC data","text":"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
"},{"location":"releases/history/#2-increase-the-upper-limit-of-the-maxfeelimit-network-parameter","title":"2. Increase the upper limit of the MaxFeeLimit network parameter.","text":"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\uff1a https://github.com/tronprotocol/java-tron/pull/4032
NOTICE\uff1a By default, this feature is disabled, it will be enabled after the London upgrade proposal takes effect.
"},{"location":"releases/history/#3-optimize-the-quick-start-script-startsh","title":"3. Optimize the quick start script start.sh","text":"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
"},{"location":"releases/history/#greatvoyage-430bacon","title":"GreatVoyage-4.3.0(Bacon)","text":"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.
"},{"location":"releases/history/#core_11","title":"Core","text":""},{"location":"releases/history/#1-add-a-proposal-to-adjust-the-free-net-limit-in-an-account","title":"1. Add a proposal to adjust the free net limit in an account.","text":"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.
"},{"location":"releases/history/#2-add-a-proposal-to-adjust-the-total-net-limit","title":"2. Add a proposal to adjust the total net limit.","text":"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.
"},{"location":"releases/history/#3-optimize-the-account-data-structure","title":"3. Optimize the Account Data Structure","text":"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.
"},{"location":"releases/history/#tvm_8","title":"TVM","text":""},{"location":"releases/history/#1-add-vote-instructions-and-precompile-contracts-in-tvm","title":"1. Add Vote Instructions and Precompile Contracts in TVM","text":"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.
"},{"location":"releases/history/#2-add-a-new-type-error-in-smart-contract-abi","title":"2. Add a New Type: Error in Smart Contract ABI","text":"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
"},{"location":"releases/history/#api_10","title":"API","text":""},{"location":"releases/history/#1-add-a-new-field-energy_used-in-transactionextention","title":"1. Add a New Field: energy_used in TransactionExtention","text":"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
"},{"location":"releases/history/#changes_1","title":"Changes","text":""},{"location":"releases/history/#1-change-the-cryptography-library-to-bouncy-castle","title":"1. Change the Cryptography Library to Bouncy Castle","text":"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
"},{"location":"releases/history/#2-modify-the-calculation-of-net_usage-value-in-the-transactioninfo-when-creating-new-accounts","title":"2. Modify the Calculation of net_usage Value in the Transactioninfo when Creating New Accounts","text":"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
"},{"location":"releases/history/#3-optimize-the-block-verification","title":"3. Optimize the Block Verification","text":"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
"},{"location":"releases/history/#4-optimize-the-node-startup","title":"4. Optimize the Node Startup","text":"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
"},{"location":"releases/history/#5-optimize-transaction-processing-flow-to-reduce-memory-usage","title":"5. Optimize Transaction Processing Flow to Reduce Memory Usage","text":"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
"},{"location":"releases/history/#6-add-new-plugins-to-optimize-the-performance-of-levedb-startup","title":"6. Add New Plugins to Optimize the Performance of levedb Startup","text":"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
"},{"location":"releases/history/#greatvoyage-4221epictetus","title":"GreatVoyage-4.2.2.1(Epictetus)","text":"We have just released the version of GreatVoyage-v4.2.2.1(Epictetus). The main new features and modifications are as follows:
"},{"location":"releases/history/#core-protocol","title":"Core Protocol","text":""},{"location":"releases/history/#1-optimize-the-processing-logic-of-pending-transactions","title":"1. Optimize the processing logic of pending transactions.","text":"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.
- Source code: #3874
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
"},{"location":"releases/history/#greatvoyage-422lucretius","title":"GreatVoyage-4.2.2(Lucretius)","text":"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.
"},{"location":"releases/history/#core-protocol_1","title":"Core Protocol","text":""},{"location":"releases/history/#1-block-processing-optimization","title":"1. Block Processing optimization","text":"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
- Source code: #3827
"},{"location":"releases/history/#2-data-query-optimization","title":"2. Data Query optimization","text":"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.
"},{"location":"releases/history/#3-smart-contract-abi-storage-optimization","title":"3. Smart Contract ABI Storage optimization","text":"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
- Source code: #3836
"},{"location":"releases/history/#other-changes_17","title":"Other Changes","text":""},{"location":"releases/history/#1-system-contract-batchvalidatesign-initialization-process-optimization","title":"1. System Contract BatchValidateSign Initialization Process optimization","text":" - Source code: #3836
--- Truths kindle light for truths.
--- Lucretius
"},{"location":"releases/history/#greatvoyage-420plato","title":"GreatVoyage-4.2.0(Plato)","text":"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.
"},{"location":"releases/history/#core-protocol_2","title":"Core Protocol","text":""},{"location":"releases/history/#1-optimize-the-resource-model","title":"1. Optimize the resource model","text":"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\uff1a TIP-207
- Source Code: #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).
"},{"location":"releases/history/#tvm_9","title":"TVM","text":""},{"location":"releases/history/#1add-freezeunfreeze-instructions-in-tvm","title":"1\u3001Add Freeze/Unfreeze instructions in TVM","text":"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
- Source Code\uff1a #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.
"},{"location":"releases/history/#other-changes_18","title":"Other Changes","text":""},{"location":"releases/history/#1optimize-the-block-synchronization","title":"1\u3001Optimize the block synchronization.","text":" - Source code\uff1a#3732
The beginning is the most important part of the work.
--- Plato
"},{"location":"releases/history/#greatvoyage-413thales","title":"GreatVoyage-4.1.3(Thales)","text":"GreatVoyage-4.1.3(Thales) is released with the following new features and modifications:
"},{"location":"releases/history/#core-protocol_3","title":"Core Protocol","text":""},{"location":"releases/history/#1sorting-the-transactions-in-pending-pool-sr-will-prioritize-the-transactions-with-high-packing-fee","title":"1.Sorting the transactions in pending pool, SR will prioritize the transactions with high packing fee","text":"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.
"},{"location":"releases/history/#api_11","title":"API","text":""},{"location":"releases/history/#1add-new-api-to-support-transaction-query-in-pending-pool","title":"1.Add new API to support transaction query in pending pool.","text":"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.
"},{"location":"releases/history/#great-voyage-v412","title":"Great Voyage - v4.1.2","text":"GreatVoyage-version 4.1.2 is released with the following new features and modifications:
"},{"location":"releases/history/#i-core-protocol","title":"I. Core Protocol","text":""},{"location":"releases/history/#1reward-srs-with-the-transaction-fees-charged-for-bandwidth-and-energy","title":"1\u3001Reward SRs with the transaction fees charged for bandwidth and energy.","text":"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
- Source Code: #3532
"},{"location":"releases/history/#2support-account-history-balance-query","title":"2\u3001Support account history balance query.","text":"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 \uff1aquery account balance at a specific block.
- /wallet/getblockbalance \uff1a 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\uff1a#3538
- Guide \uff1a https://github.com/tronprotocol/documentation-en/blob/master/docs/api/http.md
"},{"location":"releases/history/#3optimized-the-blackhole-account-to-improve-transaction-execution-speed","title":"3\u3001Optimized the blackhole account to improve transaction execution speed","text":"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\uff1a #3617
"},{"location":"releases/history/#ii-tvm","title":"II. TVM","text":""},{"location":"releases/history/#1adopt-to-solidity060","title":"1\u3001Adopt to solidity0.6.0.","text":"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
- Source Code\uff1a #3351
"},{"location":"releases/history/#2make-max_fee_limit-configurable-as-a-chain-property","title":"2\u3001Make MAX_FEE_LIMIT configurable as a chain property.","text":"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].
- TIP\uff1a TIP-204
- Source code\uff1a #3534
"},{"location":"releases/history/#iii-others-changes","title":"III. Others Changes","text":""},{"location":"releases/history/#1use-the-jitpack-repository-to-provide-dependency-support-and-make-it-easy-for-developers-to-use-java-tron-as-a-dependency-for-their-projects","title":"1\u3001Use the jitpack repository to provide dependency support and make it easy for developers to use java-tron as a dependency for their projects.","text":" - Source code: #3554
"},{"location":"releases/history/#greatvoyage-v411","title":"GreatVoyage-v4.1.1","text":"GreatVoyage-version 4.1.1 is released with the following new features and modifications:
"},{"location":"releases/history/#i-core-protocol_1","title":"I. Core Protocol","text":""},{"location":"releases/history/#1-new-consensus-protocol","title":"1. New Consensus Protocol","text":"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
"},{"location":"releases/history/#2-new-node-type","title":"2. New Node Type","text":"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
"},{"location":"releases/history/#ii-tvm_1","title":"II. TVM","text":""},{"location":"releases/history/#achieved-compatibility-with-ethereum-istanbul-upgrade","title":"Achieved compatibility with Ethereum Istanbul upgrade","text":"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
"},{"location":"releases/history/#iii-mechanism","title":"III. Mechanism","text":" - Added two new system contracts, namely MarketSellAssetContract and MarketCancelOrderContract, for on-chain TRX/TRC10 transactions in decentralized exchanges.
- TIP: TIP-127
- Source code: #3302
"},{"location":"releases/history/#iv-other-modifications","title":"IV. Other Modifications","text":" - Added a few node performance indicators.
-
Source code: #3350
-
Added market order detail in the original transactionInfo interface.
- TIP: TIP-127
-
Source code: #3302
-
Improved the script for docker deployment.
- Source code: #3330
"},{"location":"releases/history/#greatvoyage-v400","title":"GreatVoyage-v4.0.0","text":"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.
"},{"location":"releases/history/#notices","title":"Notices","text":"Forced upgrade
"},{"location":"releases/history/#new-features","title":"New features","text":" - 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.\u00a0Create shielded contract parameters
rpc CreateShieldedContractParameters (PrivateShieldedTRC20Parameters) returns (ShieldedTRC20Parameters) {}\n
2.\u00a0Create shielded contract parameters without ask rpc CreateShieldedContractParametersWithoutAsk (PrivateShieldedTRC20ParametersWithoutAsk) returns (ShieldedTRC20Parameters) {}\n
3.\u00a0Scan shielded TRC20 notes by ivk rpc ScanShieldedTRC20NotesByIvk (IvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}\n
4.\u00a0Scan shielded TRC20 notes by ovk rpc ScanShieldedTRC20NotesByOvk (OvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}\n
5.\u00a0Check if the shielded TRC20 note is spent rpc IsShieldedTRC20ContractNoteSpent (NfTRC20Parameters) returns (NullifierResult) {}\n
6.\u00a0Get the trigger input for the shielded TRC20 contract rpc GetTriggerInputForShieldedTRC20Contract (ShieldedTRC20TriggerContractParameters) returns (BytesMessage) {}\n
- 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).
"},{"location":"releases/history/#changes_2","title":"Changes","text":" - Check if null before getInstance when get transaction info from DB to fix exception of
getTransactioninfoByBlkNum (#3165).
"},{"location":"releases/history/#odyssey-v37","title":"Odyssey-v3.7","text":"Odyssey-v3.7 is a non-mandatory upgrade, includes the following new features and improvements.
"},{"location":"releases/history/#modularization","title":"Modularization","text":"Odyssey-v3.7 has modularized the code organization structure, making it much easier for developers to develop customized module\uff0cseveral mainly modules are listed as follows\uff1a
"},{"location":"releases/history/#framework","title":"Framework","text":"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.
"},{"location":"releases/history/#protocol","title":"Protocol","text":"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\uff0cincluding 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
"},{"location":"releases/history/#consensus","title":"Consensus","text":"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.
"},{"location":"releases/history/#crypto","title":"Crypto","text":"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.
"},{"location":"releases/history/#actuator","title":"Actuator","text":"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.
"},{"location":"releases/history/#chainbase","title":"Chainbase","text":"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.
"},{"location":"releases/history/#new-event-subscription-trigger-for-solidified-block","title":"New event subscription trigger for solidified block","text":"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.
"},{"location":"releases/history/#two-new-http-apis-added","title":"Two new HTTP APIs added","text":"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
"},{"location":"releases/history/#a-new-rpc-api-added","title":"A new RPC API added","text":"Adding the GetTransactionInfoByBlockNum method both in Wallet WalletSolidity services\uff1a
rpc GetTransactionInfoByBlockNum (NumberMessage) returns (TransactionInfoList) {\n}\n
a code snippet\uff1a NumberMessage.Builder builder = NumberMessage.newBuilder();\nbuilder.setNum(blockNum);\nTransactionInfoList transactionInfoList = blockingStubFull.getTransactionInfoByBlockNum(builder.build());\n
"},{"location":"releases/history/#odyssey-v365","title":"Odyssey-v3.6.5","text":"Odyssey v3.6.5 Update includes the following new features and improvements
"},{"location":"releases/history/#1-new-delegation-mechanism","title":"1. New delegation mechanism","text":"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\u2019s 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.
"},{"location":"releases/history/#2-fairer-and-more-efficient-staking-rewards-mechanism","title":"2. Fairer and more efficient staking rewards mechanism","text":"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.
"},{"location":"releases/history/#3-fairer-incentive-mechanism","title":"3. Fairer incentive mechanism","text":"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.
"},{"location":"releases/history/#4-improvement-and-optimization-of-tvm","title":"4. Improvement and optimization of TVM","text":"(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\u2019 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.
"},{"location":"releases/history/#5-improvement-of-the-dynamic-adjustment-scheme-of-energy-upper-limit","title":"5. Improvement of the dynamic adjustment scheme of Energy upper limit","text":"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\u2019 costs of using TRON blockchain network and improving network efficiency.
"},{"location":"releases/signature_verification/","title":"Signature Verification of java-tron Release Package","text":"java-tron integrity verification is to check the reliability and integrity of the obtained java-tron executable file through signature verification. Signature verification needs to know three pieces of information: the executable file to be verified, the signature of the file, and the public key corresponding to the private key that signed the file. Signature verification is to reversely deduce the public key corresponding to the signature based on the content and signature of the executable file, and then compare it with the public key issued by TRON. If they are consistent, it means that the java-tron executable file you get is a complete file released by TRON.
The version of java-tron released after January 3, 2023 adopts the GPG method for signature and verification, and the version released before January 3, 2023 used the public-private key of a specified TRON account for signature and verification.
- Versions released after January 3, 2023: GPG Signature Verification Process
- Versions released before January 3, 2023: TRON Address Signature Verification Process
"},{"location":"releases/signature_verification/#gpg-signature-verification-process","title":"GPG signature verification process","text":"The java-tron executable file and its signature file are released together, you can get it at here, please follow the below process to verify the signature of the java-tron which released after January 3, 2023.
"},{"location":"releases/signature_verification/#install-gpg","title":"Install GPG","text":"If you have already installed GPG, please skip this step. If not, please refer to the following command to install it on MacOS:
$ brew install gpg\n
On Debian, Ubuntu and other Linux distributions: $ sudo apt install gpg\n
"},{"location":"releases/signature_verification/#import-public-key","title":"Import public key","text":"If you have imported the public key before, please skip this step, just import the public key once.
Please first obtain the public key Hash and uid of the GPG signature of the java-tron release package from here.
pub: 1254\u00a0F859\u00a0D2B1\u00a0BD9F\u00a066E7\u00a0107D\u00a0F859\u00a0BCB4\u00a04A28\u00a0290B\nuid: build@tron.network\n
Import the public key from the GPG public key server to the local according to the public key Hash, the command is: $ gpg --keyserver hkp://keys.openpgp.org --recv-keys \"1254\u00a0F859\u00a0D2B1\u00a0BD9F\u00a066E7\u00a0107D\u00a0F859\u00a0BCB4\u00a04A28\u00a0290B\"\n
If the import was successful, you will see the return result like this: gpg: key 785FB96D2C7C3CA5: public key \u201cbuild_tron <build@tron.network>\u201d imported\ngpg: Total number processed: 1\ngpg: imported: 1\n
"},{"location":"releases/signature_verification/#signature-verification","title":"Signature verification","text":"For example, if the executable file of a certain version is FullNode.jar and the signature file is FullNode.jar.sig, the signature verification command is:
$ gpg --verify FullNode.jar.sig FullNode.jar\n
If the signature verification is passed, the following will be returned: gpg: Signature made Fri. 1/ 6 12:21:51 2023 CST\ngpg: using RSA key 1254F859D2B1BD9F66E7107DF859BCB44A28290B\ngpg: Good signature from \u201cbuild_tron <build@tron.network>\u201d [unknown]\ngpg: WARNING: This key is not certified with a trusted signature!\ngpg: There is no indication that the signature belongs to the owner.\nPrimary key fingerprint: 07B2 3298 AEA4 E006 BD9A 42DE 785F B96D 2C7C 3CA5\nSubkey fingerprint: 1254 F859 D2B1 BD9F 66E7 107D F859 BCB4 4A28 290B\n
If the verification fails, it will display the words gpg: BAD signature from \u201cbuild_tron <build@tron.network>\u201d."},{"location":"releases/signature_verification/#tron-address-signature-verification-process","title":"TRON address signature verification process","text":"The java-tron version released before January 3, 2023 is signed by the TRON account TKeAcHxgErbVXrG3N3TZiSV6AT566BHTj2. The signing steps are as follows: first generate a sha256 hash value for the executable file of the release package, and then use the private key of the TRON account to sign the sha256 hash value. The sha256 hash value can be viewed in the Signatures of historical versions chapter, or in the https://github.com/tronprotocol/java-tron/releases page; the signature result please check in the Signatures of historical versions chapter.
tronweb provides the Trx.verifySignature interface to verify the signature. If the verification is passed, it will return true, otherwise, it will return false. Please follow the below process to verify.
"},{"location":"releases/signature_verification/#install-tronweb","title":"Install tronweb","text":"If you have already installed tronweb, please skip this step, if not, please refer to the following command to install.
npm install -g tronweb\n
"},{"location":"releases/signature_verification/#verify-the-integrity-of-the-release-package","title":"Verify the integrity of the release package","text":"Confirm the integrity of the release package by comparing the Hash value of the executable file and the hash value in the release information. Take Odyssey-3.7 version as an example:
- The release package file name:
FullNode.jar - The SHA256 value of the release package:
2fca93b09da4ac62641e03838e77fce99b4711ddb0c09aa91656c80fc9556d2e - Signature\uff1a
21435e32131feb6d00ba8048df04e112e02569ec851064d8ecad2d4dd5da44b7628ddce16823dadfff6fd683fc58cee74964970621a845ee459e2c96a750de551b
Execute the following command for verification under MacOS system:
$ sha256sum FullNode.jar \n
Execute the following command for verification under Debian, Ubuntu and other Linux distributions: $ shasum -a 256 FullNode.jar (macOS)\n
"},{"location":"releases/signature_verification/#signature-verification_1","title":"Signature verification","text":"Execute the following command to verify the signature of the release package:
# Trx.verifySignature(SHA256, ADDRESS, SIGNATURE));\nnode -e 'console.log(require(\"tronweb\").Trx.verifySignature(\n \"2fca93b09da4ac62641e03838e77fce99b4711ddb0c09aa91656c80fc9556d2e\",\n \"TKeAcHxgErbVXrG3N3TZiSV6AT566BHTj2\",\n \"21435e32131feb6d00ba8048df04e112e02569ec851064d8ecad2d4dd5da44b7628ddce16823dadfff6fd683fc58cee74964970621a845ee459e2c96a750de551b\"\n ))'\n
"},{"location":"releases/signature_verification/#signatures-of-historical-versions","title":"Signatures of historical versions","text":" - Odyssey-3.7
FullNode sha256sum: 2fca93b09da4ac62641e03838e77fce99b4711ddb0c09aa91656c80fc9556d2e\nFullNode signature: 21435e32131feb6d00ba8048df04e112e02569ec851064d8ecad2d4dd5da44b7628ddce16823dadfff6fd683fc58cee74964970621a845ee459e2c96a750de551b\nSolidityNode sha256sum: fcdea8b3e511306218ba442fb0828f0413574012d646c39c212a59f6ba5844bc\nSolidityNode signature: 6dcad6e02f17467e5cfebeefa0f9963da08e7da10feebefdec47d689fecc30f104c9b7f5e784b883e7ceb786fe55188356c42c306d727fb7819eed2a71f788361c\n
- GreatVoyage-4.0.0
FullNode sha256sum: d3f8f9fde64bdefaadae784d09de97172e5e8a3fe539217e12b89963983a530d\nFullNode signature: e788dbaf2fe35f099f65b2403cfb0d7cbe7f4611f8c5ff8151e4bd84ae468d2e541043c9cde9e74500003027ae9f25cdda81a9bcd60abb45ca7a69f965f4dcc71c\nSolidityNode sha256sum: adddf88423c6c31f1f25ed39b10779c24dd7cdcf37f2325c02b2f2ecfc97e1f6\nSolidityNode signature: e3b9859f178f7851dedb7a0a8deb715e5f1e3af10b1064c36f2727ec2b8825510df4fd7b09d7d049204e5df3e8d5b87778e83a15ca96ce786f7977a6cb48bca91b\n
- GreatVoyage-4.1.1
FullNode sha256sum: 30e716b86b879af1e006c2b463903ae3835e239e32e2b01c2a1b903a153897fe\nFullNode signature: 5faee65a448bb9aa77835992ca3d24e50d8a76b7934f80664ad38e83179c8114278fdef4494de7231f8e40de86461676a7aa4a54c795f4c692e91d90e156ec471b\nSolidityNode sha256sum: 10a160181053b421109ecace74df5fc0f8860bc8a70181add65fd9a292c35a44\nSolidityNode signature: 1d1413b13adf7778f9a720294eca066ac728ad636d166505276f5ff1f63973c100c04778f937f240f10107edb7de477604857867fc4dbdb68238169c978fc3da1b\n
- GreatVoyage-v4.1.2
FullNode sha256sum: 4ded44b6c1a3dbd25212e14ab413142b5463dcbf30a528f83ded529048542547\nFullNode signature: 57a094c1b8a5ec301ef913eb718de2498b5695eb999530863df05252ba8919ba6866c8490e29d36f7dbf34537c898ece5ef0111efb134419c3a5fd6fc9ec03b81c\nSolidityNode sha256sum: 3db36cadbd1f7641aafc8164983f28df4b7ceff8174e090327ed407012cf12cb\nSolidityNode signature: d07604f6811cbed628dd6e5c07880c2fdd3025848fd5365925531c7748467d5228fea2e18326864acc27f3b51c73b364fa44c450d8ec4b5080a7ddb7566724701c\n
- GreatVoyage-v4.1.3(Thales)
FullNode sha256sum: c5fb99ad5b024bb7877118f30fb6065f6e6febd11a3cfa241521cbed73cca181\nFullNode signature: d80ec371e791c4316925d80ff3400cf51b14c8a4d4c696b7817c517eb094823622932b45b9b37f9e9657513c3eddb1134fbbb1ee56727c0957e8a3b40c67409b1c\nSolidityNode sha256sum: 4b941d71b561a8b2e0b97d7498823d900eaf287910eea1eaafc649f5aad14036\nSolidityNode signature: f8a8e8d411b009d02986cad1e19e745f8107384a274f146bcae60c570111b13556ff9ab528eb5d1fb4734bd4ef488ade4038781d06ab6420e35f28be6135fe9b1c\n
- GreatVoyage-v4.2.0(Plato)
FullNode sha256sum:\nbbf103432be016b582452137b4862140af15ccf7c5daa9be738450705317fdb8\nFullNode signature:\n326701699a5eb8d497eb454b5b74c1559961417fb6f262b4e6314052d73f5977312e0450937fa485236f51f706b434acf8659ce1325d704097c5748629e736ef1c\nSolidityNode sha256sum:\n1db544cbca9dc814683ccf9bef28f7d6ca4469289052230394aaf4e3bcd08615\nSolidityNode signature:\n47fea27df940db0d2a4c0abf6d06969882c027bc4f17449205a28ae5cd25b8ba5339e21f105fe1c25e799d0f4ffea64a15046b9baf5b54341411b5180da439011b\n
- GreatVoyage-v4.2.1(Origen)
FullNode sha256sum:\n9888710c915a4027f1bc3dcb1d5d983e0c00d4c438f6fa307d412f62ff6862ea\nFullNode signature:\n6e7d8ef9d033ebf9213118b7511f4ecc5def97442844fbd34de3ef76dd417a0d45da3e2e70fc213475d7fc0a44df1c54732874d858ec980159c5dbffc975680a1c\nSolidityNode sha256sum:\nc70edffa3022e9c25bf845ee978e3500c3ada89b473d895a715acf1738b83f10\nSolidityNode signature:\n0e366acce33bb7c6b02fa143a57d9380c94d3513a9fba8692efe2862a8f7df93156edbddd075f1844f2f81398b14f2db6a03e21f0f6b8ab25649fae4dc16ae731b\n
- GreatVoyage-v4.2.2(Lucretius)
FullNode sha256sum:\n8a7f8143b3351ea6b5d8e3dfc857b09256d363d4907ba3ab0288f67f77c2a58f\nFullNode signature:\n71c6300ace5cbf16d78a32aa4602c3f129cb768e32acffaecd17b4134b5955bf37efda1d27025e894e521184a21174e5eddf4e7d1f86761657827795cbddfcfd1c\nSolidityNode sha256sum:\n2d0d5334a232b7b74df8ed3211d9e0ac957894f81e9172010732f2159da261ad\nSolidityNode signature:\n0696f8cb3c65324c4b04f9ecf89d939bf7e1b955144e3fe75eeca6bd4c639e463afbe24e31ae38a6889d4d0649ae03fafeeb7c337b34a36fbac33962f64651671b\n
- GreatVoyage-v4.2.2.1(Epictetus)
FullNode sha256sum:\n8bd040a8db16ccba3e957ed3558b82d145928153a53f9688302849658a72f9bc\nFullNode signature:\n3137a8ba8fa5556e4c4a7597aec8f5f46ebb79a64edcf9e2925d2e3314afde3e0f42fd4080e5e4f4d3d1eff263d30478b0322e6dbcc71c43b534f614004b5c561b\nSolidityNode sha256sum:\nee8abd39732e4901828a61124880f1d2eab62f7f3d97150f1e1921bf7da10e54\nSolidityNode signature:\n092b08184677449dd283a31cc486f994166cd9f5ad312a9c80d3e06689ec540774ac9a1334dffeb6412039ed70ee912ead39c4025dd69b688ea9df4dd831b5771c\n
- GreatVoyage-v4.3.0(Bacon)
FullNode sha256sum:\nb5e993800cea5ca040758dd6b3c7438def03cbf1358468beb76ea45399a59298\nFullNode signature:\n8da6ac58129d78d948810e4bc7372dd8aef5232bfbc4c33ad8fb21e88314e3d97dd77509e0f03a98da32679495152ccd4a9d07541589822e5cf5d3d4f61877191b\nSolidityNode sha256sum:\n446a4736901958a450e4e95aaca99a63957163854fb32d25eed84600e6996668\nSolidityNode signature:\nc27ffde8ce88ee14689e15a9d5c3fb2d2a9d180ea43b45046131df8ac5481fae2588621b395ad7031ed49d65ddd020b3ce084537e3f527d8a5a979f8c65265561c\n
- GreatVoyage-v4.4.0(Rousseau)
FullNode sha256sum:\nbf7f962846f75139dd89ac6da32074cad33b2e172c0749abbed8773cc1ab1a37\nFullNode signature:\n56ed97f3451e3d731f799bad952750d56aa78a9a91a2688b4d6b956328ede7e01bae78037ad6ef1f9c682b566e954dfb958271f006e5cf0dcace5768d76fda6e1b\nSolidityNode sha256sum:\n9dac37763ddf75c07335ec070f837b63ee46b698066dd25c4756ad40f8750d5f\nSolidityNode signature:\ncc4325c085719e3e5045b5c6c2553d7adc9c735419618f7afad06c3a532da0ed46906ae9b2dadb15d7f94150268d5ecdc7fd2741693991586d50da30a8d917071b\n
- GreatVoyage-v4.4.1(Protagoras)
FullNode sha256sum:\n4a32918849dc8a7fedcb637ff4939389363726cb16c6a581e39253260668ee04\nFullNode signature:\nfd747f61705ef045143bd2d55b278ca347904323711e2e86b11cf1dd203f198443ab1a399767a570005bd5b2ea283187ccc41557ffb79c959b018e8d798b96f81c\nSolidityNode sha256sum:\nb6a06d3b19f41591bd8c01f35e78b316ab8e9ad4c0740128fc95ba52d3106f34\nSolidityNode signature:\nd2836bda30fd25c89494ae7a12b5357bc9e725c9e2c655fb0a9158a4bee881693ea869defe650b0b4f190458a5268f1c121e73c8305cc81a408e62fca0d234c51b\n
- GreatVoyage-v4.4.2(Augustinus)
FullNode sha256sum:\n70eba12350fa21e1b261927093090e7bdf0765592d19433c594149bd3707ef0a\nFullNode signature:\n14430f463e6fab3dd247aca6267b6aaf2f1869b455d95aee297208bd1561c6c67559d9c535e63e74bbef604141cc4ceec78367a75e6ca4d4ceb6513019329c9b1b\nSolidityNode sha256sum:\nf08438e093cc1091859f0ee9dbc7e79b0d5d9068facd4e6485374baa3acf59d1\nSolidityNode signature:\nf3935dfe4af9601cf102c975ed2eebbd4b42160e8746c0d0b21ffbd2fbd4b6f374257b1bc0e948909a9ef343d2cc70671961c8f7a992b6cd123f9ad3c8c323391c\n
- GreatVoyage-v4.4.3(Pythagoras)
FullNode sha256sum:\nc07637a1a4a9a289218554f4714caef90032e267b068411c7dd818d4af45e39f\nFullNode signature:\n2bf8d65adf556fe2c04b739c1f4e6e73058914cf642a7806ff85e57be2ff122e35cbf3d67b0bc8bad4fb827198ffd8e06f60111a167ecb0b3db0d8e571b8c67b1c\nSolidityNode sha256sum:\n64f4614160b9330d0a9e984686b66fa16e9aecf7ae16e32b8cc7c32f52694eef\nSolidityNode signature:\ndc0f910555a23667d682a6775588de90592ede44f76a32b12ea8f89fa7dcc937274cc3a44b20da49726323cc9f476d42caa318c338858474f02bf98cc398bca81c\n
- GreatVoyage-v4.4.4(Plotinus)
FullNode sha256sum:\n0264d382489dae5bf1d340030c1892b0a7aeb9364cb9380c034e159c9eb9a269\nFullNode signature:\n70cdece8c3510ce4d7d84d5d2c8b53895397c0134d73d681b6b41d4de80d74ce2c2760fdf080ff0ce8c0989246377fca529cb1a2e85e1936755abef4be64f0971b\nSolidityNode sha256sum:\nb58e7b8b0f97eb2a7a0ce5c5aeb2ce070192ca82c96adc8568aabe4f3407d873\nSolidityNode signature:\n26da2e507bbd7e82e0170039cc1c0e42332fb2dfc755aeb385240f0a93125b6c0f1e943ccf1a4e9bfec7fdd4d8a26375a38e030e0b8b69af3e2c181bf08444111b\n
- GreatVoyage-v4.4.5(Cicero)
FullNode sha256sum:\n8115e887e5af5768e8ab967f8e7bc024af94bda31be7f3dbc30934b42489d988\nFullNode signature:\n1a02f26eb6065efe5697123528f32ea352d813f9e5acf5936407ad8899c4019539e31b257cafe34b9f8045602f5a4f381b3dd8252a30bb9daf52aeeb078b54711b\nSolidityNode sha256sum:\n95884a07dcbb1531ec7ae20b7162cab3bb9c4bd2e300447c01c4772e02b24a20\nSolidityNode signature:\n8adab9501bbb2a3d9f3055c91e819f86081df9b92228a86afb7f0a27165a42690dbeb50f0f1fd1f7180b51809a291c5ff3860e49f888cf0ba87b401d3dda6e271c\n
- GreatVoyage-v4.4.6(David)
FullNode sha256sum:\neaf213f6e6cd9913f9f27bf72a42209c1a0f0fce9841c1d6bd680d879d7d6f85\nFullNode signature:\n064abe833436b3a2e9b66406abf81d12a20f9d28ef669abe7c87c0d750e58cf10c1e65de6fbd0fc368022f93e4c330b42ea9775ead91962480436985c90ad3b11c\nSolidityNode sha256sum:\nc3e9ccc1a4d2aac4c081ae01db86a0901b6f3506e3f8a953315e47ae274a98c1\nSolidityNode signature:\na03d5d6f0e6c6b869f2e545d8c3ff8a4fed569508e9abe4219271d8bf25dfb015e242add8fd2ab6b8b412dd6b393639517957877e8eb7c07ff43a1351a88d62f1b\n
- GreatVoyage-v4.5.1(Tertullian)
FullNode sha256sum:\ndb3c75d7854dcf241558c2942b9a582f478c00a88b6f7a7e5ff8a653a8d4c59a\nFullNode signature:\n61ba205f28c3bc7fa228c27e4e3b4d460ef4fad75ca1d38d82540d45eea2d3d720196b607cd45c560db7a749d05bfe8089c61fba5843e98d61fec90f1591f2861b\nSolidityNode sha256sum:\n537a81bd781d416229de5e0875247160f2569c378c8eed703203d0acca5be5f1\nSolidityNode signature:\na736f9de5425562a2af188c547245f9b4da6d793728bc767242e3df75fa104f61ce978b62fc5cea7f6008bdb51faa9510ff5633702cdb1ddca29cb06a18920d21c\n
- GreatVoyage-v4.5.2 (Aurelius)
FullNode sha256sum:\n60e959ccde3ff90c10b503bb25edf37684845e358df2ad64b2b330712b30c177\nFullNode signature:\nf2f4b6050e639047857c5b5331eb006dcc9c1e0427bac4ae3d934f7436080785472ead691aa16e6a5aed3c2932fb279ce8ab3580449071b878e0d31fdf01f0371c\nSolidityNode sha256sum:\n4783b8abef12a6c7b8319f3e8960c1d3126edcc521ac1fc3429fe2870cab91b0\nSolidityNode signature:\nafb5db2467ce9f5445679df53e2fecfaed3c4a2d0ca2ba88b65e621aa2d37a9e6aab06b30052a9381087d0164cb5c347d710b2b1c59e6f7c7107deacfd1cfc961b\n
- GreatVoyage-v4.6.0 (Socrates)
FullNode sha256sum:\n598589d428085e25c838552970844b0ba00248ad92873bd2ad25b35f37db7a5b\nFullNode signature:\nd3bcfa1bea64b7e58cb94603563cb0c5e47bc20316f61b0dfc966fb64ae846f21b8f917a63328416993f524f4de55ddf5083f163b1fe1b811a9a6f4532725c8e1c\nSolidityNode sha256sum:\nee37a425a84677063b6ea44ed073b8260e336586a61debc10ce0b1544bf7db6a\nSolidityNode signature:\n332c273ef1cdae8dc39c76a83b38750a74b3dd1b915e49698e4ae6870cfed49a1449e8d8db995c7a6be2295e2603efedb0f3e8e906ac7681583c5023b28a521d1b\n
"},{"location":"releases/upgrade-instruction/","title":"New Version Deployment Manual of java-tron","text":"For the mandatory upgrade versions, please strictly follow this guide to deploy the new version. For the non-mandatory upgrade ones, you can decide whether to deploy it according to your needs.
Please directly refer to java-tron New version deployment Process to upgrade your node. If you have deployed 'Active and Backup nodes', please follow the process of Active and Backup Nodes Upgrade Guide.
"},{"location":"releases/upgrade-instruction/#new-version-deployment-process","title":"New version deployment Process","text":"Please follow the below steps to upgrade your FullNode, FullNode that produces blocks to the latest version.
"},{"location":"releases/upgrade-instruction/#1-prepare-the-executable-file-of-the-new-version","title":"1. Prepare the executable file of the new version","text":"You can directly download the java-tron executable file, or download the code of the latest version and compile it to get the executable file of the new version. Please download the latest version of the code or jar file to a file directory other than the java-tron running directory:
-
Way 1: Download the published executable file
Directly download the latest version of the executable file FullNode.jar from the release page https://github.com/tronprotocol/java-tron/releases.
Before using it, please verify the file signature first to ensure the consistency and integrity of the jar file. For the verification steps, please refer to java-tron Consistency Verification.
-
Way 2: Compile the source code
Download the source code and switch to the branch of the new version.
$ git clone https://github.com/tronprotocol/java-tron.git\n$ git checkout -b relase_vx.x.x\n
Compile the project: In the code directory of the new version, execute the following command to compile the project, and the compiled executable file will be generated in the build/libs directory.
$ ./gradlew clean build -x test\n
"},{"location":"releases/upgrade-instruction/#2-shut-down-the-java-tron-process","title":"2. Shut down the java-tron process","text":"Shut down the node process. Note: If a java-tron node has not been deployed on this machine before, please skip to step 5.
-
First, get the process ID of the java-tron node through the following command
$ ps -ef | grep java\n
-
Shut down the node process
$ kill -15 the process id\n
"},{"location":"releases/upgrade-instruction/#3-backup","title":"3. Backup","text":"Please back up the executable file, database, and configuration file before the upgrade in sequence. The backup data is used to restore to the old version when a problem is encountered that leads to fail deploying during the upgrade.
- Backup the current executable jar file
$ mv $JAVA_TRON.jar $JAVA_TRON.jar.`date \"+%Y%m%d%H%M%S\"`\n
- Backup the current database
output-directory $ tar cvzf output-directory.`date \"+%Y%m%d%H%M%S\"`.etgz output-directory\n
- Backup the current configuration file
$ mv $config.conf $config.conf.`date \"+%Y%m%d%H%M%S\"`\n
"},{"location":"releases/upgrade-instruction/#4-replace-old-version-files","title":"4. Replace old version files","text":"After preparing the executable file of the new version and backing up the original node data, please follow the steps below to replace the old files:
- Copy the newest jar package obtained in the previous step to the java-tron working directory to replace the old executable file.
- Replace the old configuration file with the latest configuration file. If you need to modify the configuration, such as adding a keystore file, private key, etc, please modify it yourself.
Note: For the database file, you can use the original database file in the java-tron working directory, or you can choose to use database backup snapshot.
"},{"location":"releases/upgrade-instruction/#5-start-the-nodes","title":"5. Start the nodes","text":"The startup commands of FullNode which produces blocks and ordinary FullNode are different, please choose the startup command according to the actual situation:
-
For the super representative's FullNode, the startup command is:
nohup java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -p private key --witness -c main_net_config.conf </dev/null &>/dev/null &\n
Note: It is not necessary to use the above command parameter to set the private key. If you use the keystore file or configure the private key in the configuration file, please set it up your way. -
For a FullNode, the startup command is:
nohup java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c main_net_config.conf </dev/null &>/dev/null &\n
"},{"location":"releases/upgrade-instruction/#6-wait-for-syncing-completion","title":"6. Wait for syncing completion","text":"After the node is successfully started, please wait patiently for the node block synchronization to complete.
"},{"location":"releases/upgrade-instruction/#7-upgrade-completed","title":"7. Upgrade completed","text":"After the node is synchronized to the latest block of the network, it means that the deployment of the new version is completed.
If you encounter any problems during the upgrade leading to fail deploying the new version, please use the data backed up in the third step to restore to the old version, and give your feedback in GitHub or the community in time to help you complete the deployment of the new version as soon as possible.
"},{"location":"releases/upgrade-instruction/#active-and-backup-nodes-upgrade-guide","title":"Active and Backup Nodes Upgrade Guide","text":"To upgrade the active and backup nodes, please follow the steps below:
-
Upgrade the backup node
Upgrade the backup node according to the java-tron new version deployment Process.
-
Shut down the master node
After the backup node is successfully upgraded to the new version, please wait for the completion of synchronization of the backup node before shutting down the master node. At this time, the backup node will automatically take over from the master node and become the active node.
-
Upgrade the master node
If the backup node works normally, follow java-tron New Version Deployment Process to upgrade the master node. Otherwise, shut down the backup node and start the master node. If an error occurs during the upgrade, please contact TRON technical support team and send the node\u2019s log for root cause analysis.
-
Shut down the backup node
After the master node is upgraded and fully synchronized, shut down the backup node. After the backup node shuts down, the master node will take over as the active node again.
-
Start the backup node
"},{"location":"using_javatron/backup_restore/","title":"Data Backup & Restore","text":"Everything java-tron persists gets written inside its data directory. The default data directory is: /output-directory/. If you need to specify other directories, you can add -d or --output-directory parameter to the java-tron node startup command to specify the data storage location.
$ java -jar fullnode.jar -d ./outputdir\n
"},{"location":"using_javatron/backup_restore/#data-backup","title":"Data Backup","text":"Please shut down the node process before backing up the node data, for details, please refer to the following steps:
First, use the command $ ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}' to get the process id of java-tron, and then use the command kill -15 process id to kill the process. Or use a stop script like this:
#!/bin/bash\nwhile true; do\n pid=`ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}'`\n if [ -n \"$pid\" ]; then\n kill -15 $pid\n echo \"The java-tron process is exiting, it may take some time, forcing the exit may cause damage to the database, please wait patiently...\"\n sleep 1\n else\n echo \"java-tron killed successfully!\"\n break\n fi\ndone\n
Then, backup the data by the following command.
$ tar cvzf output-directory.`date \"+%Y%m%d%H%M%S\"`.etgz output-directory\n
"},{"location":"using_javatron/backup_restore/#data-restore","title":"Data Restore","text":"When restoring the data, just copy the corresponding backup data to the node directory. Take the database backup file name output-directory.20220628152402.etgz as an example, the command to restore the database file is:
$ tar xzvf output-directory.20220628152402.etgz\n
"},{"location":"using_javatron/backup_restore/#public-backup-data","title":"Public Backup Data","text":"For the TRON mainnet and Nile testnet, since the amount of data to be synchronized is large after the new node is started, it takes a long time to synchronize the data. In order to facilitate rapid node deployment for developers, the community provides data snapshots on a regular basis. A data snapshot is a compressed file of the database backup of a TRON network node at a certain time. Developers can download and use the data snapshot to speed up the node synchronization process.
"},{"location":"using_javatron/backup_restore/#main-net-data-snapshot","title":"Main Net Data Snapshot","text":""},{"location":"using_javatron/backup_restore/#fullnode-data-snapshot","title":"FullNode Data Snapshot","text":"The following table shows the download address of Fullnode data snapshots. Please select a suitable data snapshot according to the location and node database type, and whether you need to query historical internal transactions.
Fullnode Data Source Download site Description Official data source (North America: Virginia) http://34.86.86.229/ LevelDB, exclude internal transactions Official data source (Singapore) http://34.143.247.77/ LevelDB, exclude internal transactions Official data source (North America: America) http://35.197.17.205/ RocksDB, exclude internal transactions Official data source (Singapore) http://35.247.128.170/ LevelDB, include internal transactions Official data source ((North America: Virginia)) http://34.48.6.163/ LevelDB, exclude internal transactions, include account history TRX balance Note\uff1aThe data of LevelDB and RocksDB are not allowed to be mixed. The database can be specified in the config file of the full node, set db.engine to LEVELDB or ROCKSDB.
"},{"location":"using_javatron/backup_restore/#lite-fullnode-data-snapshot","title":"Lite FullNode Data Snapshot","text":"The TRON Public Chain has supported the type of the Lite FullNode since the version of GreatVoyage-v4.1.0 release. All the data required by the Lite FullNode for running is whole of the status data and a little essential block data, so, it is much more lightweight (smaller database and faster startup) than the normal FullNode. TRON officially offers database snapshots of the Lite FullNode.
Lite Fullnode Data Source Download site Description Official data source (Singapore) http://34.143.247.77/ LevelDB Tips: You can split the data from the whole data with the help of the Lite FullNode Data Pruning Tool.
"},{"location":"using_javatron/backup_restore/#use-the-data-snapshot","title":"Use the Data Snapshot","text":"The steps for using data snapshots are as follows:
- Download the corresponding compressed backup database according to your needs.
- Decompress the compressed file of the backup database to the output-directory directory or to the corresponding directory according to your needs.
- Startup the node. The node reads the output-directory directory by default. If you need to specify another directory\uff0cplease add the
-d directory parameter when the node starts.
"},{"location":"using_javatron/backup_restore/#nile-testnet-data-snapshot","title":"Nile TestNet Data Snapshot","text":"For detailed information about the Nile TestNet data snapshot, please refer to the official website, for both FullNode and Lite FullNode. The usage method is the same as that of the Main Net.
"},{"location":"using_javatron/connecting_to_tron/","title":"Connect to TRON network","text":"The TRON network is mainly divided into the main network, the Shasta test network, the Nile test network and the private network. Therefore, for the java-tron client software, it can be connected to any TRON network by modifying the configuration items in the configuration file. At present, the Shasta testnet does not support adding a new node, but the Nile testnet supports it.
You need to set the following configuration items to connect java-tron to one of the TRON networks:
node.p2p.version : It is used to set the P2P network id. Only nodes with the same network id can shake hands successfully. - TRON mainnet:
node.p2p.version=11111 - Nile testnet:
node.p2p.version = 201910292 - Private network\uff1aset to other values
seed.node: set seed nodegenesis.block: Genesis block settings. To join a network, please ensure that the settings of the genesis block are the same as those of other nodes in the network, otherwise you cannot join the network.
"},{"location":"using_javatron/connecting_to_tron/#find-peers","title":"Find peers","text":"java-tron continuously attempts to connect to other nodes on the network until it has enough peers, at the same time, it will also accept connections from other nodes. java-tron finds peers using the discovery protocol. In the discovery protocol, nodes exchange connectivity details and then establish sessions and exchange TRON data.
If you want java-tron node to do node discovery, you need to enable the node discovery service in the node configuration file first:
node.discovery = {\n enable = true\n ...\n}\n
Then, for the new node that joins the TRON network, you can configure the seed node to make it easier for the current node to connect to the peer node, and then obtain the address information of other nodes through the peer node. Generally, the seed nodes are set as stable online fullnodes. For the TRON main network, community public nodes can be used as seed nodes, for example: seed.node = {\n # List of the seed nodes\n # Seed nodes are stable full nodes\n\n ip.list = [\n \"3.225.171.164:18888\",\n \"52.53.189.99:18888\",\n \"18.196.99.16:18888\",\n \"34.253.187.192:18888\",\n \"18.133.82.227:18888\",\n \"35.180.51.163:18888\",\n \"54.252.224.209:18888\",\n \"18.231.27.82:18888\",\n \"52.15.93.92:18888\",\n \"34.220.77.106:18888\",\n \"15.207.144.3:18888\",\n \"13.124.62.58:18888\", \n \"54.151.226.240:18888\",\n \"35.174.93.198:18888\",\n \"18.210.241.149:18888\",\n \"54.177.115.127:18888\",\n \"54.254.131.82:18888\",\n \"18.167.171.167:18888\",\n \"54.167.11.177:18888\",\n \"35.74.7.196:18888\",\n \"52.196.244.176:18888\",\n \"54.248.129.19:18888\",\n \"43.198.142.160:18888\",\n \"3.0.214.7:18888\",\n \"54.153.59.116:18888\",\n \"54.153.94.160:18888\",\n \"54.82.161.39:18888\",\n \"54.179.207.68:18888\",\n \"18.142.82.44:18888\",\n \"18.163.230.203:18888\"\n ]\n}\n
There are scenarios where disabling the discovery process is useful, for example for running a local test node or an experimental test network with known, fixed nodes. This can be configured by node.discovery.enable = false to close the node discovery process.
"},{"location":"using_javatron/connecting_to_tron/#peers-limit","title":"Peers limit","text":"node.maxActiveNodes indicates the maximum number of connections between the node and other nodes, the default value is 30. Setting a larger value can enable nodes to establish more connections, join the network more efficiently, and broadcast more efficiently. However, the bandwidth required to maintain the connection is also higher and the performance consumption is higher. Therefore, please set it according to the actual situation.
node {\n maxActiveNodes = 30\n}\n
"},{"location":"using_javatron/connecting_to_tron/#active-and-passive-connections","title":"Active and passive connections","text":"java-tron supports setting its actively connected nodes node.active as well as passively connected nodes node.passive. Configuring node.active and node.passive can greatly help improve the stability of the network connection of the node.
When java-tron starts, it will actively establish a connection with the peer node in node.active.
node {\n active = [\n # Active establish connection in any case\n # Sample entries:\n # \"ip:port\",\n # \"ip:port\"\n ]\n }\n
When a node in node.passive actively establishes a connection with the current node, the current node will accept it unconditionally.
node {\n passive = [\n # Passive accept connection in any case\n # Sample entries:\n # \"ip:port\",\n # \"ip:port\"\n ]\n }\n
"},{"location":"using_javatron/connecting_to_tron/#log-and-network-connection-verification","title":"Log and network connection verification","text":"The java-tron node log is /logs/tron.log in the java-tron installation directory. Under the java-tron installation directory, you can use the following commands to view the latest log of the node and check the block synchronization status of the node:
$ tail -f /logs/tron.log/\n
You will see the below block synchronization logs if java-tron is running as expected.
15:41:48.033 INFO [nioEventLoopGroup-6-2] [DB](Manager.java:1208) pushBlock block number:76, cost/txs:13/0 false\n15:41:48.033 INFO [nioEventLoopGroup-6-2] [net](TronNetDelegate.java:255) Success process block Num:76,ID:000000000000004c9e3899ee9952a7f0d9e4f692c7070a48390e6fea8099432f.\n
For the super representative's fullnode, you will see the following producing blocks log: 02:31:33.008 INFO [DPosMiner] [DB](Manager.java:1383) Generate block 79336 begin\n02:31:33.059 INFO [DPosMiner] [DB](SnapshotManager.java:315) flush cost:51, create checkpoint cost:49, refresh cost:2\n02:31:33.060 INFO [DPosMiner] [DB](Manager.java:1492) Generate block 79336 success, trxs:0, pendingCount: 0, rePushCount: 0, postponedCount: 0\n
If no error messages are reported in the node logs, means everything is fine. You can also send an http request to check whether the node has been started, and to view the status of the node: including the node configuration information, the information about the machine where the node is located, the connection status of the node peers, etc. $ curl http://127.0.0.1:16887/wallet/getnodeinfo\n
Returns\uff1a
{\n \"activeConnectCount\": 3,\n \"beginSyncNum\": 42518346,\n \"block\": \"Num:42518365,ID:000000000288c75d1967232f1efe606ff90b9dd76660d7de8cc091849be6bf10\",\n \"cheatWitnessInfoMap\": {\n ...\n },\n \"configNodeInfo\": {\n ...\n \"codeVersion\": \"4.5.1\",\n \"dbVersion\": 2,\n \"discoverEnable\": true,\n \"listenPort\": 18888,\n ...\n },\n \"currentConnectCount\": 18,\n \"machineInfo\": {\n ...\n },\n \"passiveConnectCount\": 15,\n \"peerList\": [\n ...\n ],\n \"solidityBlock\": \"Num:42518347,ID:000000000288c74b723398aef104c585bad1c7cbade7793c5551466bd916feee\",\n \"totalFlow\": 8735314\n}\n
In order for users to interact with the TRON network, the java-tron node must be running and in a normal state of synchronization. Whether the node is synchronized with other nodes in the network, you can query the current block height in Tronscan and compare it with the result of /wallet/getnowblock queried from the local java-tron node. If they are equal, it means that the synchronization status of the local node is normal."},{"location":"using_javatron/connecting_to_tron/#connection-problems","title":"Connection problems","text":"There are occasions when java-tron simply fails to connect to peers. The common reasons for this are:
- Local time might be incorrect. An accurate clock is required to participate in the TRON network. The local clock can be resynchronized using commands such as
sudo ntpdate -s time.nist.gov. - Some firewall configurations can prohibit UDP traffic. But the node discovery service is based on the UDP protocol, so you can make it possible to let the node connect to the network by configuring
node.active in the case of node discovery invalid. - By configuring
node.passive to accept active connections from trusted nodes. - The Shasta testnet does not currently support nodes joining the network. If you need to run nodes to join the public testnet, you can choose the Nile testnet.
"},{"location":"using_javatron/connecting_to_tron/#connect-to-private-network","title":"Connect to private network","text":"It is often useful for developers to connect to private test networks rather than public testnets or TRON mainnet. Because the private chain not only has no requirements for machine configuration, but also in the sandbox environment of the private chain network, it is easier to test various functions, and it gives freedom to break things without real-world consequences.
The private chain network needs to configure the configuration item node.p2p.version in the private chain configuration file to a value which is not used by any other existing public network (TRON mainnet, testnet). For detailed instructions on private chain construction, please refer to Private Chain Network.
"},{"location":"using_javatron/installing_javatron/","title":"Deploy a java-tron Node","text":"java-tron nodes support to be deployed on Linux or MacOS operating systems, and rely on Oracle JDK 1.8, other versions of JDK are not supported.
The minimum hardware configuration required to run a java-tron node is 8-core CPU, 16G memory, 3T SDD, the recommended configuration is: 16-core CPU, 32G memory, 3.5T+ SDD. The fullnode running by super representative to produce block recommends 32-core CPU and 64G memory.
"},{"location":"using_javatron/installing_javatron/#compile-the-source-code","title":"Compile the Source Code","text":"First, clone the java-tron repository to the local with the following git command, and switch to the master branch. Before executing the command, make sure you have installed the git tool.
$ git clone https://github.com/tronprotocol/java-tron.git\n$ git checkout -t origin/master\n
Then, compile the java-tron source code by executing the following command. The parameter -x test means to skip the execution of the test case. You can also remove this parameter to execute the test code during the compilation process, which will make the compilation time longer. After the compilation is complete, FullNode.jar will be generated in the java-tron/build/libs/ directory.
$ cd java-tron\n$ ./gradlew clean build -x test\n
"},{"location":"using_javatron/installing_javatron/#startup-a-java-tron-node","title":"Startup a java-tron Node","text":"You can choose different configuration files to connect java-tron nodes to different networks. The mainnet configuration file is: main_net_config.conf, other network configuration files can be found here.
"},{"location":"using_javatron/installing_javatron/#startup-a-fullnode","title":"Startup a fullnode","text":"Fullnode has full historical data, it is the entry point into the TRON network , it provides HTTP API and gRPC API for external query. You can interact with the TRON network through fullnode\uff1atransfer assets, deploy contracts, interact with contracts and so on. The mainnet fullnode startup command is as follows, and the configuration file of the fullnode is specified by the -c parameter:
$ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c main_net_config.conf\n
- -XX:+UseConcMarkSweepGC \uff1aSpecifies parallel garbage collection. To be placed before the -jar parameter, not at the end.
- -Xmx \uff1aThe maximum value of the JVM heap, which can be set to 80% of the physical memory.
"},{"location":"using_javatron/installing_javatron/#startup-a-fullnode-that-produces-blocks","title":"Startup a fullnode that produces blocks","text":"Adding the --witness parameter to the startup command, fullnode will run as a node which produces blocks. In addition to supporting all the functions of fullnode, the block-producing fullnode also supports block production and transaction packaging. Please make sure you have a super representative account and get the votes of others. If the votes ranks in the top 27, you need to start a full node that produces blocks to participate in block production.
Fill in the private key of the super representative address into the localwitness list in the main_net_config.conf, below is an example. But if you don't want to use this way of specifying the private key in plain text, you can use the keystore + password method, please refer to Others chapter.
localwitness = [\n 650950B193DDDDB35B6E48912DD28F7AB0E7140C1BFDEFD493348F02295BD812\n]\n
then run the following command to start the node:
$ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar --witness -c main_net_config.conf\n
Note: For the mainnet and nile testnet, since the amount of data to be synchronized is large after the new node is started, it will take a long time to synchronize the data. You can use Data Snapshots to speed up node synchronization. First download the latest data snapshot and extract it to the output-directory directory of the TRON project, and then start the node, so that the node will synchronize on the basis of the data snapshot.
"},{"location":"using_javatron/installing_javatron/#others","title":"Others","text":""},{"location":"using_javatron/installing_javatron/#how-to-use-keystore-password-to-specify-the-privatekey-of-witness-account","title":"How to use keystore + password to specify the privatekey of witness account","text":" - You should not use the nohup command because the interaction is required when running the node. It is recommended to use session keeping tools such as screen, tmux, etc.
- Comment the
localwitness item in main_net_config.conf and uncomment the localwitnesskeystore item. Fill in the path of the Keystore file. Note that the Keystore file needs to be placed in the current directory where the startup command is executed or its subdirectory. If the current directory is \"A\", the directory of the Keystore file is \"A/B/localwitnesskeystore.json\", it needs to be configured as: localwitnesskeystore = [\n \"B/localwitnesskeystore.json\"\n]\n
Note: For keystore + password generation, you can use the register wallet command of the wallet-cli. - Startup the fullnode which produces blocks
$ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar --witness -c main_net_config.conf\n
- Enter the password correctly to finish the node startup.
"},{"location":"using_javatron/installing_javatron/#optimize-memory-allocation-with-tcmalloc","title":"Optimize Memory Allocation with tcmalloc","text":"Memory allocation of java-tron can be optimized with tcmalloc. The method is as follows:
First install tcmalloc, then add the following two lines to the startup script, the path of tcmalloc is slightly different for different Linux distributions.
#!/bin/bash\n\nexport LD_PRELOAD=\"/usr/lib/libtcmalloc.so.4\"\nexport TCMALLOC_RELEASE_RATE=10\n\n# original start command\njava -jar .....\n
Instructions for each Linux distributions are as belows:
-
Ubuntu 20.04 LTS / Ubuntu 18.04 LTS / Debian stable Install
$ sudo apt install libgoogle-perftools4\n
In the startup script add the following:
export LD_PRELOAD=\"/usr/lib/x86_64-linux-gnu/libtcmalloc.so.4\"\nexport TCMALLOC_RELEASE_RATE=10\n
-
Ubuntu 16.04 LTS Same install command as above. In the startup script add the following:
export LD_PRELOAD=\"/usr/lib/libtcmalloc.so.4\"\nexport TCMALLOC_RELEASE_RATE=10\n
-
CentOS 7 Install
$ sudo yum install gperftools-libs\n
In the startup script add the following: export LD_PRELOAD=\"/usr/lib64/libtcmalloc.so.4\"\nexport TCMALLOC_RELEASE_RATE=10\n
"},{"location":"using_javatron/litefullnode/","title":"Lite FullNode","text":"Lite FullNode runs the same code with FullNode, the difference is that Lite FullNode only starts based on state data snapshot, which only contains all account state data and historical data of the latest 65536 blocks. The state data snapshot is small, only about 3% of the FullNode data. Therefore, Lite Fullnode has the advantages of occupying less disk space and starting up fast, but it does not provide historical block and transaction data query by default, and only provides part of HTTP API and GRPC API of FullNode. For APIs that are not supported by Lite Fullnode, please refer to HTTP, GRPC. But these APIs can be opened by configuring openHistoryQueryWhenLiteFN = true in the configuration file, because after the Lite Fullnode startup, the saved data by the Lite Fullnode is exactly the same as that of the FullNode, so after this configuration item is turned on, the Lite Fullnode supports querying the block data synchronized after the node startup, but still does not support querying the block data before the node startup.
Therefore, if developers only need to use node for block synchronization, processing and broadcasting transactions, or only query the blocks and transactions synchronized after the node starts up, then Lite Fullnoe will be a better choice.
"},{"location":"using_javatron/litefullnode/#lite-fullnode-deployment","title":"Lite FullNode Deployment","text":"The deployment steps and startup command of a Lite fullnode are the same as fullnode's, please refer to Deployment Instructions to deploy a Lite Fullnode. The only difference is the database. You need to obtain the Lite Fullnode database. You can download the Lite Fullnode data snapshot from the public backup data and use it directly; or use the Lite Fullnode data pruning tool to convert the Fullnode database to Lite Fullnode database.
"},{"location":"using_javatron/litefullnode/#lite-fullnode-maintenance","title":"Lite FullNode Maintenance","text":"Since the Lite Fullnode will save the same data as the FullNode's after startup, although the data volume of the Lite Fullnode is very small at startup, the data expansion rate in the later period is the same as that of the FullNode, so it may be necessary to periodically cut the data. Pruning Lite Fullnode data is also to use Lite Fullnode data pruning tool to split Lite Fullnode data into snapshot dataset, that is, to obtain the pruned Lite Fullnode data.
"},{"location":"using_javatron/metrics/","title":"java-tron Node Metrics Monitoring","text":"Starting from the GreatVoyage-4.5.1 (Tertullian) version, the node provides a series of interfaces compatible with the prometheus protocol, so that the node deployer can monitor the health status of the node more conveniently. If you want to monitor various indicators of the node, you first need to deploy a prometheus service to communicate with the java-tron node, and obtain the indicator data of the node through the node interface. Then you need to deploy a visualization tool, such as Grafana, to display the node data obtained by prometheus in the form of a graphical interface. The following will introduce the deployment process of the java-tron node monitoring system in detail.
"},{"location":"using_javatron/metrics/#configure-java-tron","title":"Configure java-tron","text":"To use the Prometheus tool to monitor the java-tron node, you first need to enable prometheus metric monitoring in the node configuration file and set the http port:
node {\n ... ...\n p2p {\n version = 11111 # 11111: mainnet; 20180622: testnet\n }\n ####### add for prometheus start.\n metrics{\n prometheus{\n enable=true \n port=\"9527\"\n }\n }\n ####### add for prometheus end.\n}\n
"},{"location":"using_javatron/metrics/#start-java-tron-node","title":"Start java-tron node","text":"Start java-tron node using below command\uff1a
$ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c main_net_config.conf\n
"},{"location":"using_javatron/metrics/#deploy-prometheus-service","title":"Deploy prometheus service","text":"prometheus officially provides precompiled binaries and docker images, you can download them directly from the official website or pull the docker images on dockerhub. For more detailed installation and configuration instructions, Please refer to the prometheus documentation. As a simple deployment instruction, this article will adopt the docker image deployment:
-
After installing docker, enter the following command to pull the prometheus image:
$ docker pull prom/prometheus\n
-
Download the prometheus configuration file
The following is a prometheus configuration file template prometheus.yaml:
global:\n scrape_interval: 30s\n scrape_timeout: 10s\n evaluation_interval: 30s\nscrape_configs:\n- job_name: java-tron\n honor_timestamps: true\n scrape_interval: 3s\n scrape_timeout: 2s\n metrics_path: /metrics\n scheme: http\n follow_redirects: true\n static_configs:\n - targets:\n - 127.0.0.1:9527\n labels:\n group: group-xxx\n instance: xxx-01\n - targets:\n - 172.0.0.2:9527\n labels:\n group: group-xxx\n instance: xxx-02\n
You can download and use this template and modify the configuration items targets, it is used to configure the ip and prometheus port of the java-tron node. If you deploy multiple java-tron nodes, you can configure multiple targets to monitor multiple nodes. -
Start a Prometheus container
Start a Prometheus container with the following command and specify to use the user-defined configuration file in the previous step:/Users/test/deploy/prometheus/prometheus.yaml
$ docker run --name prometheus \\\n -d -p :9090:9090 \\\n -v /Users/test/deploy/prometheus/prometheus.yaml:/etc/prometheus/prometheus.yml \\\n prom/prometheus:latest\n
After the container starts, you can view the running status of the prometheus service through http://localhost:9090/.
Click \"Status\" -> \"Configuration\" to check whether the configuration file used by the container is correct:
Click \"Status\" -> \"Targets\" to view the status of each monitored java-tron node:
In this example, the status of the first endpoint is UP, which means that Prometheus can fetch the data of this node normally. The second endpoint, whose status is DOWN, indicates an exception. For details, please refer to the description in \"Error\".
When the status of the monitored java-tron nodes is normal, you can monitor the indicator data through visualization tools such as Grafana or Promdash, etc. This article will use grafana to display the data:
"},{"location":"using_javatron/metrics/#deploy-grafana","title":"Deploy Grafana","text":"The deployment process of the Grafana visualization tool is as follows:
-
Install Grafana Please refer to the official documentation to install Grafana. This article will adopt the docker image deployment, and the pulled image version is the open source version:
$ docker pull grafana/grafana-oss\n
-
Start Grafana
You can use the below command to start Grafana:
$ docker run -d --name=grafana -p 3000:3000 grafana/grafana-oss\n
-
Log in to the Grafana web UI
After startup, you can login the Grafana web UI through http://localhost:3000/. The initial user name and password are both admin. After login, change the password according to the prompts, and then you can enter the main interface. Click the settings icon on the left side of the main page and select \"Data Sources\" to configure Grafana's data sources:
Enter the ip and port of the prometheus service in URL:
Then click the \"Save & test\" button at the bottom of the page to save the settings. After clicking save, Grafana will detect the connection with the data source, and if the connection is successful, you will find the words Data source is working.
-
Import Dashboard
Grafana's dashboard needs to be configured. For the convenience of java-tron node deployers, the TRON community provides a comprehensive dashboard configuration file java-tron-template_rev1.json, which you can download directly and then import into Grafana.
Click the Dashboards icon on the left, then select \"+Import\", then click \"Upload JSON file\" to import the downloaded dashboard configuration file:
Then you can see the following types of monitoring metrics on the dashboard, and monitor the running status of the nodes in real time:
"},{"location":"using_javatron/private_network/","title":"Private Network","text":"To build a private chain, it is necessary to deploy at least one fullnode running by SR to produces blocks, and any number of fullnodes to synchronize blocks and broadcast transactions. Only one SR node and one fullnode are set up in this example. Before the deployment, please install the Oracle JDK 1.8 first, and then you need to prepare at least two TRON network address and save the address and private key. You can use wallet-cli or Tronlink to create address.
"},{"location":"using_javatron/private_network/#deployment-guide","title":"Deployment Guide","text":"The process of building a node on private chain is the same as that on mainnet. The difference is the content of the node configuration file. The most important step to build a private chain is to modify the configuration items in the configuration file, so that the nodes can form a private network for node discovery, block synchronization and broadcast transactions.
-
Create deployment directory
Create deployment directory, it is recommended to put the two fullnodes in different directories.
$ mkdir SR\n$ mkdir FullNode\n
-
Obtain FullNode.jar
Obtain FullNode.jar, then put it into the SR and FullNode directories respectively.
$ cp FullNode.jar ./SR\n$ cp FullNode.jar ./FullNode\n
-
Obtain the node's config file private_net_config.conf
Obtain the node's config file private_net_config.conf, then put it into the SR and FullNode directories respectively, and modify the file names respectively to supernode.conf, fullnode.conf.
$ cp private_net_config.conf ./SR/supernode.conf\n$ cp private_net_config.conf ./FullNode/fullnode.conf\n
-
Modify the configuration file of each node
Please modify each configuration item of the node in turn according to the instructions in the following table:
Config Item SR Fullnode FullNode Description localwitness The private key of witness address Please do not fill in data Generating blocks requires signing with a private key genesis.block.witnesses Witness address The same as SR node's Genesis block related configuration genesis.block.Assets Preset TRX for specific accounts. Add the pre-prepared address to the end and specify its TRX balance as needed The same as SR node's Genesis block related configuration p2p.version any positive integer except for 11111 the same as SR node's Only nodes of the same p2p version can shake hands successfully seed.node Please do not fill in data Change the seed.node ip.list in the configuration file to the IP address and the port (listen.port) of the SR Enables fullnode to establish connection with SR node and synchronize data needSyncCheck false true Set the first SR\u2019s needSyncCheck to false, other SRs true node.discovery.enable true true If it is false, the current node will not be discovered by other nodes block.proposalExpireTime 600000 The same as SR node's The default proposal effective time is 3 days: 259200000 (ms), if you want to quickly pass the proposal, you can set this item to a smaller value, such as 10 minutes, that is, 600000ms block.maintenanceTimeInterval 300000 The same as SR node's The default maintenance time interval is 6 hours: 21600000 (ms), if you want to pass the proposal quickly, you can set this item to a smaller value, such as five minutes, that is, 300000ms. committee.allowSameTokenName 1 1 Allow same token name committee.allowTvmTransferTrc10 1 1 Allow tvm transfer TRC10 -
Modify the port in the configuration file, and configure the SR and FullNode with different port numbers. Note, this step is only required if SR and FullNode are running on the same machine, otherwise, this step can be skipped.
listen.port \uff1a p2p listen porthttp port\uff1a Http listen portrpc port\uff1a rpc listen port
-
Startup the node
The fullnode that produces blocks has the different startup command with the fullnodes that do not produce blocks:
- Fullnode that produces blocks
$ java -Xmx6g -XX:+HeapDumpOnOutOfMemoryError -jar FullNode.jar --witness -c supernode.conf\n
- Fullnode
$ java -Xmx6g -XX:+HeapDumpOnOutOfMemoryError -jar FullNode.jar -c fullnode.conf\n
-
Modify the dynamic parameters of the private chain
Dynamic parameters can be obtained by getchainparameters. The main network's current dynamic parameters and committee proposals related to them can be seen here, dynamic parameters are called network parameters here.
If you want all the dynamic parameters of your private network to be the same with the main network, maybe dbfork which could capture the latest status of Mainnet is what you are interested in.
If you want to modify part of dynamic parameters, there are two ways to choose from:
-
Configure File Some dynamic parameters can be directly set through configure file. These dynamic parameters can be seen here. Below is an example of modifying dynamic parameters through configure file.
committee = {\n allowCreationOfContracts = 1\n allowAdaptiveEnergy = 0\n allowMultiSign = 1\n allowDelegateResource = 1\n allowSameTokenName = 0\n allowTvmTransferTrc10 = 1\n}\n
-
Proposal Any witness(SR, SR partner, SR candidate) is entitled to create a proposal, SRs also have the right to vote for the proposal. A witness uses proposalcreate to create a proposal, and then SRs use proposalapprove to approve the proposal(Proposals only support voting for yes, super representatives do not vote means they do not agree with the proposal). Below is an code example of modifying two dynamic parameters through a committee proposal. In proposalcreate, dynamic parameters are represented by numbers, the mapping between number and string name of dynamic parameters can be seen here.
var TronWeb = require('tronweb');\nvar tronWeb = new TronWeb({\n fullHost: 'http://localhost:16887',\n privateKey: 'c741f5c0224020d7ccaf4617a33cc099ac13240f150cf35f496db5bfc7d220dc'\n})\n\nvar parametersForProposal1 = [{\"key\":9,\"value\":1},{\"key\":10,\"value\":1}];\n\nasync function modifyChainParameters(parameters,proposalID){\n\n parameters.sort((a, b) => {\n return a.key.toString() > b.key.toString() ? 1 : a.key.toString() === b.key.toString() ? 0 : -1;\n })\n var unsignedProposal1Txn = await tronWeb.transactionBuilder.createProposal(parameters,\"41D0B69631440F0A494BB51F7EEE68FF5C593C00F0\")\n var signedProposal1Txn = await tronWeb.trx.sign(unsignedProposal1Txn);\n var receipt1 = await tronWeb.trx.sendRawTransaction(signedProposal1Txn);\n\n setTimeout(async function() {\n console.log(receipt1)\n console.log(\"Vote proposal 1 !\")\n var unsignedVoteP1Txn = await tronWeb.transactionBuilder.voteProposal(proposalID, true, tronWeb.defaultAddress.hex)\n var signedVoteP1Txn = await tronWeb.trx.sign(unsignedVoteP1Txn);\n var rtn1 = await tronWeb.trx.sendRawTransaction(signedVoteP1Txn);\n }, 1000)\n\n}\n\nmodifyChainParameters(parametersForProposal1, 1)\n
After creating the proposal through the above code, you can check whether the proposal has been approved through listproposals interface. If the \"state\" in the return value of the interface is \"APPROVED\" When expiration time of the proposal has passed, it means that the proposal has been approved. It should be noted that dynamic parameters with interdependent relationships cannot be included in one proposal, the correct approach is to separate them into different proposals and pay attention to order of them.
"},{"location":"using_javatron/toolkit/","title":"java-tron Node Maintenance Tool - Toolkit","text":"The Toolkit integrates a series of tools of java-tron, and more functions will be added into it in the future for the convenience of developers. Currently Toolkit includes the following functions:
- Database Partition Tool
- Lite Fullnode Data Pruning
- Data Copy
- Data Conversion
- LevelDB Startup Optimization
The following describes the acquisition and use of the Toolkit toolbox in detail.
"},{"location":"using_javatron/toolkit/#obtain-toolkitjar","title":"Obtain Toolkit.jar","text":"Toolkit.jar can be obtained from the released version directly or by compiling the java-tron source code.
Compile the source code:
- Obtain java-tron source code
$ git clone https://github.com/tronprotocol/java-tron.git\n$ git checkout -t origin/master\n
- Compile
$ cd java-tron\n$ ./gradlew clean build -x test\n
You will find the Toolkit.jar under ./java-tron/build/libs/ folder if build is successful."},{"location":"using_javatron/toolkit/#database-partition-tool","title":"Database Partition Tool","text":"As the data on the chain continues to grow, the pressure on data storage will increase. At present, the FullNode data of the TRON public chain has reached 1T, and the daily data growth is about 1.2G. According to the current data growth rate, the annual growth rate is about 450G. A single disk capacity may be insufficient and need to be replaced by a larger disk. To this end the Toolkit toolbox introduces the database storage partitioning tool. The tool can migrate some databases to other storage disks. When the user encounters insufficient disk space, he only needs to add another disk according to the capacity requirement and does not need to replace the original disk.
"},{"location":"using_javatron/toolkit/#commands-and-parameters","title":"Commands and parameters","text":"To use the data partition function provided by Toolkit through the db mv command:
# full command\njava -jar Toolkit.jar db mv [-h] [-c=<config>] [-d=<database>]\n# examples\njava -jar Toolkit.jar db mv -c main_net_config.conf -d /data/tron/output-directory\n
Optional command parameters are as follows:
-c | --config: [ string ] This option is used to specify the FullNode configuration file. If not specified, the default value will be config.conf.-d | --database-directory: [ string ] This option is used to specify the FullNode database directory. If not specified, the default value will be output-directory.-h | --help: [ bool ] This option is used to view help description, default value: false.
"},{"location":"using_javatron/toolkit/#usage-instructions","title":"Usage Instructions","text":"Follow the following steps to use the database partition tool:
- Stop FullNode service
- Configure for database storage migration
- Perform database migration
- Restart FullNode service
"},{"location":"using_javatron/toolkit/#stop-fullnode-service","title":"Stop FullNode Service","text":"Use the command kill -15 pid to close FullNode.jar, below is the FullNode process pid lookup command:
$ ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}'`\n
"},{"location":"using_javatron/toolkit/#configure-for-database-storage-migration","title":"Configure For Database Storage Migration","text":"The configuration of database migration is in the storage.properties field in the java-tron node configuration file. The following is an example of migrating only the block and trans databases to illustrate how to migrate some databases to other storage disks:
storage {\n ......\n properties = [\n {\n name = \"block\",\n path = \"/data1/tron\",\n\n },\n {\n name = \"trans\",\n path = \"/data1/tron\",\n }\n ]\n ......\n}\n
name is the database name which you want to migrate, and path is the destination directory for database migration. The tool will migrate the database specified by name to the directory specified by path, and then create a soft link under the original path pointing to path directory. After FullNode starts, it will find the path directory according to the soft link."},{"location":"using_javatron/toolkit/#perform-database-migration","title":"Perform Database Migration","text":"When executed, the current migration progress will be shown.
$ java -jar Toolkit.jar db mv -c main_net_config.conf -d /data/tron/output-directory\n
"},{"location":"using_javatron/toolkit/#restart-fullnode-service","title":"Restart FullNode Service","text":"After the migration is complete, restart the java-tron node.
# FullNode\n$ nohup java -Xms9G -Xmx9G -XX:ReservedCodeCacheSize=256m \\\n -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m \\\n -XX:MaxDirectMemorySize=1G -XX:+PrintGCDetails \\\n -XX:+PrintGCDateStamps -Xloggc:gc.log \\\n -XX:+UseConcMarkSweepGC -XX:NewRatio=2 \\\n -XX:+CMSScavengeBeforeRemark -XX:+ParallelRefProcEnabled \\\n -XX:+HeapDumpOnOutOfMemoryError \\\n -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 \\\n -jar FullNode.jar -c main_net_config.conf >> start.log 2>&1 &\n\n# Super representative's FullNode\n$ nohup java -Xms9G -Xmx9G -XX:ReservedCodeCacheSize=256m \\\n -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m \\\n -XX:MaxDirectMemorySize=1G -XX:+PrintGCDetails \\\n -XX:+PrintGCDateStamps -Xloggc:gc.log \\\n -XX:+UseConcMarkSweepGC -XX:NewRatio=2 \\\n -XX:+CMSScavengeBeforeRemark -XX:+ParallelRefProcEnabled \\\n -XX:+HeapDumpOnOutOfMemoryError \\\n -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 \\\n -jar FullNode.jar --witness -c main_net_config.conf >> start.log 2>&1 &\n
"},{"location":"using_javatron/toolkit/#lite-fullnode-data-pruning","title":"Lite Fullnode Data Pruning","text":"Toolkit provides data pruning tool, which is mainly used for generating or pruning Lite Fullnode data.
The data pruning tool can divide the complete FullNode data into a snapshot dataset (Snapshot dataset) or a historical dataset (History dataset) according to the current latest_block_number, the snapshot dataset is used to start the Lite Fullnode (That is the Lite fullnode database), and the historical dataset is used for historical data query. Lite Fullnode started with a snapshot data set do not support querying historical data prior to the latest block height at the time of pruning. The data pruning tool also provides the function of merging historical data set with snapshot data set. The usage scenarios are as follows:
-
Convert FullNode data into Lite Fullnode data
The Lite Fullnode starts only based on the snapshot data set, use the data pruning tool to convert the full node data into the snapshot data set, and that will get the Lite Fullnode data
-
Prune Lite Fullnode data regularly
Since the Lite Fullnode saves the same data as the FullNode after startup, although the data volume of the Lite Fullnode is very small at startup, the data expansion rate in the later period is the same as that of the FullNode, so it may be necessary to periodically prune the data. Clipping the Lite Fullnode data is also to use this tool to cut the Lite Fullnode data into snapshot data set, that is, to obtain the Pruned Lite Fullnode data
-
Convert Lite Fullnode data back to FullNode data
Since Lite Fullnode does not support historical data query, if you want to support it, you need to change Lite Fullnode data into FullNode data, then the node will change from Lite Fullnode to FullNode. You can directly download the snapshot of the FullNode database, or you can use the data pruning tool: first, convert the FullNode data into historical data set, and then merge the historical data set and the snapshot data set of the Lite Fullnode to obtain the FullNode data.
Note: Before using this tool for any operation, you need to stop the currently running node first.
"},{"location":"using_javatron/toolkit/#command-and-parameters","title":"Command and parameters","text":"To use the data pruning tool provided by Toolkit through the db lite command:
# full command\n java -jar Toolkit.jar db lite [-h] -ds=<datasetPath> -fn=<fnDataPath> [-o=<operate>] [-t=<type>]\n# examples\n #split and get a snapshot dataset\n java -jar Toolkit.jar db lite -o split -t snapshot --fn-data-path output-directory/database --dataset-path /tmp\n #split and get a history dataset\n java -jar Toolkit.jar db lite -o split -t history --fn-data-path output-directory/database --dataset-path /tmp\n #merge history dataset and snapshot dataset\n java -jar Toolkit.jar db lite -o merge --fn-data-path /tmp/snapshot --dataset-path /tmp/history\n
Optional command parameters are as follows:
--operation | -o: [ split | merge ], this parameter specifies the operation as either to split or to merge, default is split.--type | -t: [ snapshot | history ], this parameter is used only when the operation is split. snapshot means clip to Snapshot Dataset and history means clip to History Dataset. Default is snapshot.--fn-data-path | -fn: The database path to be split or merged. When the operation type is split, fn-data-path is used to indicate the directory of the data to be pruned; when the operation type is merge, fn-data-path indicates the database directory of the Lite Fullnode or the directory of the snapshot dataset.--dataset-path | -ds: When operation is split, dataset-path is the path that store the snapshot or history, when operation is merge, dataset-path is the history data path.
"},{"location":"using_javatron/toolkit/#usage-instructions_1","title":"Usage Instructions","text":"The node database is stored in the output-directory/database directory by default. The examples in this chapter will be explained with the default database directory.
The following three examples illustrate how to use the data pruning tool:
-
Split and get a Snapshot Dataset
This function can split FullNode data into Lite Fullnode data, and can also be used to regularly trim Lite Fullnode data. The steps are as follows:
First, stop the FullNode and execute:
# just for simplify, save the snapshot into /tmp directory\njava -jar Toolkit.jar db lite -o split -t snapshot --fn-data-path output-directory/database --dataset-path /tmp\n
- --fn-data-path\uff1a The data directory to be trimmed, that is, the node data directory
- --dataset-path\uff1a The directory where the output snapshot dataset is stored
After the command is executed, a snapshot directory will be generated in /tmp, the data in this directory is the Lite Fullnode data, then rename the directory from snapshot to database (the default value of the storage.db.directory is database, make sure rename the snapshot directory to the specified value) and copy the database directory to the Lite Fullnode database directory to finish the splitting. Finally start the Lite Fullnode.
-
Split and get a History Dataset
The command to split the historical data set is as follows:
# just for simplify, save the history into `/tmp` directory,\njava -jar Toolkit.jar db lite -o split -t history --fn-data-path output-directory/database --dataset-path /tmp\n
- --fn-data-path\uff1a FullNode data directory
- --dataset-path\uff1a The directory where the output historical dataset is stored
After the command is executed, the history directory will be generated under the /tmp directory, and the data in it is the historical dataset.
-
Merge History Dataset and Snapshot Dataset
Both History Dataset and Snapshot Dataset have an info.properties file to identify the block height when they are split. Make sure that the split_block_num in History Dataset is not less than the corresponding value in the Snapshot Dataset. After the historical dataset is merged with the snapshot dataset through the merge operation, the Lite Fullnode will become a real FullNode.
The command to merge the historical dataset and the snapshot dataset is as follows:
# just for simplify, assume `History dataset` is locate in /tmp\njava -jar Toolkit.jar db lite -o merge --fn-data-path /tmp/snapshot --dataset-path /tmp/history\n
- --fn-data-path\uff1a snapshot dataset directory
- --dataset-path\uff1a history dataset directory
After the command is executed, the merged data will overwrite the directory where the snapshot data set is located, that is, the directory specified by --fn-data-path, copy the merged data to the node database directory, and the Lite Fullnode becomes a FullNode.
"},{"location":"using_javatron/toolkit/#data-copy","title":"Data Copy","text":"The node database is large, and the database copy operation is time-consuming. The Toolkit provides a fast database copy function, which can quickly copy the LevelDB or RocksDB database in the same file system by creating a hard link.
"},{"location":"using_javatron/toolkit/#command-and-parameters_1","title":"Command and parameters","text":"To use the data copy function provided by Toolkit through db copy :
# full command\n java -jar Toolkit.jar db cp [-h] <src> <dest>\n# examples\n java -jar Toolkit.jar db cp output-directory/database /tmp/database\n
Optional command parameters are as follows:
<src>: Source path for database. Default: output-directory/database<dest>: Output path for database. Default: output-directory-cp/database-h | --help\uff1a[ bool ] provide the help info. Default: false
Note: Before using this tool for any operation, you need to stop the currently running node first.
"},{"location":"using_javatron/toolkit/#data-conversion","title":"Data Conversion","text":"Toolkit supports database data conversion function, which can convert LevelDB data into RocksDB data.
"},{"location":"using_javatron/toolkit/#command-and-parameters_2","title":"Command and parameters","text":"To use the data conversion function provided by Toolkit through db convert command:
# full command\n java -jar Toolkit.jar db convert [-h] [--safe] <src> <dest>\n# examples\n java -jar Toolkit.jar db convert output-directory/database /tmp/database\n
Optional command parameters are as follows:
<src>: Input path for leveldb, default: output-directory/database.<dest>: Output path for rocksdb, default: output-directory-dst/database.--safe\uff1aIn safe mode, read data from leveldb then put into rocksdb, it's a very time-consuming procedure. If not, just change engine.properties from leveldb to rocksdb, rocksdb is compatible with leveldb for the current version. This may not be the case in the future, default: false.-h | --help\uff1a[ bool ] Provide the help info, default: false\u3002
Note: Before using this tool for any operation, you need to stop the currently running node first.
"},{"location":"using_javatron/toolkit/#leveldb-startup-optimization","title":"LevelDB Startup Optimization","text":"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, moreover, there may be an issue that the service is terminated abnormally due to the continuous growth of memory. To solve this issue, toolkit provides the leveldb startup optimization tool. The tool optimizes the file size of the manifest and the startup process of LevelDB, reduces memory usage, and improves node startup speed.
"},{"location":"using_javatron/toolkit/#command-and-parameters_3","title":"Command and parameters","text":"To use the LevelDB startup optimization function provided by Toolkit through db archive command:
# full command\n java -jar Toolkit.jar db archive [-h] [-b=<maxBatchSize>] [-d=<databaseDirectory>] [-m=<maxManifestSize>]\n# examples\n #1. use default settings\n java -jar Toolkit.jar db archive \n #2. specify the database directory as /tmp/db/database\n java -jar Toolkit.jar db archive -d /tmp/db/database \n #3. specify the batch size to 64000 when optimizing manifest\n java -jar Toolkit.jar db archive -b 64000\n #4. specify optimization only when Manifest exceeds 128M\n java -jar Toolkit.jar db archive -m 128 \n
Optional command parameters are as follows:
-b | --batch-size: Specify the batch manifest size, default: 80000.-d | --database-directory: Specify the database directory to be processed, default: output-directory/database.-m | --manifest-size: Specify the minimum required manifest file size, unit: M, default: 0.-h | --help\uff1a[ bool ] Provide the help info, default: false.
Note: Before using this tool for any operation, you need to stop the currently running node first. Usage instructions, please refer to Leveldb Startup Optimization Plugins.
"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Welcome to the java-tron user manual!","text":"java-tron is a TRON client implemented in Java, it provides completely open source code, you can download the java-tron source code on Github. This article will introduce the knowledge related to java-tron. Through this article, you will learn how to use java-tron and how to participate in the development and maintenance of java-tron, including the following parts:
- Getting Started With java-tron
- Using java-tron
- API
- Core Protocol
- For java-tron Developers
- For Dapp Developers
- Clients
- Releases
For other TRON related information, please visit the official website tron.network or the following resource links:
- TRON Whitepaper
- TRON Improvement Proposals (TIPs)
- TRON Developer Hub
"},{"location":"glossary/","title":"Glossary","text":"energyUsage
The Energy conumption of the contract caller in one contract trigger.
energyFee
The number of TRX burned from the contract caller for Energy conumption in one contract trigger.
originEnergyUsage
The total Energy conumption of the contract developer in one contract trigger.
energyUsageTotal
The total Energy conumption of the contract developer and the contract caller combined.
Feelimit
When the user triggers or create the contract, this is used to set the usage limit of the Energy consumption got from burning TRX or staking TRX, Energy got from staking TRX will be used first.
CallValue
When the user triggers or create the contract, this can be used to send TRX to the contract.
consume_user_resource_percent
For a contract, Resource consumption is composed of two parts, one part is afforded by contract developer and the other part is afforded by contract caller. This is the percentage of the two parts in the Resource consumption.
origin_energy_limit
The usage limit of the Energy consumption of the developer in one contract trigger, should be greater than 0.
net_usage
The Bandwidth consumption in one contract trigger. (NetFee not included)
net_fee
The TRX burned for Bandwidth consumption in one contract trigger.
Bandwidth
The Bandwidth Points consumed by a transaction is the size of the byte array in this transaction. If the byte array length of a transaction is 100, then the transaction needs to consume 100 Bandwidth Points.
Energy
The creation and operation of a smart contract consume CPU resources. It takes time for smart contracts to operate in virtual machines (VMs), and the time consumed in the system is calculated in microseconds. CPU resources are consumed in energy, which means 1 Energy = 1 Microsecond (\u03bcs). If a contract takes 100 \u03bcs to execute in a VM, it needs to consume 100 Energy.
TRON Power(TP)
1 staked TRX = 1 TP, TP can be used to vote, 1 TP = 1 vote.
Super Representative(SR)
The current block producing Top 27 nodes.
"},{"location":"api/http/","title":"HTTP API","text":"This article introduces FullNode's HTTP APIs and their usage.
Note
Although TRON has avoided XSS by setting the Content-Type of HTTP APIs to application/json, there are a few APIs that don't have input validation. To better protect user data security, we recommend that you correctly encode any data from APIs before they use it in any UI, especially when the parameter visible equals true.
Here is a typical XSS protection method: Encode all data from the APIs in HTML. Use methods such as encodeURIComponent() or escape() to encode the data, which can convert special characters into their HTML entities and prevent them from being interpreted as HTML code by the browser.
Please be sure to implement XSS protection for all data from the APIs to ensure the security of user data. We understand that you may need more information about XSS protection. It is recommended that you refer to the following resources: OWASP XSS Prevention Cheat Sheet.
First, Let's explain the selection of the address format in the HTTP API: Account addresses of the TRON network have two formats: HexString format and Base58 format. The Fullnode HTTP API supports address format selection. Users can set the address format through the visible parameter. The default value is false and the address format in the parameter and return value is hex format. When visible is set to true, the address format in the parameter and return value are in Base58 format. If the parameter format does not match the visible setting, an error will be reported. Setting method:
- For HTTP GET API or the api needs no parameter: by adding
visible=true parameter to the url http://127.0.0.1:8090/wallet/listexchanges?visible=true\n
- For POST API: By adding
\"visible\": true parameter to the most out layer of the json curl -X POST http://127.0.0.1:8090/wallet/createtransaction -d\n'{\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"to_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\",\n \"amount\": 1000000,\n \"visible\": true\n}'\n
"},{"location":"api/http/#fullnode-http-api","title":"Fullnode HTTP API","text":"The FullNode HTTP API is categorized as follows:
- Accounts
- Transfer and Transactions
- Account Resources
- Query The Network
- Smart Contracts
- TRC-10 Token
- Voting & SRs
- Proposals
- DEX Exchange
- TRONZ Shielded Smart Contract
- Pending Pool
"},{"location":"api/http/#accounts","title":"Accounts","text":"The following are the APIs related to on-chain accounts:
- wallet/validateaddress
- wallet/createaccount
- wallet/getaccount
- wallet/updateaccount
- wallet/accountpermissionupdate
- wallet/getaccountbalance
- wallet/setaccountid
- wallet/getaccountbyid
"},{"location":"api/http/#walletvalidateaddress","title":"wallet/validateaddress","text":"Description: Check the validity of the address
curl -X POST http://127.0.0.1:8090/wallet/validateaddress -d '{\"address\": \"4189139CB1387AF85E3D24E212A008AC974967E561\"}'\n
Parameters: address Return: the address is correct or not
"},{"location":"api/http/#walletcreateaccount","title":"wallet/createaccount","text":"Description: Create an account. Uses an already activated account to create a new account. If the owner_address has enough bandwidth obtained by freezing TRX, then creating an account will only consume bandwidth , otherwise, 0.1 TRX will be burned to pay for bandwidth, and at the same time, 1 TRX will be required to be created.
curl -X POST http://127.0.0.1:8090/wallet/createaccount -d '{\"owner_address\":\"41d1e7a6bc354106cb410e65ff8b181c600ff14292\", \"account_address\": \"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\"}'\n
Parameters: owner_address Owner address, default hexStringaccount_address New address, default hexStringPermission_id Optional, for multi-signature use
Return: Unsigned transaction object
"},{"location":"api/http/#walletgetaccount","title":"wallet/getaccount","text":"Description: Query an account information
curl -X POST http://127.0.0.1:8090/wallet/getaccount -d '{\"address\": \"41E552F6487585C2B58BC2C9BB4492BC1F17132CD0\"}'\n
Parameters: address - account address Return: Account object
"},{"location":"api/http/#walletupdateaccount","title":"wallet/updateaccount","text":"Description: Update the name of an account
curl -X POST http://127.0.0.1:8090/wallet/updateaccount -d '{\"account_name\": \"0x7570646174654e616d6531353330383933343635353139\" ,\"owner_address\":\"41d1e7a6bc354106cb410e65ff8b181c600ff14292\"}'\n
Parameters: account_name Account name, default hexStringowner_address Owner address, default hexStringPermission_id Optional, for multi-signature use
Return:\u200b\u672a\u200b\u7b7e\u540d\u200b\u7684\u200b\u4fee\u6539\u200b\u540d\u79f0\u200bTransaction
"},{"location":"api/http/#walletaccountpermissionupdate","title":"wallet/accountpermissionupdate","text":"Description: Update the account's permission.
curl -X POST http://127.0.0.1:8090/wallet/accountpermissionupdate -d\n'{\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"owner\": {\n \"type\": 0,\n \"permission_name\": \"owner\",\n \"threshold\": 1,\n \"keys\": [{\n \"address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"weight\": 1\n }]\n },\n \"witness\": {\n \"type\": 1,\n \"permission_name\": \"witness\",\n \"threshold\": 1,\n \"keys\": [{\n \"address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"weight\": 1\n }]\n },\n \"actives\": [{\n \"type\": 2,\n \"permission_name\": \"active12323\",\n \"threshold\": 2,\n \"operations\": \"7fff1fc0033e0000000000000000000000000000000000000000000000000000\",\n \"keys\": [{\n \"address\": \"TNhXo1GbRNCuorvYu5JFWN3m2NYr9QQpVR\",\n \"weight\": 1\n }, {\n \"address\": \"TKwhcDup8L2PH5r6hxp5CQvQzZqJLmKvZP\",\n \"weight\": 1\n }]\n }],\n \"visible\": true}'\n
Parameters: - owner_address: Owner address of the account, default hexString
- owner: Account owner permission
- witness: Account witness permission, only for witness
- actives: List of active permissions for the account
Return: Unsigned transaction
"},{"location":"api/http/#walletgetaccountbalance","title":"wallet/getaccountbalance","text":"Description\uff1a Get the account balance in a specific block.
curl -X POST http://127.0.0.1:8090/wallet/getaccountbalance -d\n'{\n \"account_identifier\": {\n \"address\": \"TLLM21wteSPs4hKjbxgmH1L6poyMjeTbHm\"\n },\n \"block_identifier\": {\n \"hash\": \"0000000000010c4a732d1e215e87466271e425c86945783c3d3f122bfa5affd9\",\n \"number\": 68682\n },\n \"visible\": true\n}'\n
Parameters:
account_identifier: The account address. block_identifier: The block number.
Return: The balance object of the account in a specific block, the block_identifier is the block hash.
{\n \"balance\": 64086449348265042,\n \"block_identifier\": {\n \"hash\": \"0000000000010c4a732d1e215e87466271e425c86945783c3d3f122bfa5affd9\",\n \"number\": 68682\n }\n}\n
"},{"location":"api/http/#walletsetaccountid","title":"wallet/setaccountid","text":"Description: To set an account id for an account
curl -X POST http://127.0.0.1:8090/wallet/setaccountid -d '{\n\"owner_address\":\"41a7d8a35b260395c14aa456297662092ba3b76fc0\",\"account_id\":\"6161616162626262\"}'\n
Parameters: owner_address: Owner address, default hexStringaccount_id :Account id, default hexString
Return: Unsigned transaction
"},{"location":"api/http/#walletgetaccountbyid","title":"wallet/getaccountbyid","text":"Description: Query an account information by account id
curl -X POST http://127.0.0.1:8090/wallet/getaccountbyid -d\n'{\"account_id\":\"6161616162626262\"}'\n
Parameters: account_id Account id, default hexString Return:Account object
"},{"location":"api/http/#transfers-and-transactions","title":"Transfers and transactions","text":"The following are transfer and transaction related APIs:
- wallet/createtransaction
- wallet/broadcasttransaction
- wallet/broadcasthex
- wallet/getsignweight
- wallet/getapprovedlist
"},{"location":"api/http/#walletcreatetransaction","title":"wallet/createtransaction","text":"Description: Create a transfer transaction, if to address is not existed, then create the account on the blockchain
curl -X POST http://127.0.0.1:8090/wallet/createtransaction -d '{\"to_address\": \"41e9d79cc47518930bc322d9bf7cddd260a0260a8d\", \"owner_address\": \"41D1E7A6BC354106CB410E65FF8B181C600FF14292\", \"amount\": 1000 }'\n
Parameters: to_address To address, default hexStringowner_address Owner address, default hexStringamount Transfer amountPermission_id Optional, for multi-signature use
Return: Unsigned transaction
"},{"location":"api/http/#walletbroadcasttransaction","title":"wallet/broadcasttransaction","text":"Description: Broadcast transaction after sign
curl -X POST http://127.0.0.1:8090/wallet/broadcasttransaction -d '{\"signature\":[\"97c825b41c77de2a8bd65b3df55cd4c0df59c307c0187e42321dcc1cc455ddba583dd9502e17cfec5945b34cad0511985a6165999092a6dec84c2bdd97e649fc01\"],\"txID\":\"454f156bf1256587ff6ccdbc56e64ad0c51e4f8efea5490dcbc720ee606bc7b8\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"amount\":1000,\"owner_address\":\"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\",\"to_address\":\"41d1e7a6bc354106cb410e65ff8b181c600ff14292\"},\"type_url\":\"type.googleapis.com/protocol.TransferContract\"},\"type\":\"TransferContract\"}],\"ref_block_bytes\":\"267e\",\"ref_block_hash\":\"9a447d222e8de9f2\",\"expiration\":1530893064000,\"timestamp\":1530893006233}}'\n
Parameters: Transaction after sign Return:The result of the broadcast
"},{"location":"api/http/#walletbroadcasthex","title":"wallet/broadcasthex","text":"Description: Broadcast transaction hex string after sign
curl -X POST http://127.0.0.1:8090/wallet/broadcasthex -d '{\"transaction\":\"0A8A010A0202DB2208C89D4811359A28004098A4E0A6B52D5A730802126F0A32747970652E676F6F676C65617069732E636F6D2F70726F746F636F6C2E5472616E736665724173736574436F6E747261637412390A07313030303030311215415A523B449890854C8FC460AB602DF9F31FE4293F1A15416B0580DA195542DDABE288FEC436C7D5AF769D24206412418BF3F2E492ED443607910EA9EF0A7EF79728DAAAAC0EE2BA6CB87DA38366DF9AC4ADE54B2912C1DEB0EE6666B86A07A6C7DF68F1F9DA171EEE6A370B3CA9CBBB00\"}'\n
Parameters: Transaction hex after sign Return: The result of the broadcast
"},{"location":"api/http/#walletgetsignweight","title":"wallet/getsignweight","text":"Description: Query the current signatures total weight of a transaction after sign
curl -X POST http://127.0.0.1:8090/wallet/getsignweight -d '{\n \"signature\": [\n \"e0bd4a60f1b3c89d4da3894d400e7e32385f6dd690aee17fdac4e016cdb294c5128b66f62f3947a7182c015547496eba95510c113bda2a361d811b829343c36501\",\n \"596ead6439d0f381e67f30b1ed6b3687f2bd53ce5140cdb126cfe4183235804741eeaf79b4e91f251fd7042380a9485d4d29d67f112d5387bc7457b355cd3c4200\"\n ],\n \"txID\": \"0ae84a8439f5aa8fd2c458879a4031a7452aebed8e6e99ffbccd26842d4323c4\",\n \"raw_data\": {\n \"contract\": [{\n \"parameter\": {\n \"value\": {\n \"amount\": 1000000,\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"to_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\"\n },\n \"type_url\": \"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\": \"TransferContract\"\n }],\n \"ref_block_bytes\": \"163d\",\n \"ref_block_hash\": \"77ef4ace148b05ba\",\n \"expiration\": 1555664823000,\n \"timestamp\": 1555664763418\n },\n \"raw_data_hex\": \"0a02163d220877ef4ace148b05ba40d8c5e5a6a32d5a69080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541a7d8a35b260395c14aa456297662092ba3b76fc01215415a523b449890854c8fc460ab602df9f31fe4293f18c0843d2802709af4e1a6a32d\",\n \"visible\": true}'\n
Parameters: Transaction object after sign Return: The current signatures total weight
"},{"location":"api/http/#walletgetapprovedlist","title":"wallet/getapprovedlist","text":"Description: Query the signatures list of a transaction after sign
curl -X POST http://127.0.0.1:8090/wallet/getapprovedlist -d '{\n \"signature\": [\n \"e0bd4a60f1b3c89d4da3894d400e7e32385f6dd690aee17fdac4e016cdb294c5128b66f62f3947a7182c015547496eba95510c113bda2a361d811b829343c36501\",\n \"596ead6439d0f381e67f30b1ed6b3687f2bd53ce5140cdb126cfe4183235804741eeaf79b4e91f251fd7042380a9485d4d29d67f112d5387bc7457b355cd3c4200\"\n ],\n \"txID\": \"0ae84a8439f5aa8fd2c458879a4031a7452aebed8e6e99ffbccd26842d4323c4\",\n \"raw_data\": {\n \"contract\": [{\n \"parameter\": {\n \"value\": {\n \"amount\": 1000000,\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"to_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\"\n },\n \"type_url\": \"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\": \"TransferContract\"\n }],\n \"ref_block_bytes\": \"163d\",\n \"ref_block_hash\": \"77ef4ace148b05ba\",\n \"expiration\": 1555664823000,\n \"timestamp\": 1555664763418\n },\n \"raw_data_hex\": \"0a02163d220877ef4ace148b05ba40d8c5e5a6a32d5a69080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541a7d8a35b260395c14aa456297662092ba3b76fc01215415a523b449890854c8fc460ab602df9f31fe4293f18c0843d2802709af4e1a6a32d\",\n \"visible\": true}'\n
Parameter: Transaction object after sign Return: The list of the signatures
"},{"location":"api/http/#account-resources","title":"Account Resources","text":"The following are account resource related APIs:
- wallet/getaccountresource
- wallet/getaccountnet
- wallet/unfreezebalance
- wallet/getdelegatedresource
- wallet/getdelegatedresourceaccountindex
- wallet/freezebalancev2
- wallet/unfreezebalancev2
- wallet/cancelallunfreezev2
- wallet/delegateresource
- wallet/undelegateresource
- wallet/withdrawexpireunfreeze
- wallet/getavailableunfreezecount
- wallet/getcanwithdrawunfreezeamount
- wallet/getcandelegatedmaxsize
- wallet/getdelegatedresourcev2
- wallet/getdelegatedresourceaccountindexv2
"},{"location":"api/http/#walletgetaccountresource","title":"wallet/getaccountresource","text":"Description: Query the resource information of an account
curl -X POST http://127.0.0.1:8090/wallet/getaccountresource -d {\"address\" : \"419844f7600e018fd0d710e2145351d607b3316ce9\"}\n
Parameters: address: Address, default hexString
Return: The resource information
"},{"location":"api/http/#walletgetaccountnet","title":"wallet/getaccountnet","text":"Description: Query the bandwidth information of an account
curl -X POST http://127.0.0.1:8090/wallet/getaccountnet -d '{\"address\": \"4112E621D5577311998708F4D7B9F71F86DAE138B5\"}'\n
Parameters: address - Address, default hexString Return: Bandwidth information
"},{"location":"api/http/#walletfreezebalance","title":"wallet/freezebalance","text":"Description: Stake TRX. This interface has been deprecated, please use FreezeBalanceV2 to stake TRX to obtain resources.
"},{"location":"api/http/#walletunfreezebalance","title":"wallet/unfreezebalance","text":"Description: Unstake the TRX that staked during stake1.0 phase.
curl -X POST http://127.0.0.1:8090/wallet/unfreezebalance -d '{\n\"owner_address\":\"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n\"resource\": \"BANDWIDTH\",\n\"receiver_address\":\"414332f387585c2b58bc2c9bb4492bc1f17342cd1\"\n}'\n
Parameters: owner_address Owner address, default hexStringresource unstake type 'BANDWIDTH' or 'ENERGY'receiverAddress The address that will lose the resource, default hexStringPermission_id Optional, for multi-signature use
Return: Unsigned transaction
"},{"location":"api/http/#walletgetdelegatedresource","title":"wallet/getdelegatedresource","text":"Description: Query the resource delegation information
curl -X POST http://127.0.0.1:8090/wallet/getdelegatedresource -d '\n{\n\"fromAddress\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n\"toAddress\": \"41c6600433381c731f22fc2b9f864b14fe518b322f\"\n}'\n
Parameters: fromAddress: from address, default hexStringtoAddress: to address, default hexString
Return: Resource delegation information
"},{"location":"api/http/#walletgetdelegatedresourceaccountindex","title":"wallet/getdelegatedresourceaccountindex","text":"Description: Query the resource delegation by an account during stake1.0 phase. i.e. list all addresses that have delegated resources to an account.
curl -X POST http://127.0.0.1:8090/wallet/getdelegatedresourceaccountindex -d '\n{\n\"value\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n}'\n
Parameters: value: account address
Return:resource delegation index
"},{"location":"api/http/#walletfreezebalancev2","title":"wallet/freezebalancev2","text":"Description: Stake TRX
curl -X POST http://127.0.0.1:8090/wallet/freezebalancev2 -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"frozen_balance\": 10000,\n \"resource\": \"BANDWIDTH\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringfrozen_balance: TRX stake amount, the unit is sunresource: TRX stake type, 'BANDWIDTH' or 'ENERGY'permission_id: Optional, for multi-signature use
Return: Unsigned transaction
"},{"location":"api/http/#walletunfreezebalancev2","title":"wallet/unfreezebalancev2","text":"Description: Unstake some TRX staked in Stake2.0, release the corresponding amount of bandwidth or energy, and voting rights (TP)
curl -X POST http://127.0.0.1:8090/wallet/unfreezebalancev2 -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"unfreeze_balance\": 1000000,\n \"resource\": \"BANDWIDTH\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringresource: Resource type: 'BANDWIDTH' or 'ENERGY'unfreeze_balance: The amount of TRX to unstake, in sunpermission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#walletcancelallunfreezev2","title":"wallet/cancelallunfreezev2","text":"Description: Cancel unstakings, all unstaked funds still in the waiting period will be re-staked, all unstaked funds that exceeded the 14-day waiting period will be automatically withdrawn to the owner\u2019s account
curl -X POST http://127.0.0.1:8090/wallet/cancelallunfreezev2 -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringpermission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#walletdelegateresource","title":"wallet/delegateresource","text":"Description: Delegate bandwidth or energy resources to other accounts in Stake2.0.
curl -X POST http://127.0.0.1:8090/wallet/delegateresource -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"receiver_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"balance\": 1000000,\n \"resource\": \"BANDWIDTH\",\n \"lock\": false\n}'\n
Parameters:
owner_address: Account addressreceiver_address: Resource receiver addressbalance: Amount of TRX staked for resources to be delegated, unit is sunresource: Resource type: 'BANDWIDTH' or 'ENERGY'lock: Whether it is locked, if it is set to true, the delegated resources cannot be undelegated within 3 days. When the lock time is not over, if the owner delegates the same type of resources using the lock to the same address, the lock time will be reset to 3 dayslock_period: lock time,The unit is block interval(3 seconds), indicates the time of how many blocks will be produced from the moment the transaction is executed. Only when lock is true, this field is valid. If the delegate lock period is 1 day, the lock_period is: 28800permission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#walletundelegateresource","title":"wallet/undelegateresource","text":"Description: Cancel the delegation of bandwidth or energy resources to other account
curl -X POST http://127.0.0.1:8090/wallet/undelegateresource -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"receiver_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"balance\": 1000000,\n \"resource\": \"BANDWIDTH\"\n}'\n
Parameters:
owner_address: Account addressreceiver_address: Resource receiver addressbalance: Amount of TRX staked for resources to be delegated, unit is sunresource: Resource type: 'BANDWIDTH' or 'ENERGY'permission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#walletwithdrawexpireunfreeze","title":"wallet/withdrawexpireunfreeze","text":"Description: Withdraw unfrozen balance in Stake2.0, the user can call this API to get back their funds after executing /wallet/unfreezebalancev2 transaction and waiting N days, N is a network parameter
curl -X POST http://127.0.0.1:8090/wallet/withdrawexpireunfreeze -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n}'\n
Parameters:
owner_address: Account addresspermission_id: Optional, for multi-signature use
Return: Unsigned transaction
"},{"location":"api/http/#walletgetavailableunfreezecount","title":"wallet/getavailableunfreezecount","text":"Description:Remaining times of executing unstake operation in Stake2.0
curl -X POST http://127.0.0.1:8090/wallet/getavailableunfreezecount -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account address
Return:Remaining times of available unstaking.
"},{"location":"api/http/#walletgetcanwithdrawunfreezeamount","title":"wallet/getcanwithdrawunfreezeamount","text":"Description:Query the withdrawable balance at the specified timestamp In Stake2.0
curl -X POST http://127.0.0.1:8090/wallet/getcanwithdrawunfreezeamount -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"timestamp\": 1667977444000,\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account addresstimestamp: query cutoff timestamp, in milliseconds.
Return: withdrawable balance, unit is sun.
"},{"location":"api/http/#walletgetcandelegatedmaxsize","title":"wallet/getcandelegatedmaxsize","text":"Description: In Stake2.0, query the amount of delegatable resources share of the specified resource type for an address, unit is sun.
curl -X POST http://127.0.0.1:8090/wallet/getcandelegatedmaxsize -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"type\": 0,\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account addresstype: resource type, 0 is bandwidth, 1 is energy
Return:the amount of delegatable resource share, unit is sun.
"},{"location":"api/http/#walletgetdelegatedresourcev2","title":"wallet/getdelegatedresourcev2","text":"In Stake2.0, query the detail of resource share delegated from fromAddress to toAddress
curl -X POST http://127.0.0.1:8090/wallet/getdelegatedresourcev2 -d\n'{\n \"fromAddress\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"toAddress\": \"TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1\",\n \"visible\": true\n}\n'\n
Parameters:
fromAddress: resource from address, default hexStringtoAddress: resource to address
Return:Resource delegation list
"},{"location":"api/http/#walletgetdelegatedresourceaccountindexv2","title":"wallet/getdelegatedresourceaccountindexv2","text":"In Stake2.0, query the resource delegation index by an account. Two lists will return, one is the list of addresses the account has delegated its resources(toAddress), and the other is the list of addresses that have delegated resources to the account(fromAddress).
curl -X POST http://127.0.0.1:8090/wallet/getdelegatedresourceaccountindexv2 -d\n'{\n \"value\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"visible\": true\n}\n'\n
Parameters:
value: account address
Return:Two lists will return, one is the list of addresses the account has delegated its resources(toAddress), and the other is the list of addresses that have delegated resources to the account(fromAddress).
"},{"location":"api/http/#query-the-network","title":"Query The Network","text":"The following is the API for querying data on the chain:
- wallet/getnowblock
- wallet/getblock
- wallet/getblockbynum
- wallet/getblockbyid
- wallet/getblockbylatestnum
- wallet/getblockbylimitnext
- wallet/getblockbalance
- wallet/gettransactionbyid
- wallet/gettransactioninfobyid
- wallet/gettransactioncountbyblocknum
- wallet/gettransactioninfobyblocknum
- wallet/listnodes
- wallet/getnodeinfo
- wallet/getchainparameters
- wallet/getenergyprices
- wallet/getbandwidthprices
- wallet/getburntrx
"},{"location":"api/http/#walletgetnowblock","title":"wallet/getnowblock","text":"Description: Query the latest block information
curl -X POST http://127.0.0.1:8090/wallet/getnowblock\n
Parameters: N/A Return: The latest block
"},{"location":"api/http/#walletgetblock","title":"wallet/getblock","text":"Query block header information or entire block information according to block height or block hash
curl -X POST http://127.0.0.1:8090/wallet/getblock -d '{\"detail\":false}'\n
Parameters: id_or_num: id_or_num can be the block height or the block hash. No value entered means to query the latest block.detail: true means query the entire block information include the header and body. false means only query the block header information.
Return: block or block header
"},{"location":"api/http/#walletgetblockbynum","title":"wallet/getblockbynum","text":"Description: Query a block information by block height
curl -X POST http://127.0.0.1:8090/wallet/getblockbynum -d '{\"num\": 1}'\n
Parameters: Block height Return: block
"},{"location":"api/http/#walletgetblockbyid","title":"wallet/getblockbyid","text":"Description: Query a block information by block id
curl -X POST http://127.0.0.1:8090/wallet/getblockbyid -d '{\"value\": \"0000000000038809c59ee8409a3b6c051e369ef1096603c7ee723c16e2376c73\"}'\n
Parameters: Block id Return: block
"},{"location":"api/http/#walletgetblockbylatestnum","title":"wallet/getblockbylatestnum","text":"Description: Query the several latest blocks
curl -X POST http://127.0.0.1:8090/wallet/getblockbylatestnum -d '{\"num\": 5}'\n
Parameters: The number of the blocks expected to return Return:The list of the blocks
"},{"location":"api/http/#walletgetblockbylimitnext","title":"wallet/getblockbylimitnext","text":"Description: Query a list of blocks by range
curl -X POST http://127.0.0.1:8090/wallet/getblockbylimitnext -d '{\"startNum\": 1, \"endNum\": 2}'\n
Parameters: startNum: The start block height, itself includedendNum: The end block height, itself not included
Return: The list of the blocks
"},{"location":"api/http/#walletgetblockbalance","title":"wallet/getblockbalance","text":"Description\uff1aGet all balance change operations in a block.
curl -X POST http://127.0.0.1:8090/wallet/getblockbalance -d\n'{\n \"hash\": \"000000000000dc2a3731e28a75b49ac1379bcc425afc95f6ab3916689fbb0189\",\n \"number\": 56362,\n \"visible\": true\n}'\n
Parameters: The hash and block number must match. Return:
{\n \"block_identifier\": {\n \"hash\": \"000000000000dc2a3731e28a75b49ac1379bcc425afc95f6ab3916689fbb0189\",\n \"number\": 56362\n },\n \"timestamp\": 1530060672000,\n \"transaction_balance_trace\": [\n {\n \"transaction_identifier\": \"e6cabb1833cd1f795eed39d8dd7689eaa70e5bb217611766c74c7aa9feea80df\",\n \"operation\": [\n {\n \"operation_identifier\": 0,\n \"address\": \"TPttBLmFuykRi83y9HxDoEWxTQw6CCcQ4p\",\n \"amount\": -100000\n },\n {\n \"operation_identifier\": 1,\n \"address\": \"TLsV52sRDL79HXGGm9yzwKibb6BeruhUzy\",\n \"amount\": 100000\n },\n {\n \"operation_identifier\": 2,\n \"address\": \"TPttBLmFuykRi83y9HxDoEWxTQw6CCcQ4p\",\n \"amount\": -10000000\n },\n {\n \"operation_identifier\": 3,\n \"address\": \"TMrysg7DbwR1M8xqhpaPdVCHCuWFhw7uk1\",\n \"amount\": 10000000\n }\n ],\n \"type\": \"TransferContract\",\n \"status\": \"SUCCESS\"\n }\n ]\n}\n
"},{"location":"api/http/#walletgettransactionbyid","title":"wallet/gettransactionbyid","text":"Description: Query a transaction information by transaction id
curl -X POST http://127.0.0.1:8090/wallet/gettransactionbyid -d '{\"value\": \"d5ec749ecc2a615399d8a6c864ea4c74ff9f523c2be0e341ac9be5d47d7c2d62\"}'\n
Parameters: Transaction id Return: Transaction information
"},{"location":"api/http/#walletgettransactioninfobyid","title":"wallet/gettransactioninfobyid","text":"Description: Query the transaction fee, block height by transaction id
curl -X POST http://127.0.0.1:8090/wallet/gettransactioninfobyid -d '{\"value\" : \"309b6fa3d01353e46f57dd8a8f27611f98e392b50d035cef213f2c55225a8bd2\"}'\n
Parameters: value - Transaction id Return: Transaction fee & block height
"},{"location":"api/http/#walletgettransactioncountbyblocknum","title":"wallet/gettransactioncountbyblocknum","text":"Description: Query th the number of transactions in a specific block
curl -X POST http://127.0.0.1:8090/wallet/gettransactioncountbyblocknum -d '{\"num\" : 100}'\n
Parameters: num - Block height Return: The number of transactions
"},{"location":"api/http/#walletgettransactioninfobyblocknum","title":"wallet/gettransactioninfobyblocknum","text":"Description: Query the list of transaction information in a specific block
curl -X POST http://127.0.0.1:8090/wallet/gettransactioninfobyblocknum -d '{\"num\" : 100}'\n
Parameters: num is the Block height Return:The list of transaction information
"},{"location":"api/http/#walletlistnodes","title":"wallet/listnodes","text":"Description: Query the list of nodes connected to the ip of the api
curl -X POST http://127.0.0.1:8090/wallet/listnodes\n
Parameters: N/A Return: The list of nodes
"},{"location":"api/http/#walletgetnodeinfo","title":"wallet/getnodeinfo","text":"Description: Query the current node information
curl http://127.0.0.1:8090/wallet/getnodeinfo\n
Return: The node information"},{"location":"api/http/#walletgetchainparameters","title":"wallet/getchainparameters","text":"Description: Query the parameters of the blockchain used for SR(Super Representatives) to create a proposal
curl -X POST http://127.0.0.1:8090/wallet/getchainparameters\n
Return: The list of parameters of the blockchain"},{"location":"api/http/#walletgetenergyprices","title":"wallet/getenergyprices","text":"Description: Query historical energy unit price
curl -X POST http://127.0.0.1:8090/wallet/getenergyprices\n
Return: All historical energy unit price information. Each unit price change is separated by a comma. Before the colon is the millisecond timestamp, and after the colon is the energy unit price in sun."},{"location":"api/http/#walletgetbandwidthprices","title":"wallet/getbandwidthprices","text":"Description: Query historical bandwidth unit price
curl -X POST http://127.0.0.1:8090/wallet/getbandwidthprices\n
Return: All historical bandwidth unit price information. Each unit price change is separated by a comma. Before the colon is the millisecond timestamp, and after the colon is the bandwidth unit price in sun."},{"location":"api/http/#walletgetburntrx","title":"wallet/getburntrx","text":"Description: Query the amount of TRX burned due to on-chain transaction fees since No. 54 Committee Proposal took effect
curl -X POST http://127.0.0.1:8090/wallet/getburntrx\n
Return: Amount of TRX burned, in sun."},{"location":"api/http/#smart-contracts","title":"Smart Contracts","text":"The following are smart contract related APIs:
- wallet/getcontract
- wallet/getcontractinfo
- wallet/deploycontract
- wallet/triggersmartcontract
- wallet/triggerconstantcontract
- wallet/updatesetting
- wallet/updateenergylimit
- wallet/clearabi
- wallet/estimateenergy
"},{"location":"api/http/#walletgetcontract","title":"wallet/getcontract","text":"Queries a contract's information from the blockchain, including the bytecode of the contract, ABI, configuration parameters, etc.
curl -X POST http://127.0.0.1:8090/wallet/getcontract -d '{\"value\":\"4189139CB1387AF85E3D24E212A008AC974967E561\"}'\n
Parameters: value - Contract address Return:SmartContract
"},{"location":"api/http/#walletgetcontractinfo","title":"wallet/getcontractinfo","text":"Queries a contract's information from the blockchain. The difference from the wallet/getcontract interface is that this interface returns not only the bytecode but also the runtime bytecode of the contract. Compared with bytecode, runtime bytecode does not contain constructor and constructor parameter information.
curl -X POST http://127.0.0.1:8090/wallet/getcontractinfo -d '{\"value\":\"4189139CB1387AF85E3D24E212A008AC974967E561\"}'\n
Parameters: value - Contract address Return: contract's information
"},{"location":"api/http/#walletdeploycontract","title":"wallet/deploycontract","text":"Description: Deploy a smart contract
curl -X POST http://127.0.0.1:8090/wallet/deploycontract -d '{\"abi\":\"[{\\\"constant\\\":false,\\\"inputs\\\":[{\\\"name\\\":\\\"key\\\",\\\"type\\\":\\\"uint256\\\"},{\\\"name\\\":\\\"value\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"name\\\":\\\"set\\\",\\\"outputs\\\":[],\\\"payable\\\":false,\\\"stateMutability\\\":\\\"nonpayable\\\",\\\"type\\\":\\\"function\\\"},{\\\"constant\\\":true,\\\"inputs\\\":[{\\\"name\\\":\\\"key\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"name\\\":\\\"get\\\",\\\"outputs\\\":[{\\\"name\\\":\\\"value\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"payable\\\":false,\\\"stateMutability\\\":\\\"view\\\",\\\"type\\\":\\\"function\\\"}]\",\"bytecode\":\"608060405234801561001057600080fd5b5060de8061001f6000396000f30060806040526004361060485763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416631ab06ee58114604d5780639507d39a146067575b600080fd5b348015605857600080fd5b506065600435602435608e565b005b348015607257600080fd5b50607c60043560a0565b60408051918252519081900360200190f35b60009182526020829052604090912055565b600090815260208190526040902054905600a165627a7a72305820fdfe832221d60dd582b4526afa20518b98c2e1cb0054653053a844cf265b25040029\",\"parameter\":\"\",\"call_value\":100,\"name\":\"SomeContract\",\"consume_user_resource_percent\":30,\"fee_limit\":10,\"origin_energy_limit\": 10,\"owner_address\":\"41D1E7A6BC354106CB410E65FF8B181C600FF14292\"}'\n
Parameters: abi:abibytecode:bytecode\uff0chexStringparameter:The list of the parameters of the constructor, It should be converted hexString after encoded according to ABI encoder. If constructor has no parameter, this can be optionalconsume_user_resource_percent: Consume user's resource percentage. It should be an integer between [0, 100]. if 0, means it does not consume user's resource until the developer's resource has been used upfee_limit: The maximum TRX burns for resource consumptioncall_value: The TRX transfer to the contract for each callowner_address:Owner address of the contract, default hexStringname:Contract nameorigin_energy_limit: The maximum resource consumption of the creator in one execution or creationcall_token_value: The amount of trc10 token transfer to the contract for each call (Optional)token_id:The id of trc10 token transfer to the contract (Optional)Permission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#wallettriggersmartcontract","title":"wallet/triggersmartcontract","text":"Description: Trigger smart contract
$ curl -X POST http://127.0.0.1:8090/wallet/triggersmartcontract -d\n'{\n \"contract_address\": \"4189139CB1387AF85E3D24E212A008AC974967E561\",\n \"function_selector\": \"set(uint256,uint256)\",\n \"parameter\": \"00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000002\",\n \"fee_limit\": 10,\n \"call_value\": 100,\n \"owner_address\": \"41D1E7A6BC354106CB410E65FF8B181C600FF14292\"\n}'\n
Parameters: contract_address: Contract address, default hexStringfunction_selector: Function call, must not leave a blank spaceparameter: The parameter passed to 'function_selector', the format must match with the VM's requirement. You can use a js tool provided by remix to convert a parameter like [1,2] to the format that VM requiresdata: The data for interacting with smart contracts, including the contract function and parameters. You can choose to use this field, or you can choose to use function_selector and parameter for contract interaction. When both of data and function_selector exist, function_selector is preferredfee_limit: The maximum TRX burns for resource consumptioncall_value: The TRX transfer to the contract for each callcall_token_value: The amount of trc10 token transfer to the contract for each calltoken_id: The id of trc10 token transfer to the contractowner_address: Owner address that triggers the contract, default hexStringpermission_id: Optional, for multi-signature use
Return:Unsigned transaction
"},{"location":"api/http/#wallettriggerconstantcontract","title":"wallet/triggerconstantcontract","text":"Description: Trigger the constant of the smart contract, the transaction is off the blockchain
$ curl -X POST http://127.0.0.1:8090/wallet/triggerconstantcontract -d\n'{\n \"contract_address\": \"4189139CB1387AF85E3D24E212A008AC974967E561\",\n \"function_selector\": \"set(uint256,uint256)\",\n \"parameter\": \"00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000002\",\n \"call_value\": 100,\n \"owner_address\": \"41D1E7A6BC354106CB410E65FF8B181C600FF14292\"\n}'\n
Parameters: contract_address: Smart contract address, default hexStringfunction_selector: Function call, must not leave a blank spaceparameter: The parameter passed to 'function_selector', the format must match with the VM's requirement. You can use a hs tool provided by remix to convert a parameter like [1,2] to the format that VM requiresdata: The data for interacting with smart contracts, including the contract function and parameters. You can choose to use this field, or you can choose to use function_selector and parameter for contract interaction. When both of data and function_selector exist, function_selector is preferredcall_value: The TRX transfer to the contract for each callowner_address: Owner address that triggers the contract, default hexStringcall_token_value: The amount of trc10 token transfer to the contract for each calltoken_id: The id of trc10 token transfer to the contract
Return: Transaction object
Note: The unit of TRX in the parameters is SUN
"},{"location":"api/http/#walletupdatesetting","title":"wallet/updatesetting","text":"Description: Update the consume_user_resource_percent parameter of a smart contract
$ curl -X POST http://127.0.0.1:8090/wallet/updatesetting -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"contract_address\": \"41c6600433381c731f22fc2b9f864b14fe518b322f\",\n \"consume_user_resource_percent\": 7\n}'\n
owner_address:Owner address of the smart contract, default hexStringcontract_address:Smart contract address, default hexStringconsume_user_resource_percent:Consume user's resource percentagePermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletupdateenergylimit","title":"wallet/updateenergylimit","text":"Description: Update the origin_energy_limit parameter of a smart contract
$ curl -X POST http://127.0.0.1:8090/wallet/updateenergylimit -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"contract_address\": \"41c6600433381c731f22fc2b9f864b14fe518b322f\",\n \"origin_energy_limit\": 7\n}'\n
Parameters: owner_address: Owner address of the smart contract, default hexStringcontract_address: Smart contract address, default hexStringorigin_energy_limit: The maximum resource consumption of the creator in one execution or creationpermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletclearabi","title":"wallet/clearabi","text":"Description: To clear the abi of a smart contract
$ curl -X POST http://127.0.0.1:8090/wallet/clearabi -d\n'{\n \"owner_address\": \"41a7d8a35b260395c14aa456297662092ba3b76fc0\",\n \"contract_address\": \"417bcb781f4743afaacf9f9528f3ea903b3782339f\"\n}'\n
Parameters:
owner_address:Owner address of the smart contractcontract_address: Smart contract address, default hexString
Return: Transaction object
"},{"location":"api/http/#walletestimateenergy","title":"wallet/estimateenergy","text":"Estimate the energy required for the successful execution of smart contract transactions
curl -X POST http://127.0.0.1:8090/wallet/estimateenergy -d '{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"contract_address\": \"TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs\",\n \"function_selector\": \"transfer(address,uint256)\",\n \"parameter\": \"00000000000000000000004115208EF33A926919ED270E2FA61367B2DA3753DA0000000000000000000000000000000000000000000000000000000000000032\",\n \"visible\": true\n}'\n
Parameters:
contract_address : Smart contract address. If visible=true, use base58check format, otherwise use hex format.function_selector: Function call, must not be left blank.parameter: Parameter encoding needs to be in accordance with the ABI rules, the rules are more complicated, users can use the ethers library to encodedata: The data for interacting with smart contracts, including the contract function and parameters. You can choose to use this field, or you can choose to use function_selector and parameter for contract interaction. When both of data and function_selector exist, function_selector is preferredcall_value: The TRX transfer to the contract for each callowner_address:Owner address that triggers the contract. If visible=true, use base58check format, otherwise use hex call_token_value: The amount of trc10 token transfer to the contract for each calltoken_id: The id of trc10 token transfer to the contract
Return:Estimated the energy value
"},{"location":"api/http/#trc10-token","title":"TRC10 token","text":"The following are TRC10 token-related APIs:
- wallet/getassetissuebyaccount
- wallet/getassetissuebyname
- wallet/getassetissuelistbyname
- wallet/getassetissuebyid
- wallet/getassetissuelist
- wallet/getpaginatedassetissuelist
- wallet/transferasset
- wallet/participateassetissue
- wallet/createassetissue
- wallet/unfreezeasset
- wallet/updateasset
"},{"location":"api/http/#walletgetassetissuebyaccount","title":"wallet/getassetissuebyaccount","text":"Description: Query the token issue information of an account
$ curl -X POST http://127.0.0.1:8090/wallet/getassetissuebyaccount -d\n'{\n \"address\": \"41F9395ED64A6E1D4ED37CD17C75A1D247223CAF2D\"\n}'\n
Parameter address: Token issuer's address, default hexString
Return: Token object
"},{"location":"api/http/#walletgetassetissuebyname","title":"wallet/getassetissuebyname","text":"Description: Query a token by token name
$ curl -X POST http://127.0.0.1:8090/wallet/getassetissuebyname -d\n'{\n \"value\": \"44756354616E\"\n}'\n
Parameter value: Token name, default hexString
Return: Token object
"},{"location":"api/http/#walletgetassetissuelistbyname","title":"wallet/getassetissuelistbyname","text":"Description: Query the list of tokens by name
$ curl -X POST http://127.0.0.1:8090/wallet/getassetissuelistbyname -d\n'{\n \"value\": \"44756354616E\"\n}'\n
Parameter value: Token name, default hexString
Return: The list of tokens
"},{"location":"api/http/#walletgetassetissuebyid","title":"wallet/getassetissuebyid","text":"Description: Query a token by token id
$ curl -X POST http://127.0.0.1:8090/wallet/getassetissuebyid -d\n'{\n \"value\": \"1000001\"\n}'\n
Parameter value: Token id
Return: Token object
"},{"location":"api/http/#walletgetassetissuelist","title":"wallet/getassetissuelist","text":"Description: Query the list of all the tokens
$ curl -X GET http://127.0.0.1:8090/wallet/getassetissuelist\n
Parameter: No parameter
Return: The list of all the tokens
"},{"location":"api/http/#walletgetpaginatedassetissuelist","title":"wallet/getpaginatedassetissuelist","text":"Description: Query the list of all the tokens by pagination
$ curl -X POST http://127.0.0.1:8090/wallet/getpaginatedassetissuelist -d\n'{\n \"offset\": 0,\n \"limit\": 10\n}'\n
Parameters:
offset: The index of the start tokenlimit: The amount of tokens per page
Return: The list of tokens by pagination
"},{"location":"api/http/#wallettransferasset","title":"wallet/transferasset","text":"Description: Transfer token
$ curl -X POST http://127.0.0.1:8090/wallet/transferasset -d\n'{\n \"owner_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"to_address\": \"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\",\n \"asset_name\": \"31303030303031\",\n \"amount\": 100\n}'\n
Parameters: owner_address: Owner address, default hexStringto_address: To address, default hexStringasset_name: Token id, default hexStringamount: Token transfer amountpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'amount' is the smallest unit of the token
"},{"location":"api/http/#walletparticipateassetissue","title":"wallet/participateassetissue","text":"Description: Participate a token
$ curl -X POST http://127.0.0.1:8090/wallet/participateassetissue -d\n'{\n \"to_address\": \"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\",\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"amount\": 100,\n \"asset_name\": \"3230313271756265696a696e67\"\n}'\n
Parameters: to_address: The issuer address of the token, default hexStringowner_address: The participant address, default hexStringamount: Participate token amountasset_name: Token id, default hexStringpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'amount' is the smallest unit of the token
"},{"location":"api/http/#walletcreateassetissue","title":"wallet/createassetissue","text":"Description: Issue a token
$ curl -X POST http://127.0.0.1:8090/wallet/createassetissue -d\n'{\n \"owner_address\": \"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\",\n \"name\": \"0x6173736574497373756531353330383934333132313538\",\n \"abbr\": \"0x6162627231353330383934333132313538\",\n \"total_supply\": 4321,\n \"trx_num\": 1,\n \"num\": 1,\n \"start_time\": 1530894315158,\n \"end_time\": 1533894312158,\n \"description\": \"007570646174654e616d6531353330363038383733343633\",\n \"url\": \"007570646174654e616d6531353330363038383733343633\",\n \"free_asset_net_limit\": 10000,\n \"public_free_asset_net_limit\": 10000,\n \"frozen_supply\": {\n \"frozen_amount\": 1,\n \"frozen_days\": 2\n }\n}'\n
Parameters: owner_address: Owner address, default hexStringname: Token name, default hexStringabbr: Token name abbreviation, default hexStringtotal_supply: Token total supplytrx_num: Define the price by the ratio of trx_num/numnum: Define the price by the ratio of trx_num/numstart_time: ICO start timeend_time: ICO end timedescription: Token description, default hexStringurl: Token official website url, default hexStringfree_asset_net_limit: Token free asset net limitpublic_free_asset_net_limit: Token public free asset net limitfrozen_supply: Token staked supplypermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'trx_num' is SUN
"},{"location":"api/http/#walletunfreezeasset","title":"wallet/unfreezeasset","text":"Description: Unstake the staked token that is due
$ curl -X POST http://127.0.0.1:8090/wallet/unfreezeasset -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\"\n}'\n
Parameters: - owner_address: Owner address, default hexString - permission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletupdateasset","title":"wallet/updateasset","text":"Description: Update token information
$ curl -X POST http://127.0.0.1:8090/wallet/updateasset -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\",\n \"description\": \"\",\n \"url\": \"\",\n \"new_limit\": 1000000,\n \"new_public_limit\": 100\n}'\n
Parameters:
owner_address: The issuers address of the token, default hexStringdescription: The description of token, default hexStringurl: The token's website url, default hexStringnew_limit: Each token holder's free bandwidthnew_public_limit: The total free bandwidth of the tokenpermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#vote-and-sr","title":"Vote and SR","text":"The following are voting and SR related APIs:
- wallet/createwitness
- wallet/updatewitness
- wallet/listwitnesses
- wallet/withdrawbalance
- wallet/votewitnessaccount
- wallet/getBrokerage
- wallet/updateBrokerage
- wallet/getReward
- wallet/getnextmaintenancetime
"},{"location":"api/http/#walletcreatewitness","title":"wallet/createwitness","text":"Description: Apply to become a super representative
$ curl -X POST http://127.0.0.1:8090/wallet/createwitness -d\n'{\n \"owner_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"url\": \"007570646174654e616d6531353330363038383733343633\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringurl: Website url, default hexStringpermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletupdatewitness","title":"wallet/updatewitness","text":"Description: Update the super representative' website url
$ curl -X POST http://127.0.0.1:8090/wallet/updatewitness -d\n'{\n \"owner_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"update_url\": \"007570646174654e616d6531353330363038383733343633\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringupdate_url: Website url, default hexStringpermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletlistwitnesses","title":"wallet/listwitnesses","text":"Description: Qyery the list of the super representatives
curl -X POST http://127.0.0.1:8090/wallet/listwitnesses\n
Parameters: N/A Return:SR(Super Representatives) list
"},{"location":"api/http/#walletwithdrawbalance","title":"wallet/withdrawbalance","text":"Description: Withdraw reward to account balance for super representatives
$ curl -X POST http://127.0.0.1:8090/wallet/withdrawbalance -d\n'{\n \"owner_address\": \"41e472f387585c2b58bc2c9bb4492bc1f17342cd1\"\n}'\n
Parameters:
owner_address: Owner address, default hexStringpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: It can only withdraw once for every 24 hours
"},{"location":"api/http/#walletvotewitnessaccount","title":"wallet/votewitnessaccount","text":"Description: Vote for super representatives
$ curl -X POST http://127.0.0.1:8090/wallet/votewitnessaccount -d\n'{\n \"owner_address\": \"41d1e7a6bc354106cb410e65ff8b181c600ff14292\",\n \"votes\": [\n {\n \"vote_address\": \"41e552f6487585c2b58bc2c9bb4492bc1f17132cd0\",\n \"vote_count\": 5\n }\n ]\n}'\n
Parameters:
owner_address: Owner address, default hexStringvotes: 'vote_address' stands for the address of the super representative you want to vote, default hexString, 'vote_count' stands for the number of votes you want to votepermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletgetbrokerage","title":"wallet/getBrokerage","text":"Description: Query the ratio of brokerage of the super representative
$ curl -X GET http://127.0.0.1:8090/wallet/getBrokerage -d '{\n\"address\":\"41E552F6487585C2B58BC2C9BB4492BC1F17132CD0\"}'\n
Parameter address: The address of the SR's account, default hexString
Return: The ratio of brokerage of the SR
"},{"location":"api/http/#walletupdatebrokerage","title":"wallet/updateBrokerage","text":"Description: Update the ratio of brokerage
$ curl -X POST http://127.0.0.1:8090/wallet/updateBrokerage -d '{\n\"owner_address\":\"41E552F6487585C2B58BC2C9BB4492BC1F17132CD0\",\n\"brokerage\":30\n}'\n
Parameters:
owner_address: The address of the SR's account, default hexStringbrokerage: The ratio of brokerage you want to update to
Return: Transaction object
"},{"location":"api/http/#walletgetreward","title":"wallet/getReward","text":"Description: Query unclaimed reward
$ curl -X GET\nhttp://127.0.0.1:8090/wallet/getReward -d '{\n\"address\":\"41E552F6487585C2B58BC2C9BB4492BC1F17132CD0\"}'\n
Parameter address: The address of the voter's account, default hexString
Return: Unclaimed reward
"},{"location":"api/http/#walletgetnextmaintenancetime","title":"wallet/getnextmaintenancetime","text":"Description: Query the time interval till the next vote round
curl -X POST http://127.0.0.1:8090/wallet/getnextmaintenancetime\n
Parameters: N/A Return: The time interval till the next vote round(unit: ms)
"},{"location":"api/http/#proposals","title":"Proposals","text":"The following are proposal-related APIs:
- wallet/proposalcreate
- wallet/getproposalbyid
- wallet/listproposals
- wallet/proposalapprove
- wallet/proposaldelete
- wallet/getpaginatedproposallist
"},{"location":"api/http/#walletproposalcreate","title":"wallet/proposalcreate","text":"Description: Create a proposal
$ curl -X POST http://127.0.0.1:8090/wallet/proposalcreate -d\n'{\n \"owner_address\": \"419844F7600E018FD0D710E2145351D607B3316CE9\",\n \"parameters\": [\n {\n \"key\": 0,\n \"value\": 100000\n },\n {\n \"key\": 1,\n \"value\": 2\n }\n ]\n}'\n
Parameters:
owner_address: Creator addressparameters: Proposal parameterspermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletgetproposalbyid","title":"wallet/getproposalbyid","text":"Description: Query a proposal by proposal id
$ curl -X POST http://127.0.0.1:8090/wallet/getproposalbyid -d\n'{\n \"id\": 1\n}'\n
Parameter id: Proposal id
Return: The proposal information
"},{"location":"api/http/#walletlistproposals","title":"wallet/listproposals","text":"Description: Query all the proposals
$ curl -X POST http://127.0.0.1:8090/wallet/listproposals\n
Parameter: No parameter
Return: The list of all the proposals
"},{"location":"api/http/#walletproposalapprove","title":"wallet/proposalapprove","text":"Description: To approve a proposal
$ curl -X POST http://127.0.0.1:8090/wallet/proposalapprove -d\n'{\n \"owner_address\": \"419844F7600E018FD0D710E2145351D607B3316CE9\",\n \"proposal_id\": 1,\n \"is_add_approval\": true\n}'\n
Parameters:
owner_address: The address that makes the approve action, default hexStringproposal_id: Proposal idis_add_approval: Whether to approvepermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletproposaldelete","title":"wallet/proposaldelete","text":"Description: To delete a proposal
$ curl -X POST http://127.0.0.1:8090/wallet/proposaldelete -d\n'{\n \"owner_address\": \"419844F7600E018FD0D710E2145351D607B3316CE9\",\n \"proposal_id\": 1\n}'\n
Parameters:
owner_address: Owner address of the proposal, default hexStringproposal_id: Proposal idpermission_id: Optional, for multi-signature use
Return: Transaction object
"},{"location":"api/http/#walletgetpaginatedproposallist","title":"wallet/getpaginatedproposallist","text":"Description: Query the list of all the proposals by pagination
$ curl -X POST http://127.0.0.1:8090/wallet/getpaginatedproposallist -d\n'{\n \"offset\": 0,\n \"limit\": 10\n}'\n
Parameters:
offset: The index of the start proposallimit: The amount of proposals per page
Return: The list of proposals by pagination
"},{"location":"api/http/#dex-exchange","title":"DEX Exchange","text":"The following are the APIs related to decentralized exchanges:
- wallet/exchangecreate
- wallet/exchangeinject
- wallet/exchangewithdraw
- wallet/exchangetransaction
- wallet/getexchangebyid
- wallet/listexchanges
- wallet/getpaginatedexchangelist
- wallet/marketsellasset
- wallet/marketcancelorder
- wallet/getmarketorderbyaccount
- wallet/getmarketpairlist
- wallet/getmarketorderlistbypair
- wallet/getmarketpricebypair
- wallet/getmarketorderbyid
"},{"location":"api/http/#walletexchangecreate","title":"wallet/exchangecreate","text":"Description: Create an exchange pair
$ curl -X POST http://127.0.0.1:8090/wallet/exchangecreate -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"first_token_id\": \"token_a\",\n \"first_token_balance\": 100,\n \"second_token_id\": \"token_b\",\n \"second_token_balance\": 200\n}'\n
Parameters:
owner_address: addressfirst_token_id: The first token's id, default hexStringfirst_token_balance: The first token's balancesecond_token_id: The second token's id, default hexStringsecond_token_balance: The second token's balancepermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'first_token_balance' and 'second_token_balance' is the smallest unit of the token
"},{"location":"api/http/#walletexchangeinject","title":"wallet/exchangeinject","text":"Description: Inject funds for exchange pair
$ curl -X POST http://127.0.0.1:8090/wallet/exchangeinject -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"exchange_id\": 1,\n \"token_id\": \"74726f6e6e616d65\",\n \"quant\": 100\n}'\n
Parameters:
owner_address: Owner address of the exchange pair, default hexStringexchange_id: Exchange pair idtoken_id: Token id, default hexStringquant: Token inject amountpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'quant' is the smallest unit of the token
"},{"location":"api/http/#walletexchangewithdraw","title":"wallet/exchangewithdraw","text":"Description: Withdraw from exchange pair
$ curl -X POST http://127.0.0.1:8090/wallet/exchangewithdraw -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"exchange_id\": 1,\n \"token_id\": \"74726f6e6e616d65\",\n \"quant\": 100\n}'\n
Parameters:
owner_address: Owner address of the exchange pair, default hexStringexchange_id: Exchange pair idtoken_id: Token id, default hexStringquant: Token withdraw amountpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'quant' is the smallest unit of the token
"},{"location":"api/http/#walletexchangetransaction","title":"wallet/exchangetransaction","text":"Description: Participate the transaction of exchange pair
$ curl -X POST http://127.0.0.1:8090/wallet/exchangetransaction -d\n'{\n \"owner_address\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n \"exchange_id\": 1,\n \"token_id\": \"74726f6e6e616d65\",\n \"quant\": 100,\n \"expected\": 10\n}'\n
Parameters:
owner_address: Owner address of the exchange pair, default hexStringexchange_id: Exchange pair idtoken_id: Token id, default hexStringquant: Sell token amountexpected: Expected token amount to getpermission_id: Optional, for multi-signature use
Return: Transaction object
Note: The unit of 'quant' and 'expected' is the smallest unit of the token
"},{"location":"api/http/#walletgetexchangebyid","title":"wallet/getexchangebyid","text":"Description: Query an exchange pair by exchange pair id
$ curl -X POST http://127.0.0.1:8090/wallet/getexchangebyid -d\n'{\n \"id\": 1\n}'\n
Parameter id: Exchange pair id
Return: Exchange pair information
"},{"location":"api/http/#walletlistexchanges","title":"wallet/listexchanges","text":"Description: Query the list of all the exchange pairs
$ curl -X GET http://127.0.0.1:8090/wallet/listexchanges\n
Parameter: No parameter
Return: The list of all the exchange pairs
"},{"location":"api/http/#walletgetpaginatedexchangelist","title":"wallet/getpaginatedexchangelist","text":"Description: Query the list of all the exchange pairs by pagination
$ curl -X POST http://127.0.0.1:8090/wallet/getpaginatedexchangelist -d\n'{\n \"offset\": 0,\n \"limit\": 10\n}'\n
Parameters:
offset: The index of the start exchange pairlimit: The amount of exchange pairs per page
Return: The list of exchange pairs by pagination
"},{"location":"api/http/#walletmarketsellasset","title":"wallet/marketsellasset","text":"Description\uff1aCreate an market order
curl -X POST http://127.0.0.1:8090/wallet/marketsellasset -d \n'{\n \"owner_address\": \"4184894b42f66dce8cb84aec2ed11604c991351ac8\",\n \"sell_token_id\": \"5f\",\n \"sell_token_quantity\": 100,\n \"buy_token_id\": \"31303030303031\",\n \"buy_token_quantity\": 200 \n}' \n
Parameters\uff1a owner_address\uff1aowner address, default hexString sell_token_id\uff1asell token id, default hexString sell_token_quantity\uff1asell token quantity buy_token_id\uff1abuy token id, default hexString buy_token_quantity\uff1abuy token quantity (min to receive)
Return\uff1aTransaction object
"},{"location":"api/http/#walletmarketcancelorder","title":"wallet/marketcancelorder","text":"Description\uff1aCancel the order
curl -X POST http://127.0.0.1:8090/wallet/marketcancelorder -d \n'{\n \"owner_address\": \"4184894b42f66dce8cb84aec2ed11604c991351ac8\",\n \"order_id\": \"0a7af584a53b612bcff1d0fc86feab05f69bc4528f26a4433bb344d453bd6eeb\"\n}' \n
Parameters\uff1a owner_address\uff1aowner address, default hexString order_id\uff1aorder id
Return\uff1aTransaction object
"},{"location":"api/http/#walletgetmarketorderbyaccount","title":"wallet/getmarketorderbyaccount","text":"Description\uff1aGet all orders for the account
curl -X POST http://127.0.0.1:8090/wallet/getmarketorderbyaccount -d \n'{\n \"value\": \"4184894b42f66dce8cb84aec2ed11604c991351ac8\" \n}' \n
Parameters\uff1avalue - owner address, default hexString Return\uff1aorder list
"},{"location":"api/http/#walletgetmarketpairlist","title":"wallet/getmarketpairlist","text":"Description\uff1aGet all trading pairs
curl -X get http://127.0.0.1:8090/wallet/getmarketpairlist\n
Parameters: N/A Return: makket pair list
"},{"location":"api/http/#walletgetmarketorderlistbypair","title":"wallet/getmarketorderlistbypair","text":"Description\uff1aGet all orders for the trading pair demo:
curl -X POST http://127.0.0.1:8090/wallet/getmarketorderlistbypair -d \n'{\n \"sell_token_id\": \"5f\" ,\n \"buy_token_id\": \"31303030303031\"\n}' \n
Parameters\uff1a sell_token_id\uff1asell token id, default hexString buy_token_id\uff1abuy token id, default hexString
Return\uff1aorder list
"},{"location":"api/http/#walletgetmarketpricebypair","title":"wallet/getmarketpricebypair","text":"Description\uff1aGet all prices for the trading pair
curl -X POST http://127.0.0.1:8090/wallet/getmarketpricebypair -d \n'{\n \"sell_token_id\": \"5f\" \n \"buy_token_id\": \"31303030303031\" \n}' \n
Parameters\uff1a sell_token_id\uff1asell token id, default hexString buy_token_id\uff1abuy token id, default hexString Return\uff1aprice list
"},{"location":"api/http/#walletgetmarketorderbyid","title":"wallet/getmarketorderbyid","text":"Description\uff1aGet all orders for the account
curl -X POST http://127.0.0.1:8090/wallet/getmarketorderbyid -d \n'{\n \"value\": \"orderid\" \n}' \n
Parameters\uff1avalue - order id, default hexString Return\uff1aorder
"},{"location":"api/http/#tronz-shielded-smart-contract","title":"TRONZ Shielded Smart Contract","text":"The following are TRONZ anonymous smart contract related APIs:
- wallet/getexpandedspendingkey
- wallet/getakfromask
- wallet/getnkfromnsk
- wallet/getspendingkey
- wallet/getdiversifier
- wallet/getincomingviewingkey
- wallet/getzenpaymentaddress
- wallet/createshieldedtransactionwithoutspendauthsig
- wallet/scannotebyivk
- wallet/scanandmarknotebyivk
- wallet/scannotebyovk
- wallet/createshieldnullifier
- wallet/getshieldtransactionhash
- wallet/createshieldedtransaction
- wallet/getnewshieldedaddress
- wallet/createshieldedcontractparameters
- wallet/createshieldedcontractparameterswithoutask
- wallet/scanshieldedtrc20notesbyivk
- wallet/scanshieldedtrc20notesbyovk
- wallet/isshieldedtrc20contractnotespent
- wallet/gettriggerinputforshieldedtrc20contract
- wallet/getrcm
- wallet/getmerkletreevoucherinfo
- wallet/isspend
- wallet/createspendauthsig
"},{"location":"api/http/#walletgetexpandedspendingkey","title":"wallet/getexpandedspendingkey","text":"Description: To get expanded spending keys from spending key
curl -X POST http://127.0.0.1:8090/wallet/getexpandedspendingkey -d\n'{\n \"value\": \"06b02aaa00f230b0887ff57a6609d76691369972ac3ba568fe7a8a0897fce7c4\"\n}'\n
Parameters: value:Spending key Return: Expanded spending keys, it consists of three keys: ask, nsk and ovk.
"},{"location":"api/http/#walletgetakfromask","title":"wallet/getakfromask","text":"Description: To get ak key from ask key
curl -X POST http://127.0.0.1:8090/wallet/getakfromask -d\n'{\n \"value\": \"653b3a3fdd40b60d2f53ba121df8840f6590384993f8fa9a0ecb0dfb23496604\"\n}'\n
Parameters: value:Ask Return:Ak
"},{"location":"api/http/#walletgetnkfromnsk","title":"wallet/getnkfromnsk","text":"Description: To get nk key from nsk key
curl -X POST http://127.0.0.1:8090/wallet/getnkfromnsk -d\n'{\n \"value\": \"428ff3c9e101dc1fca08f7b0e3387b23b68016746ae565aefc19d112b696db01\"\n}'\n
Parameters: value:Nsk Return:Nk
"},{"location":"api/http/#walletgetspendingkey","title":"wallet/getspendingkey","text":"Description: To get spending key
curl -X GET http://127.0.0.1:8090/wallet/getspendingkey\n
Parameters: N/A Return:Spending key
"},{"location":"api/http/#walletgetdiversifier","title":"wallet/getdiversifier","text":"Description: To get diversifier
curl -X GET http://127.0.0.1:8090/wallet/getdiversifier\n
Parameters: N/A Return: Diversifier
"},{"location":"api/http/#walletgetincomingviewingkey","title":"wallet/getincomingviewingkey","text":"Description: To get incoming viewing key
curl -X POST http://127.0.0.1:8090/wallet/getincomingviewingkey -d\n'{\n \"ak\":\"b443f1a303ef5837ba95750b48b6fef15f9c77f63a8c28c161bcd6613f423b5c\",\n \"nk\":\"632137e69179df3d10e252fcce85d13464c3163fe7a619edf8d43ebefa8162d9\"\n }'\n
Parameters: ak:Aknk:Nk
Return:Incoming viewing key
"},{"location":"api/http/#walletgetzenpaymentaddress","title":"wallet/getzenpaymentaddress","text":"Description: To get payment address
curl -X POST http://127.0.0.1:8090/wallet/getzenpaymentaddress -d\n'{\n \"ivk\":\"8c7852e10862d8eec058635974f70f24c1f8d73819131bb5b54028d0a9408a03\",\n \"d\":\"736ba8692ed88a5473e009\"\n }'\n
Parameters: ivk:Ivkd:D
Return: Payment address
"},{"location":"api/http/#walletcreateshieldedtransactionwithoutspendauthsig","title":"wallet/createshieldedtransactionwithoutspendauthsig","text":"Description: To create shielded transaction without using ask
$ curl -X POST http://127.0.0.1:8090/wallet/createshieldedtransactionwithoutspendauthsig -d\n'{\n \"ivk\":\"8c7852e10862d8eec058635974f70f24c1f8d73819131bb5b54028d0a9408a03\",\n \"d\":\"736ba8692ed88a5473e009\"\n }'\n
Parameters:
transparent_from_address: Transparent sender's addressfrom_amount: Send amount from transparent addressask: Asknsk: Nskovk: Ovkshielded_receives: Shielded receive informationshieldedSpends: Shielded spend informationtransparent_to_address: Transparent receiver's addressto_amount: Send amount to transparent address
Return: Transaction object
"},{"location":"api/http/#walletcreateshieldedtransactionwithoutspendauthsig_1","title":"wallet/createshieldedtransactionwithoutspendauthsig","text":"Description: To create shielded transaction with using ask
curl -X POST http://127.0.0.1:8090/wallet/createshieldedtransactionwithoutspendauthsig -d\n'{\n \"ak\": \"bf051629fd8122cd9dd8591d72947b026c214cf7cdac1f68eff97179727d38e9\",\n \"nsk\": \"42963d26af8122204273fa3489d9efd6babf1f7179ff193c955a1f3d9c2df10c\",\n \"ovk\": \"bc9848a83966709655b12efadc9e978785858316045e0115a0e72567a9a2a823\",\n \"shielded_spends\": [\n {\n \"note\": {\n \"value\": 500000000,\n \"payment_address\": \"ztron1jld8fmvujrz2vgkc867zuwklmewy4ypw0wtwgweqs2paee0uhc8f3azy90el770arksa2kunl02\",\n \"rcm\": \"723053bcbfecdf5da66c18ab0376476ef308c61b7abe891b2c01e903bcb87c0e\"\n },\n \"alpha\": \"2608999c3a97d005a879ecdaa16fd29ae434fb67b177c5e875b0c829e6a1db04\",\n \"voucher\": {\n \"tree\": {\n \"left\": {\n \"content\": \"a3d5c9b2db9699f32afec5febbd5586ce9ff33a0bef6fee5691028313b8e1f6a\"\n },\n \"parents\": [\n {\n \"content\": \"d9c38484296b3aa8f5e8b59d418a3775e2bb414e75498ad352e4614f05aae548\"\n },\n {\n \"content\": \"d0420777afdc4151c3f14fbe4c714d82dc15873edb1ca65ebb3887334a4bae15\"\n }\n ]\n },\n \"rt\": \"fb1115d5ddd16c5427c3a608d6b5add5967e70f51c890307c6142083a2c28565\"\n },\n \"path\": \"2020b2eed031d4d6a4f02a097f80b54cc1541d4163c6b6f5971f88b6e41d35c538142012935f14b676509b81eb49ef25f39269ed72309238b4c145803544b646dca62d20e1f34b034d4a3cd28557e2907ebf990c918f64ecb50a94f01d6fda5ca5c7ef722028e7b841dcbc47cceb69d7cb8d94245fb7cb2ba3a7a6bc18f13f945f7dbd6e2a20a5122c08ff9c161d9ca6fc462073396c7d7d38e8ee48cdb3bea7e2230134ed6a20d2e1642c9a462229289e5b0e3b7f9008e0301cbb93385ee0e21da2545073cb582016d6252968971a83da8521d65382e61f0176646d771c91528e3276ee45383e4a20fee0e52802cb0c46b1eb4d376c62697f4759f6c8917fa352571202fd778fd712204c6937d78f42685f84b43ad3b7b00f81285662f85c6a68ef11d62ad1a3ee0850200769557bc682b1bf308646fd0b22e648e8b9e98f57e29f5af40f6edb833e2c492008eeab0c13abd6069e6310197bf80f9c1ea6de78fd19cbae24d4a520e6cf3023208d5fa43e5a10d11605ac7430ba1f5d81fb1b68d29a640405767749e841527673206aca8448d8263e547d5ff2950e2ed3839e998d31cbc6ac9fd57bc6002b15921620cd1c8dbf6e3acc7a80439bc4962cf25b9dce7c896f3a5bd70803fc5a0e33cf00206edb16d01907b759977d7650dad7e3ec049af1a3d875380b697c862c9ec5d51c201ea6675f9551eeb9dfaaa9247bc9858270d3d3a4c5afa7177a984d5ed1be245120d6acdedf95f608e09fa53fb43dcd0990475726c5131210c9e5caeab97f0e642f20bd74b25aacb92378a871bf27d225cfc26baca344a1ea35fdd94510f3d157082c201b77dac4d24fb7258c3c528704c59430b630718bec486421837021cf75dab65120ec677114c27206f5debc1c1ed66f95e2b1885da5b7be3d736b1de98579473048204777c8776a3b1e69b73a62fa701fa4f7a6282d9aee2c7a6b82e7937d7081c23c20ba49b659fbd0b7334211ea6a9d9df185c757e70aa81da562fb912b84f49bce722043ff5457f13b926b61df552d4e402ee6dc1463f99a535f9a713439264d5b616b207b99abdc3730991cc9274727d7d82d28cb794edbc7034b4f0053ff7c4b68044420d6c639ac24b46bd19341c91b13fdcab31581ddaf7f1411336a271f3d0aa52813208ac9cf9c391e3fd42891d27238a81a8a5c1d3a72b1bcbea8cf44a58ce738961320912d82b2c2bca231f71efcf61737fbf0a08befa0416215aeef53e8bb6d23390a20e110de65c907b9dea4ae0bd83a4b0a51bea175646a64c12b4c9f931b2cb31b4920d8283386ef2ef07ebdbb4383c12a739a953a4d6e0d6fb1139a4036d693bfbb6c20d0420777afdc4151c3f14fbe4c714d82dc15873edb1ca65ebb3887334a4bae1520d9c38484296b3aa8f5e8b59d418a3775e2bb414e75498ad352e4614f05aae5482001000000000000000000000000000000000000000000000000000000000000000600000000000000\"\n }\n ],\n \"shielded_receives\": [\n {\n \"note\": {\n \"value\": 40000000,\n \"payment_address\": \"ztron1wd46s6fwmz99gulqpxul6zffqtevzfpl93ng3s5834fhwf6e7w5l6zmjhmpvtwsc4wxa7dusmvr\",\n \"rcm\": \"ccced07d36641fc93cba33cddda7064cb82f6962a0bdf15a4240a4a742770e03\"\n }\n }\n ]\n}'\n
Parameters: transparent_from_address: Transparent sender's addressfrom_amount: Send amount from transparent addressak: Aknsk: Nskovk: Ovkshielded_receives: Shielded receive informationshieldedSpends: Shielded spend informationtransparent_to_address: Transparent receiver's addressto_amount: Send amount to transparent address
Return: Transaction object
"},{"location":"api/http/#walletscannotebyivk","title":"wallet/scannotebyivk","text":"Description: To get all the notes by ivk
$ curl -X POST http://127.0.0.1:8090/wallet/scannotebyivk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ivk\": \"80a481c3c739e54b4e0608090b3a1a6e9f8dce42346e95bf5a2d8a487bf45c05\"\n}'\n
Parameters:
start_block_index: The start block height, itself includedend_block_index: The end block height, itself not includedivk: Incoming viewing key
Return: Notes list
Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletscanandmarknotebyivk","title":"wallet/scanandmarknotebyivk","text":"Description: To get all the notes with spent status by ivk
$ curl -X POST http://127.0.0.1:8090/wallet/scanandmarknotebyivk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ivk\": \"80a481c3c739e54b4e0608090b3a1a6e9f8dce42346e95bf5a2d8a487bf45c05\",\n \"ak\": \"1d4f9b5551f4aa9443ceb263f0e208eb7e26080264571c5ef06de97a646fe418\",\n \"nk\": \"748522c7571a9da787e43940c9a474aa0c5c39b46c338905deb6726fa3678bdb\"\n}'\n
Parameters:
start_block_index: The start block height, itself includedend_block_index: The end block height, itself not includedivk: Incoming viewing keyak: Ak keynk: Nk key
Return: Notes list
Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletscannotebyovk","title":"wallet/scannotebyovk","text":"Description: To get all the notes by ovk
$ curl -X POST http://127.0.0.1:8090/wallet/scannotebyovk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ovk\": \"705145aa18cbe6c11d5d0011419a98f3d5b1d341eb4727f1315597f4bdaf8539\"\n}'\n
Parameters:
start_block_index: The start block height, itself includedend_block_index: The end block height, itself not includedovk: Outgoing viewing key
Return: Notes list
Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletcreateshieldnullifier","title":"wallet/createshieldnullifier","text":"Description: To create a shielded nullifier
$ curl -X POST http://127.0.0.1:8090/wallet/createshieldnullifier -d\n'{\n \"note\": {\n \"payment_address\": \"ztron1aqgauawtkelxfu2w6s48cwh0mchjt6kwpj44l4wym3pullx0294j4r4v7kpm75wnclzycsw73mq\",\n \"rcm\": \"74a16c1b27ec7fbf06881d9d35ddaab1554838b1bddcd54f6bd8a9fb4ba0b80a\",\n \"value\": 500000000\n },\n \"voucher\": {\n \"tree\": {\n \"left\": {\n \"content\": \"a4d763fae3fee78964ccdf7567ec3062c95a5b97825d731202d3dfa6cb01c143\"\n }\n },\n \"rt\": \"7dc3652c2a16e8518a8be0e3e038f9d28c3eb96f13e8da8acc2a9b650702f33e\"\n },\n \"ak\": \"a3e65d509b675aaa2aeda977ceff11eebd76218079b6f543d78a615e396ca129\",\n \"nk\": \"62cfda9bea09a53cf2a21022057913734a8458969e11e0bb9c59ead48fbce83e\"\n}'\n
Parameters:
note: Note informationvoucher: Voucher informationak: Aknk: Nk
Return: A shielded nullifier
"},{"location":"api/http/#walletgetshieldtransactionhash","title":"wallet/getshieldtransactionhash","text":"Description: To get a shielded transaction hash
curl -X POST http://127.0.0.1:8090/wallet/getshieldtransactionhash -d\n'{\n \"txID\": \"de639a64497d86bb27e34a2953093a0cc488ec4c7bc9624ac5857d3799748595\",\n \"raw_data\": {\n \"contract\": [\n {\n \"parameter\": {\n \"value\": {\n \"binding_signature\": \"2b8ae5e11ecad3e6946f54b7ad513bd8692a3edae72d29e266b28e47c9b37ccdb38e3b6433575694b6681136b1734f85afcfe672061d2ee7368755ad0b96a80b\",\n \"spend_description\": [\n {\n \"value_commitment\": \"cbe1063adbe7e10919421fa6133f03150253913f5aff02d165e2c019cea4a869\",\n \"anchor\": \"fb1115d5ddd16c5427c3a608d6b5add5967e70f51c890307c6142083a2c28565\",\n \"nullifier\": \"93e329d464e1dbddc8bb4d2dcc939a796dfe11e985d4e9033a15edf0e3df4f35\",\n \"rk\": \"10c702d6dff1509502ee5acc0b01d4b4531b2ff53b0dd54488aea6031b5e6d16\",\n \"zkproof\": \"abf64b3beacfd873b1db764c3da9f739993518f3f740e761cb8af60682b7171892895c3ccfb550c3cf757e906dbf5313a3676b8226b0b84960f76a185c8d3fdfc3fa9c08479a704852d7b3dfeb913cf13e01c25657561e00a06c61e7c65b50b812902ddc4f17bfe2bcb2f247c2dc6132d0f0e0abcecc0332fdd99077af10d07bbdb88c4fd257948428e233c57f84eee8b2eeab2162c1aeccf2e1dfaa306d5803a8b2d281a549440fbd5a3657a830c1ca07a384cea446aa077b195b29b23023b1\"\n }\n ],\n \"receive_description\": [\n {\n \"value_commitment\": \"f6d45db8ec5a1c8dbbde040b4ea138efbe8db2d0597ed2306ff3fdd0620b3c5a\",\n \"note_commitment\": \"ec3f5472ac8114a9a07987d1c2a0e1254504e352d9574971e77084293900312e\",\n \"epk\": \"719eeb5ebaeeccc55c9f0d73767aadf0c0513603400ccb50bd789637d984b8e6\",\n \"c_enc\": \"3a6c4fe0e79f5b23fed34a419c4728d0b26bca23180a22871743b0a9444c27663cf07c55a0ea6db504d70421768bf17384e180b2ad8b8be88ff5cf662c53a4ba086effc3a4b1df39265f71dfac884bff5a69e1dcdcae8aecf6ae443168ffab692a5c1e4908b415dd830dcf6432fae1c32461132080da74d6b83d3d00887eb2ce9965a749f8d8410ea4182969371ac2fd5e0e74d27d883492a08e6209cd9959d74bb67c2a9fe7faac5a4777f1bff19cf0b6398a2faa9b194bbb93d60f132f382f7d693a722e8cbca1da084ee7e0c371397419a7259d1fa0943078cfe5ea352e4b53907bb6c04ca8ad409fb0ae0b110a6b312200e21ab79d543ae7aeb16802cf87afdac1e8954038caa42818f4ca2847fd642360c098accfeeade4abd1cc9ca3315a4336be224ba3516973c7dae3f41875457236675993df38d3a544470c4f9335d77b005e6a9aec40fd881b34852ec9bbbcc3d24ee92930eae770a5462ce04c4e37b0524ef07e00e8d58c810d6aefb19fa7bc2c3a2fdfab6dd4fe73dbecc0795a280f9b7ca35cc8bc1062aed8e26bd81ba33c6f4c318974636f6d796723e77772ced3dbc1f42afec6fc9bb61f8beac704affea9baf2e2de226250c1d427c7d78b1eb1d239e1f3eb6af0f017b80541333f4fce17340048d826b9b0be8477c996ad8bfc3440dc686fdff6d0d63986db4d95962d7977289cbfd14c745de7c79d4dc0bcd220e5b4ced5b409e79142e0f336e44ca29a9a87f6f43707d8c4936e895236dd2b393a478a8bc27b1f682496ba84a0ddc549da06cb7855c4d8680dc66ac40240733b7f\",\n \"c_out\": \"50be6e77854d4c427b2af4f16e5275f0b0c206b3ea2d2a24ffb287ea356f323523354cd83d15e7c48e6f1fa103dfca3d49ca2263dbb0cd8bfb35d72cdcad1351de6fba7a30aea27184a68bcda19cc6da\",\n \"zkproof\": \"a4e6c50d5753092d005689922c2bdeafc98775bce59db840974163ace23c13fec18112e32aae1c39842c645ed172ad8fa277e63c1e3d6d7fb12eb15d56b573237b776f562a81d0e6be362d147d8604fdfec421482270ca82950de1883fda06e719f5d256d7a039769bffc570a1778d70c17295d1c0336a6ae0903d2460dc139a9563c2d40f37bffefa73003a55af1ff0861b6f79ef40099b6a0cb25ab3f40727210e4629647d0711abff125712a5f0d64fcb6e6a6b0b34478d7da0552b493a80\"\n }\n ]\n },\n \"type_url\": \"type.googleapis.com/protocol.ShieldedTransferContract\"\n },\n \"type\": \"ShieldedTransferContract\"\n }\n ],\n \"ref_block_bytes\": \"0d59\",\n \"ref_block_hash\": \"7356ce5c35d8265e\",\n \"expiration\": 1559237283000,\n \"timestamp\": 1559201285590\n },\n \"raw_data_hex\": \"0a020d5922087356ce5c35d8265e40b899a3ceb02d5a940b0833128f0b0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e747261637412d50a1acb020a20cbe1063adbe7e10919421fa6133f03150253913f5aff02d165e2c019cea4a8691220fb1115d5ddd16c5427c3a608d6b5add5967e70f51c890307c6142083a2c285651a2093e329d464e1dbddc8bb4d2dcc939a796dfe11e985d4e9033a15edf0e3df4f35222010c702d6dff1509502ee5acc0b01d4b4531b2ff53b0dd54488aea6031b5e6d162ac001abf64b3beacfd873b1db764c3da9f739993518f3f740e761cb8af60682b7171892895c3ccfb550c3cf757e906dbf5313a3676b8226b0b84960f76a185c8d3fdfc3fa9c08479a704852d7b3dfeb913cf13e01c25657561e00a06c61e7c65b50b812902ddc4f17bfe2bcb2f247c2dc6132d0f0e0abcecc0332fdd99077af10d07bbdb88c4fd257948428e233c57f84eee8b2eeab2162c1aeccf2e1dfaa306d5803a8b2d281a549440fbd5a3657a830c1ca07a384cea446aa077b195b29b23023b122c2070a20f6d45db8ec5a1c8dbbde040b4ea138efbe8db2d0597ed2306ff3fdd0620b3c5a1220ec3f5472ac8114a9a07987d1c2a0e1254504e352d9574971e77084293900312e1a20719eeb5ebaeeccc55c9f0d73767aadf0c0513603400ccb50bd789637d984b8e622c4043a6c4fe0e79f5b23fed34a419c4728d0b26bca23180a22871743b0a9444c27663cf07c55a0ea6db504d70421768bf17384e180b2ad8b8be88ff5cf662c53a4ba086effc3a4b1df39265f71dfac884bff5a69e1dcdcae8aecf6ae443168ffab692a5c1e4908b415dd830dcf6432fae1c32461132080da74d6b83d3d00887eb2ce9965a749f8d8410ea4182969371ac2fd5e0e74d27d883492a08e6209cd9959d74bb67c2a9fe7faac5a4777f1bff19cf0b6398a2faa9b194bbb93d60f132f382f7d693a722e8cbca1da084ee7e0c371397419a7259d1fa0943078cfe5ea352e4b53907bb6c04ca8ad409fb0ae0b110a6b312200e21ab79d543ae7aeb16802cf87afdac1e8954038caa42818f4ca2847fd642360c098accfeeade4abd1cc9ca3315a4336be224ba3516973c7dae3f41875457236675993df38d3a544470c4f9335d77b005e6a9aec40fd881b34852ec9bbbcc3d24ee92930eae770a5462ce04c4e37b0524ef07e00e8d58c810d6aefb19fa7bc2c3a2fdfab6dd4fe73dbecc0795a280f9b7ca35cc8bc1062aed8e26bd81ba33c6f4c318974636f6d796723e77772ced3dbc1f42afec6fc9bb61f8beac704affea9baf2e2de226250c1d427c7d78b1eb1d239e1f3eb6af0f017b80541333f4fce17340048d826b9b0be8477c996ad8bfc3440dc686fdff6d0d63986db4d95962d7977289cbfd14c745de7c79d4dc0bcd220e5b4ced5b409e79142e0f336e44ca29a9a87f6f43707d8c4936e895236dd2b393a478a8bc27b1f682496ba84a0ddc549da06cb7855c4d8680dc66ac40240733b7f2a5050be6e77854d4c427b2af4f16e5275f0b0c206b3ea2d2a24ffb287ea356f323523354cd83d15e7c48e6f1fa103dfca3d49ca2263dbb0cd8bfb35d72cdcad1351de6fba7a30aea27184a68bcda19cc6da32c001a4e6c50d5753092d005689922c2bdeafc98775bce59db840974163ace23c13fec18112e32aae1c39842c645ed172ad8fa277e63c1e3d6d7fb12eb15d56b573237b776f562a81d0e6be362d147d8604fdfec421482270ca82950de1883fda06e719f5d256d7a039769bffc570a1778d70c17295d1c0336a6ae0903d2460dc139a9563c2d40f37bffefa73003a55af1ff0861b6f79ef40099b6a0cb25ab3f40727210e4629647d0711abff125712a5f0d64fcb6e6a6b0b34478d7da0552b493a802a402b8ae5e11ecad3e6946f54b7ad513bd8692a3edae72d29e266b28e47c9b37ccdb38e3b6433575694b6681136b1734f85afcfe672061d2ee7368755ad0b96a80b70d68b8ebdb02d\"\n}'\n
Parameter transaction: Transaction object
Return: a shielded transaction hash
"},{"location":"api/http/#walletcreateshieldedtransaction","title":"wallet/createshieldedtransaction","text":"Description: To create shielded transaction Please refer to The Demo
Parameters:
transparent_from_address: Transparent sender's addressfrom_amount: Send amount from transparent addressask: Asknsk: Nskovk: Ovkshielded_receives: Shielded receive informationshieldedSpends: Shielded spend informationtransparent_to_address: Transparent receiver's addressto_amount: Send amount to transparent address
Return: Transaction object
"},{"location":"api/http/#walletgetnewshieldedaddress","title":"wallet/getnewshieldedaddress","text":"Description: To get new shieldedAddress
curl -X GET http://127.0.0.1:8090/wallet/getnewshieldedaddress\n
Parameters: N/A Return: Spending key Ask key Nsk key Outgoing viewing key Ak Key Nk key incoming viewing key Diversifier pkD payment address"},{"location":"api/http/#walletcreateshieldedcontractparameters","title":"wallet/createshieldedcontractparameters","text":"Description: create the shielded TRC-20 transaction parameters, which has three types: mint, transfer and burn
demo: curl -X POST http://127.0.0.1:8090/wallet/createshieldedcontractparameters -d\n'{ \n \"ask\": \"0f63eabdfe2bbfe08012f6bb2db024e6809c16e8ed055aa41a6095424f192005\",\n \"nsk\": \"cd43d722fd4b6b01f19449ea826c3e935609648520fcc2a95c0026f0fa9ee404\",\n \"ovk\": \"1797de3b7f33cafffe3fe18c6b43ec6760add2ad81b10978d1fca5290497ede9\",\n \"from_amount\": \"5000\",\n \"shielded_receives\": {\n \"note\": {\n \"value\": 50,\n \"payment_address\": \"ztron15js0jkuxczt8caq5hp59rnh6rgf34sek7vqn9u6ljelxv4nuzz2x9qe3ffm2wzz6ck53yxyhxs6\",\n \"rcm\": \"74baec30dfac8ed59968955ff245ae002009005194e5b824c35ab88c52e5170e\"\n }\n },\n \"shielded_TRC20_contract_address\": \"41f3392eaa7d38749176e0671dbc6912f8ef956943\"\n }'\n
Parameters:
ask: Asknsk: Nskovk: Outgoing view keyfrom_amount: the amount for mint, which is scaled by scalingfactor with note value, namely from_amount = value * scalingFactor. In the above example, the value of scalingFactor is 100shielded_receives: the shielded notes to be createdshielded_TRC20_contract_address: shielded TRC-20 contract address
Return: the shielded TRC-20 transaction parameters
Note: the input parameters will differ according to the variety of shielded TRC-20 transaction type
"},{"location":"api/http/#walletcreateshieldedcontractparameterswithoutask","title":"wallet/createshieldedcontractparameterswithoutask","text":"Description: create the shielded TRC-20 transaction parameters without Ask, which has three types: mint, transfer and burn
demo: curl -X POST http://127.0.0.1:8090/wallet/createshieldedcontractparameterswithoutask -d\n'{\n \"ovk\": \"cd361834b3adc06f130de24f7d0c18f92a093cc885d9ce492cc6c02071f7a4f0\",\n \"from_amount\": \"5000\",\n \"shielded_receives\": {\n \"note\": {\n \"value\": 50,\n \"payment_address\": \"ztron13lvfnt4rau4ad9mmgztd3aftw49e3amz8gm2kvyzrsaw0ugz2grxwkvcfys5e2gkchj7cnnetjz\",\n \"rcm\": \"499e73f2f8aaf05fac41a35b8343bde27f6629cbe66d35da5364a99b94a55a06\"\n }\n },\n \"shielded_TRC20_contract_address\": \"41f3392eaa7d38749176e0671dbc6912f8ef956943\"\n }'\n
Parameters:
ovk: Outgoing view keyfrom_amount: the amount for mint, which is scaled by scalingfactor with note value, namely from_amount = value * scalingFactor. In the above example, the value of scalingFactor is 100shielded_receives: the shielded notes to be createdshielded_TRC20_contract_address: shielded TRC-20 contract address
Return: the shielded TRC-20 transaction parameters
Note: the input parameters will differ according to the variety of shielded TRC-20 transaction type
"},{"location":"api/http/#walletscanshieldedtrc20notesbyivk","title":"wallet/scanshieldedtrc20notesbyivk","text":"Description: scan the shielded TRC-20 notes by ivk and mark their status of whether spent
demo: curl -X POST http://127.0.0.1:8090/wallet/scanshieldedtrc20notesbyivk -d\n'{\n \"start_block_index\": 9200,\n \"end_block_index\": 9240,\n \"shielded_TRC20_contract_address\": \"41274fc7464fadac5c00c893c58bce6c39bf59e4c7\",\n \"ivk\": \"9f8e74bb3d7188a2781dc1db38810c6914eef4570a79e8ec8404480948e4e305\",\n \"ak\":\"8072d9110c9de9d9ade33d5d0f5890a7aa65b0cde42af7816d187297caf2fd64\",\n \"nk\":\"590bf33f93f792be659fd404df91e75c3b08d38d4e08ee226c3f5219cf598f14\"\n}'\n
Parameters:
start_block_index: the start block index, inclusiveend_block_index: the end block index, exclusiveshielded_TRC20_contract_address: shielded TRC-20 contract addressivk: Incoming viewing keyak: Ak keynk: Nk key
Return: notes list
Note: block limit\uff08end_block_index - start_block_index <= 1000\uff09
"},{"location":"api/http/#walletscanshieldedtrc20notesbyovk","title":"wallet/scanshieldedtrc20notesbyovk","text":"Description: scan the shielded TRC-20 notes by ovk
demo: curl -X POST http://127.0.0.1:8090/wallet/scanshieldedtrc20notesbyovk -d\n'{\n \"start_block_index\": 9200,\n \"end_block_index\": 9240,\n \"shielded_TRC20_contract_address\": \"41274fc7464fadac5c00c893c58bce6c39bf59e4c7\",\n \"ovk\": \"0ff58efd75e083fe4fd759c8701e1c8cb6961c4297a12b2c800bdb7b2bcab889\"\n}'\n
Parameters:
start_block_index: start block index, inclusiveend_block_index: end block index, exclusiveshielded_TRC20_contract_address: shielded TRC-20 contract addressovk: Outgoing viewing key
Return: notes list
Note: block limit\uff08end_block_index - start_block_index <= 1000\uff09
"},{"location":"api/http/#walletisshieldedtrc20contractnotespent","title":"wallet/isshieldedtrc20contractnotespent","text":"Description: check the status whether the specified shielded TRC-20 note is spent
Parameters:
note: the specified noteak: Aknk: Nkposition: the leaf position index of note commitment in the Merkle treeshielded_TRC20_contract_address: the shielded TRC-20 contract address
Return: note status
Note: the value in note is the scaled value by scalingFactor set in the shielded TRC-20 contract, namely real_amount = value * scalingFactor.
"},{"location":"api/http/#walletgettriggerinputforshieldedtrc20contract","title":"wallet/gettriggerinputforshieldedtrc20contract","text":"Description: get the trigger input data of shielded TRC-20 contract for the shielded TRC-20 parameters without spend authority signature.
demo: curl -X POST http://127.0.0.1:8090/wallet/gettriggerinputforshieldedtrc20contract -d\n'{ \n \"shielded_TRC20_Parameters\": {\"spend_description\": [{\"value_commitment\": \"e3fcc8609ff6a4b00b77a00ef624f305cec5f55cc7312ff5526d0b3057f2ef9e\",\"anchor\": \"4c9cbebece033dc1d253b93e4a3682187daae4f905515761d10287b801e69816\",\"nullifier\": \"74edce8798a3976ee41e045bb666f3a121c27235b0f1b44b3456d2c84bc725dc\",\"rk\": \"9dcf4254aa7c4fb7c8bc6956d4b0c7c6c87c37a2552e7bf4e60c12cb5bc6c8cd\",\"zkproof\": \"9926045cd1442a7d20153e6abda9f77a6526895f0a29a57cb1bc76ef6b7cacef2d0f4c94aa97c3acacdb95cabb065057b7edb4cbea098149a8aa7114a6a6b340c58007ac64b64e592eb18fdd299de5962a2a32ab0caebb2ab198704c751a9d0e143d68a50257d7c9e2230a7420fa46450299fd167141367e201726532d8e815413d8571d6c8c12937674dec92caf1f4583ebe560ac4c7eba290deee0a1c0da5f72c0b9df89fb3b338c683b654b3dc2373a4c2a4fef7f4fa489b44405fb7d2bfb\"}],\"binding_signature\": \"11e949887d9ec92eb32c78f0bc48afdc9a16a2ecbd5a0eca1be070fb900eeda347918bd6e9521d4baf1f74963bee0c1956559623a9e7cbc886941b227341ea06\",\"message_hash\": \"7e6a00736c4f9e0036cb74c7fa3b1e3cd8f6bf0f038edeb03b668c4c5536a357\",\"parameter_type\": \"burn\"},\n \"spend_authority_signature\": [\n {\n \"value\": \"eeaaecd725ac80ec398b95cf188b769c1be66cc8e76e6c90843b7f23818704595719ce8bf694ffb8cd7aaa8739d50fe8eea7ba39d5026c4b019c973185ca7201\"\n }\n ],\n \"amount\": \"6000\",\n \"transparent_to_address\": \"4140cd765f8e637a2bbe00f9bc458f6b21eb0e648f\"\n }'\n
Parameters:
shielded_TRC20_Parameters: the generated shielded TRC-20 parametersspend_authority_signature: the spend authority signaturesamount: the amount transparent_to_address: the receiver for the burn operation.
Return: the input data for triggering shielded TRC-20 contract.
"},{"location":"api/http/#walletgetrcm","title":"wallet/getrcm","text":"Description: To get a random commitment trapdoor
curl -X GET http://127.0.0.1:8090/wallet/getrcm\n
Parameters: N/A Return:rcm
"},{"location":"api/http/#walletgetmerkletreevoucherinfo","title":"wallet/getmerkletreevoucherinfo","text":"Description: To get a merkle tree information of a note
$ curl -X POST http://127.0.0.1:8090/wallet/getmerkletreevoucherinfo -d\n'{\n \"out_points\":[{\n \"hash\":\"185b3e085723f5862b3a3c3cf54d52f5c1eaf2541e3a1e0ecd08bc12cd958d74\",\n \"index\":0\n }]\n}'\n
Parameter out_points: Note information
Return: A merkle tree of a note
"},{"location":"api/http/#walletisspend","title":"wallet/isspend","text":"Description: To check whether a note is spent or not
$ curl -X POST http://127.0.0.1:8090/wallet/isspend -d\n'{\n \"ak\": \"a3e65d509b675aaa2aeda977ceff11eebd76218079b6f543d78a615e396ca129\",\n \"nk\": \"62cfda9bea09a53cf2a21022057913734a8458969e11e0bb9c59ead48fbce83e\",\n \"note\": {\n \"payment_address\": \"ztron1aqgauawtkelxfu2w6s48cwh0mchjt6kwpj44l4wym3pullx0294j4r4v7kpm75wnclzycsw73mq\",\n \"rcm\": \"74a16c1b27ec7fbf06881d9d35ddaab1554838b1bddcd54f6bd8a9fb4ba0b80a\",\n \"value\": 500000000\n },\n \"txid\": \"7d09e471bb047d3ac044d5d6691b3721a2dddbb683ac02c207fbe78af6302463\",\n \"index\": 1\n}'\n
Parameters:
ak: Ak keynk: Nk keynote: Note informationtxid: Transaction idindex: Note index
Return: Note status
"},{"location":"api/http/#walletcreatespendauthsig","title":"wallet/createspendauthsig","text":"Description: To create a signature for a transaction
$ curl -X POST http://127.0.0.1:8090/wallet/createspendauthsig -d\n'{\n \"ask\": \"e3ebcba1531f6d9158d9c162660c5d7c04dadf77d85d7436a9c98b291ff69a09\",\n \"tx_hash\": \"3b78fee6e956f915ffe082284c5f18640edca9c57a5f227e5f7d7eb65ad61502\",\n \"alpha\": \"2608999c3a97d005a879ecdaa16fd29ae434fb67b177c5e875b0c829e6a1db04\"\n}'\n
Parameters:
ask: Ask keytx_hash: Transaction hashalpha: Alpha
Return: A signature
"},{"location":"api/http/#pending-pool","title":"Pending Pool","text":"The following are Pending Pool related APIs:
- wallet/gettransactionfrompending
- wallet/gettransactionlistfrompending
- wallet/getpendingsize
"},{"location":"api/http/#walletgettransactionfrompending","title":"wallet/gettransactionfrompending","text":"Get transaction details from the pending pool
curl -X POST http://127.0.0.1:8090/wallet/gettransactionfrompending -d\n'{\n \"value\": \"txId\"\n}'\n
Parameters: value: transaction id Return: Transaction details
"},{"location":"api/http/#walletgettransactionlistfrompending","title":"wallet/gettransactionlistfrompending","text":"Get transaction list information from pending pool
curl -X get http://127.0.0.1:8090/wallet/gettransactionlistfrompending\n
Parameters: N/A Return: Pending transaction IDs in the pool
"},{"location":"api/http/#walletgetpendingsize","title":"wallet/getpendingsize","text":"Get the size of the pending pool queue
curl -X get http://127.0.0.1:8090/wallet/getpendingsize\n
Parameters: N/A Return:pending pool size
"},{"location":"api/http/#fullnode-solidity-http-api","title":"FullNode Solidity HTTP API","text":""},{"location":"api/http/#account-resources_1","title":"Account Resources","text":""},{"location":"api/http/#walletsoliditygetaccount","title":"walletsolidity/getaccount","text":"Description: Query an account information
curl -X POST http://127.0.0.1:8091/walletsolidity/getaccount -d '{\"address\": \"41E552F6487585C2B58BC2C9BB4492BC1F17132CD0\"}'\n
Parameters: address - Account to query, default hexString Return: Account object
"},{"location":"api/http/#walletsoliditygetdelegatedresource","title":"walletsolidity/getdelegatedresource","text":"Description: Query the energy delegation information
curl -X POST http://127.0.0.1:8091/walletsolidity/getdelegatedresource -d '\n{\n\"fromAddress\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n\"toAddress\": \"41c6600433381c731f22fc2b9f864b14fe518b322f\"\n}'\n
Parameters: fromAddress: Energy from address, default hexStringtoAddress: Energy to address, default hexString
Return: Energy delegation information list, the elements of the list is DelegatedResource
"},{"location":"api/http/#walletsoliditygetdelegatedresourceaccountindex","title":"walletsolidity/getdelegatedresourceaccountindex","text":"Description: Query the energy delegation index by an account
curl -X POST http://127.0.0.1:8091/walletsolidity/getdelegatedresourceaccountindex -d '\n{\n\"value\": \"419844f7600e018fd0d710e2145351d607b3316ce9\",\n}'\n
Parameters: value: Address, default hexString
Return: DelegatedResourceAccountIndex of the address
"},{"location":"api/http/#walletsoliditygetaccountbyid","title":"walletsolidity/getaccountbyid","text":"Description: Query an account information by account id
curl -X POST http://127.0.0.1:8091/walletsolidity/getaccountbyid -d '{\"account_id\":\"6161616162626262\"}'\n
Parameters: account_id - Account id, default hexString Return: Account object
"},{"location":"api/http/#walletsoliditygetavailableunfreezecount","title":"walletsolidity/getavailableunfreezecount","text":"Description:Remaining times of executing unstake operation in Stake2.0
curl -X POST http://127.0.0.1:8090/walletsolidity/getavailableunfreezecount -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account address
Return:Remaining times of available unstaking.
"},{"location":"api/http/#walletsoliditygetcanwithdrawunfreezeamount","title":"walletsolidity/getcanwithdrawunfreezeamount","text":"Description: Query the withdrawable balance at the specified timestamp In Stake2.0
curl -X POST http://127.0.0.1:8090/walletsolidity/getcanwithdrawunfreezeamount -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"timestamp\": 1667977444000,\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account addresstimestamp: query cutoff timestamp, in milliseconds.
Return: Withdrawable balance, unit is sun.
"},{"location":"api/http/#walletsoliditygetcandelegatedmaxsize","title":"walletsolidity/getcandelegatedmaxsize","text":"Description: In Stake2.0, query the amount of delegatable resources share of the specified resource type for an address, unit is sun.
curl -X POST http://127.0.0.1:8090/walletsolidity/getcandelegatedmaxsize -d\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"type\": 0,\n \"visible\": true\n}\n'\n
Parameters:
owner_address: Account addresstype: Resource type, 0 is bandwidth, 1 is energy
Return: The amount of delegatable resource share, unit is sun.
"},{"location":"api/http/#walletsoliditygetdelegatedresourcev2","title":"walletsolidity/getdelegatedresourcev2","text":"In Stake2.0, query the detail of resource share delegated from fromAddress to toAddress
curl -X POST http://127.0.0.1:8090/walletsolidity/getdelegatedresourcev2 -d\n'{\n \"fromAddress\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"toAddress\": \"TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1\",\n \"visible\": true\n}\n'\n
Parameters:
fromAddress: resource from address, default hexStringtoAddress: resource to address
Return: Resource delegation list
"},{"location":"api/http/#walletsoliditygetdelegatedresourceaccountindexv2","title":"walletsolidity/getdelegatedresourceaccountindexv2","text":"In Stake2.0, query the resource delegation index by an account. Two lists will return, one is the list of addresses the account has delegated its resources(toAddress), and the other is the list of addresses that have delegated resources to the account(fromAddress).
curl -X POST http://127.0.0.1:8090/walletsolidity/getdelegatedresourceaccountindexv2 -d\n'{\n \"value\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"visible\": true\n}\n'\n
Parameters:
value: account address
Return: Two lists will return, one is the list of addresses the account has delegated its resources(toAddress), and the other is the list of addresses that have delegated resources to the account(fromAddress).
"},{"location":"api/http/#voting-srs","title":"Voting & SRs","text":""},{"location":"api/http/#walletsoliditylistwitnesses","title":"walletsolidity/listwitnesses","text":"Description: Query the list of super representatives
curl -X POST http://127.0.0.1:8091/walletsolidity/listwitnesses\n
Parameters: N/A Return: List of all super representatives
"},{"location":"api/http/#trc10-token_1","title":"TRC10 Token","text":""},{"location":"api/http/#walletsoliditygetassetissuelist","title":"walletsolidity/getassetissuelist","text":"Description: Query the list of all tokens
curl -X POST http://127.0.0.1:8091/walletsolidity/getassetissuelist\n
Parameters: N/A Return: The list of all tokens
"},{"location":"api/http/#walletsoliditygetpaginatedassetissuelist","title":"walletsolidity/getpaginatedassetissuelist","text":"Description: Query the list of all the tokens by pagination
curl -X POST http://127.0.0.1:8091/walletsolidity/getpaginatedassetissuelist -d '{\"offset\": 0, \"limit\":10}'\n
Parameters: - offset: The index of the start token - limit: The amount of tokens per page Return: List of tokens
"},{"location":"api/http/#walletsoliditygetassetissuebyname","title":"walletsolidity/getassetissuebyname","text":"Description: Query a token by token name
curl -X POST http://127.0.0.1:8091/walletsolidity/getassetissuebyname -d '{\"value\": \"44756354616E\"}'\n
Parameters: value - Token name, default hexString Return: Token object Note: Since Odyssey-v3.2, getassetissuebyid or getassetissuelistbyname is recommended, as since v3.2, token name can be repeatable. If the token name you query is not unique, this api will throw out an error.
"},{"location":"api/http/#walletsoliditygetassetissuelistbyname","title":"walletsolidity/getassetissuelistbyname","text":"Description: Query the token list by name
curl -X POST http://127.0.0.1:8091/walletsolidity/getassetissuelistbyname -d '{\"value\": \"44756354616E\"}'\n
Parameters: value - Token name, default hexString Return: Token list
"},{"location":"api/http/#walletsoliditygetassetissuebyid","title":"walletsolidity/getassetissuebyid","text":"Description: Query a token by token id
curl -X POST http://127.0.0.1:8091/walletsolidity/getassetissuebyid -d '{\"value\": \"1000001\"}'\n
Parameters: value - Token id Return: Token object
"},{"location":"api/http/#blocks","title":"Blocks","text":""},{"location":"api/http/#walletsoliditygetnowblock","title":"walletsolidity/getnowblock","text":"Description: Query the latest block information
curl -X POST http://127.0.0.1:8091/walletsolidity/getnowblock\n
Parameters: N/A Return: The latest block from solidityNode
"},{"location":"api/http/#walletsoliditygetblockbynum","title":"walletsolidity/getblockbynum","text":"Description: Query a block information by block height
curl -X POST http://127.0.0.1:8091/walletsolidity/getblockbynum -d '{\"num\" : 100}'\n
Parameters: num - Block height Return: Block information
"},{"location":"api/http/#walletsoliditygetblockbyid","title":"walletsolidity/getblockbyid","text":"Description: Query a block information by block id
curl -X POST http://127.0.0.1:8091/walletsolidity/getblockbyid-d '{\"value\":\n\"0000000000038809c59ee8409a3b6c051e369ef1096603c7ee723c16e2376c73\"}'\n
Parameters: value - Block id Return: The block object
"},{"location":"api/http/#walletsoliditygetblockbylimitnext","title":"walletsolidity/getblockbylimitnext","text":"Description: Query a list of blocks by range
curl -X POST http://127.0.0.1:8091/walletsolidity/getblockbylimitnext -d '{\"startNum\": 1, \"endNum\": 2}'\n
Parameters: startNum: The start block height, inclusiveendNum: The end block height, exclusive
Return: List of blocks
"},{"location":"api/http/#walletsoliditygetblockbylatestnum","title":"walletsolidity/getblockbylatestnum","text":"Description: Query the latest few blocks
curl -X POST http://127.0.0.1:8091/walletsolidity/getblockbylatestnum -d '{\"num\": 5}'\n
Parameters: num - The number of blocks expected to return Return: List of blocks
"},{"location":"api/http/#walletgetnodeinfo_1","title":"wallet/getnodeinfo","text":"Description: Query the current node information
curl -X GET http://127.0.0.1:8091/wallet/getnodeinfo\n
Parameters: N/A Return: NodeInfo of the current node
"},{"location":"api/http/#transactions","title":"Transactions","text":""},{"location":"api/http/#walletsoliditygettransactionbyid","title":"walletsolidity/gettransactionbyid","text":"Description: Query an transaction information by transaction id
curl -X POST http://127.0.0.1:8091/walletsolidity/gettransactionbyid -d '{\"value\" : \"309b6fa3d01353e46f57dd8a8f27611f98e392b50d035cef213f2c55225a8bd2\"}'\n
Parameters: value - Transaction id Return: Transaction information
"},{"location":"api/http/#walletsoliditygettransactioncountbyblocknum","title":"walletsolidity/gettransactioncountbyblocknum","text":"Description: Query th the number of transactions in a specific block
curl -X POST http://127.0.0.1:8091/walletsolidity/gettransactioncountbyblocknum -d '{\"num\" : 100}'\n
Parameters: num - Block height Return: The number of transactions
"},{"location":"api/http/#walletsoliditygettransactioninfobyid","title":"walletsolidity/gettransactioninfobyid","text":"Description: Query the transaction fee, block height by transaction id
curl -X POST http://127.0.0.1:8091/walletsolidity/gettransactioninfobyid -d '{\"value\" : \"309b6fa3d01353e46f57dd8a8f27611f98e392b50d035cef213f2c55225a8bd2\"}'\n
Parameters: value - Transaction id Return: Transaction fee, block height and the time of creation
"},{"location":"api/http/#walletsoliditygettransactioninfobyblocknum","title":"walletsolidity/gettransactioninfobyblocknum","text":"Description: Query the list of transaction information in a specific block
curl -X POST http://127.0.0.1:8091/walletsolidity/gettransactioninfobyblocknum -d '{\"num\" : 100}'\n
Parameters: num - Block height Return: The list of transaction information inside the queried block
"},{"location":"api/http/#dex-exchanges","title":"DEX Exchanges","text":""},{"location":"api/http/#walletsoliditygetexchangebyid","title":"walletsolidity/getexchangebyid","text":"Description: Query an exchange pair by exchange pair id
curl -X POST http://127.0.0.1:8091/walletsolidity/getexchangebyid -d {\"id\":1}\n
Parameters: - id: Exchange pair id
Return: Exchange pair information
"},{"location":"api/http/#walletsoliditylistexchanges","title":"walletsolidity/listexchanges","text":"Description: Query the list of all the exchange pairs
curl -X POST http://127.0.0.1:8091/walletsolidity/listexchanges\n
Parameters: N/A Return: The list of all the exchange pairs
"},{"location":"api/http/#tronz-shielded-smart-contract_1","title":"TRONZ Shielded Smart Contract","text":""},{"location":"api/http/#walletsoliditygetmerkletreevoucherinfo","title":"walletsolidity/getmerkletreevoucherinfo","text":"Description: Get the Merkle tree information of a note
curl -X POST http://127.0.0.1:8090/walletsolidity/getmerkletreevoucherinfo -d\n'{\n \"out_points\":[{\n \"hash\":\"185b3e085723f5862b3a3c3cf54d52f5c1eaf2541e3a1e0ecd08bc12cd958d74\",\n \"index\":0\n }]\n}'\n
Parameters: out_points: Note information
Return: Merkle tree information of a note
"},{"location":"api/http/#walletsolidityscannotebyivk","title":"walletsolidity/scannotebyivk","text":"Description: Get all notes related to ivk
curl -X POST http://127.0.0.1:8090/walletsolidity/scannotebyivk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ivk\": \"80a481c3c739e54b4e0608090b3a1a6e9f8dce42346e95bf5a2d8a487bf45c05\"\n}'\n
Parameters: start_block_index: The start block height, inclusiveend_block_index: The end block height, exclusiveivk: Incoming viewing key
Return: Notes list Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletsolidityscanandmarknotebyivk","title":"walletsolidity/scanandmarknotebyivk","text":"Description: Get all notes with spent status related to ivk
curl -X POST http://127.0.0.1:8090/walletsolidity/scanandmarknotebyivk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ivk\": \"80a481c3c739e54b4e0608090b3a1a6e9f8dce42346e95bf5a2d8a487bf45c05\",\n \"ak\": \"1d4f9b5551f4aa9443ceb263f0e208eb7e26080264571c5ef06de97a646fe418\",\n \"nk\": \"748522c7571a9da787e43940c9a474aa0c5c39b46c338905deb6726fa3678bdb\"\n}'\n
Parameters: start_block_index: The start block height, inclusiveend_block_index: The end block height, exclusiveivk: Incoming viewing keyak: Ak keynk: Nk key
Return: Notes list Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletsolidityscannotebyovk","title":"walletsolidity/scannotebyovk","text":"Description: Query all notes related to ovk
curl -X POST http://127.0.0.1:8090/walletsolidity/scannotebyovk -d\n'{\n \"start_block_index\": 0,\n \"end_block_index\": 100,\n \"ovk\": \"705145aa18cbe6c11d5d0011419a98f3d5b1d341eb4727f1315597f4bdaf8539\"\n}'\n
Parameters: start_block_index: The start block height, inclusiveend_block_index: The end block height, exclusiveovk: Outgoing viewing key
Return: Notes list Note: Range limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletsolidityisspend","title":"walletsolidity/isspend","text":"Description: Check whether a note has been spent
curl -X POST http://127.0.0.1:8090/walletsolidity/isspend -d\n'{\n \"ak\": \"a3e65d509b675aaa2aeda977ceff11eebd76218079b6f543d78a615e396ca129\",\n \"nk\": \"62cfda9bea09a53cf2a21022057913734a8458969e11e0bb9c59ead48fbce83e\",\n \"note\": {\n \"payment_address\": \"ztron1aqgauawtkelxfu2w6s48cwh0mchjt6kwpj44l4wym3pullx0294j4r4v7kpm75wnclzycsw73mq\",\n \"rcm\": \"74a16c1b27ec7fbf06881d9d35ddaab1554838b1bddcd54f6bd8a9fb4ba0b80a\",\n \"value\": 500000000\n },\n \"txid\": \"7d09e471bb047d3ac044d5d6691b3721a2dddbb683ac02c207fbe78af6302463\",\n \"index\": 1\n}'\n
Parameters: ak: Aknk: Nknote: Note informationtxid: Transaction idindex: Note index
Return: Whether a note has been spent
"},{"location":"api/http/#walletsolidityscanshieldedtrc20notesbyivk","title":"walletsolidity/scanshieldedtrc20notesbyivk","text":"Description: Scan the shielded TRC-20 notes by ivk, and mark whether it has been spent
curl -X POST http://127.0.0.1:8091/walletsolidity/scanshieldedtrc20notesbyivk -d\n'{\n \"start_block_index\": 9200,\n \"end_block_index\": 9240,\n \"shielded_TRC20_contract_address\": \"41274fc7464fadac5c00c893c58bce6c39bf59e4c7\",\n \"ivk\": \"9f8e74bb3d7188a2781dc1db38810c6914eef4570a79e8ec8404480948e4e305\",\n \"ak\":\"8072d9110c9de9d9ade33d5d0f5890a7aa65b0cde42af7816d187297caf2fd64\",\n \"nk\":\"590bf33f93f792be659fd404df91e75c3b08d38d4e08ee226c3f5219cf598f14\"\n}'\n
Parameters: start_block_index: The start block index, inclusiveend_block_index: The end block index, exclusiveshielded_TRC20_contract_address: Shielded TRC-20 contract addressivk: Incoming viewing keyak: Ak keynk: Nk key
Return: Notes list Note: Block limit\uff08end_block_index - start_block_index <= 1000\uff09
"},{"location":"api/http/#walletsolidityscanshieldedtrc20notesbyovk","title":"walletsolidity/scanshieldedtrc20notesbyovk","text":"Description: Scan the shielded TRC-20 notes by ovk
curl -X POST http://127.0.0.1:8091/walletsolidity/scanshieldedtrc20notesbyovk -d\n'{\n \"start_block_index\": 9200,\n \"end_block_index\": 9240,\n \"shielded_TRC20_contract_address\": \"41274fc7464fadac5c00c893c58bce6c39bf59e4c7\",\n \"ovk\": \"0ff58efd75e083fe4fd759c8701e1c8cb6961c4297a12b2c800bdb7b2bcab889\"\n}'\n
Parameters: start_block_index: Start block index, inclusiveend_block_index: Start block index, inclusiveshielded_TRC20_contract_address: Shielded TRC-20 contract addressovk: Outgoing viewing key
Return: Notes list
Note: Block limit (end_block_index - start_block_index <= 1000)
"},{"location":"api/http/#walletsolidityisshieldedtrc20contractnotespent","title":"walletsolidity/isshieldedtrc20contractnotespent","text":"Description: Check the status whether the specified shielded TRC-20 note is spent
curl -X POST http://127.0.0.1:8091/walletsolidity/scanshieldedtrc20notesbyovk -d\n'{\n \"note\": {\n \"value\": 40,\n \"payment_address\":\"ztron1768kf7dy4qquefp46szk978d65eeua66yhr4zv260c0uzj68t3tfjl3en9lhyyfxalv4jus30xs\",\n \"rcm\": \"296070782a94c6936b0b4f6daf8d7c7605a4374fe595b96148dc0f4b59015d0d\"\n },\n \"ak\": \"8072d9110c9de9d9ade33d5d0f5890a7aa65b0cde42af7816d187297caf2fd64\",\n \"nk\": \"590bf33f93f792be659fd404df91e75c3b08d38d4e08ee226c3f5219cf598f14\",\n \"position\": 272,\n \"shielded_TRC20_contract_address\": \"41274fc7464fadac5c00c893c58bce6c39bf59e4c7\"\n}'\n
Parameters: note: The specified noteak: Aknk: Nkposition: The leaf position index of note commitment in the Merkle treeshielded_TRC20_contract_address: The shielded TRC-20 contract address
Return: Note status
Note: The value in note is the scaled value by scalingFactor set in the shielded TRC-20 contract, namely real_amount = value * scalingFactor.
"},{"location":"api/json-rpc/","title":"jsonRPC API","text":""},{"location":"api/json-rpc/#overview","title":"Overview","text":"JSON-RPC is a stateless, lightweight remote procedure call (RPC) protocol. The JSON-RPC interface supported by the TRON network is compatible with Ethereum's. However, due to the difference in chain mechanism and design, TRON cannot support some interfaces on Ethereum. At the same time, TRON also provides dedicated APIs to create different types of transactions.
Please pay attention
- The JSON-RPC service needs to be enabled and set the port in the node configuration file. If not configured, the service is disable by default.
"},{"location":"api/json-rpc/#how-to-enable-or-disable-json-rpc-service-of-a-node","title":"How to enable or disable JSON-RPC service of a node","text":"Add below items in node's configuration file, then enable or disable it:
node.jsonrpc { \n httpFullNodeEnable = true \n httpFullNodePort = 50545 \n httpSolidityEnable = true \n httpSolidityPort = 50555 \n}\n
"},{"location":"api/json-rpc/#hex-value-encoding","title":"HEX value encoding","text":"At present there are two key data types that are passed over JSON: unformatted byte arrays and quantities. Both are passed with a hex encoding, however with different requirements to formatting:
When encoding QUANTITIES (integers, numbers): encode as hex, prefix with \u201c0x\u201d, the most compact representation (slight exception: zero should be represented as \u201c0x0\u201d). Examples:
- 0x41 (65 in decimal)
- 0x400 (1024 in decimal)
- WRONG: 0x (should always have at least one digit - zero is \u201c0x0\u201d)
- WRONG: 0x0400 (no leading zeros allowed)
- WRONG: ff (must be prefixed 0x)
When encoding UNFORMATTED DATA (byte arrays, account addresses, hashes, bytecode arrays): encode as hex, prefix with \u201c0x\u201d, two hex digits per byte. Examples:
- 0x41 (size 1, \u201cA\u201d)
- 0x004200 (size 3, \u201c\\0B\\0\u201d)
- 0x (size 0, \u201c\u201d)
- WRONG: 0xf0f0f (must be even number of digits)
- WRONG: 004200 (must be prefixed 0x)
"},{"location":"api/json-rpc/#eth","title":"eth","text":""},{"location":"api/json-rpc/#eth_accounts","title":"eth_accounts","text":"Returns a list of addresses owned by the client.
Parameters
None
Returns
Empty List
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '\n\n{\"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"eth_accounts\", \"params\": []}'\n
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":[]}\n
"},{"location":"api/json-rpc/#eth_blocknumber","title":"eth_blockNumber","text":"Returns the number of the most recent block.
Parameters
None
Returns
The latest block number.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_blockNumber\",\"params\":[],\"id\":64}'\n
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x20e0cf0\"}\n
"},{"location":"api/json-rpc/#eth_call","title":"eth_call","text":"Executes a message call immediately without creating a transaction on the block chain.
Parameters
1. Object - The transaction call object, the items in it as below.
Item Name Data Type Description from DATA, 20 Bytes Caller address. Hex format address, remove the prefix \"41\" to DATA, 20 Bytes Contract address. Hex format address, remove the prefix \"41\" gas QUANTITY Not supported. The value is 0x0 gasPrice QUANTITY Not supported. The value is 0x0 value QUANTITY Not supported. The value is 0x0 data DATA Hash of the method signature and encoded parameters. 2. QUANTITY|TAG - currently, only \"latest\" is available.
Returns
DATA - the return value of executed contract function.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_call\",\n\n \"params\": [{\n\n \"from\": \"0xF0CC5A2A84CD0F68ED1667070934542D673ACBD8\",\n\n \"to\": \"0x70082243784DCDF3042034E7B044D6D342A91360\",\n\n \"gas\": \"0x0\",\n\n \"gasPrice\": \"0x0\",\n\n \"value\": \"0x0\",\n\n \"data\": \"0x70a08231000000000000000000000041f0cc5a2a84cd0f68ed1667070934542d673acbd8\"\n\n }, \"latest\"],\n\n \"id\": 1\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x\"}\n
### eth_chainId\n\n*Returns the chainId of the TRON network which is the last four bytes of the genesis block hash*\n\n**Parameters** \n\nNone\n\n**Returns** \n\nDATA - The chainId of the TRON network\n\n**Example**\n\n```curl\n\ncurl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_chainId\",\"params\":[],\"id\":79}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":79,\"result\":\"0x2b6653dc\"}\n
"},{"location":"api/json-rpc/#eth_coinbase","title":"eth_coinbase","text":"Returns the super representative address of the current node.
Parameters
None
Returns
DATA - The super representative address of the node. (Note: Return the first address If more than one super representative address is configured, return error if there is no valid address or the address did not generate any block, the error will be \u201cetherbase must be explicitly specified\u201d . )
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"eth_coinbase\", \"params\": []}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"error\":{\"code\":-32000,\"message\":\"etherbase must be explicitly specified\",\"data\":\"{}\"}}\n
"},{"location":"api/json-rpc/#eth_estimategas","title":"eth_estimateGas","text":"Get the required energy through triggerConstantContract.
Parameters
object - The transaction call object, the items in it as below
Item Name Data Type Description from DATA, 20 Bytes address of the sender to DATA, 20 Bytes address of the receiver gas QUANTITY unused. gasPrice QUANTITY unused. value QUANTITY Integer of the value sent with this transaction data DATA Hash of the method signature and encoded parameters. Returns
The amount of energy used.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 1,\n\n \"method\": \"eth_estimateGas\",\n\n \"params\": [{\n\n \"from\": \"0x41F0CC5A2A84CD0F68ED1667070934542D673ACBD8\",\n\n \"to\": \"0x4170082243784DCDF3042034E7B044D6D342A91360\",\n\n \"gas\": \"0x01\",\n\n \"gasPrice\": \"0x8c\",\n\n \"value\": \"0x01\",\n\n \"data\": \"0x70a08231000000000000000000000041f0cc5a2a84cd0f68ed1667070934542d673acbd8\"\n\n }]\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x0\"}\n
"},{"location":"api/json-rpc/#eth_gasprice","title":"eth_gasPrice","text":"Returns the current energy price in sun.
Parameters
None
Returns
Integer of the current energy price in sun.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"eth_gasPrice\", \"params\": []}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x8c\"}\n
"},{"location":"api/json-rpc/#eth_getbalance","title":"eth_getBalance","text":"Returns the balance of the account of the given address.
Parameters
Index Data Type Description 1 DATA, 20 Bytes address to check for balance. 2 QUANTITY only \"latest\" is available now Returns
QUANTITY - integer of the current balance in sun.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getBalance\",\n\n \"params\": [\"0x41f0cc5a2a84cd0f68ed1667070934542d673acbd8\", \"latest\"],\n\n \"id\": 64\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x492780\"}\n
"},{"location":"api/json-rpc/#eth_getblockbyhash","title":"eth_getBlockByHash","text":"Returns information about a block by hash.
Parameters
Index Data Type Description 1 DATA, 32 Bytes hash of a block 2 Boolean If true it returns the full transaction objects, if false only the hashes of the transactions. Returns
object - a block object or null when no block was found. The block includes items as below.
Item Name Data Type Description number QUANTITY block number hash DATA, 32 Bytes hash of the block parentHash DATA, 32 Bytes hash of the parent block nonce QUANTITY unused sha3Uncles DATA, 32 Bytes SHA3 of the uncles data in the block logsBloom DATA, 256 Bytes the bloom filter for the logs of the block. transactionsRoot DATA, 32 Bytes the root of the transaction trie of the block stateRoot DATA, 32 Bytes the root of the final state trie of the block receiptsRoot DATA, 32 Bytes the root of the receipts trie of the block miner DATA, 20 Bytes the address of the beneficiary to whom the mining rewards were given difficulty QUANTITY integer of the difficulty for this block totalDifficulty QUANTITY integer of the total difficulty of the chain until this block extraData DATA the \u201cextra data\u201d field of this block size QUANTITY integer the size of this block in bytes gasLimit QUANTITY the maximum gas allowed in this block gasUsed QUANTITY the total used gas by all transactions in this block timestamp QUANTITY the unix timestamp for when the block was created, the unit is second. transactions Array Array of transaction objects, or 32 Bytes transaction hashes depending on the last given parameter. uncles Array Array of uncle hashes Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getBlockByHash\",\n\n \"params\": [\"0x0000000000f9cc56243898cbe88685678855e07f51c5af91322c225ce3693868\", false],\n\n \"id\": 1\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":null}\n
"},{"location":"api/json-rpc/#eth_getblockbynumber","title":"eth_getBlockByNumber","text":"Returns information about a block by hash.
Parameters
Index Data Type Description 1 QUANTITY|TAG Integer of a block number, or the string \"earliest\", \"latest\" 2 Boolean If true it returns the full transaction objects, if false only the hashes of the transactions. Returns
object - a block object or null when no block was found. See eth_getBlockByHash
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getBlockByNumber\",\n\n \"params\": [\"0xF9CC56\", true],\n\n \"id\": 1\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":null}\n
"},{"location":"api/json-rpc/#eth_getblocktransactioncountbyhash","title":"eth_getBlockTransactionCountByHash","text":"Returns the number of transactions in a block from a block matching the given block hash.
Parameters
DATA, 32 Bytes - hash of a block
Returns
QUANTITY - integer of the number of transactions in this block.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 1,\n\n \"method\": \"eth_getBlockTransactionCountByHash\",\n\n \"params\": [\"0x00000000020ef11c87517739090601aa0a7be1de6faebf35ddb14e7ab7d1cc5b\"]\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x39\"}\n
"},{"location":"api/json-rpc/#eth_getblocktransactioncountbynumber","title":"eth_getBlockTransactionCountByNumber","text":"Returns the number of transactions in a block matching the given block number.
Parameters
QUANTITY|TAG - integer of a block number, or the string \"earliest\" or \"latest\".
Returns
QUANTITY - integer of the number of transactions in this block.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getBlockTransactionCountByNumber\",\n\n \"params\": [\"0xF96B0F\"],\n\n \"id\": 1\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x23\"}\n
"},{"location":"api/json-rpc/#eth_getcode","title":"eth_getCode","text":"Returns runtime code of a given smart contract address.
Parameters
Index Data Type Description 1 DATA, 20 Bytes contract address 2 QUANTITY|TAG currently, only \"latest\" is available Returns
DATA - the runtime code from the given address.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getCode\",\n\n \"params\": [\"0x4170082243784DCDF3042034E7B044D6D342A91360\", \"latest\"],\n\n \"id\": 64\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x\"}\n
"},{"location":"api/json-rpc/#eth_getstorageat","title":"eth_getStorageAt","text":"Returns the value from a storage position at a given address. It can be used to get the value of a variable in a contract.
Parameters
Index Data Type Description 1 DATA, 20 Bytes address 2 QUANTITY integer of the position in the storage 3 QUANTITY|TAG currently only support \"latest\" Returns
DATA - the value at this storage position.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getStorageAt\",\n\n \"params\": [\"0xE94EAD5F4CA072A25B2E5500934709F1AEE3C64B\", \"0x29313b34b1b4beab0d3bad2b8824e9e6317c8625dd4d9e9e0f8f61d7b69d1f26\", \"latest\"],\n\n \"id\": 1\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x0000000000000000000000000000000000000000000000000000000000000000\"}\n
"},{"location":"api/json-rpc/#eth_gettransactionbyblockhashandindex","title":"eth_getTransactionByBlockHashAndIndex","text":"Returns information about a transaction by block hash and transaction index position.
Parameters
Index Data Type Description 1 DATA, 32 Bytes hash of a block 2 QUANTITY the transaction index position Returns
object - a transaction object or null when no transaction was found. The transaction includes items as below.
Item Name Data Type Description blockHash DATA, 32 Bytes hash of the block where this transaction was in. blockNumber QUANTITY block number where this transaction was in. from DATA, 20 Bytes address of the sender gas QUANTITY unused. gasPrice QUANTITY energy price hash DATA, 32 Bytes hash of the transaction input DATA the data sent along with the transaction nonce QUANTITY unused to DATA, 20 Bytes address of the receiver transactionIndex QUANTITY integer of the transactions index position in the block value QUANTITY value transferred in sun v QUANTITY ECDSA recovery id r DATA, 32 Bytes ECDSA signature r s DATA, 32 Bytes ECDSA signature s Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getTransactionByBlockHashAndIndex\",\n\n \"params\": [\"00000000020ef11c87517739090601aa0a7be1de6faebf35ddb14e7ab7d1cc5b\", \"0x0\"],\n\n \"id\": 64\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 64,\n\n \"result\": {\n\n \"blockHash\": \"0x00000000020ef11c87517739090601aa0a7be1de6faebf35ddb14e7ab7d1cc5b\",\n\n \"blockNumber\": \"0x20ef11c\",\n\n \"from\": \"0xb4f1b6e3a1461266b01c2c4ff9237191d5c3d5ce\",\n\n \"gas\": \"0x0\",\n\n \"gasPrice\": \"0x8c\",\n\n \"hash\": \"0x8dd26d1772231569f022adb42f7d7161dee88b97b4b35eeef6ce73fcd6613bc2\",\n\n \"input\": \"0x\",\n\n \"nonce\": null,\n\n \"r\": \"0x6212a53b962345fb8ab02215879a2de05f32e822c54e257498f0b70d33825cc5\",\n\n \"s\": \"0x6e04221f5311cf2b70d3aacfc444e43a5cf14d0bf31d9227218efaabd9b5a812\",\n\n \"to\": \"0x047d4a0a1b7a9d495d6503536e2a49bb5cc72cfe\",\n\n \"transactionIndex\": \"0x0\",\n\n \"type\": \"0x0\",\n\n \"v\": \"0x1b\",\n\n \"value\": \"0x203226\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_gettransactionbyblocknumberandindex","title":"eth_getTransactionByBlockNumberAndIndex","text":"Returns information about a transaction by block number and transaction index position.
Parameters
Index Data Type Description 1 QUANTITY|TAG a block number, or the string \"earliest\", \"latest\", 2 QUANTITY the transaction index position Returns
object - a transaction object or null when no transaction was found. See eth_getTransactionByBlockHashAndIndex
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getTransactionByBlockNumberAndIndex\",\n\n \"params\": [\"0xfb82f0\", \"0x0\"],\n\n \"id\": 64\n\n}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":null}\n
"},{"location":"api/json-rpc/#eth_gettransactionbyhash","title":"eth_getTransactionByHash","text":"Returns the information about a transaction requested by transaction hash.
Parameters
DATA, 32 Bytes - hash of a transaction
Returns
object - a transaction object or null when no transaction was found. See eth_getTransactionByBlockHashAndIndex
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getTransactionByHash\",\n\n \"params\": [\"c9af231ad59bcd7e8dcf827afd45020a02112704dce74ec5f72cb090aa07eef0\"],\n\n \"id\": 64\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 64,\n\n \"result\": {\n\n \"blockHash\": \"0x00000000020ef11c87517739090601aa0a7be1de6faebf35ddb14e7ab7d1cc5b\",\n\n \"blockNumber\": \"0x20ef11c\",\n\n \"from\": \"0x6eced5214d62c3bc9eaa742e2f86d5c516785e14\",\n\n \"gas\": \"0x0\",\n\n \"gasPrice\": \"0x8c\",\n\n \"hash\": \"0xc9af231ad59bcd7e8dcf827afd45020a02112704dce74ec5f72cb090aa07eef0\",\n\n \"input\": \"0x\",\n\n \"nonce\": null,\n\n \"r\": \"0x433eaf0a7df3a08c8828a2180987146d39d44de4ac327c4447d0eeda42230ea8\",\n\n \"s\": \"0x6f91f63b37f4d1cd9342f570205beefaa5b5ba18d616fec643107f8c1ae1339d\",\n\n \"to\": \"0x0697250b9d73b460a9d2bbfd8c4cacebb05dd1f1\",\n\n \"transactionIndex\": \"0x6\",\n\n \"type\": \"0x0\",\n\n \"v\": \"0x1b\",\n\n \"value\": \"0x1cb2310\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_gettransactionreceipt","title":"eth_getTransactionReceipt","text":"Returns the transaction info: receipt, transaction fee, block height ... by transaction hash. Please refer to http api: wallet/gettransactioninfobyid
Parameters
DATA, 32 Bytes - hash of a transaction
Returns
object - A transaction receipt object, or null when no receipt was found. The items in transaction receipt as below.
Item Name Data Type Description transactionHash DATA, 32 Bytes hash of the transaction transactionIndex QUANTITY integer of the transactions index position in the block blockHash DATA, 32 Bytes hash of the block where this transaction was in. blockNumber QUANTITY block number where this transaction was in. from DATA, 20 Bytes address of the sender to DATA, 20 Bytes address of the receiver cumulativeGasUsed QUANTITY The total amount of gas used when this transaction was executed in the block. gasUsed QUANTITY The amount of gas used by this specific transaction alone. contractAddress DATA, 20 Bytes The contract address created, if the transaction was a contract creation, otherwise null. logs Array Array of log objects, which this transaction generated. logsBloom DATA, 256 Bytes Bloom filter for light clients to quickly retrieve related logs. root DATA 32 bytes of post-transaction stateroot (pre Byzantium) status QUANTITY either 1 (success) or 0 (failure) Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getTransactionReceipt\",\n\n \"params\": [\"c9af231ad59bcd7e8dcf827afd45020a02112704dce74ec5f72cb090aa07eef0\"],\n\n \"id\": 64\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 64,\n\n \"result\": {\n\n \"blockHash\": \"0x00000000020ef11c87517739090601aa0a7be1de6faebf35ddb14e7ab7d1cc5b\",\n\n \"blockNumber\": \"0x20ef11c\",\n\n \"contractAddress\": null,\n\n \"cumulativeGasUsed\": \"0x646e2\",\n\n \"effectiveGasPrice\": \"0x8c\",\n\n \"from\": \"0x6eced5214d62c3bc9eaa742e2f86d5c516785e14\",\n\n \"gasUsed\": \"0x0\",\n\n \"logs\": [],\n\n \"logsBloom\": \"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\",\n\n \"status\": \"0x1\",\n\n \"to\": \"0x0697250b9d73b460a9d2bbfd8c4cacebb05dd1f1\",\n\n \"transactionHash\": \"0xc9af231ad59bcd7e8dcf827afd45020a02112704dce74ec5f72cb090aa07eef0\",\n\n \"transactionIndex\": \"0x6\",\n\n \"type\": \"0x0\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_getwork","title":"eth_getWork","text":"Returns the hash of the current block
Parameters
None
Returns
Array - Array with the following properties:
Index Data Type Description 1 DATA, 32 Bytes hash of the block 2 DATA unused 3 DATA unused Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getWork\",\n\n \"params\": [],\n\n \"id\": 73\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 73,\n\n \"result\": [\"0x00000000020e73915413df0c816e327dc4b9d17069887aef1fff0e854f8d9ad0\", null, null]\n\n}\n
"},{"location":"api/json-rpc/#eth_protocolversion","title":"eth_protocolVersion","text":"Returns the java-tron block version
Parameters
None
Returns
String - The current java-tron block version
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_protocolVersion\",\"params\":[],\"id\":64}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x16\"}\n
"},{"location":"api/json-rpc/#eth_syncing","title":"eth_syncing","text":"Returns an object with data about the sync status of the node
Parameters
None
Returns
Object|Boolean, An object with sync status data or FALSE, when not syncing, the items in object includes:
startingBlock QUANTITY The block at which the import started (will only be reset, after the sync reached his head) currentBlock QUANTITY The current block highestBlock QUANTITY The estimated highest block Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_syncing\",\"params\":[],\"id\":64}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 64,\n\n \"result\": {\n\n \"startingBlock\": \"0x20e76cc\",\n\n \"currentBlock\": \"0x20e76df\",\n\n \"highestBlock\": \"0x20e76e0\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_newfilter","title":"eth_newFilter","text":"Creates a filter object, based on filter options, to notify when the state changes (logs).
Parameters
Object - The filter options:
Field Type Description fromBlock QUANTITY|TAG Integer block number, or \"latest\" toBlock QUANTITY|TAG Integer block number, or \"latest\" address DATA|Array, 20 Bytes Contract address or a list of addresses from which logs should originate. topics Array of DATA Topics Returns
QUANTITY - A filter id.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_newFilter\",\"params\":[{\"address\":[\"cc2e32f2388f0096fae9b055acffd76d4b3e5532\",\"E518C608A37E2A262050E10BE0C9D03C7A0877F3\"],\"fromBlock\":\"0x989680\",\"toBlock\":\"0x9959d0\",\"topics\":[\"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef\",null,[\"0x0000000000000000000000001806c11be0f9b9af9e626a58904f3e5827b67be7\",\"0x0000000000000000000000003c8fb6d064ceffc0f045f7b4aee6b3a4cefb4758\"]]}],\"id\":1}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x2bab51aee6345d2748e0a4a3f4569d80\"}\n
"},{"location":"api/json-rpc/#eth_newblockfilter","title":"eth_newBlockFilter","text":"Creates a filter in the node, to notify when a new block arrives.
Parameters
None.
Returns
QUANTITY - A filter id.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_newBlockFilter\",\"params\":[],\"id\":1}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x2bab51aee6345d2748e0a4a3f4569d80\"}\n
"},{"location":"api/json-rpc/#eth_getfilterchanges","title":"eth_getFilterChanges","text":"Polling method for a filter, which returns an array of logs which occurred since last poll.
Parameters
QUANTITY - the filter id.
Returns
- For filters created with eth_newFilte, return logs object list, each log object with following params:
Field Type Description removed TAG true when the log was removed, due to a chain reorganization. false if its a valid log. logIndex QUANTITY Integer of the log index position in the block. null when its pending log. transactionIndex QUANTITY Integer of the transactions index position log was created from. null when its pending log. transactionHash DATA, 32Bytes Hash of the transactions this log was created from. blockHash DATA, 32 Bytes Hash of the block where this log was in. null when its pending. blockNumber QUANTITY The block number where this log was in. address DATA, 32 Bytes Address from which this log originated. data DATA Contains one or more 32 Bytes non-indexed arguments of the log. topics DATA[] Event topic and indexed arguments. - For filters created with eth_newBlockFilter the return are block hashes (DATA, 32 Bytes).
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getFilterChanges\",\n\n \"params\": [\n\n \"0xc11a84d5e906ecb9f5c1eb65ee940b154ad37dce8f5ac29c80764508b901d996\"\n\n ],\n\n \"id\": 71\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 71,\n\n \"error\": {\n\n \"code\": -32000,\n\n \"message\": \"filter not found\",\n\n \"data\": \"{}\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_getfilterlogs","title":"eth_getFilterLogs","text":"Returns an array of all logs matching filter with given id.
Parameters
QUANTITY - the filter id.
Returns
See eth_getFilterChanges\u3002
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_getFilterLogs\",\n\n \"params\": [\n\n \"0xc11a84d5e906ecb9f5c1eb65ee940b154ad37dce8f5ac29c80764508b901d996\"\n\n ],\n\n \"id\": 71\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 71,\n\n \"error\": {\n\n \"code\": -32000,\n\n \"message\": \"filter not found\",\n\n \"data\": \"{}\"\n\n }\n\n}\n
"},{"location":"api/json-rpc/#eth_uninstallfilter","title":"eth_uninstallFilter","text":"Uninstalls a filter with given id. Should always be called when watch is no longer needed. Additionally Filters timeout when they aren't requested with eth_getFilterChanges for a period of time.
Parameters
QUANTITY - the filter id.
Returns
Boolean - true if the filter was successfully uninstalled, otherwise false.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"eth_uninstallFilter\",\n\n \"params\": [\n\n \"0xc11a84d5e906ecb9f5c1eb65ee940b154ad37dce8f5ac29c80764508b901d996\"\n\n ],\n\n \"id\": 71\n\n}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 71,\n\n \"result\": true\n\n}\n
"},{"location":"api/json-rpc/#eth_getlogs","title":"eth_getLogs","text":"Returns an array of all logs matching a given filter object.
Parameters
Object - The filter options which include below fields:
Field Type Description fromBlock QUANTITY|TAG (optional, default: \"latest\") Integer block number, or \"latest\" for the last mined block toBlock QUANTITY|TAG (optional, default: \"latest\") Integer block number, or \"latest\" for the last mined block address DATA|Array, 20 Bytes (optional) Contract address or a list of addresses from which logs should originate. topics Array of DATA (optional) Array of 32 Bytes DATA topics. Topics are order-dependent. Each topic can also be an array of DATA with \"or\" options. blockhash DATA, 32 Bytes (optional) Block hash Returns
See eth_getFilterChanges.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getLogs\",\"params\":[{\"address\":[\"cc2e32f2388f0096fae9b055acffd76d4b3e5532\",\"E518C608A37E2A262050E10BE0C9D03C7A0877F3\"],\"fromBlock\":\"0x989680\",\"toBlock\":\"0x9959d0\",\"topics\":[\"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef\",null,[\"0x0000000000000000000000001806c11be0f9b9af9e626a58904f3e5827b67be7\",\"0x0000000000000000000000003c8fb6d064ceffc0f045f7b4aee6b3a4cefb4758\"]]}],\"id\":1}'\n
Result
{\n\n \"jsonrpc\": \"2.0\",\n\n \"id\": 71,\n\n \"result\": []\n\n}\n
"},{"location":"api/json-rpc/#net","title":"net","text":""},{"location":"api/json-rpc/#net_listening","title":"net_listening","text":"Returns true if the client is actively listening for network connections.
Parameters
None
Returns
Boolean - true when listening, otherwise false.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"net_listening\",\"params\":[],\"id\":64}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":true}\n
"},{"location":"api/json-rpc/#net_peercount","title":"net_peerCount","text":"Returns number of peers currently connected to the client.
Parameters
None
Returns
QUANTITY - integer of the number of connected peers.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"net_peerCount\",\"params\":[],\"id\":64}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x9\"}\n
"},{"location":"api/json-rpc/#net_version","title":"net_version","text":"Returns the hash of the genesis block.
Parameters
None
Returns
String - The hash of genesis block
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\":\"2.0\",\"method\":\"net_version\",\"params\":[],\"id\":64}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":64,\"result\":\"0x2b6653dc\"}\n
"},{"location":"api/json-rpc/#web3","title":"web3","text":""},{"location":"api/json-rpc/#web3_clientversion","title":"web3_clientVersion","text":"Returns the current client version.
Parameters
None
Returns
String - The current client version
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"web3_clientVersion\", \"params\": []}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"TRON/v4.3.0/Linux/Java1.8/GreatVoyage-v4.2.2.1-281-gc1d9dfd6c\"}\n
"},{"location":"api/json-rpc/#web3_sha3","title":"web3_sha3","text":"Returns Keccak-256 (not the standardized SHA3-256) of the given data.
Parameters
DATA - the data to convert into a SHA3 hash
Returns
DATA - The SHA3 result of the given string.
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"web3_sha3\", \"params\": [\"0x68656c6c6f20776f726c64\"]}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad\"}\n
"},{"location":"api/json-rpc/#buildtransaction","title":"buildTransaction","text":"Create a transaction, different transaction types have different parameters
"},{"location":"api/json-rpc/#transfercontract","title":"TransferContract","text":"Parameters
Object - the items in object as below:
Param Name Data Type Description from DATA, 20 Bytes The address the transaction is sent from. to DATA, 20 Bytes The address the transaction is directed to. value DATA the transfer amount Returns
Object - transaction of TransferContract or an error
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"id\": 1337,\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"buildTransaction\",\n\n \"params\": [\n\n {\n\n \"from\": \"0xC4DB2C9DFBCB6AA344793F1DDA7BD656598A06D8\",\n\n \"to\": \"0x95FD23D3D2221CFEF64167938DE5E62074719E54\",\n\n \"value\": \"0x1f4\"\n\n }]}'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1337,\"result\":{\"transaction\":{\"visible\":false,\"txID\":\"ae02a80abd985a6f05478b9bbf04706f00cdbf71e38c77d21ed77e44c634cef9\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"amount\":500,\"owner_address\":\"41c4db2c9dfbcb6aa344793f1dda7bd656598a06d8\",\"to_address\":\"4195fd23d3d2221cfef64167938de5e62074719e54\"},\"type_url\":\"type.googleapis.com/protocol.TransferContract\"},\"type\":\"TransferContract\"}],\"ref_block_bytes\":\"957e\",\"ref_block_hash\":\"3922d8c0d28b5283\",\"expiration\":1684469286000,\"timestamp\":1684469226841},\"raw_data_hex\":\"0a02957e22083922d8c0d28b528340f088c69183315a66080112620a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412310a1541c4db2c9dfbcb6aa344793f1dda7bd656598a06d812154195fd23d3d2221cfef64167938de5e62074719e5418f40370d9bac2918331\"}}}\n
"},{"location":"api/json-rpc/#transferassetcontract","title":"TransferAssetContract","text":"Parameters
Object - the items in object as below:
from DATA, 20 Bytes The address the transaction is sent from to DATA, 20 Bytes The address the transaction is directed to tokenId QUANTITY Token ID tokenValue QUANTITY The transfer amount of TRC10 Returns
Object - transaction of TransferAssetContract or an error
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"method\": \"buildTransaction\",\n\n \"params\": [\n\n {\n\n \"from\": \"0xC4DB2C9DFBCB6AA344793F1DDA7BD656598A06D8\",\n\n \"to\": \"0x95FD23D3D2221CFEF64167938DE5E62074719E54\",\n\n \"tokenId\": 1000016,\n\n \"tokenValue\": 20\n\n }\n\n ],\n\n \"id\": 44,\n\n \"jsonrpc\": \"2.0\"\n\n}\n\n'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":44,\"error\":{\"code\":-32600,\"message\":\"assetBalance must be greater than 0.\",\"data\":\"{}\"}}\n
"},{"location":"api/json-rpc/#createsmartcontract","title":"CreateSmartContract","text":"Parameters
Object - the items in object as below:
from DATA, 20 Bytes The address the transaction is sent from name DATA The name of the smart contract. gas DATA Fee limit abi DATA The ABI of the smart contract. data DATA The byte code of the smart contract. consumeUserResourcePercent QUANTITY The consume user resource percent. originEnergyLimit QUANTITY The origin energy limit. value DATA The data passed through call_value. tokenId QUANTITY Token ID tokenValue QUANTITY The transfer amount of TRC10 Returns
Object - transaction of CreateSmartContract or an error
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\n\n \"id\": 1337,\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"buildTransaction\",\n\n \"params\": [\n\n {\n\n \"from\": \"0xC4DB2C9DFBCB6AA344793F1DDA7BD656598A06D8\",\n\n \"name\": \"transferTokenContract\",\n\n \"gas\": \"0x245498\",\n\n \"abi\": \"[{\\\"constant\\\":false,\\\"inputs\\\":[],\\\"name\\\":\\\"getResultInCon\\\",\\\"outputs\\\":[{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"trcToken\\\"},{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"uint256\\\"},{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"payable\\\":true,\\\"stateMutability\\\":\\\"payable\\\",\\\"type\\\":\\\"function\\\"},{\\\"constant\\\":false,\\\"inputs\\\":[{\\\"name\\\":\\\"toAddress\\\",\\\"type\\\":\\\"address\\\"},{\\\"name\\\":\\\"id\\\",\\\"type\\\":\\\"trcToken\\\"},{\\\"name\\\":\\\"amount\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"name\\\":\\\"TransferTokenTo\\\",\\\"outputs\\\":[],\\\"payable\\\":true,\\\"stateMutability\\\":\\\"payable\\\",\\\"type\\\":\\\"function\\\"},{\\\"constant\\\":false,\\\"inputs\\\":[],\\\"name\\\":\\\"msgTokenValueAndTokenIdTest\\\",\\\"outputs\\\":[{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"trcToken\\\"},{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"uint256\\\"},{\\\"name\\\":\\\"\\\",\\\"type\\\":\\\"uint256\\\"}],\\\"payable\\\":true,\\\"stateMutability\\\":\\\"payable\\\",\\\"type\\\":\\\"function\\\"},{\\\"inputs\\\":[],\\\"payable\\\":true,\\\"stateMutability\\\":\\\"payable\\\",\\\"type\\\":\\\"constructor\\\"}]\\n\",\n\n \"data\": \"6080604052d3600055d2600155346002556101418061001f6000396000f3006080604052600436106100565763ffffffff7c010000000000000000000000000000000000000000000000000000000060003504166305c24200811461005b5780633be9ece71461008157806371dc08ce146100aa575b600080fd5b6100636100b2565b60408051938452602084019290925282820152519081900360600190f35b6100a873ffffffffffffffffffffffffffffffffffffffff600435166024356044356100c0565b005b61006361010d565b600054600154600254909192565b60405173ffffffffffffffffffffffffffffffffffffffff84169082156108fc029083908590600081818185878a8ad0945050505050158015610107573d6000803e3d6000fd5b50505050565bd3d2349091925600a165627a7a72305820a2fb39541e90eda9a2f5f9e7905ef98e66e60dd4b38e00b05de418da3154e7570029\",\n\n \"consumeUserResourcePercent\": 100,\n\n \"originEnergyLimit\": 11111111111111,\n\n \"value\": \"0x1f4\",\n\n \"tokenId\": 1000033,\n\n \"tokenValue\": 100000\n\n }\n\n ]\n\n}\n\n'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1337,\"result\":{\"transaction\":{\"visible\":false,\"txID\":\"598d8aafbf9340e92c8f72a38389ce9661b643ff37dd2a609f393336a76025b9\",\"contract_address\":\"41dfd93697c0a978db343fe7a92333e11eeb2f967d\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"token_id\":1000033,\"owner_address\":\"41c4db2c9dfbcb6aa344793f1dda7bd656598a06d8\",\"call_token_value\":100000,\"new_contract\":{\"bytecode\":\"6080604052d3600055d2600155346002556101418061001f6000396000f3006080604052600436106100565763ffffffff7c010000000000000000000000000000000000000000000000000000000060003504166305c24200811461005b5780633be9ece71461008157806371dc08ce146100aa575b600080fd5b6100636100b2565b60408051938452602084019290925282820152519081900360600190f35b6100a873ffffffffffffffffffffffffffffffffffffffff600435166024356044356100c0565b005b61006361010d565b600054600154600254909192565b60405173ffffffffffffffffffffffffffffffffffffffff84169082156108fc029083908590600081818185878a8ad0945050505050158015610107573d6000803e3d6000fd5b50505050565bd3d2349091925600a165627a7a72305820a2fb39541e90eda9a2f5f9e7905ef98e66e60dd4b38e00b05de418da3154e7570029\",\"consume_user_resource_percent\":100,\"name\":\"transferTokenContract\",\"origin_address\":\"41c4db2c9dfbcb6aa344793f1dda7bd656598a06d8\",\"abi\":{\"entrys\":[{\"outputs\":[{\"type\":\"trcToken\"},{\"type\":\"uint256\"},{\"type\":\"uint256\"}],\"payable\":true,\"name\":\"getResultInCon\",\"stateMutability\":\"Payable\",\"type\":\"Function\"},{\"payable\":true,\"inputs\":[{\"name\":\"toAddress\",\"type\":\"address\"},{\"name\":\"id\",\"type\":\"trcToken\"},{\"name\":\"amount\",\"type\":\"uint256\"}],\"name\":\"TransferTokenTo\",\"stateMutability\":\"Payable\",\"type\":\"Function\"},{\"outputs\":[{\"type\":\"trcToken\"},{\"type\":\"uint256\"},{\"type\":\"uint256\"}],\"payable\":true,\"name\":\"msgTokenValueAndTokenIdTest\",\"stateMutability\":\"Payable\",\"type\":\"Function\"},{\"payable\":true,\"stateMutability\":\"Payable\",\"type\":\"Constructor\"}]},\"origin_energy_limit\":11111111111111,\"call_value\":500}},\"type_url\":\"type.googleapis.com/protocol.CreateSmartContract\"},\"type\":\"CreateSmartContract\"}],\"ref_block_bytes\":\"80be\",\"ref_block_hash\":\"ac7c3d59c55ac92c\",\"expiration\":1634030190000,\"fee_limit\":333333280,\"timestamp\":1634030131693},\"raw_data_hex\":\"0a0280be2208ac7c3d59c55ac92c40b0fba79ec72f5ad805081e12d3050a30747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e437265617465536d617274436f6e7472616374129e050a1541c4db2c9dfbcb6aa344793f1dda7bd656598a06d812fc040a1541c4db2c9dfbcb6aa344793f1dda7bd656598a06d81adb010a381a0e676574526573756c74496e436f6e2a0a1a08747263546f6b656e2a091a0775696e743235362a091a0775696e743235363002380140040a501a0f5472616e73666572546f6b656e546f22141209746f416464726573731a0761646472657373220e120269641a08747263546f6b656e22111206616d6f756e741a0775696e743235363002380140040a451a1b6d7367546f6b656e56616c7565416e64546f6b656e4964546573742a0a1a08747263546f6b656e2a091a0775696e743235362a091a0775696e743235363002380140040a0630013801400422e0026080604052d3600055d2600155346002556101418061001f6000396000f3006080604052600436106100565763ffffffff7c010000000000000000000000000000000000000000000000000000000060003504166305c24200811461005b5780633be9ece71461008157806371dc08ce146100aa575b600080fd5b6100636100b2565b60408051938452602084019290925282820152519081900360600190f35b6100a873ffffffffffffffffffffffffffffffffffffffff600435166024356044356100c0565b005b61006361010d565b600054600154600254909192565b60405173ffffffffffffffffffffffffffffffffffffffff84169082156108fc029083908590600081818185878a8ad0945050505050158015610107573d6000803e3d6000fd5b50505050565bd3d2349091925600a165627a7a72305820a2fb39541e90eda9a2f5f9e7905ef98e66e60dd4b38e00b05de418da3154e757002928f40330643a157472616e73666572546f6b656e436f6e747261637440c7e3d28eb0c30218a08d0620e1843d70edb3a49ec72f9001a086f99e01\"}}}\n
"},{"location":"api/json-rpc/#triggersmartcontract","title":"TriggerSmartContract","text":"Parameters
Object - the items in object as below:
from DATA, 20 Bytes The address the transaction is sent from to DATA, 20 Bytes The address of the smart contract data DATA The invoked contract function and parameters gas DATA Fee limit value DATA The data passed through call_value tokenId QUANTITY Token ID tokenValue QUANTITY The transfer amount of TRC10 Returns
Object - transaction of TriggerSmartContract or an error
Example
curl -X POST 'https://api.shasta.trongrid.io/jsonrpc' --data '{\"id\": 1337,\n\n \"jsonrpc\": \"2.0\",\n\n \"method\": \"buildTransaction\",\n\n \"params\": [\n\n {\n\n \"from\": \"0xC4DB2C9DFBCB6AA344793F1DDA7BD656598A06D8\",\n\n \"to\": \"0xf859b5c93f789f4bcffbe7cc95a71e28e5e6a5bd\",\n\n \"data\": \"0x3be9ece7000000000000000000000000ba8e28bdb6e49fbb3f5cd82a9f5ce8363587f1f600000000000000000000000000000000000000000000000000000000000f42630000000000000000000000000000000000000000000000000000000000000001\",\n\n \"gas\": \"0x245498\",\n\n \"value\": \"0xA\",\n\n \"tokenId\": 1000035,\n\n \"tokenValue\": 20\n\n }\n\n ]\n\n }\n\n'\n
Result
{\"jsonrpc\":\"2.0\",\"id\":1337,\"result\":{\"transaction\":{\"visible\":false,\"txID\":\"c3c746beb86ffc366ec0ff8bf6c9504c88f8714e47bc0009e4f7e2b1d49eb967\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"amount\":10,\"owner_address\":\"41c4db2c9dfbcb6aa344793f1dda7bd656598a06d8\",\"to_address\":\"41f859b5c93f789f4bcffbe7cc95a71e28e5e6a5bd\"},\"type_url\":\"type.googleapis.com/protocol.TransferContract\"},\"type\":\"TransferContract\"}],\"ref_block_bytes\":\"958c\",\"ref_block_hash\":\"9d8c6bae734a2281\",\"expiration\":1684469328000,\"timestamp\":1684469270364},\"raw_data_hex\":\"0a02958c22089d8c6bae734a22814080d1c89183315a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541c4db2c9dfbcb6aa344793f1dda7bd656598a06d8121541f859b5c93f789f4bcffbe7cc95a71e28e5e6a5bd180a70dc8ec5918331\"}}}\n
"},{"location":"api/rpc/","title":"RPC List","text":"For the specific definition of API, please refer to the following link: api/api.proto
Note
SolidityNode is deprecated. Now a FullNode supports all RPCs of a SolidityNode. New developers should deploy FullNode only.
"},{"location":"api/rpc/#get-account-information","title":"Get account information","text":"rpc GetAccount (Account) returns (Account) {}\n
Nodes: Fullnode and SolidityNode"},{"location":"api/rpc/#trx-transfer","title":"TRX transfer","text":"rpc CreateTransaction (TransferContract) returns (Transaction) {}\n
Nodes: Fullnode"},{"location":"api/rpc/#broadcast-transaction","title":"Broadcast transaction","text":"rpc BroadcastTransaction (Transaction) returns (Return) {}\n
Nodes: Fullnode Description: Transfer, vote, issuance of token, or participation in token offering. Sending signed transaction information to node, and broadcasting it to the entire network after super representatives verification.
"},{"location":"api/rpc/#create-an-account","title":"Create an account","text":"rpc CreateAccount (AccountCreateContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#account-name-update","title":"Account name update","text":"rpc UpdateAccount (AccountUpdateContract) returns (Transaction) {}\n
Nodes: Fullnode"},{"location":"api/rpc/#vote-for-super-representative-candidates","title":"Vote for super representative candidates","text":"rpc VoteWitnessAccount (VoteWitnessContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-ratio-of-brokerage-of-the-super-representative","title":"Query the ratio of brokerage of the super representative","text":"rpc GetBrokerageInfo (BytesMessage) returns (NumberMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-unclaimed-reward","title":"Query unclaimed reward","text":"rpc GetRewardInfo (BytesMessage) returns (NumberMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#update-the-ratio-of-brokerage","title":"Update the ratio of brokerage","text":"rpc UpdateBrokerage (UpdateBrokerageContract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#issue-a-token","title":"Issue a token","text":"rpc CreateAssetIssue (AssetIssueContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-of-list-of-super-representative-candidates","title":"Query of list of super representative candidates","text":"rpc ListWitnesses (EmptyMessage) returns (WitnessList) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#application-for-super-representative","title":"Application for super representative","text":"rpc CreateWitness (WitnessCreateContract) returns (Transaction) {}\n
Nodes: FullNode Description: To apply to become TRON\u2019s Super Representative candidate.
"},{"location":"api/rpc/#information-update-of-super-representative-candidates","title":"Information update of Super Representative candidates","text":"rpc UpdateWitness (WitnessUpdateContract) returns (Transaction) {}\n
Nodes: FullNode Description: Update the website url of the SR.
"},{"location":"api/rpc/#token-transfer","title":"Token transfer","text":"rpc TransferAsset (TransferAssetContract) returns (Transaction){}\n
Node: FullNode"},{"location":"api/rpc/#participate-a-token","title":"Participate a token","text":"rpc ParticipateAssetIssue (ParticipateAssetIssueContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-list-of-nodes-connected-to-the-ip-of-the-api","title":"Query the list of nodes connected to the ip of the api","text":"rpc ListNodes (EmptyMessage) returns (NodeList) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#query-the-list-of-all-issued-tokens","title":"Query the list of all issued tokens","text":"rpc GetAssetIssueList (EmptyMessage) returns (AssetIssueList) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#query-the-token-issued-by-a-given-account","title":"Query the token issued by a given account","text":"rpc GetAssetIssueByAccount (Account) returns (AssetIssueList) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#query-the-token-information-by-token-name","title":"Query the token information by token name","text":"rpc GetAssetIssueByName (BytesMessage) returns (AssetIssueContract) {}\n
Nodes: FullNode and Soliditynode"},{"location":"api/rpc/#query-the-list-of-tokens-by-timestamp","title":"Query the list of tokens by timestamp","text":"rpc GetAssetIssueListByTimestamp (NumberMessage) returns (AssetIssueList){}\n
Nodes: SolidityNode"},{"location":"api/rpc/#get-current-block-information","title":"Get current block information","text":"rpc GetNowBlock (EmptyMessage) returns (Block) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#get-a-block-by-block-height","title":"Get a block by block height","text":"rpc GetBlockByNum (NumberMessage) returns (Block) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#get-the-total-number-of-transactions","title":"Get the total number of transactions","text":"rpc TotalTransaction (EmptyMessage) returns (NumberMessage) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#query-the-transaction-by-transaction-id","title":"Query the transaction by transaction id","text":"rpc getTransactionById (BytesMessage) returns (Transaction) {}\n
Nodes: SolidityNode"},{"location":"api/rpc/#query-the-transaction-by-timestamp","title":"Query the transaction by timestamp","text":"rpc getTransactionsByTimestamp (TimeMessage) returns (TransactionList) {}\n
Nodes: SolidityNode"},{"location":"api/rpc/#stake-trx","title":"Stake TRX","text":"This interface has been deprecated, please use FreezeBalanceV2 to stake TRX to obtain resources.
rpc FreezeBalance (FreezeBalanceContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#unstake-trx","title":"Unstake TRX","text":"Unstake the TRX staked during Stake1.0.
rpc UnfreezeBalance (UnfreezeBalanceContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#block-producing-reward-redemption","title":"Block producing reward redemption","text":"rpc WithdrawBalance (WithdrawBalanceContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#unstake-token-balance","title":"Unstake token balance","text":"rpc UnfreezeAsset (UnfreezeAssetContract) returns (Transaction) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-next-maintenance-time","title":"Query the next maintenance time","text":"rpc GetNextMaintenanceTime (EmptyMessage) returns (NumberMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-transaction-fee-block-information","title":"Query the transaction fee & block information","text":"rpc GetTransactionInfoById (BytesMessage) returns (TransactionInfo) {}\n
Nodes: SolidityNode"},{"location":"api/rpc/#query-block-information-by-block-id","title":"Query block information by block id","text":"rpc GetBlockById (BytesMessage) returns (Block) {}\n
Nodes: FullNode"},{"location":"api/rpc/#update-token-information","title":"Update token information","text":"rpc UpdateAsset (UpdateAssetContract) returns (Transaction) {}\n
Nodes: Fullnode Description: Token update can only be initiated by the token issuer to update token description, url, maximum bandwidth consumption by each account and total bandwidth consumption.
"},{"location":"api/rpc/#query-the-list-of-all-the-tokens-by-pagination","title":"Query the list of all the tokens by pagination","text":"rpc GetPaginatedAssetIssueList (PaginatedMessage) returns (AssetIssueList) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#deploy-a-smart-contract","title":"Deploy a smart contract","text":"rpc DeployContract (CreateSmartContract) returns (TransactionExtention) {}\n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#trigger-a-smart-contract","title":"Trigger a smart contract","text":"rpc TriggerContract (TriggerSmartContract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-a-shielded-transaction","title":"Create a shielded transaction","text":"rpc CreateShieldedTransaction (PrivateParameters) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-a-merkle-tree-information-of-a-note","title":"Get a Merkle tree information of a note","text":"rpc GetMerkleTreeVoucherInfo (OutputPointInfo) returns (IncrementalMerkleVoucherInfo) {}\n
Nodes: FullNode"},{"location":"api/rpc/#scan-note-by-ivk","title":"Scan note by ivk","text":"rpc ScanNoteByIvk (IvkDecryptParameters) returns (DecryptNotes) {}\n
Nodes: FullNode"},{"location":"api/rpc/#scan-note-by-ovk","title":"Scan note by ovk","text":"rpc ScanNoteByOvk (OvkDecryptParameters) returns (DecryptNotes) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-spending-key","title":"Get spending key","text":"rpc GetSpendingKey (EmptyMessage) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-expanded-spending-key","title":"Get expanded spending key","text":"rpc GetExpandedSpendingKey (BytesMessage) returns (ExpandedSpendingKeyMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-ak-from-ask","title":"Get ak from ask","text":"rpc GetAkFromAsk (BytesMessage) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-nk-from-nsk","title":"Get nk from nsk","text":"rpc GetNkFromNsk (BytesMessage) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-incoming-viewing-key","title":"Get incoming viewing key","text":"rpc GetIncomingViewingKey (ViewingKeyMessage) returns (IncomingViewingKeyMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-diversifier","title":"Get diversifier","text":"rpc GetDiversifier (EmptyMessage) returns (DiversifierMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-zen-payment-address","title":"Get zen payment address","text":"rpc GetZenPaymentAddress (IncomingViewingKeyDiversifierMessage) returns (PaymentAddressMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-rcm","title":"Get rcm","text":"rpc GetRcm (EmptyMessage) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-a-note-status-of-is-spent-or-not","title":"Get a note status of is spent or not","text":"rpc IsSpend (NoteParameters) returns (SpendResult) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-a-shielded-transaction-without-using-ask","title":"Create a shielded transaction without using ask","text":"rpc CreateShieldedTransactionWithoutSpendAuthSig (PrivateParametersWithoutAsk) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-a-shielded-transaction-hash","title":"Create a shielded transaction hash","text":"rpc GetShieldTransactionHash (Transaction) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-a-signature-for-a-shielded-transaction","title":"Create a signature for a shielded transaction","text":"rpc CreateSpendAuthSig (SpendAuthSigParameters) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-a-shield-nullifier","title":"Create a shield nullifier","text":"rpc CreateShieldNullifier (NfParameters) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-new-shielded-address","title":"Get new shielded address","text":"rpc GetNewShieldedAddress (EmptyMessage) returns (ShieldedAddressInfo){}\n
Nodes: FullNode"},{"location":"api/rpc/#create-shielded-contract-parameters","title":"Create shielded contract parameters","text":"rpc CreateShieldedContractParameters (PrivateShieldedTRC20Parameters) returns (ShieldedTRC20Parameters) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-shielded-contract-parameters-without-ask","title":"Create shielded contract parameters without ask","text":"rpc CreateShieldedContractParametersWithoutAsk (PrivateShieldedTRC20ParametersWithoutAsk) returns (ShieldedTRC20Parameters) {}\n
Nodes: FullNode"},{"location":"api/rpc/#scan-shielded-trc20-notes-by-ivk","title":"Scan shielded TRC20 notes by ivk","text":"rpc ScanShieldedTRC20NotesbyIvk (IvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}\n
Nodes: FullNode, SolidityNode"},{"location":"api/rpc/#scan-shielded-trc20-notes-by-ovk","title":"Scan shielded TRC20 notes by ovk","text":"rpc ScanShieldedTRC20NotesbyOvk (OvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}\n
Nodes: FullNode, SolidityNode"},{"location":"api/rpc/#get-the-status-of-shielded-trc20-note-of-spent-or-not","title":"Get the status of shielded TRC20 note of spent or not","text":"rpc IsShieldedTRC20ContractNoteSpent (NfTRC20Parameters) returns (NullifierResult) {}\n
Nodes: FullNode, SolidityNode"},{"location":"api/rpc/#get-the-trigger-input-for-the-shielded-trc20","title":"Get the trigger input for the shielded TRC20","text":" rpc GetTriggerInputForShieldedTRC20Contract (ShieldedTRC20TriggerContractParameters) returns (BytesMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#create-an-market-order","title":"Create an market order","text":"rpc MarketSellAsset (MarketSellAssetContract) returns (TransactionExtention) {};\n
Nodes: FullNode"},{"location":"api/rpc/#cancel-the-order","title":"Cancel the order","text":"rpc MarketCancelOrder (MarketCancelOrderContract) returns (TransactionExtention) {};\n
Nodes: FullNode "},{"location":"api/rpc/#get-all-orders-for-the-account","title":"Get all orders for the account","text":"rpc GetMarketOrderByAccount (BytesMessage) returns (MarketOrderList) {};\n
Nodes: FullNode "},{"location":"api/rpc/#get-all-trading-pairs","title":"Get all trading pairs","text":"rpc GetMarketPairList (EmptyMessage) returns (MarketOrderPairList) {};\n
Nodes: FullNode "},{"location":"api/rpc/#get-all-orders-for-the-trading-pair","title":"Get all orders for the trading pair","text":"rpc GetMarketOrderListByPair (MarketOrderPair) returns (MarketOrderList) {};\n
Nodes: FullNode "},{"location":"api/rpc/#get-all-prices-for-the-trading-pair","title":"Get all prices for the trading pair","text":"rpc GetMarketPriceByPair (MarketOrderPair) returns (MarketPriceList) {};\n
Nodes: FullNode "},{"location":"api/rpc/#get-order-by-id","title":"Get order by id","text":"rpc GetMarketOrderById (BytesMessage) returns (MarketOrder) {}; \n
Nodes: FullNode "},{"location":"api/rpc/#perform-a-historical-balance-lookup","title":"perform a historical balance lookup","text":"rpc GetAccountBalance (AccountBalanceRequest) returns (AccountBalanceResponse){}; \n
Nodes: FullNode "},{"location":"api/rpc/#fetch-all-balance-changing-transactions-in-a-block","title":"fetch all balance-changing transactions in a block","text":"rpc GetBlockBalanceTrace (BlockBalanceTrace.BlockIdentifier) returns (BlockBalanceTrace) {}; \n
Nodes: FullNode "},{"location":"api/rpc/#get-the-burn-trx-amount","title":"get the burn trx amount","text":"rpc GetBurnTrx (EmptyMessage) returns (NumberMessage) {}; \n
Nodes: FullNode and SolidityNode"},{"location":"api/rpc/#freeze-trx","title":"Freeze TRX","text":"rpc FreezeBalanceV2 (FreezeBalanceV2Contract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#unfreeze-trx","title":"UnFreeze TRX","text":"rpc UnfreezeBalanceV2 (UnfreezeBalanceV2Contract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#withdraw-staked-trx","title":"Withdraw Staked TRX","text":"rpc WithdrawExpireUnfreeze (WithdrawExpireUnfreezeContract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#delegate-resource","title":"Delegate Resource","text":"rpc DelegateResource (DelegateResourceContract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#undelegate-resource","title":"UnDelegate Resource","text":"rpc UnDelegateResource (UnDelegateResourceContract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#query-transaction-information-in-the-pending-pool","title":"Query transaction information in the pending pool","text":"rpc GetTransactionFromPending (BytesMessage) returns (Transaction) {};\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-pending-pool-transaction-id-list","title":"Query the pending pool transaction id list","text":"rpc GetTransactionListFromPending (EmptyMessage) returns (TransactionIdList) {};\n
Nodes: FullNode"},{"location":"api/rpc/#query-the-size-of-the-pending-pool","title":"Query the size of the pending pool","text":"rpc GetPendingSize (EmptyMessage) returns (NumberMessage) {};\nNodes: FullNode\n
"},{"location":"api/rpc/#cancel-unfreeze","title":"Cancel UnFreeze","text":"rpc CancelAllUnfreezeV2 (CancelAllUnfreezeV2Contract) returns (TransactionExtention) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-bandwidth-unit-price","title":"Get bandwidth unit price","text":"rpc GetBandwidthPrices (EmptyMessage) returns (PricesResponseMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-energy-unit-price","title":"Get energy unit price","text":"rpc GetEnergyPrices (EmptyMessage) returns (PricesResponseMessage) {}\n
Nodes: FullNode"},{"location":"api/rpc/#get-transaction-memo-fee","title":"Get transaction memo fee","text":"rpc GetMemoFee (EmptyMessage) returns (PricesResponseMessage) {}\n
Nodes: FullNodes"},{"location":"architecture/database/","title":"Database configuration","text":"java-tron data storage supports LevelDB or RocksDB, and LevelDB is used by default. You can also choose RocksDB, which provides lots of configuration parameters, allowing nodes to be tuned according to their own machine configuration. The node database occupies less disk space than LevelDB. At the same time, RocksDB supports data backup during runtime, and the backup time only takes a few seconds.
The following describes how to set the storage engine of the java-tron node to RocksDB, and how to perform data conversion between leveldb and rocksdb.
"},{"location":"architecture/database/#rocksdb","title":"RocksDB","text":""},{"location":"architecture/database/#configuration","title":"Configuration","text":"Use RocksDB as the data storage engine, need to set db.engine to \"ROCKSDB\".
Note: RocksDB only supports db.version=2, yet does not supports db.version=1
The optimization parameters RocksDB support:
"},{"location":"architecture/database/#use-rocksdbs-data-backup-function","title":"Use RocksDB's data backup function","text":"Choose RocksDB to be the data storage engine, you can use its data backup function while running
Note: FullNode can use data backup function. In order not to affect SuperNode's block producing performance, SuperNode does not support backup service, but SuperNode's backup service node can use this function.
"},{"location":"architecture/database/#convert-leveldb-to-rocksdb","title":"Convert LevelDB to RocksDB","text":"The data storage structure of LevelDB and RocksDB is not compatible, please make sure the node use the same type of data engine all the time. We provide data conversion script which can convert LevelDB data to RocksDB data.
Usage:
> cd /path/to/java-tron/source-code\n> ./gradlew build # build the source code\n> java -jar build/libs/DBConvert.jar # run data conversion command\n
Note: If the node's data storage directory is self-defined, before run DBConvert.jar, you need to add the following parameters:
- src_db_path: specify LevelDB source directory, default output-directory/database
- dst_db_path: specify RocksDb source directory, default output-directory-dst/database
Example, if you run the script like this:
> nohup java -jar FullNode.jar -d your_database_dir </dev/null &>/dev/null &\n
then, you should run DBConvert.jar this way:
> java -jar build/libs/DBConvert.jar your_database_dir/database output-directory-dst/database\n
Note: You have to stop the running of the node, and then to run the data conversion script.
If you do not want to stop the running of the node for too long, after node is shut down, you can copy leveldb's output-directory to the new directory, and then restart the node. Run DBConvert.jar in the previous directory of the new directory, and specify the parameters: src_db_path and dst_db_path.
Example:
> cp -rf output-directory /tmp/output-directory\n> cd /tmp\n> java -jar DBConvert.jar output-directory/database output-directory-dst/database\n
All the whole data conversion process may take 10 hours.
"},{"location":"architecture/database/#leveldb","title":"LevelDB","text":"You can refer to the following documents for detailed information about RocksDB vs LevelDB
"},{"location":"architecture/event/","title":"Event Subscription","text":""},{"location":"architecture/event/#using-event-plugin-for-event-subscription","title":"Using Event Plugin for Event Subscription","text":""},{"location":"architecture/event/#tip","title":"TIP","text":"The TIP: TIP-12:TRON event subscribes model .
"},{"location":"architecture/event/#event-type","title":"Event Type","text":"TRON Event Subscription supports 4 types of event:
"},{"location":"architecture/event/#transaction-event","title":"Transaction Event","text":"The parameters passed to Subscriber:
transactionId: transaction hash\nblockHash: block hash\nblockNumber: block number\nenergyUsage: energy usage\nenergyFee: energy fee\noriginEnergyUsage: origin energy usage\nenergyUsageTotal: total energy usage total\n
"},{"location":"architecture/event/#block-event","title":"Block Event","text":"The parameters passed to Subscriber:
blockHash: block hash\nblockNumber: block number\ntransactionSize: the number of transactions in a block\nlatestSolidifiedBlockNumber: the latest solidified block number\ntransactionList: the transactions hash list\n
"},{"location":"architecture/event/#contract-event","title":"Contract Event","text":"The parameters passed to Subscriber:
transactionId: transaction id\ncontractAddress: contract address\ncallerAddress: contract caller address\nblockNumber: the number of the block contract related events recorded\nblockTimestamp: the block time stamp\neventSignature: event signature\ntopicMap: the map of topic in solidity language\ndata: the data information in solidity language\nremoved: 'true' means the log is removed\n
"},{"location":"architecture/event/#contract-log-event","title":"Contract Log Event","text":"The parameters passed to Subscriber:
transactionId: transaction hash\ncontractAddress: contract address\ncallerAddress: contract caller address\nblockNumber: the number of the block contract related events recorded\nblockTimestamp: the block time stamp\ncontractTopics: the list of topic in solidity language\ndata: the data information in solidity language\nremoved: 'true' means the log is removed\n
Contract Event and Contract Log Even support event filter function which includes:
fromBlock: the start block number\ntoBlock: the end block number\ncontractAddress: contract addresses list\ncontractTopics: contract topics list\n
Note
- Historical data query is not supported.
- When subscribing to non-solidified events, be sure to use the two parameters
blockNumber and blockHash as the criteria to verify that the received events are valid. In special cases such as unstable network connections causing chain reorg, event reorg may occur as well, resulting in stale events.
"},{"location":"architecture/event/#new-features","title":"New Features","text":" - Supporting event plug-ins, kafka & mongodb plug-ins have been released, developers can also customize their own plug-ins according to their own needs.
- Supporting subscription of chain data, such as block, transaction, contract log, contract event and so on. For transaction events, developers can get information such as internal transactions, contract info and so on; for contract events, developers could configure the contract addresses list or contract topic list to receive the specified events, and event subscription has a very low latency. The deployed fullnode can receive event information immediately after the contract is executed.
- Event query service tron-eventquery, online Event query service provided. Developers can query trigger information in the last seven days through https, and the query address is https://api.tronex.io.
"},{"location":"architecture/event/#github-projects","title":"Github projects","text":" - tronprotocol/event-plugin
- tronprotocol/tron-eventquery
"},{"location":"architecture/event/#event-plugin","title":"Event plugin","text":" - Kafka deployment
- MongoDB deployment
"},{"location":"architecture/event/#event-query","title":"Event query","text":"TRON Event Query Service
TronEventQuery is implemented with Tron's new event subscribe model. It uses same query interface with Tron-Grid. Users can also subscribe block trigger, transaction trigger, contract log trigger, and contract event trigger. TronEvent is independent of a particular branch of java-tron, the new event subscribes model will be released on version 3.5 of java-tron.
For more information of TRON event subscribe model, please refer to TIP-12.
- Event query deployment
- Event query HTTP API
"},{"location":"architecture/event/#using-java-trons-built-in-message-queue-for-event-subscription","title":"Using java-tron's Built-in Message Queue for Event Subscription","text":"TRON provides event subscription service. Developers can not only obtain on-chain events through event plugin, but also through java-tron\u2019s built-in ZeroMQ message queue. The difference is that event plugin needs to be additionally deployed, which is used to implement event storage: developers can choose appropriate storage tools according to their needs, such as MongoDB, Kafka, etc., and the plugin help complete the storage of subscribed events. java-tron's built-in ZeroMQ does not require additional deployment operations. Event subscribers can directly connect to the publisher's ip and port, set subscription topics, and receive subscribed events. However, this method does not provide event storage. Therefore, when developers want to subscribe to events directly from nodes for a short period of time, then using the built-in message queue will be a more appropriate choice.
This article will introduce how to subscribe to events through java-tron's built-in message queue in detail.
"},{"location":"architecture/event/#configure-node","title":"Configure node","text":"To use the built-in ZeroMQ of the node for event subscription, you need to set the configuration item useNativeQueue to true in the node configuration file.
event.subscribe = {\n native = {\n useNativeQueue = true // if true, use native message queue, else use event plugin.\n bindport = 5555 // bind port\n sendqueuelength = 1000 //max length of send queue\n }\n\n ......\n\n topics = [\n {\n triggerName = \"block\" // block trigger, the value can't be modified\n enable = true\n topic = \"block\" // plugin topic, the value could be modified\n },\n ......\n ]\n}\n
native.useNativeQueue: true is to use the built-in message queue, false is to use the event pluginnative.bindport: ZeroMQ publisher binding port. In this example, it is 5555, so the publisher address that the subscriber should connect to is \"tcp://127.0.0.1:5555\" native.sendqueuelength: The length of the send queue, that is, when the subscriber receives messages slowly, the maximum number of messages published by the publisher that the TCP buffer can hold. if it exceeds, The message will be discarded if exceeds the capacitytopics: Subscribed event type , including block type, transaction type, etc.
"},{"location":"architecture/event/#start-node","title":"Start node","text":"The event subscription service is disabled by default and needs to be enabled by adding the command line parameter --es. The start command of the node that enables the event subscription service is as follows:
$ java -jar FullNode.jar --es\n
"},{"location":"architecture/event/#prepare-event-subscription-script","title":"Prepare event subscription script","text":"This article takes Nodejs as an example to illustrate how to subscribe to events.
First, install the zeromq library:
$ npm install zeromq@5\n
Then, write the subscriber code: // subscriber.js\nvar zmq = require(\"zeromq\"),\nvar sock = zmq.socket(\"sub\");\n\nsock.connect(\"tcp://127.0.0.1:5555\");\nsock.subscribe(\"block\");\nconsole.log(\"Subscriber connected to port 5555\");\n\nsock.on(\"message\", function(topic, message) {\n console.log(\n \"received a message related to:\",\n Buffer.from(topic).toString(),\n \", containing message:\",\n Buffer.from(message).toString()\n );\n});\n
This example connects the subscriber to the node event publisher and subscribes to block events."},{"location":"architecture/event/#start-subscriber","title":"Start subscriber","text":"Start command of Nodejs is as below:
$ node subscriber.js\n\n> Subscriber connected to port 5555\n
When the node has a new block, the subscriber will receive block event, the output information is as follows: received a message related to: blockTrigger, containing message: {\"timeStamp\":1678343709000,\"triggerName\":\"blockTrigger\",\"blockNumber\":1361,\"blockHash\":\"00000000000005519b3995cd638753a862c812d1bda11de14bbfaa5ad3383280\",\"transactionSize\":0,\"latestSolidifiedBlockNumber\":1361,\"transactionList\":[]}\nreceived a message related to: blockTrigger, containing message: {\"timeStamp\":1678343712000,\"triggerName\":\"blockTrigger\",\"blockNumber\":1362,\"blockHash\":\"0000000000000552d53d1bdd9929e4533a983f14df8931ee9b3bf6d6c74a47b0\",\"transactionSize\":0,\"latestSolidifiedBlockNumber\":1362,\"transactionList\":[]}\n
"},{"location":"clients/wallet-cli/","title":"wallet-cli","text":""},{"location":"clients/wallet-cli/#introduction","title":"Introduction","text":"wallet-cli is an interactive command-line wallet that supports the TRON network for signing and broadcasting transactions in a secure local environment, as well as access to on-chain data. wallet-cli supports key management, you can import the private key into the wallet, wallet-cli will encrypt your private key with a symmetric encryption algorithm and store it in a keystore file. wallet-cli does not store on-chain data locally. It uses gRPC to communicate with a java-tron node. You need to configure the java-tron node to be linked in the configuration file. The following figure shows the process of the use of wallet-cli to sign and broadcast when transferring TRX:
The user first runs the Login command to unlock the wallet, and then runs the SendCoin command to send TRX, wallet-cli will build and sign the transaction locally, and then call the BroadcastTransaction gRPC API of the java-tron node to broadcast the transaction to the network. After the broadcast is successful, the java-tron node will return the transaction hash to wallet-cli, and wallet-cli will display the transaction hash to the user.
Install and run: wallet-cli
"},{"location":"clients/wallet-cli/#commands","title":"Commands","text":"Below, please find all types of wallet-cli commands\uff1a
- Wallet
- Account
- AccountResource
- Transaction
- On-ChainInquire
- SmartContract
- TRC-10
- Governance
- DEX
"},{"location":"clients/wallet-cli/#wallet","title":"Wallet","text":"Here are all the wallet related commands \uff1a
- RegisterWallet
- Login
- BackupWallet
- BackupWallet2Base64
- ChangePassword
- ImportWallet
- ImportWalletByBase64
This section introduces commands related to wallet management. Let's start withregisterwalletto get a new account.
"},{"location":"clients/wallet-cli/#registerwallet","title":"RegisterWallet","text":"To register your wallet, you need to set the wallet password and generate the address and private key. A .json keystore file will be generated under the path of wallet-cli/wallet. The file will be used for login and backupwallet later.
wallet> RegisterWallet \nPlease input password.\npassword: \nPlease input password again.\npassword: \nRegister a wallet successful, keystore file name is UTC--2022-06-27T07-37-47.601000000Z--TWyDBTHsWJFhgywWkTNW7vh7jSUxeBaiAw.json\n
"},{"location":"clients/wallet-cli/#login","title":"Login","text":"When we have a keystore file, we can start to login. After enter the command, choose the keystore file and enter the password.
wallet> login\nuse user defined config file in current dir\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-06-22T08-31-57.735000000Z--TBnPDbw99BLzPUZuW8Rrcc3RGGQT3cnSfF.json\nThe 4th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 5th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 5\n4\nPlease input your password.\npassword: \nLogin successful !!!\n
"},{"location":"clients/wallet-cli/#backupwallet","title":"BackupWallet","text":"This will Back up your wallet. You need to enter your wallet password to export the privat key in hex string format, such as:
721d63b074f18d41c147e04c952ec93467777a30b6f16745bc47a8eae5076545\n
wallet> backupwallet\nPlease input your password.\npassword: \nBackupWallet successful !!\n721d63b074f18d41c147e04c952ec93467777a30b6f16745bc47a8eae5076545\n
"},{"location":"clients/wallet-cli/#backupwallet2base64","title":"BackupWallet2Base64","text":"This will Back up your wallet, you need to enter your wallet password to export the private key in base64 format, as below:
ch1jsHTxjUHBR+BMlS7JNGd3ejC28WdFvEeo6uUHZUU=\n
wallet> backupwallet\nPlease input your password.\npassword: \nBackupWallet successful !!\nch1jsHTxjUHBR+BMlS7JNGd3ejC28WdFvEeo6uUHZUU=\n
"},{"location":"clients/wallet-cli/#changepassword","title":"ChangePassword","text":"Modify the password of an account
wallet> changepassword\nPlease input old password.\npassword: \nPlease input new password.\nPlease input password.\npassword: \nPlease input password again.\npassword: \nThe 1th keystore file name is .DS_Store\nThe 2th keystore file name is UTC--2022-06-27T10-58-59.306000000Z--TBnPDbw99BLzPUZuW8Rrcc3RGGQT3cnSfF.json\nPlease choose between 1 and 2\n2\nChangePassword successful !!\n
"},{"location":"clients/wallet-cli/#importwallet","title":"ImportWallet","text":"Import a wallet, you need to set a password first and then enter your hex string private key.
wallet> importwallet\nPlease input password.\npassword: \nPlease input password again.\npassword: \nPlease input private key. Max retry time:3\nbd1ff0f4f852db45316bf08755bf6eee45d0678bfbf852a00020a13d42a1fb5b\nImport a wallet successful, keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\n
"},{"location":"clients/wallet-cli/#importwalletbybase64","title":"ImportWalletByBase64","text":"To import a wallet, you need to set a password first and then enter your private key in base64 format.
wallet> importwalletbybase64\nPlease input password.\npassword: \nPlease input password again.\npassword: \nPlease input private key by base64. Max retry time:3\nvR/w9PhS20Uxa/CHVb9u7kXQZ4v7+FKgACChPUKh+1s= \nImport a wallet successful, keystore file name is UTC--2022-06-28T06-51-56.154000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\n
"},{"location":"clients/wallet-cli/#account","title":"Account","text":"Here are all the account related commands \uff1a
- GenerateAddress
- GetAccount
- GetAddress
- GetBalance
- UpdateAccountPermission
"},{"location":"clients/wallet-cli/#generateaddress","title":"GenerateAddress","text":"Generate an address and print out the public (address) and private key
wallet> generateaddress\n{\n \"address\": \"TQAvi6bemLa1t1irdV1KuaSC5vKc2EswTj\",\n \"privateKey\": \"610a8a809114a96140e1cb040a7813afc74603e58c3d7824c3f68ccc642c297e\"\n}\n
Note: address and private key generated by this command would not be saved in wallet-cli. Keep properly if you would like to use them."},{"location":"clients/wallet-cli/#getaccount","title":"GetAccount","text":"Get account information by an address
wallet> getaccount [address]\n
wallet> getaccount TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\n{\n \"address\": \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"balance\": 2665198240,\n \"create_time\": 1650363711000,\n \"latest_opration_time\": 1653578769000,\n \"latest_consume_free_time\": 1651228080000,\n \"account_resource\": {\n \"latest_consume_time_for_energy\": 1653578769000\n },\n \"owner_permission\": {\n \"permission_name\": \"owner\",\n \"threshold\": 1,\n \"keys\": [\n {\n \"address\": \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"weight\": 1\n }\n ]\n },\n \"active_permission\": [\n {\n \"type\": \"Active\",\n \"id\": 2,\n \"permission_name\": \"active\",\n \"threshold\": 1,\n \"operations\": \"7fff1fc0033e3b00000000000000000000000000000000000000000000000000\",\n \"keys\": [\n {\n \"address\": \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"weight\": 1\n }\n ]\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#getaddress","title":"GetAddress","text":"Get the address of the current account
wallet> getaddress\nGetAddress successful !!\naddress = TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\n
"},{"location":"clients/wallet-cli/#getbalance","title":"GetBalance","text":"Get the TRX balance of the current account
wallet> getbalance\nBalance = 2665198240\n
"},{"location":"clients/wallet-cli/#updateaccountpermission","title":"UpdateAccountPermission","text":"wallet>UpdateAccountPermission [ownerAddress] [permissions]\n
This command is used to manage account permissions, assign permissions to other accounts, is utilized for multi-signature transactions, which allows other users to access the account with paritcular permission in order to better manage it. There are three types of permissions: - owner: access to the owner of account
- active: access to other features of accounts, and access that authorizes a certain feature. Block production authorization is not included if it's for SR purposes.
- witness: only for super representatives, block production authorization will be granted to one of the other users.
NOTE the parameterPermission must written in JSON format and entered in line. If the owner account is not SR, then do not assign super representative permission.
wallet> updateaccountpermission TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8 {\"owner_permission\":{\"keys\":[{\"address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\"weight\":1}],\"threshold\":1,\"type\":0,\"permission_name\":\"owner\"},\"active_permissions\":[{\"operations\":\"7fff1fc0033e0000000000000000000000000000000000000000000000000000\",\"keys\":[{\"address\":\"TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej\",\"weight\":1},{\"address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\",\"weight\":1}],\"threshold\":2,\"type\":2,\"permission_name\":\"active12323\"}]}\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"owner\":{\n \"keys\":[\n {\n \"address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"weight\":1\n }\n ],\n \"threshold\":1,\n \"permission_name\":\"owner\"\n },\n \"owner_address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"actives\":[\n {\n \"operations\":\"7fff1fc0033e0000000000000000000000000000000000000000000000000000\",\n \"keys\":[\n {\n \"address\":\"TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej\",\n \"weight\":1\n },\n {\n \"address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\",\n \"weight\":1\n }\n ],\n \"threshold\":2,\n \"type\":\"Active\",\n \"permission_name\":\"active12323\"\n }\n ]\n },\n \"type_url\":\"type.googleapis.com/protocol.AccountPermissionUpdateContract\"\n },\n \"type\":\"AccountPermissionUpdateContract\"\n }\n ],\n \"ref_block_bytes\":\"4e88\",\n \"ref_block_hash\":\"11a47859be13f689\",\n \"expiration\":1656423231000,\n \"timestamp\":1656423171818\n },\n \"raw_data_hex\":\"0a024e88220811a47859be13f6894098dc92d49a305aee01082e12e9010a3c747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e4163636f756e745065726d697373696f6e557064617465436f6e747261637412a8010a1541babecec4d9f58f0df77f0728b9c53abb1f21d68412241a056f776e657220013a190a1541babecec4d9f58f0df77f0728b9c53abb1f21d6841001226908021a0b6163746976653132333233200232207fff1fc0033e00000000000000000000000000000000000000000000000000003a190a15410cfaec7164cbfe78dbb8d8fba7e23b4d745ed81310013a190a1541e8bd653015895947cec33d1670a88cf67ab277b9100170ea8d8fd49a30\"\n}\nbefore sign transaction hex string is 0a8d020a024e88220811a47859be13f6894098dc92d49a305aee01082e12e9010a3c747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e4163636f756e745065726d697373696f6e557064617465436f6e747261637412a8010a1541babecec4d9f58f0df77f0728b9c53abb1f21d68412241a056f776e657220013a190a1541babecec4d9f58f0df77f0728b9c53abb1f21d6841001226908021a0b6163746976653132333233200232207fff1fc0033e00000000000000000000000000000000000000000000000000003a190a15410cfaec7164cbfe78dbb8d8fba7e23b4d745ed81310013a190a1541e8bd653015895947cec33d1670a88cf67ab277b9100170ea8d8fd49a30\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 4th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 4\n3\nPlease input your password.\npassword: \nafter sign transaction hex string is 0a8d020a024e88220811a47859be13f6894096bcb5de9a305aee01082e12e9010a3c747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e4163636f756e745065726d697373696f6e557064617465436f6e747261637412a8010a1541babecec4d9f58f0df77f0728b9c53abb1f21d68412241a056f776e657220013a190a1541babecec4d9f58f0df77f0728b9c53abb1f21d6841001226908021a0b6163746976653132333233200232207fff1fc0033e00000000000000000000000000000000000000000000000000003a190a15410cfaec7164cbfe78dbb8d8fba7e23b4d745ed81310013a190a1541e8bd653015895947cec33d1670a88cf67ab277b9100170ea8d8fd49a301241881b00f8e8828d9347469fcbcec730093841c2363561243b7162a9669439266049ab82f20f97a136adc88feff0a4d5aa57b11f762eaa7e05105d27ec5d55a33900\ntxid is 3dce7f18f6cf6962c38904678947b3b32f9e94ba6460874679d8ed063bb1c0eb\nUpdateAccountPermission successful !!!\n
"},{"location":"clients/wallet-cli/#accountresource","title":"AccountResource","text":"Here are all the account resource related commands \uff1a
- FreezeBalance
- UnfreezeBalance
- GetDelegatedResource
- FreezeBalanceV2
- UnfreezeBalanceV2
- DelegateResource
- UndelegateResource
- WithdrawExpireUnfreeze
- GetAvailableUnfreezeCount
- GetCanWithdrawUnfreezeAmount
- GetCanDelegatedMaxsize
- GetDelegatedResourceV2
- GetDelegatedResourceAccountIndexV2
- GetAccountNet
- GetAccountResource
"},{"location":"clients/wallet-cli/#freezebalance","title":"FreezeBalance","text":"This interface has been deprecated, please use freezeBalanceV2 to stake TRX to obtain resources.
wallet> freezeBalance [OwnerAddress] [frozen_balance] [frozen_duration] [ResourceCode:0 BANDWIDTH, 1 ENERGY] [receiverAddress]\n
OwnerAddressis the address of the account that initiated the transaction, optional, default is the address of the login account.frozen_balanceis the amount of frozen TRX, the unit is the smallest unit (Sun), the minimum is 1000000sun.frozen_duration is frozen duration, only be specified as 3 days, indicates that you can unfreeze after 3 days.ResourceCode indicates the type of the acquired resource\uff0c0 BANDWIDTH and 1 ENERGY. receiverAddressis the address that will receive the resource.
ResourceCode and receiverAddress are optional parameters. If ResourceCode is not set\uff0cdefault is 0. If receiverAddress is not set, the TRX is frozen to obtain resources for its OwnerAddress use; if it is not empty, the acquired resources are used by receiverAddress.
Example:
wallet> freezeBalance TWyDBTHsWJFhgywWkTNW7vh7jSUxeBaiAw 1000000 3 1 TCrkRWJuHP4VgQF3xwLNBAjVVXvxRRGpbA\n{\n \"raw_data\":{\n ...\n },\n \"raw_data_hex\":\"0a02a9b822081db2070d39d2316640c095dda19a305a70080b126c0a32747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e6365436f6e747261637412360a1541e65aca838a9e15dd81bd9532d2ad61300e58cf7110c0843d180350017a15411fafb1e96dfe4f609e2259bfaf8c77b60c535b9370c6c8d9a19a30\"\n}\nbefore sign transaction hex string is 0a8e010a02a9b822081db2070d39d2316640c095dda19a305a70080b126c0a32747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e6365436f6e747261637412360a1541e65aca838a9e15dd81bd9532d2ad61300e58cf7110c0843d180350017a15411fafb1e96dfe4f609e2259bfaf8c77b60c535b9370c6c8d9a19a30\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-22T08-21-05.158000000Z--TDQgNvjrE6RH749f8aFGyJqEEGyhV4BDEU.json\nThe 2th keystore file name is UTC--2022-06-27T07-37-47.601000000Z--TWyDBTHsWJFhgywWkTNW7vh7jSUxeBaiAw.json\nPlease choose between 1 and 2\n2\nPlease input your password.\npassword: \nafter sign transaction hex string is 0a8e010a02a9b822081db2070d39d2316640e0f7ffab9a305a70080b126c0a32747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e6365436f6e747261637412360a1541e65aca838a9e15dd81bd9532d2ad61300e58cf7110c0843d180350017a15411fafb1e96dfe4f609e2259bfaf8c77b60c535b9370c6c8d9a19a301241c45742648e6970e01b242c9b6eca2549c8721b860ced71abd331b9fe925f3c0f184768e0d2e3b580ce787cc6f67d186a0d583226fdb69c2cc8cfc6ec42e389f600\ntxid is f45cb5ae425796a492d4a9ecac8d60fd48bf78dbcdbe1d92725047c5dfbffba2\nFreezeBalance successful !!!\n
"},{"location":"clients/wallet-cli/#unfreezebalance","title":"UnfreezeBalance","text":"unstake TRX which staked during stake1.0.
wallet>unfreezeBalance [OwnerAddress] ResourceCode(0 BANDWIDTH,1 ENERGY,2 TRON_POWER) [receiverAddress]\n
OwnerAddressis the address of the account that initiated the transaction, optional, default is the address of the login account. ResourceCodeindicates the type of the acquired resource\uff0c0 stands for BANDWIDTH and 1 stands for ENERGY. receiverAddressis the address that will receive the resource. wallet> unfreezebalance TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8 1 TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"resource\":\"ENERGY\",\n \"receiver_address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\",\n \"owner_address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\"\n },\n \"type_url\":\"type.googleapis.com/protocol.UnfreezeBalanceContract\"\n },\n \"type\":\"UnfreezeBalanceContract\"\n }\n ],\n \"ref_block_bytes\":\"c8b7\",\n \"ref_block_hash\":\"8842722f2845274d\",\n \"expiration\":1656915213000,\n \"timestamp\":1656915154748\n },\n \"raw_data_hex\":\"0a02c8b722088842722f2845274d40c8f5debe9c305a6c080c12680a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e6365436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d68450017a1541e8bd653015895947cec33d1670a88cf67ab277b970bcaedbbe9c30\"\n}\nbefore sign transaction hex string is 0a8a010a02c8b722088842722f2845274d40c8f5debe9c305a6c080c12680a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e6365436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d68450017a1541e8bd653015895947cec33d1670a88cf67ab277b970bcaedbbe9c30\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny \nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 4th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 4\n3\nPlease input your password.\npassword: \nafter sign transaction hex string is 0a8a010a02c8b722088842722f2845274d40e8dd81c99c305a6c080c12680a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e6365436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d68450017a1541e8bd653015895947cec33d1670a88cf67ab277b970bcaedbbe9c301241593a94650274df29619a6a6946258ea32a22f24a33445f943e3d72cd7d9b8ce7234d188f4bf3a6f0c90cb60af36fc77dc8d376afac9ed840f36dfd68c429fb7e00\ntxid is 3ea58b3ac2cb05868e70d40f58916312d927c40fd1e4c549554dc3e520c1efde\nUnfreezeBalance successful !!!\n
"},{"location":"clients/wallet-cli/#getdelegatedresource","title":"GetDelegatedResource","text":"wallet>getdelegatedresource [fromAddress] [toAddress]\n
Get the information from the fromAddress, which is the resource owner's address, to the toAddress, which is the delegated address who is on behalf of the resource owner. wallet> getdelegatedresource TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8 TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\n{\n \"delegatedResource\": [\n {\n \"from\": \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"to\": \"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\",\n \"frozen_balance_for_energy\": 1000000,\n \"expire_time_for_energy\": 1656660447000\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#freezebalancev2","title":"FreezeBalanceV2","text":"Stake 2.0 API: Stake TRX to obtain TRON Power (voting rights) and bandwidth or energy.
wallet> freezeBalanceV2 [OwnerAddress] frozen_balance ResourceCode(0 BANDWIDTH,1 ENERGY,2 TRON_POWER)\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.frozen_balance is the amount of frozen TRX, the unit is the smallest unit (Sun), the minimum is 1000000sun.ResourceCode indicates the type of the acquired resource\uff0c0 BANDWIDTH and 1 ENERGY.
Example:
wallet> freezeBalanceV2 1000000 1\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"resource\":\"ENERGY\",\n \"frozen_balance\":1000000,\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\"\n },\n \"type_url\":\"type.googleapis.com/protocol.FreezeBalanceV2Contract\"\n },\n \"type\":\"FreezeBalanceV2Contract\"\n }\n ],\n \"ref_block_bytes\":\"00bb\",\n \"ref_block_hash\":\"0c237850e9e3c216\",\n \"expiration\":1676620524000,\n \"timestamp\":1676620465372\n },\n \"raw_data_hex\":\"0a0200bb22080c237850e9e3c21640e0d3fbf2e5305a59083612550a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d180170dc89f8f2e530\"\n}\nbefore sign transaction hex string is 0a770a0200bb22080c237850e9e3c21640e0d3fbf2e5305a59083612550a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d180170dc89f8f2e530\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2023-02-17T02-53-57.163000000Z--THLJLytz6UHwpmDFi5RC43D44dmnh4ZTeL.json\nThe 2th keystore file name is UTC--2023-02-17T07-40-47.121000000Z--TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM.json\nPlease choose between 1 and 2\n2\nPlease input your password.\npassword:\nafter sign transaction hex string is 0a770a0200bb22080c237850e9e3c21640dbb89efde5305a59083612550a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d180170dc89f8f2e53012419e46cc7b6706ee6a14a541df5f9c518fae9a71ac7a7cc484c48386eb0997a8ab10c41e09feb905c5cc370fe1d15968d22cec2fd2cdc5916adfd3a78c52f8d47000\ntxid is 1743aa098f5e10ac8b68ccbf0ca6b5f1364a63485e442e6cb03fd33e3331e3fb\nfreezeBalanceV2 successful !!!\n
"},{"location":"clients/wallet-cli/#unfreezebalancev2","title":"UnfreezeBalanceV2","text":"Stake 2.0 API: Unstake TRX to release bandwidth and energy and at the same time TRON Power will be reclaimed and corresponding votes will be revoked.
wallet> unfreezeBalanceV2 [OwnerAddress] unfreezeBalance ResourceCode(0 BANDWIDTH,1 ENERGY,2 TRON_POWER)\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account. unfreezeBalance Amount of TRX to be unstaked. the unit is sun.ResourceCode indicates the type of the acquired resource\uff0c0 stands for BANDWIDTH and 1 stands for ENERGY.
Example:
wallet> unfreezeBalanceV2 1000000 1\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"resource\":\"ENERGY\",\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"unfreeze_balance\":1000000\n },\n \"type_url\":\"type.googleapis.com/protocol.UnfreezeBalanceV2Contract\"\n },\n \"type\":\"UnfreezeBalanceV2Contract\"\n }\n ],\n \"ref_block_bytes\":\"0132\",\n \"ref_block_hash\":\"0772c1a1727e2ef0\",\n \"expiration\":1676620887000,\n \"timestamp\":1676620829314\n },\n \"raw_data_hex\":\"0a02013222080772c1a1727e2ef040d8e791f3e5305a5b083712570a36747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d18017082a58ef3e530\"\n}\nbefore sign transaction hex string is 0a790a02013222080772c1a1727e2ef040d8e791f3e5305a5b083712570a36747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d18017082a58ef3e530\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2023-02-17T02-53-57.163000000Z--THLJLytz6UHwpmDFi5RC43D44dmnh4ZTeL.json\nThe 2th keystore file name is UTC--2023-02-17T07-40-47.121000000Z--TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM.json\nPlease choose between 1 and 2\n2\nPlease input your password.\npassword:\nafter sign transaction hex string is 0a790a02013222080772c1a1727e2ef040ecd2b4fde5305a5b083712570a36747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e63655632436f6e7472616374121d0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d18017082a58ef3e530124111bac22e9bc35e1a78c13796893e9f2b81dc99eb26d9ce7a95d0c6a0a9b5588739c52b999acd370b255d178f57bf2abef8881891f23e042ddf83c3551b8bd98e01\ntxid is f9e114347ea89c5d722d20226817bc41c8a39ea36be756ba216cf450ab3f1fb3\nunfreezeBalanceV2 successful !!!\n
"},{"location":"clients/wallet-cli/#delegateresource","title":"DelegateResource","text":"Stake 2.0 API: delegate bandwidth or energy resource to other address.
wallet> delegateResource [OwnerAddress] balance ResourceCode(0 BANDWIDTH,1 ENERGY), ReceiverAddress [lock]\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.balance Amount of TRX staked for resources to be delegated, unit is sun.ResourceCode Resource type, \"BANDWIDTH\" is 0, \"ENERGY\" is 1.ReceiverAddress Receiver address of resource to be delegated to.lock Whether it is locked, if it is set to true, the delegated resources cannot be undelegated within 3 days. When the lock time is not over, if the owner delegates the same type of resources using the lock to the same address, the lock time will be reset to 3 days. optional, default is 0, 0-lock, 1-unlock.
Example:
wallet> delegateResource 1000000 1 TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g 0\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"balance\":1000000,\n \"resource\":\"ENERGY\",\n \"receiver_address\":\"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\"\n },\n \"type_url\":\"type.googleapis.com/protocol.DelegateResourceContract\"\n },\n \"type\":\"DelegateResourceContract\"\n }\n ],\n \"ref_block_bytes\":\"020c\",\n \"ref_block_hash\":\"54e32e95d11894f8\",\n \"expiration\":1676621547000,\n \"timestamp\":1676621487525\n },\n \"raw_data_hex\":\"0a02020c220854e32e95d11894f840f88bbaf3e5305a710839126d0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e70a5bbb6f3e530\"\n}\nbefore sign transaction hex string is 0a8f010a02020c220854e32e95d11894f840f88bbaf3e5305a710839126d0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e70a5bbb6f3e530\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2023-02-17T02-53-57.163000000Z--THLJLytz6UHwpmDFi5RC43D44dmnh4ZTeL.json\nThe 2th keystore file name is UTC--2023-02-17T07-40-47.121000000Z--TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM.json\nPlease choose between 1 and 2\n2\nPlease input your password.\npassword:\nafter sign transaction hex string is 0a8f010a02020c220854e32e95d11894f84093e9dcfde5305a710839126d0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e70a5bbb6f3e5301241414de060e9c104bb45d745e22b7b7a30b4a89a2635c62aab152fff5d2f10b7443023a9aa487be86652b74974ff6a7d82d3dbf94cea9ac1e0a7e48e682175e3f601\ntxid is 0917002d0068dde7ad4ffe46e75303d11192e17bfa78934a5f867c5ae20720ec\ndelegateResource successful !!!\n
"},{"location":"clients/wallet-cli/#undelegateresource","title":"UndelegateResource","text":"Stake 2.0 API: undelegate resource.
wallet> unDelegateResource [OwnerAddress] balance ResourceCode(0 BANDWIDTH,1 ENERGY), ReceiverAddress\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.balance Amount of TRX staked for resource to be undelegated, unit is sun.ResourceCode Resource type, \"BANDWIDTH\" is 0, \"ENERGY\" is 1.ReceiverAddress Receiver address of resource to be delegated to.
Example:
wallet> unDelegateResource 1000000 1 TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"balance\":1000000,\n \"resource\":\"ENERGY\",\n \"receiver_address\":\"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\"\n },\n \"type_url\":\"type.googleapis.com/protocol.UnDelegateResourceContract\"\n },\n \"type\":\"UnDelegateResourceContract\"\n }\n ],\n \"ref_block_bytes\":\"0251\",\n \"ref_block_hash\":\"68ac15256c213e71\",\n \"expiration\":1676621754000,\n \"timestamp\":1676621695001\n },\n \"raw_data_hex\":\"0a020251220868ac15256c213e714090ddc6f3e5305a73083a126f0a37747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e709990c3f3e530\"\n}\nbefore sign transaction hex string is 0a91010a020251220868ac15256c213e714090ddc6f3e5305a73083a126f0a37747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e709990c3f3e530\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2023-02-17T02-53-57.163000000Z--THLJLytz6UHwpmDFi5RC43D44dmnh4ZTeL.json\nThe 2th keystore file name is UTC--2023-02-17T07-40-47.121000000Z--TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM.json\nPlease choose between 1 and 2\n2\nPlease input your password.\npassword:\nafter sign transaction hex string is 0a91010a020251220868ac15256c213e7140febde9fde5305a73083a126f0a37747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e44656c65676174655265736f75726365436f6e747261637412340a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca100118c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e709990c3f3e530124102ebde16d1abaccd976f8ead4b5acf92b05f7d9796c28ca6a26b4e51442e638e5e33e598bb03732da24dc761a39b9d307c045b55323128dc9b07510ffc48933a01\ntxid is 537a3f4461ab55c705b77503bc42f469bfc22c0cb8588b8f3641ab40117ebfd8\nunDelegateResource successful !!!\n
"},{"location":"clients/wallet-cli/#withdrawexpireunfreeze","title":"WithdrawExpireUnfreeze","text":"Stake 2.0 API: withdraw unfrozen balance.
wallet> withdrawExpireUnfreeze [OwnerAddress]\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.
Example:
wallet> withdrawExpireUnfreeze \n
"},{"location":"clients/wallet-cli/#getavailableunfreezecount","title":"GetAvailableUnfreezeCount","text":"Stake 2.0 API: remaining times of executing unstake operation.
wallet> getavailableunfreezecount [OwnerAddress]\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.
Example:
wallet> GetAvailableUnfreezeCount\n{\n \"count\": 30\n}\n
"},{"location":"clients/wallet-cli/#getcanwithdrawunfreezeamount","title":"GetCanWithdrawUnfreezeAmount","text":"Stake 2.0 API: query the withdrawable balance at the specified timestamp.
wallet> getcanwithdrawunfreezeamount ownerAddress timestamp\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.timestamp query cutoff timestamp, in milliseconds.
Example:
wallet> getcanwithdrawunfreezeamount 1776621695001\n{\n \"amount\": 4000000\n}\n
"},{"location":"clients/wallet-cli/#getcandelegatedmaxsize","title":"GetCanDelegatedMaxsize","text":"Stake 2.0 API: query the amount of delegatable resources share of the specified resource type for an address, unit is sun.
wallet> getcandelegatedmaxsize ownerAddress type\n
OwnerAddress is the address of the account that initiated the transaction, optional, default is the address of the login account.type resource type, 0 is bandwidth, 1 is energy
Example:
wallet> getcandelegatedmaxsize 1\n{\n \"max_size\": 11000000\n}\n
"},{"location":"clients/wallet-cli/#getdelegatedresourcev2","title":"GetDelegatedResourceV2","text":"Stake 2.0 API\uff1aquery the detail of resource share delegated from fromAddress to toAddress.
wallet> getdelegatedresourcev2 fromAddress toAddress\n
fromAddress resource from address.toAddress resource to address.
Example:
wallet> getdelegatedresourcev2 TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\n{\n \"delegatedResource\": [\n {\n \"from\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"to\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"frozen_balance_for_bandwidth\": 7000000,\n \"frozen_balance_for_energy\": 3000000\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#getdelegatedresourceaccountindexv2","title":"GetDelegatedResourceAccountIndexV2","text":"Stake 2.0 API\uff1aquery the resource delegation index by an account. Two lists will return, one is the list of addresses the account has delegated its resources(toAddress), and the other is the list of addresses that have delegated resources to the account(fromAddress).
wallet> getdelegatedresourceaccountindexv2 ownerAddress\n
OwnerAddress account address.
Example:
wallet> getdelegatedresourceaccountindexv2 TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\n{\n \"account\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"fromAccounts\": [\n \"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\"\n ],\n \"toAccounts\": [\n \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\"\n ]\n}\n
"},{"location":"clients/wallet-cli/#getaccountnet","title":"GetAccountNet","text":"This command shows the usage of bandwidth for a certain account.
wallet> getaccountnet TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\n{\n \"freeNetUsed\": 262,\n \"freeNetLimit\": 1500,\n \"TotalNetLimit\": 43200000000,\n \"TotalNetWeight\": 8725123062\n}\n
"},{"location":"clients/wallet-cli/#getaccountresource","title":"GetAccountResource","text":"This command shows the usage of bandwidth and energy for a certain account.
wallet> getaccountresource TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\n{\n \"freeNetUsed\": 262,\n \"freeNetLimit\": 1500,\n \"TotalNetLimit\": 43200000000,\n \"TotalNetWeight\": 8725123062,\n \"tronPowerLimit\": 1,\n \"TotalEnergyLimit\": 90000000000,\n \"TotalEnergyWeight\": 328098231\n}\n
"},{"location":"clients/wallet-cli/#transaction","title":"Transaction","text":"Here are all the transaction related commands \uff1a
- SendCoin
- AddTransactionSign
- BroadcastTransaction
- BackupWallet2Base64
- GetTransactionApprovedList
"},{"location":"clients/wallet-cli/#sendcoin","title":"SendCoin","text":"> SendCoin [toAddress] [amount]\n
Here is an example of multi-signed transaction. The accounts permission have assigned as in UpdateAccountPermission section, please check for reference. wallet> SendCoin TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE 10\n{\n \"raw_data\":{\n \"contract\":[\n \u00b7\u00b7\u00b7\n \"raw_data_hex\":\"0a029ca12208432ed1fe1357ff7f40c0c484f19a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a708a8481f19a30\"\n}\nbefore sign transaction hex string is 0a83010a029ca12208432ed1fe1357ff7f40c0c484f19a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a708a8481f19a30\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\n2\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 4th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 4\n1\nPlease input your password.\npassword: \nCurrent signWeight is:\n{\n \"result\":{\n \"code\":\"NOT_ENOUGH_PERMISSION\"\n },\n \"approved_list\":[\n \"TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej\"\n ],\n \"permission\":{\n \"operations\":\"7fff1fc0033e0000000000000000000000000000000000000000000000000000\",\n \"keys\":[\n {\n \"address\":\"TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej\",\n \"weight\":1\n },\n {\n \"address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\",\n \"weight\":1\n }\n ],\n \"threshold\":2,\n \"id\":2,\n \"type\":\"Active\",\n \"permission_name\":\"active12323\"\n },\n \"current_weight\":1,\n \"transaction\":{\n \"result\":{\n \"result\":true\n },\n \"txid\":\"ece603ec8ad11578450dc8adf29dd9d9833e733c313fe16a947c8c768f1e4483\",\n \"transaction\":{\n \"signature\":[\n \"990001e909e638bbaa5de9b392121971d25cabde1391f5e164cd8a14608812df01a273e867c2329b8adb233599c5d353c435e789c777fd3e0b9fe83f0737a91101\"\n ],\n \"txID\":\"ece603ec8ad11578450dc8adf29dd9d9833e733c313fe16a947c8c768f1e4483\",\n \"raw_data\":\u00b7\u00b7\u00b7,\n \"raw_data_hex\":\"0a029ca12208432ed1fe1357ff7f40a2b3a7fb9a305a67080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a2802708a8481f19a30\"\n }\n }\n}\nPlease confirm if continue add signature enter y or Y, else any other\ny\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 4th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 4\n4\nPlease input your password.\npassword: \nafter sign transaction hex string is 0a85010a029ca12208432ed1fe1357ff7f40a2b3a7fb9a305a67080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a2802708a8481f19a301241990001e909e638bbaa5de9b392121971d25cabde1391f5e164cd8a14608812df01a273e867c2329b8adb233599c5d353c435e789c777fd3e0b9fe83f0737a91101124141ba3ffe9c7bb1ed184df8bf635d8c987982b2f4b22c447666ac82726f4a97cb2ef4d3fabd64137b8d59239bd7173c74264733ed140ccd04934a88c438de1cab00\ntxid is ece603ec8ad11578450dc8adf29dd9d9833e733c313fe16a947c8c768f1e4483\nSend 10 Sun to TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE successful !!\n
Apermission_id is always required, it is \"0\" by default, which means this transaction only needed to be sign by owner. In the example above, we enter \"2\" to make a multi-signed transaction this time, needs the two accounts assigned actives permission in UpdateAccountPermission section above to sign this transaction. In the example, we picked the account TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej to sign first, after that, it asks you if want to add another sign ,enter y and pick the account TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE to finish multi-signing.
The weight of each account is 1 and the granting threshold is 2. When the requirements are met, the transaction is done successfully! This example shows how to complete a multi-signed transaction using the same client. When using multiple clients, please refer to the following command.
"},{"location":"clients/wallet-cli/#addtransactionsign","title":"AddTransactionSign","text":"Use the instruction addTransactionSign according to the obtained transaction hex string if signing at multiple cli.
wallet> addtransactionsign 0a83010a0241aa2208b2d2c13c86e8bd884098acb1cf9a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a30\nPlease input permission id.\n0\nPlease choose your key for sign.\nThe 1th keystore file name is UTC--2022-06-28T06-52-56.928000000Z--TB9qhqbev6DpX8mxdf3zDdtSQ6GC6Vb6Ej.json\nThe 2th keystore file name is .DS_Store\nThe 3th keystore file name is UTC--2022-04-06T09-43-20.710000000Z--TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8.json\nThe 4th keystore file name is UTC--2022-04-07T09-03-38.307000000Z--TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE.json\nPlease choose between 1 and 4\n3\nPlease input your password.\npassword: \n{\n \"signature\":[\n \"dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\"\n ],\n \"txID\":\"6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\",\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"amount\":10,\n \"owner_address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"to_address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\"\n },\n \"type_url\":\"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\":\"TransferContract\"\n }\n ],\n \"ref_block_bytes\":\"41aa\",\n \"ref_block_hash\":\"b2d2c13c86e8bd88\",\n \"expiration\":1656434882649,\n \"timestamp\":1656413188328\n },\n \"raw_data_hex\":\"0a0241aa2208b2d2c13c86e8bd8840d9f0d9d99a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a30\"\n}\nTransaction hex string is 0a83010a0241aa2208b2d2c13c86e8bd8840d9f0d9d99a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a301241dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\n
After signing, the users will need to broadcast final transactions manually.
"},{"location":"clients/wallet-cli/#broadcasttransaction","title":"BroadcastTransaction","text":"Broadcast the transaction, where the transaction is in hex string format.
wallet> broadcasttransaction 0a83010a0241aa2208b2d2c13c86e8bd8840d9f0d9d99a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a301241dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\nBroadcastTransaction successful !!!\n
"},{"location":"clients/wallet-cli/#gettransactionapprovedlist","title":"GetTransactionApprovedList","text":"Get signature information according to transactions.
wallet> getTransactionApprovedList\n0a8c010a020318220860e195d3609c86614096eadec79d2d5a6e080112680a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412370a1541a7d8a35b260395c14aa456297662092ba3b76fc01215415a523b449890854c8fc460ab602df9f31fe4293f18808084fea6dee11128027094bcb8bd9d2d1241c18ca91f1533ecdd83041eb0005683c4a39a2310ec60456b1f0075b4517443cf4f601a69788f001d4bc03872e892a5e25c618e38e7b81b8b1e69d07823625c2b0112413d61eb0f8868990cfa138b19878e607af957c37b51961d8be16168d7796675384e24043d121d01569895fcc7deb37648c59f538a8909115e64da167ff659c26101\n{\n \"result\":{\n\n },\n \"approved_list\":[\n \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\"\n ],\n \"transaction\":{\n \"result\":{\n \"result\":true\n },\n \"txid\":\"6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\",\n \"transaction\":{\n \"signature\":[\n \"dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\"\n ],\n \"txID\":\"6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\",\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"amount\":10,\n \"owner_address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"to_address\":\"TXBpeye7UQ4dDZEnmGDv4vX37mBYDo1tUE\"\n },\n \"type_url\":\"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\":\"TransferContract\"\n }\n ],\n \"ref_block_bytes\":\"41aa\",\n \"ref_block_hash\":\"b2d2c13c86e8bd88\",\n \"expiration\":1656434882649,\n \"timestamp\":1656413188328\n },\n \"raw_data_hex\":\"0a0241aa2208b2d2c13c86e8bd8840d9f0d9d99a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a30\"\n }\n }\n}\n
"},{"location":"clients/wallet-cli/#on-chaininquire","title":"On-ChainInquire","text":"Here are all the on-chain inquire commands \uff1a
- GetNextMaintenanceTime
- ListNodes
- GetBlock
- GetBlockbyID
- GetBlockbyLatestNum
- GetBlockbyLimitNext
- GetTransactionbyID
- GetTransactionCountbyBlockNum
- GetTransactionInfobyID
- GetTransactionInfobyBlockNum
- GetTransactionSignWeight
"},{"location":"clients/wallet-cli/#getnextmaintenancetime","title":"GetNextMaintenanceTime","text":"Get the start time of the next maintain period
wallet> GetNextMaintenanceTime\nNext maintenance time is : 2022-06-29 16:40:00\n
"},{"location":"clients/wallet-cli/#listnodes","title":"ListNodes","text":"Get other peers' information
wallet> listnodes\nIP::1.23.456.789\nPort::12345\nIP::2.345.67.89\nPort::12345\nIP::345.678.901.234\nPort::12345\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#getblock","title":"GetBlock","text":"Get the block by block height; if you do not pass the parameter, get the latest block
wallet> getblock\nGet current block !!!\n{\n \"block_header\":{\n \"raw_data\":{\n \"number\":27774469,\n \"txTrieRoot\":\"0000000000000000000000000000000000000000000000000000000000000000\",\n \"witness_address\":\"TQuzjxWcqHSh1xDUw4wmMFmCcLjz4wSCBp\",\n \"parentHash\":\"0000000001a7ce048eb88d7c3c5e9c5f8e93a6cc568f47140e243d00d0f9280a\",\n \"version\":24,\n \"timestamp\":1656919215000\n },\n \"witness_signature\":\"3af25276891b1cf7f9f72e63ad956b50e5819fb3fa6f0b6393ed092e53a90a5438620b92b5d499e0068c6775b723e3c90677157b3e9f7b8933d1e863716145f500\"\n }\n}\n
"},{"location":"clients/wallet-cli/#getblockbyid","title":"GetBlockbyID","text":"Get block based on blockID\uff08block hash\uff09
wallet> getblockbyid [blockID]\n
wallet> getblockbyid 0000000001a7cd54ee2b302cfd443cccec78e55a31902d2e7ea47e737c1a5ede\n{\n \"block_header\":{\n \"raw_data\":{\n \"number\":27774292,\n \"txTrieRoot\":\"a60f8cb160d06d5279cb463925274e18fec37f0414c4d8fdc4fb2299ccb0a8bf\",\n \"witness_address\":\"TGsdxpHNJaxsVNFFdb4R6Rib1TsKGon2Wp\",\n \"parentHash\":\"0000000001a7cd53685867286b17fa0f2389e1d3026bea0a0019c5fc37f873cb\",\n \"version\":24,\n \"timestamp\":1656918678000\n },\n \"witness_signature\":\"a93db1a8d989c6637d587369de2872a008f14d1df8f0aaeda8a54c324a44c269367ea31daf623834fd6a4ef3f6150ab8d370adff1df6c0e8c96af9cf34408d5600\"\n },\n \u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#getblockbylatestnum","title":"GetBlockByLatestNum","text":"Get the latest n blocks, where 0 < n < 100
wallet> getblockbylatestnum [n]\n
"},{"location":"clients/wallet-cli/#getblockbylimitnext","title":"GetBlockByLimitNext","text":"Get the block in a set range by block height. startBlockis the starting block height, endBlockis the ending block height.
wallet> GetBlockByLimitNext [startBlock, endBlock]\n
wallet> getblockbylimitnext 27774670 27774674\n[\n {\n \"block_header\":{\n \"raw_data\":{\n \"number\":27774670,\n \"txTrieRoot\":\"0eb9ba48deda22fafa613c0aefa6d3e0b21261ad82a126ce99a6b80e8b68045c\",\n \"witness_address\":\"TVKfvNUMcZdZbxhPLb2CkQ4nyUUhvwhv1b\",\n \"parentHash\":\"0000000001a7cecd7a2cdc58fdfd2edbfeaeb530958879bf1a299cc30043cd0b\",\n \"version\":24,\n \"timestamp\":1656919824000\n },\n \"witness_signature\":\"ee6653289e24edd24d70f4975e12934573d6e798a2a5c5e26e0b13bc6d25138c49a0f55fb0e9a5c503622b5877811403577a5e278528293d05c5f0b9d5d5542401\"\n },\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#gettransactionbyid","title":"GetTransactionbyID","text":"Get transaction information based on transaction id (hash)
wallet> GetTransactionById [transactionID]\n
"},{"location":"clients/wallet-cli/#gettransactioncountbyblocknum","title":"GetTransactionCountbyBlockNum","text":"Get how many transactions contains in a block based on block height, see below
wallet> gettransactioncountbyblocknum 27633562\nThe block contains 4 transactions\n
"},{"location":"clients/wallet-cli/#gettransactioninfobyid","title":"GetTransactionInfobyID","text":"Get transaction-info based on transaction id, generally used to check the result of a smart contract trigger
wallet> gettransactioninfobyid 6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\n{\n \"id\": \"6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\",\n \"blockNumber\": 27609041,\n \"blockTimeStamp\": 1656417906000,\n \"contractResult\": [\n \"\"\n ],\n \"receipt\": {\n \"net_usage\": 265\n }\n}\n
"},{"location":"clients/wallet-cli/#gettransactioninfobyblocknum","title":"GetTransactionInfobyBlockNum","text":"Get the list of transaction information in the block based on the block height
wallet> gettransactioninfobyblocknum [blockNum]\n
"},{"location":"clients/wallet-cli/#gettransactionsignweight","title":"GetTransactionSignWeight","text":"Get the sign weight by transaction hex string.
>getTransactionSignWeight \n0a83010a0241aa2208b2d2c13c86e8bd8840d9f0d9d99a305a65080112610a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412300a1541babecec4d9f58f0df77f0728b9c53abb1f21d684121541e8bd653015895947cec33d1670a88cf67ab277b9180a70e8e1adcf9a301241dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\n
The information displays as follows: {\n \"result\":{\n\n },\n \"approved_list\":[\n \"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\"\n ],\n \"permission\":{\n \"keys\":[\n {\n \"address\":\"TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\",\n \"weight\":1\n }\n ],\n \"threshold\":1,\n \"permission_name\":\"owner\"\n },\n \"current_weight\":1,\n \"transaction\":{\n \"result\":{\n \"result\":true\n },\n \"txid\":\"6e1d2460796f717b701e355734ac0e4e8b32e14c24ce569a60ad3f63afe46c87\",\n \"transaction\":{\n \"signature\":[\n \"dbfe007bb44e8db164f4c0cf9b586a8d6a65f0612c4d9ec5350adeae6cd97c7874e7254bbf4156b545a90c34e48c8f28bdb5c8f9258514233b9201b2844d7f9201\"\n ],\n \u00b7\u00b7\u00b7\n }\n }\n}\n
"},{"location":"clients/wallet-cli/#smartcontract","title":"SmartContract","text":"Below, please find all the commands for smart contract interactions:
- DeployContract
- TriggerContract
- TriggerConstantContract
- EstimateEnergy
- GetContract
- UpdateEnergyLimit
- UpdateSetting
"},{"location":"clients/wallet-cli/#deploycontract","title":"DeployContract","text":"wallet> DeployContract [ownerAddress] [contractName] [ABI] [byteCode] [constructor] [params] [isHex] [fee_limit] [consume_user_resource_percent] [origin_energy_limit] [value] [token_value] [token_id](e.g: TRXTOKEN, use # if don't provided) <library:address,library:address,...> <lib_compiler_version(e.g:v5)> library:address,...>\n
OwnerAddressis the address of the account that initiated the transaction, optional, considered as the address of the login account by default.contractName is the name of smart contract.ABI is ABI code generated when compiling.byteCode is byte code generated when compiling.constructor, params, isHex These three parameters define the format of the bytecode, which determines the way to parse byteCode from parameters.fee_limit determines the limit of consumed TRX for each transaction.consume_user_resource_percent is the percentage of user consumed resource, in the range between [0, 100%].origin_energy_limit is the most amount of developer energy consumed by triggering the contract once.value is the amount of trx transferred to the contract account.token_value is the number of TRC-10 token.token_id is TRC-10 Id.
Example:
wallet> deployContract normalcontract544 [{\"constant\":false,\"inputs\":[{\"name\":\"i\",\"type\":\"uint256\"}],\"name\": \"findArgsByIndexTest\",\"outputs\":[{\"name\":\"z\",\"type\":\"uint256\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"}]\n608060405234801561001057600080fd5b50610134806100206000396000f3006080604052600436106100405763ffffffff7c0100000000000000000000000000000000000000000000000000000000600035041663329000b58114610045575b600080fd5b34801561005157600080fd5b5061005d60043561006f565b60408051918252519081900360200190f35b604080516003808252608082019092526000916060919060208201838038833901905050905060018160008151811015156100a657fe5b602090810290910101528051600290829060019081106100c257fe5b602090810290910101528051600390829060029081106100de57fe5b6020908102909101015280518190849081106100f657fe5b906020019060200201519150509190505600a165627a7a72305820b24fc247fdaf3644b3c4c94fcee380aa610ed83415061ff9e65d7fa94a5a50a00029 # # false 1000000000 75 50000 0 0 #\n
Get the result of the contract execution with the getTransactionInfoById command: wallet> getTransactionInfoById 4978dc64ff746ca208e51780cce93237ee444f598b24d5e9ce0da885fb3a3eb9\n{\n \"id\": \"8c1f57a5e53b15bb0a0a0a0d4740eda9c31fbdb6a63bc429ec2113a92e8ff361\",\n \"fee\": 6170500,\n \"blockNumber\": 1867,\n \"blockTimeStamp\": 1567499757000,\n \"contractResult\": [\n \"6080604052600436106100405763ffffffff7c0100000000000000000000000000000000000000000000000000000000600035041663329000b58114610045575b600080fd5b34801561005157600080fd5b5061005d60043561006f565b60408051918252519081900360200190f35b604080516003808252608082019092526000916060919060208201838038833901905050905060018160008151811015156100a657fe5b602090810290910101528051600290829060019081106100c257fe5b602090810290910101528051600390829060029081106100de57fe5b6020908102909101015280518190849081106100f657fe5b906020019060200201519150509190505600a165627a7a72305820b24fc247fdaf3644b3c4c94fcee380aa610ed83415061ff9e65d7fa94a5a50a00029\"\n ],\n \"contract_address\": \"TJMKWmC6mwF1QVax8Sy2AcgT6MqaXmHEds\",\n \"receipt\": {\n \"energy_fee\": 6170500,\n \"energy_usage_total\": 61705,\n \"net_usage\": 704,\n \"result\": \"SUCCESS\"\n }\n}\n
"},{"location":"clients/wallet-cli/#triggercontract","title":"TriggerContract","text":"The command is used to trigger smart contract that deployed.
wallet> TriggerContract [ownerAddress] [contractAddress] [method] [args] [isHex] [fee_limit] [value] [token_value] [token_id]\n
OwnerAddressThe address of the account that initiated the transaction, optional, default value is the address of the login account.ContractAddress is the smart contract address.method is the name of the function and parameters, please refer to the example below.args is a parameter for placeholding, pass '#' instead when method does not need extra parameters.isHex controls the format of the parameters method and args, whether they are in hex string or not.fee_limit is the most amount of trx allows for consumption.token_value indicate the number of TRC-10 token.token_id the TRC-10 token id, If not, use \u2018#\u2019 instead.
Here is an example:
wallet> triggerContract TGdtALTPZ1FWQcc5MW7aK3o1ASaookkJxG findArgsByIndexTest(uint256) 0 false\n1000000000 0 0 #\n
Get the result of the contract execution with the getTransactionInfoById command, wallet> getTransactionInfoById 7d9c4e765ea53cf6749d8a89ac07d577141b93f83adc4015f0b266d8f5c2dec4\n{\n \"id\": \"de289f255aa2cdda95fbd430caf8fde3f9c989c544c4917cf1285a088115d0e8\",\n \"fee\": 8500,\n \"blockNumber\": 2076,\n \"blockTimeStamp\": 1567500396000,\n \"contractResult\": [\n \"\"\n ],\n \"contract_address\": \"TJMKWmC6mwF1QVax8Sy2AcgT6MqaXmHEds\",\n \"receipt\": {\n \"energy_fee\": 8500,\n \"energy_usage_total\": 85,\n \"net_usage\": 314,\n \"result\": \"REVERT\"\n },\n \"result\": \"FAILED\",\n \"resMessage\": \"REVERT opcode executed\"\n}\n
"},{"location":"clients/wallet-cli/#triggerconstantcontract","title":"TriggerConstantContract","text":"Invoke the readonly function (modified by the view or pure modifier) of a contract for contract data query; or Invoke the non-readonly function of a contract for predicting whether the transaction can be successfully executed or estimating the energy consumption.
wallet> TriggerConstantContract ownerAddress(use # if you own) contractAddress method args isHex [value token_value token_id(e.g: TRXTOKEN, use # if don't provided)]\n
ownerAddress Owner address that triggers the contract. If it is the login account, please input #.contractAddress Smart contract address.method Function call.args Parameters, if there is no parameter of method, please input #. isHex argsis hex string or not\u3002value TRX amount to be transferred. Optional, if no value, # can be inplaced.token_value TRC-10 token amount to be transferred. Optional, if no value, # can be inplaced.token_id TRC-10 token id to be transferred. Optional, if no value, # can be inplaced.
Example:
wallet> TriggerConstantContract TTGhREx2pDSxFX555NWz1YwGpiBVPvQA7e TVSvjZdyDSNocHm7dP3jvCmMNsCnMTPa5W transfer(address,uint256) 0000000000000000000000002ce5de57373427f799cc0a3dd03b841322514a8c00000000000000000000000000000000000000000000000000038d7ea4c68000 true\n\ntransfer(address,uint256):a9059cbb\nExecution result = {\n \"constant_result\": [\n \"0000000000000000000000000000000000000000000000000000000000000001\"\n ],\n \"result\": {\n \"result\": true\n },\n \"energy_used\": 13253,\n \"logs\": [\n {\n \"address\": \"LUijWGF4iFrT7hV37Q2Q45DU5TUBvVZb7\",\n \"topics\": [\n \"ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef\",\n \"000000000000000000000000bdc8ee51fdd1b1e01d71f836481828f88463c838\",\n \"0000000000000000000000002ce5de57373427f799cc0a3dd03b841322514a8c\"\n ],\n \"data\": \"00000000000000000000000000000000000000000000000000038d7ea4c68000\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#estimateenergy","title":"EstimateEnergy","text":"Estimate the energy required for the successful execution of smart contract transactions. But for FullNode, enabling the wallet/estimateEnergy API is optional. So please pay attention that when developers call wallet/estimateEnergy, if the error message shows that the node does not support this function when calling the new API (this node does not support estimate energy), it is recommended to continue using the wallet/triggerconstantcontract API to estimate energy consumption.
wallet> EstimateEnergy ownerAddress contractAddress method args isHex [value token_value token_id]\n
ownerAddress Owner address that triggers the contract. If it is the login account, please input #.contractAddress Smart contract address.method Function call.args Parameters, if there is no parameter of method, please input #. isHex argsis hex string or not\u3002value TRX amount to be transferred. Optional, if no value, # can be inplaced.token_value TRC-10 token amount to be transferred. Optional, if no value, # can be inplaced.token_id TRC-10 token id to be transferred. Optional, if no value, # can be inplaced.
Example:
wallet> EstimateEnergy TTGhREx2pDSxFX555NWz1YwGpiBVPvQA7e TVSvjZdyDSNocHm7dP3jvCmMNsCnMTPa5W transfer(address,uint256) 0000000000000000000000002ce5de57373427f799cc0a3dd03b841322514a8c00000000000000000000000000000000000000000000000000038d7ea4c68000 true\n\ntransfer(address,uint256):a9059cbb\nEstimate energy result = {\n \"result\": {\n \"result\": true\n },\n \"energy_required\": 14910\n}\n
"},{"location":"clients/wallet-cli/#getcontract","title":"GetContract","text":"Get the smart contract info by its address.
wallet> GetContract [contractAddress]\n
Example:
wallet> GetContract TGdtALTPZ1FWQcc5MW7aK3o1ASaookkJxG\n{\n \"origin_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"contract_address\": \"TJMKWmC6mwF1QVax8Sy2AcgT6MqaXmHEds\",\n \"abi\": {\n \"entrys\": [\n {\n \"name\": \"findArgsByIndexTest\",\n \"inputs\": [\n {\n \"name\": \"i\",\n \"type\": \"uint256\"\n }\n ],\n \"outputs\": [\n {\n \"name\": \"z\",\n \"type\": \"uint256\"\n }\n ],\n \"type\": \"Function\",\n \"stateMutability\": \"Nonpayable\"\n }\n ]\n },\n \"bytecode\": \"608060405234801561001057600080fd5b50610134806100206000396000f3006080604052600436106100405763ffffffff7c0100000000000000000000000000000000000000000000000000000000600035041663329000b58114610045575b600080fd5b34801561005157600080fd5b5061005d60043561006f565b60408051918252519081900360200190f35b604080516003808252608082019092526000916060919060208201838038833901905050905060018160008151811015156100a657fe5b602090810290910101528051600290829060019081106100c257fe5b602090810290910101528051600390829060029081106100de57fe5b6020908102909101015280518190849081106100f657fe5b906020019060200201519150509190505600a165627a7a72305820b24fc247fdaf3644b3c4c94fcee380aa610ed83415061ff9e65d7fa94a5a50a00029\",\n \"consume_user_resource_percent\": 75,\n \"name\": \"normalcontract544\",\n \"origin_energy_limit\": 50000,\n \"code_hash\": \"23423cece3b4866263c15357b358e5ac261c218693b862bcdb90fa792d5714e6\"\n}\n
"},{"location":"clients/wallet-cli/#updateenergylimit","title":"UpdateEnergyLimit","text":"Update parameter energy limit\uff0cparameter are the same as above.
wallet> UpdateEnergyLimit [ownerAddress] [contract_address] [energy_limit]\n
"},{"location":"clients/wallet-cli/#updatesetting","title":"UpdateSetting","text":"Update parameter of energy consume percentage per user
wallet> UpdateSetting [ownerAddress] contract_address consume_user_resource_percent\n
"},{"location":"clients/wallet-cli/#trc-10","title":"TRC-10","text":"Below, please find all the commands for TRC-10:
- AssetIssue
- UpdateAsset
- TransferAsset
- ParticipateAssetissue
- UnfreezeAsset
- ListAssetIssue
- GetAssetIssuebyAccount
- GetAssetIssuebyID
- GetAssetIssuebyName
- GetAssetIssueListbyName
"},{"location":"clients/wallet-cli/#assetissue","title":"AssetIssue","text":"Each account is allowed to issue only ONE TRC-10 token.
wallet> AssetIssue [OwnerAddress] [AssetName] [AbbrName] [TotalSupply] [TrxNum] [AssetNum] [Precision] [StartDate] [EndDate] [Description Url] [FreeNetLimitPerAccount] [PublicFreeNetLimit] [FrozenAmount0] [FrozenDays0] [...] [FrozenAmountN] [FrozenDaysN]\n
OwnerAddress (optional) is the address of the account which initiated the transaction. Default: the address of the login account. AssetName is the name of the issued TRC-10 token.
AbbrName is the abbreviation of TRC-10 token you want to issue.
TotalSupply is total issuing amount of TRC-10 token.
- TotalSupply = Account Balance of Issuer + All Frozen Token Amount
- Account Balance Of Issuer: balance at the time of issuance
- All Frozen Token Amount: Before asset transfer and the issuance
TrxNum, AssetNum are two parameters determine the exchange rate when the token is issued.
- Exchange Rate = TrxNum / AssetNum
AssetNum: Unit in the base unit of the issued token TrxNum: Unit in SUN (0.000001 TRX)
Precision indicates how many decimal places there is.
FreeNetLimitPerAccount determines the maximum amount of bandwidth each account is allowed to use. Token issuers can freeze TRX to obtain bandwidth (TransferAssetContract only)
PublicFreeNetLimit is the maximum total amount of bandwidth which is allowed to use for all accounts. Token issuers can freeze TRX to obtain bandwidth (TransferAssetContract only)
StartDate, EndDate is the start and end date of token issuance. Within this period time, other users can participate in token issuance.
FrozenAmount0, FrozenDays0 determines the amount and days of token freeze. FrozenAmount0: Must be bigger than 0. FrozenDays0: Must between 1 and 3652.
Example:
wallet> AssetIssue TestTRX TRX 75000000000000000 1 1 2 \"2019-10-02 15:10:00\" \"2020-07-11\" \"just for test121212\" www.test.com 100 100000 10000 10 10000 1\nwallet> GetAssetIssueByAccount TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ # View published information\n{\n \"assetIssue\": [\n {\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"name\": \"TestTRX\",\n \"abbr\": \"TRX\",\n \"total_supply\": 75000000000000000,\n \"frozen_supply\": [\n {\n \"frozen_amount\": 10000,\n \"frozen_days\": 1\n },\n {\n \"frozen_amount\": 10000,\n \"frozen_days\": 10\n }\n ],\n \"trx_num\": 1,\n \"precision\": 2,\n \"num\": 1,\n \"start_time\": 1570000200000,\n \"end_time\": 1594396800000,\n \"description\": \"just for test121212\",\n \"url\": \"www.test.com\",\n \"free_asset_net_limit\": 100,\n \"public_free_asset_net_limit\": 100000,\n \"id\": \"1000001\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#updateasset","title":"UpdateAsset","text":"wallet> UpdateAsset [OwnerAddress] [newLimit] [newPublicLimit] [description url]\n
Specific meaning of the parameters are the same as they are in AssetIssue. Example:
wallet> UpdateAsset 1000 1000000 \"change description\" www.changetest.com\nwallet> GetAssetIssueByAccount TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ # to check the modified information\n{\n \"assetIssue\": [\n {\n \"owner_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"name\": \"TestTRX\",\n \"abbr\": \"TRX\",\n \"total_supply\": 75000000000000000,\n \"frozen_supply\": [\n {\n \"frozen_amount\": 10000,\n \"frozen_days\": 1\n },\n {\n \"frozen_amount\": 10000,\n \"frozen_days\": 10\n }\n ],\n \"trx_num\": 1,\n \"precision\": 2,\n \"num\": 1,\n \"start_time\": 1570000200000,\n \"end_time\": 1594396800000,\n \"description\": \"change description\",\n \"url\": \"www.changetest.com\",\n \"free_asset_net_limit\": 1000,\n \"public_free_asset_net_limit\": 1000000,\n \"id\": \"1000001\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#transferasset","title":"TransferAsset","text":"> TransferAsset [OwnerAddress] [ToAddress] [AssertID] [Amount]\n
OwnerAddress (optional) is the address of the account which initiated the transaction. By default, the address of the login account. ToAddress is the address of the target account.
AssertName is the TRC-10 token ID. Example: 1000001
Amount is the number of TRC10 token to transfer with.
Example:
wallet> TransferAsset TN3zfjYUmMFK3ZsHSsrdJoNRtGkQmZLBLz 1000001 1000\nwallet> getaccount TN3zfjYUmMFK3ZsHSsrdJoNRtGkQmZLBLz # to check target account information after the transfer\naddress: TN3zfjYUmMFK3ZsHSsrdJoNRtGkQmZLBLz\n assetV2\n {\n id: 1000001\n balance: 1000\n latest_asset_operation_timeV2: null\n free_asset_net_usageV2: 0\n }\n
"},{"location":"clients/wallet-cli/#participateassetissue","title":"ParticipateAssetissue","text":"> ParticipateAssetIssue [OwnerAddress] [ToAddress] [AssetID] [Amount]\n
OwnerAddress (optional) is the address of the account which initiated the transaction. Default: the address of the login account. ToAddress is the account address of TRC10 issuers.
AssertName is the TRC-10 token ID. Example: 1000001
Amount is the number of TRC10 token to transfers with.
The participation process must happen during the release of TRC10, otherwise an error may occur.
Example:
wallet> ParticipateAssetIssue TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ 1000001 1000\nwallet> getaccount TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW # View remaining balance\naddress: TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\nassetV2\n {\n id: 1000001\n balance: 1000\n latest_asset_operation_timeV2: null\n free_asset_net_usageV2: 0\n }\n
"},{"location":"clients/wallet-cli/#unfreezeasset","title":"UnfreezeAsset","text":"To unfreeze all TRC10 token which are supposed to be unfrozen after the freezing period.
wallet> unfreezeasset [OwnerAddress]\n
"},{"location":"clients/wallet-cli/#listassetissue","title":"ListAssetIssue","text":"Obtain all of the published TRC10 token information.
wallet> listassetissue\n{\n \"assetIssue\": [\n {\n \"owner_address\": \"TMWXhuxiT1KczhBxCseCDDsrhmpYGUcoA9\",\n \"name\": \"tronlink_token\",\n \"abbr\": \"tronlink_token\",\n \"total_supply\": 1000000000000000,\n \"frozen_supply\": [\n {\n \"frozen_amount\": 1,\n \"frozen_days\": 1\n }\n ],\n \"trx_num\": 1,\n \"precision\": 6,\n \"num\": 1,\n \"start_time\": 1574757000000,\n \"end_time\": 1757595000000,\n \"description\": \"Description\",\n \"url\": \"https://blog.csdn.net/u010270891/article/details/82978260\",\n \"free_asset_net_limit\": 1000,\n \"public_free_asset_net_limit\": 2000,\n \"id\": \"1000001\"\n },\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#getassetissuebyaccount","title":"GetAssetIssuebyAccount","text":"Obtain TRC10 token information based on owner address.
wallet> getassetissuebyaccount [owneraddress]\n
wallet> getassetissuebyaccount TUwjpfqW7NG6BF3GCTrKy1aDvfchwSG4tN\n{\n \"assetIssue\": [\n {\n \"owner_address\": \"TUwjpfqW7NG6BF3GCTrKy1aDvfchwSG4tN\",\n \"name\": \"h00966\",\n \"abbr\": \"h00966\",\n \"total_supply\": 100000000000,\n \"trx_num\": 1000000,\n \"precision\": 6,\n \"num\": 1000000,\n \"start_time\": 1656374400000,\n \"end_time\": 1656460800000,\n \"description\": \"Automated gaming platform. \nTRC10 token h0966.\nMore info on website. TRC10 token h0966.\nMore info on website. More info on website.\",\n \"url\": \"https://h00966.com\",\n \"id\": \"1004901\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#getassetissuebyid","title":"GetAssetIssuebyID","text":"Obtain TRC10 token Information based on token ID.
wallet> GetAssetIssueById 1004901\n{\n \"owner_address\": \"TUwjpfqW7NG6BF3GCTrKy1aDvfchwSG4tN\",\n \"name\": \"h00966\",\n \"abbr\": \"h00966\",\n \"total_supply\": 100000000000,\n \"trx_num\": 1000000,\n \"precision\": 6,\n \"num\": 1000000,\n \"start_time\": 1656374400000,\n \"end_time\": 1656460800000,\n \"description\": \"Automated gaming platform. \nTRC10 token h0966.\nMore info on website.TRC10 token h0966.\nMore info on website.More info on website.\",\n \"url\": \"https://h00966.com\",\n \"id\": \"1004901\"\n}\n
"},{"location":"clients/wallet-cli/#getassetissuebyname","title":"GetAssetIssuebyName","text":"Obtain TRC10 token Information based on token names.
wallet> GetAssetIssueByname h00966\n{\n \"owner_address\": \"TUwjpfqW7NG6BF3GCTrKy1aDvfchwSG4tN\",\n \"name\": \"h00966\",\n \"abbr\": \"h00966\",\n \"total_supply\": 100000000000,\n \"trx_num\": 1000000,\n \"precision\": 6,\n \"num\": 1000000,\n \"start_time\": 1656374400000,\n \"end_time\": 1656460800000,\n \"description\": \"Automated gaming platform. \nTRC10 token h0966.\nMore info on website.TRC10 token h0966.\nMore info on website.More info on website.\",\n \"url\": \"https://h00966.com\",\n \"id\": \"1004901\"\n}\n
"},{"location":"clients/wallet-cli/#getassetissuelistbyname","title":"GetAssetIssueListbyName","text":"Obtain a list of TRC10 token information based on names.
wallet> GetAssetIssueListByName ROFLOTOKEN\n{\n \"assetIssue\": [\n {\n \"owner_address\": \"TLvQSVH9Hm7kxLFtTP228fN6pCrHmtVjpb\",\n \"name\": \"ROFLOTOKEN\",\n \"abbr\": \"roflotoken\",\n \"total_supply\": 10000000000000000,\n \"trx_num\": 1000000,\n \"precision\": 6,\n \"num\": 100000000,\n \"start_time\": 1656349200000,\n \"end_time\": 1656435600000,\n \"description\": \"roflotoken.com\",\n \"url\": \"https://haxibaibo.com/\",\n \"id\": \"1004898\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#governance","title":"Governance","text":"Any proposal-related operations, except for viewing operations, must be performed by committee members. Please find all the commands for Governance:
- CreateProposal
- ApproveProposal
- DeleteProposal
- ListProposals
- ListProposalsPaginated
- GetProposal
- VoteWitness
- ListWitnesses
- GetBrokerage
- GetReward
- UpdateBrokerage
"},{"location":"clients/wallet-cli/#creatproposal","title":"CreatProposal","text":"Initiate a proposal with createProposal.
wallet> createProposal [OwnerAddress] [id0] [value0] ... [idN] [valueN]\n
OwnerAddress (optional) is the address of the account which initiated the transaction. By default, it is the address of the login account. id0 is the serial number of TRON Network Parameter. Of which, each one has a serial number corresponded. Please refer to http://tronscan.org/#/sr/committee.
Value0 is the modified value.
In the example, modification No.4 (modifying token issuance fee) costs 1000TRX as follows:
wallet> createProposal 4 1000\nwallet> listproposals # to check initiated proposal\n{\n \"proposals\": [\n {\n \"proposal_id\": 1,\n \"proposer_address\": \"TRGhNNfnmgLegT4zHNjEqDSADjgmnHvubJ\",\n \"parameters\": [\n {\n \"key\": 4,\n \"value\": 1000\n }\n ],\n \"expiration_time\": 1567498800000,\n \"create_time\": 1567498308000\n }\n ]\n}\n
The corresponding id is 1."},{"location":"clients/wallet-cli/#approveproposal","title":"ApproveProposal","text":"Approve or disapprove a proposal using approveProposal.
wallet> approveProposal [OwnerAddress] [id] [is_or_not_add_approval]\n
OwnerAddress (optional) is the address of the account which initiated the transaction. Default: the address of the login account. id is the ID of the initiated proposal. Example: 1.
is_or_not_add_approval is true for approve; is false for disapprove.
Example:
wallet> ApproveProposal 1 true # in favor of the offer\nwallet> ApproveProposal 1 false # Cancel the approved proposal\n
"},{"location":"clients/wallet-cli/#deleteproposal","title":"DeleteProposal","text":"wallet> deleteProposal [OwnerAddress] [proposalId]\n
proposalId is the ID of the initiated proposal. Example: 1. The proposal must be canceled by the supernode that initiated the proposal.
Example\uff1a
wallet> DeleteProposal 1\n
"},{"location":"clients/wallet-cli/#listproposals","title":"ListProposals","text":"Obtain a list of initiated proposals
wallet> listproposals\n{\n \"proposals\": [\n {\n \"proposal_id\": 12732,\n \"proposer_address\": \"TQ4eBJna51sew13DBLd7YjEHHHW7fkNzc2\",\n \"parameters\": [\n {\n \"key\": 65,\n \"value\": 1\n },\n {\n \"key\": 66,\n \"value\": 1\n },\n {\n \"key\": 62,\n \"value\": 432000000\n }\n ],\n \"expiration_time\": 1656491400000,\n \"create_time\": 1656490794000,\n \"approvals\": [\n \"TQ4eBJna51sew13DBLd7YjEHHHW7fkNzc2\"\n ],\n \"state\": \"DISAPPROVED\"\n },\n {\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#listproposalspaginated","title":"ListProposalsPaginated","text":"Use the paging mode to obtain the initiated proposal.
wallet> ListProposalsPaginated [offset] [limit] \n
offset is the number of proposals you want to skip. limit is the number of proposals you want to be listed. By default, all proposals would be listed from proposal_id 1 to date. The parameter in the example below means you want to skip the first 33 proposals and list the 2 proposals right after that. wallet> listproposalspaginated 33 2\n{\n \"proposals\": [\n {\n \"proposal_id\": 34,\n \"proposer_address\": \"TEDguVMSsFw3HSizQXFK1BsrGWeuRMNN7t\",\n \"parameters\": [\n {\n \"key\": 1,\n \"value\": 9997000000\n }\n ],\n \"expiration_time\": 1582381200000,\n \"create_time\": 1582380477000,\n \"state\": \"DISAPPROVED\"\n },\n {\n \"proposal_id\": 35,\n \"proposer_address\": \"TDkSQtBhZx7Ua8qvenM4zuH52u2BsYTwzc\",\n \"parameters\": [\n {\n \"key\": 1,\n \"value\": 9997000000\n }\n ],\n \"expiration_time\": 1582381200000,\n \"create_time\": 1582380498000,\n \"state\": \"DISAPPROVED\"\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#getproposal","title":"GetProposal","text":"Obtain proposal information based on the proposal ID.
wallet> getproposal 34\n{\n \"proposal_id\": 34,\n \"proposer_address\": \"TEDguVMSsFw3HSizQXFK1BsrGWeuRMNN7t\",\n \"parameters\": [\n {\n \"key\": 1,\n \"value\": 9997000000\n }\n ],\n \"expiration_time\": 1582381200000,\n \"create_time\": 1582380477000,\n \"state\": \"DISAPPROVED\"\n}\n
"},{"location":"clients/wallet-cli/#votewitness","title":"VoteWitness","text":"Voting requires TRON Power, which can be obtained by freezing funds.
wallet> votewitness [SR(Super Representatives) address] [TRON Power Amount]\n
- The share calculation method is: 1 unit of share can be obtained for every 1TRX frozen.
- After unfreezing, previous vote will expire. You can avoid the invalidation of the vote by re-freezing and voting.
NOTE The TRON Network only records the status of your last vote, which means that each of your votes will overwrite all previous voting results.
For example:
wallet> freezeBalance 100000000 3 1 address # Freeze 10TRX and acquire 10 units of TRON Power\n\nwallet> votewitness [SR1] 4 [SR2] 6 # Cast 4 votes for SR1 and 6 votes for SR2 at the same time\n\nwallet> votewitness [SR1] 10 # Voted 10 votes for SR1\n
The final result of the above command was 10 votes for SR1 and 0 vote for SR2."},{"location":"clients/wallet-cli/#listwitnesses","title":"ListWitnesses","text":"Get all miner node information
wallet> listwitnesses\n{\n \"witnesses\": [\n {\n \"address\": \"TPffmvjxEcvZefQqS7QYvL1Der3uiguikE\",\n \"voteCount\": 324999518,\n \"url\": \"http://sr-26.com\",\n \"totalProduced\": 414028,\n \"totalMissed\": 20,\n \"latestBlockNum\": 27638663,\n \"latestSlotNum\": 552169224,\n \"isJobs\": true\n },\n {\n \"address\": \"TFFLWM7tmKiwGtbh2mcz2rBssoFjHjSShG\",\n \"voteCount\": 324759460,\n \"url\": \"http://sr-27.com\",\n \"totalProduced\": 414144,\n \"totalMissed\": 16,\n \"latestBlockNum\": 27638664,\n \"latestSlotNum\": 552169225,\n \"isJobs\": true\n },\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#getbrokerage","title":"GetBrokerage","text":"View the ratio of brokerage of the SR(Super Representatives).
After voting for the super representative, you will receive the rewards. The super representative has the right to decide the ratio of brokerage. The default ratio is 20%, and the super representative can adjust it.
By default, if a super representative is rewarded, he will receive 20% of the whole rewards, and 80% of the rewards will be distributed to his voters.
OwnerAddress is the address of the SR's account, it is a base58check type address.
wallet> getbrokerage TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\nThe brokerage is : 20\n
"},{"location":"clients/wallet-cli/#getreward","title":"GetReward","text":"Query unclaimed reward.
OwnerAddress is the address of the voter's account, it is a base58check type address.
wallet> getreward TSzdGHnhYnQKFF4LKrRLztkjYAvbNoxnQ8\nThe reward is : 0\n
"},{"location":"clients/wallet-cli/#updatebrokerage","title":"UpdateBrokerage","text":"Update the ratio of brokerage, this command is usually used by a super representative account.
wallet> updateBrokerage [OwnerAddress] [brokerage]\n
OwnerAddress is the address of the super representative's account, it is a base58check type address. brokerage is the ratio of brokerage you want to update to, the limit of it: 0-100.
For example:
wallet> updateBrokerage TZ7U1WVBRLZ2umjizxqz3XfearEHhXKX7h 30\n
"},{"location":"clients/wallet-cli/#dex","title":"DEX","text":"The trading and price fluctuations of trading pairs are in accordance with the Bancor Agreement.
Here are all the commands for DEX:
- ExchangeCreate
- ExchangeInject
- ExchangeTransaction
- ExchangeWithdraw
- ListExchanges
- ListExchangesPaginated
- MarketSellAsset
- MarketCancelOrder
- GetMarketOrderbyAccount
- GetMarketOrderbyID
- GetMarketPairList
- GetMarketOrderListbyPair
- GetMarketPricebyPair
"},{"location":"clients/wallet-cli/#exchangecreate","title":"ExchangeCreate","text":"Create a trading pair
wallet> exchangeCreate [OwnerAddress][first_token_id] [first_token_balance] [second_token_id] [second_token_balance]\n
OwnerAddress is the address of the account which initiated the transaction. Considered as the login account by default. First_token_id, first_token_balance is the ID and amount of the first token.
second_token_id, second_token_balance is the ID and amount of the second token.
The ID is the ID of the issued TRC10 token. If it is TRX, the ID is \"\". The amount must be greater than 0, and less than 1,000,000,000,000,000.
Example:
wallet> exchangeCreate 1000001 10000 _ 10000\n# Create trading pairs with the IDs of 1000001 and TRX, with amount 10000 for both.\n
"},{"location":"clients/wallet-cli/#exchangeinject","title":"ExchangeInject","text":"Capital injection
wallet> exchangeInject [OwnerAddress] [exchange_id] [token_id] [quant]\n
OwnerAddress is the address of the account which initiated the transaction. Default: the address of the login account. exchange_id is the ID of the trading pair to be funded.
token_id, quant is the token Id and quantity (unit in base unit) of capital injection.
When conducting a capital injection, depending on its quantity (quant), a proportion of each token in the trading pair will be withdrawn from the account, and injected into the trading pair. Depending on the difference in the balance of the transaction, the same amount of money for the same token would vary.
"},{"location":"clients/wallet-cli/#exchangetransaction","title":"ExchangeTransaction","text":"Making transaction
wallet> exchangeTransaction [OwnerAddress] [exchange_id] [token_id] [quant] [expected]\n
OwnerAddress is the address of the account which initiated the transaction. Default: the address of the login account. exchange_id is the ID of the trading pair.
token_id, quant is the ID and quantity of tokens being exchanged, equivalent to selling.
expected is the expected quantity of another token. IT must be less than quant, or an error will be reported.
Example\uff1a
wallet> ExchangeTransaction 1 1000001 100 80\n
It is expected to acquire the 80 TRX by exchanging 1000001 from the trading pair ID of 1, and the amount is 100.(Equivalent to selling an amount of 100 tokenID - 1000001, at a price of 80 TRX, in trading pair ID - 1)."},{"location":"clients/wallet-cli/#exchangewithdraw","title":"ExchangeWithdraw","text":"wallet> exchangeWithdraw [OwnerAddress] [exchange_id] [token_id] [quant]\n
OwnerAddress is the address of the account which initiated the transaction. Default: the address of the login account. Exchange_id is the ID of the trading pair to be withdrawn.
Token_id, quant is token Id and quantity (unit in base unit) of capital withdrawal.
When conducting a capital withdrawal, depending on its quantity (quant), a proportion of each token in the transaction pair is withdrawn from the trading pair, and injected into the account. Depending on the difference in the balance of the transaction, the same amount of money for the same token would vary.
You may obtain information on trading pairs by the following commands,
"},{"location":"clients/wallet-cli/#listexchanges","title":"ListExchanges","text":"List trading pairs
wallet> listexchanges\n{\n \"exchanges\": [\n {\n \"exchange_id\": 14,\n \"creator_address\": \"TCjuQbm5yab7ENTYb7tbdAKaiNa9Lrj4mo\",\n \"create_time\": 1654154880000,\n \"first_token_id\": \"1004852\",\n \"first_token_balance\": 91,\n \"second_token_id\": \"_\",\n \"second_token_balance\": 110000000\n },\n {\n \"exchange_id\": 13,\n \"creator_address\": \"TBpbKyKVUB1YLULrbhawUws69Gv33cmKDL\",\n \"create_time\": 1648004214000,\n \"first_token_id\": \"1000575\",\n \"first_token_balance\": 991,\n \"second_token_id\": \"1000184\",\n \"second_token_balance\": 1010\n },\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#listexchangespaginated","title":"ListExchangesPaginated","text":"List trading pairs by page
wallet> ListExchangesPaginated [offset] [limit]\n
offset is the number of exchange pair you want to skip. limit is the number of exchange pair you want to be listed. The parameters in the example below means to skip the first 3 exchange pairs and show the next 2 exchange pairs.
wallet> listexchangespaginated 3 2\n{\n \"exchanges\": [\n {\n \"exchange_id\": 4,\n \"creator_address\": \"TXmHTj3t5LXGvqGkr4jRNw7nf9GjquQ5yf\",\n \"create_time\": 1601458377000,\n \"first_token_id\": \"1000088\",\n \"first_token_balance\": 1,\n \"second_token_id\": \"_\",\n \"second_token_balance\": 1\n },\n {\n \"exchange_id\": 5,\n \"creator_address\": \"TTJJvoPKGVKnbUBPVTn1Zi8o6k3EfFDXVS\",\n \"create_time\": 1602578613000,\n \"first_token_id\": \"1000091\",\n \"first_token_balance\": 456125,\n \"second_token_id\": \"_\",\n \"second_token_balance\": 106968111\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#marketsellasset","title":"MarketSellAsset","text":"Create an order to sell asset
wallet> MarketSellAsset [owner_address] [sell_token_id] [sell_token_quantity] [buy_token_id] [buy_token_quantity]\n
OwnerAddress is the address of the account that initiated the transaction. sell_token_id and sell_token_quantity are the ID and amount of the token want to sell.
buy_token_id, buy_token_quantity determines the ID and amount of the token want to buy.
Example:
wallet> MarketSellAsset TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW 1000001 200 _ 100 \n
Then we use the command getTransactionInfoById to check the result of the contract execution as below, wallet> getTransactionInfoById 10040f993cd9452b25bf367f38edadf11176355802baf61f3c49b96b4480d374 \n\n{\n \"id\": \"10040f993cd9452b25bf367f38edadf11176355802baf61f3c49b96b4480d374\",\n \"blockNumber\": 669,\n \"blockTimeStamp\": 1578983493000,\n \"contractResult\": [\n \"\"\n ],\n \"receipt\": {\n \"net_usage\": 264\n }\n} \n
"},{"location":"clients/wallet-cli/#marketcancelorder","title":"MarketCancelOrder","text":"This command cancels the order.
wallet> MarketCancelOrder [owner_address] [order_id]\n
owner_address is the account address who have created the order. order_id is the order id which want to cancel.
Example:
wallet> MarketCancelOrder TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW fc9c64dfd48ae58952e85f05ecb8ec87f55e19402493bb2df501ae9d2da75db0 \n
Get the result of the contract execution with the getTransactionInfoById command: wallet> getTransactionInfoById b375787a098498623403c755b1399e82910385251b643811936d914c9f37bd27 \n{\n \"id\": \"b375787a098498623403c755b1399e82910385251b643811936d914c9f37bd27\",\n \"blockNumber\": 1582,\n \"blockTimeStamp\": 1578986232000,\n \"contractResult\": [\n \"\"\n ],\n \"receipt\": {\n \"net_usage\": 283\n }\n}\n
"},{"location":"clients/wallet-cli/#getmarketorderbyaccount","title":"GetMarketOrderbyAccount","text":"Use this command to get the order created by account(just include active status).
wallet> GetMarketOrderByAccount [ownerAddress]\n
ownerAddress is the address of the account that created market order. Example:
wallet> GetMarketOrderByAccount TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW \n{\n \"orders\": [\n {\n \"order_id\": \"fc9c64dfd48ae58952e85f05ecb8ec87f55e19402493bb2df501ae9d2da75db0\",\n \"owner_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\",\n \"create_time\": 1578983490000,\n \"sell_token_id\": \"_\",\n \"sell_token_quantity\": 100,\n \"buy_token_id\": \"1000001\",\n \"buy_token_quantity\": 200,\n \"sell_token_quantity_remain\": 100\n }\n ]\n} \n
"},{"location":"clients/wallet-cli/#getmarketorderbyid","title":"GetMarketOrderbyID","text":"Get the specific order by order_id
wallet> GetMarketOrderById [orderId]\n
Example: wallet> GetMarketOrderById fc9c64dfd48ae58952e85f05ecb8ec87f55e19402493bb2df501ae9d2da75db0 \n{\n \"order_id\": \"fc9c64dfd48ae58952e85f05ecb8ec87f55e19402493bb2df501ae9d2da75db0\",\n \"owner_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\",\n \"create_time\": 1578983490000,\n \"sell_token_id\": \"_\",\n \"sell_token_quantity\": 100,\n \"buy_token_id\": \"1000001\",\n \"buy_token_quantity\": 200,\n}\n
"},{"location":"clients/wallet-cli/#getmarketpairlist","title":"GetMarketPairList","text":"This command is to get market pair listed
wallet> getmarketpairlist\n{\n \"orderPair\": [\n {\n \"sell_token_id\": \"1000012\",\n \"buy_token_id\": \"_\"\n },\n {\n \"sell_token_id\": \"1000094\",\n \"buy_token_id\": \"1000095\"\n },\n {\n \"sell_token_id\": \"1000099\",\n \"buy_token_id\": \"1000100\"\n },\n\u00b7\u00b7\u00b7\n
"},{"location":"clients/wallet-cli/#getmarketorderlistbypair","title":"GetMarketOrderListbyPair","text":"This command is to get market order list by c pair,
wallet> GetMarketOrderListByPair [sell_token_id] [buy_token_id]\n
sell_token_id is the ID of the token want to sell. buy_token_id is the ID of the token want to buy.
Example:
wallet> GetMarketOrderListByPair _ 1000001 \n{\n \"orders\": [\n {\n \"order_id\": \"fc9c64dfd48ae58952e85f05ecb8ec87f55e19402493bb2df501ae9d2da75db0\",\n \"owner_address\": \"TJCnKsPa7y5okkXvQAidZBzqx3QyQ6sxMW\",\n \"create_time\": 1578983490000,\n \"sell_token_id\": \"_\",\n \"sell_token_quantity\": 100,\n \"buy_token_id\": \"1000001\",\n \"buy_token_quantity\": 200,\n \"sell_token_quantity_remain\": 100\n }\n ]\n}\n
"},{"location":"clients/wallet-cli/#getmarketpricebypair","title":"GetMarketPricebyPair","text":"Use this command to get market price by exchange pair.
wallet> GetMarketPriceByPair [sell_token_id] [buy_token_id]\n
sell_token_id is the ID of the token want to sell. buy_token_id is the ID of the token want to buy.
Example:
wallet> GetMarketPriceByPair _ 1000001 \n{\n \"sell_token_id\": \"_\",\n \"buy_token_id\": \"1000001\",\n \"prices\": [\n {\n \"sell_token_quantity\": 100,\n \"buy_token_quantity\": 200\n }\n ]\n}\n
"},{"location":"contracts/contract/","title":"Contract","text":""},{"location":"contracts/contract/#introduction","title":"Introduction","text":"Smart contract is a computerized transaction protocol that automatically implements its terms. Smart contract is the same as common contract, they all define the terms and rules related to the participants. Once the contract is started, it can runs in the way it is designed.
TRON smart contract support Solidity language in (Ethereum). You can find the latest solidity version in the TRON solidity repository. Write a smart contract, then build the smart contract and deploy it to TRON network. When the smart contract is triggered, the corresponding function will be executed automatically.
"},{"location":"contracts/contract/#features","title":"Features","text":"TRON virtual machine is based on Ethereum solidity language, it also has TRON's own features.
"},{"location":"contracts/contract/#defination-of-smart-contract","title":"Defination of Smart Contract","text":"TRON VM is compatible with Ethereum's smart contract, using protobuf to define the content of the contract:
message SmartContract {\n message ABI {\n message Entry {\n enum EntryType {\n UnknownEntryType = 0;\n Constructor = 1;\n Function = 2;\n Event = 3;\n Fallback = 4;\n Receive = 5;\n Error = 6;\n }\n message Param {\n bool indexed = 1;\n string name = 2;\n string type = 3;\n }\n enum StateMutabilityType {\n UnknownMutabilityType = 0;\n Pure = 1;\n View = 2;\n Nonpayable = 3;\n Payable = 4;\n }\n\n bool anonymous = 1;\n bool constant = 2;\n string name = 3;\n repeated Param inputs = 4;\n repeated Param outputs = 5;\n EntryType type = 6;\n bool payable = 7;\n StateMutabilityType stateMutability = 8;\n }\n repeated Entry entrys = 1;\n }\n bytes origin_address = 1;\n bytes contract_address = 2;\n ABI abi = 3;\n bytes bytecode = 4;\n int64 call_value = 5;\n int64 consume_user_resource_percent = 6;\n string name = 7;\n int64 origin_energy_limit = 8;\n bytes code_hash = 9;\n bytes trx_hash = 10;\n}\n
- origin_address: smart contract creator address
- contract_address: smart contract address
- abi: the api information of all the function of the smart contract
- bytecode: smart contract byte code
- call_value: TRX transferred into smart contract while call the contract
- consume_user_resource_percent: resource consumption percentage set by the developer
- name: smart contract name
- origin_energy_limit: energy consumption of the developer limit in one call, must be greater than 0. For the old contracts, if this parameter is not set, it will be set 0, developer can use updateEnergyLimit api to update this parameter (must greater than 0)
Through other two grpc message types CreateSmartContract and TriggerSmartContract to create and use smart contract.
"},{"location":"contracts/contract/#usage-of-the-function-of-smart-contract","title":"Usage of the Function of Smart Contract","text":" - constant function and inconstant function
There are two types of function according to whether any change will be made to the properties on the chain: constant function and inconstant function Constant function uses view/pure/constant to decorate, will return the result on the node it is called and not be broadcasted in the form of a transaction Inconstant function will be broadcasted in the form of a transaction while being called, the function will change the data on the chain, such as transfer, changing the value of the internal variables of contracts, etc.
Note: If you use create command inside a contract (CREATE instruction), even use view/pure/constant to decorate the dynamically created contract function, this function will still be treated as inconstant function, be dealt in the form of transaction.
- message calls
Message calls can call the functions of other contracts, also can transfer TRX to the accounts of contract and none-contract. Like the common TRON triggercontract, Message calls have initiator, recipient, data, transfer amount, fees and return attributes. Every message call can generate a new one recursively. Contract can define the distribution of the remaining energy in the internal message call. If it comes with OutOfEnergyException in the internal message call, it will return false, but not error. In the meantime, only the gas sent with the internal message call will be consumed, if energy is not specified in call.value(energy), all the remaining energy will be used.
- delegate call/call code/library
There is a special type of message call, delegate call. The difference with common message call is the code of the target address will be run in the context of the contract that initiates the call, msg.sender and msg.value remain unchanged. This means a contract can dynamically loadcode from another address while running. Storage, current address and balance all point to the contract that initiates the call, only the code is get from the address being called. This gives Solidity the ability to achieve the 'lib' function: the reusable code lib can be put in the storage of a contract to implement complex data structure library.
- CREATE command
This command will create a new contract with a new address. The only difference with Ethereum is the newly generated TRON address used the smart contract creation transaction id and the hash of nonce called combined. Different from Ethereum, the definition of nonce is the contract sequence number of the creation of the root call. Even there are many CREATE commands calls, contract number in sequence from 1. Refer to the source code for more detail. Note: Different from creating a contract by grpc's deploycontract, contract created by CREATE command does not store contract abi.
- built-in function and built-in function attribute (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)
1)TVM is compatible with solidity language's transfer format, including:\n- accompany with constructor to call transfer\n- accompany with internal function to call transfer\n- use transfer/send/call/callcode/delegatecall to call transfer\n\nNote: TRON's smart contract is different from TRON's system contract, if the transfer to address does not exist it can not create an account by smart contract transfer.\n\n2)Different accounts vote for SuperNode (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n3)SuperNode gets all the reward (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n4)SuperNode approves or disapproves the proposal (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n5)SuperNode proposes a proposal (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n6)SuperNode deletes a proposal (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n7)TRON byte address converts to solidity address (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n8)TRON string address converts to solidity address (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n9)Send token to target address (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n10)Query token amount of target address (Since Odyssey-v3.1.1, TVM built-in function is not supported temporarily)\n\n11)Compatible with all the built-in functions of Ethereum\n
Note: Ethereum's RIPEMD160 function is not recommended, because the return of TRON is a hash result based on TRON's sha256, not an accurate Ethereum RIPEMD160."},{"location":"contracts/contract/#contract-address-used-in-solidity-language","title":"Contract Address Used in Solidity Language","text":"Ethereum VM address is 20 bytes, but TRON's VM address is 21 bytes.
- address conversion
Need to convert TRON's address while using in solidity (recommended):
/**\n * @dev convert uint256 (HexString add 0x at beginning) TRON address to solidity address type\n * @param tronAddress uint256 tronAddress, begin with 0x, followed by HexString\n * @return Solidity address type\n*/\n\nfunction convertFromTronInt(uint256 tronAddress) public view returns(address){\n return address(tronAddress);\n}\n
This is similar with the grammar of the conversion from other types converted to address type in Ethereum. - address judgement
Solidity has address constant judgement, if using 21 bytes address the compiler will throw out an error, so you should use 20 bytes address, like:
function compareAddress(address tronAddress) public view returns (uint256){\n // if (tronAddress == 0x41ca35b7d915458ef540ade6068dfe2f44e8fa733c) { // compile error\n if (tronAddress == 0xca35b7d915458ef540ade6068dfe2f44e8fa733c) { // right\n return 1;\n } else {\n return 0;\n }\n}\n
But if you are using wallet-cli, you can use 21 bytes address, like 0000000000000000000041ca35b7d915458ef540ade6068dfe2f44e8fa733c - variable assignment
Solidity has address constant assignment, if using 21 bytes address the compiler will throw out an error, so you should use 20 bytes address, like:
function assignAddress() public view {\n // address newAddress = 0x41ca35b7d915458ef540ade6068dfe2f44e8fa733c; // compile error\n address newAddress = 0xca35b7d915458ef540ade6068dfe2f44e8fa733c;\n // do something\n}\n
If you want to use TRON address of string type (TLLM21wteSPs4hKjbxgmH1L6poyMjeTbHm) please refer to (2-4-7,2-4-8)."},{"location":"contracts/contract/#special-constants-differ-from-ethereum","title":"Special Constants Differ from Ethereum","text":""},{"location":"contracts/contract/#currency","title":"Currency","text":"Like solidity supports ETH, TRON VM supports trx and sun, 1 trx = 1000000 sun, case sensitive, only support lower case. tron-studio supports trx and sun, remix does not support trx and sun. We recommend to use tron-studio instead of remix to build TRON smart contract.
"},{"location":"contracts/contract/#block-related","title":"Block Related","text":" - block.blockhash (uint blockNumber) returns (bytes32): specified block hash, can only apply to the latest 256 blocks and current block excluded
- block.coinbase (address): SuperNode address that produced the current block
- block.difficulty (uint): current block difficulty, not recommended, set 0
- block.gaslimit (uint): current block gas limit, not supported, set 0
- block.number (uint): current block number
- block.timestamp (uint): current block timestamp
- gasleft() returns (uint256): remaining gas
- msg.data (bytes): complete call data
- msg.gas (uint): remaining gas - since 0.4.21, not recommended, replaced by gesleft()
- msg.sender (address): message sender (current call)
- msg.sig (bytes4): first 4 bytes of call data (function identifier)
- msg.value (uint): the amount of SUN send with message
- now (uint): current block timestamp (block.timestamp)
- tx.gasprice (uint): the gas price of transaction, not recommended, set 0
- tx.origin (address): transaction initiator
Each command of smart contract consume system resource while running, we use 'Energy' as the unit of the consumption of the resource.
"},{"location":"contracts/tools/","title":"Tools","text":""},{"location":"contracts/tools/#tronide","title":"TronIDE","text":"Support the build, debug, run, etc. for solidity language written smart contract. http://www.tronide.io
"},{"location":"contracts/tools/#tronbox","title":"TronBox","text":"Support the build, deploy, transplant, etc. for solidity language written smart contract. https://developers.tron.network/reference/what-is-tronbox
"},{"location":"contracts/tools/#tronweb","title":"TronWeb","text":"Provide javascript api for the usage of smart contract. https://tronweb.network/docu/docs/intro/
"},{"location":"contracts/tools/#trongrid","title":"TronGrid","text":"Provide smart contract event query service. https://developers.tron.network/docs/trongrid
"},{"location":"contracts/tools/#trident-java","title":"Trident-java","text":"Trident-java is a lightweight SDK that includes libraries for working with TRON system contracts and smart contracts. https://tronprotocol.github.io/trident/
"},{"location":"developers/advanced-configuration/","title":"Advanced Configurations","text":"we provide some configuration items for LevelDB and gRPC in config.conf file, for fine-grained performance tuning. You may custom these items only if you have deep understanding on them, otherwise keep them as default.
"},{"location":"developers/advanced-configuration/#leveldb","title":"LevelDB","text":"You can custom LevelDB options in the storage part of config.conf, which looks like:
storage {\n # Directory for storing persistent data\n\n db.directory = \"database\",\n index.directory = \"index\",\n\n # You can custom these 14 databases' configs:\n\n # account, account-index, asset-issue, block, block-index,\n # block_KDB, peers, properties, recent-block, trans,\n # utxo, votes, witness, witness_schedule.\n\n # Otherwise, db configs will remain default and data will be stored in\n # the path of \"output-directory\" or which is set by \"-d\" (\"--output-directory\").\n\n # Attention: name is a required field that must be set !!!\n properties = [\n {\n name = \"account\",\n path = \"/path/to/account\", // relative or absolute path\n createIfMissing = true,\n paranoidChecks = true,\n verifyChecksums = true,\n compressionType = 1, // 0 - no compression, 1 - compressed with snappy\n blockSize = 4096, // 4 KB = 4 * 1024 B\n writeBufferSize = 10485760, // 10 MB = 10 * 1024 * 1024 B\n cacheSize = 10485760, // 10 MB = 10 * 1024 * 1024 B\n maxOpenFiles = 100\n }\n ]\n\n}\n
As shown in the example above, the data of database account will be stored in the path of /path/to/account/database while the index be stored in /path/to/account/index. And, the example also shows our default value of LevelDB options from createIfMissing to maxOpenFiles. You can just refer to the docs of LevelDB to figure out details of these options.
"},{"location":"developers/advanced-configuration/#grpc","title":"gRPC","text":"You can custom gPRC options in the node.rpc part of config.conf, which looks like:
node {\n rpc {\n port = 50051\n\n # Number of gRPC thread, default availableProcessors / 2\n # thread = 16\n\n # The maximum number of concurrent calls permitted for each incoming connection\n # maxConcurrentCallsPerConnection =\n\n # The HTTP/2 flow control window, default 1MB\n # flowControlWindow =\n\n # Connection being idle for longer than which will be gracefully terminated\n maxConnectionIdleInMillis = 60000\n\n # Connection lasting longer than which will be gracefully terminated\n # maxConnectionAgeInMillis =\n\n # The maximum message size allowed to be received on the server, default 4MB\n # maxMessageSize =\n\n # The maximum size of header list allowed to be received, default 8192\n # maxHeaderListSize =\n }\n}\n
"},{"location":"developers/advanced-configuration/#backup","title":"backup","text":"You can custom backup options in the node.backup part of config.conf, which looks like:
node.backup {\n # my priority, each member should use different priority\n priority = \n # members should use same port\n port = \n # peer's ip list, can't contain mine\n members = []\n}\n
policy: 1. the one which synchronized first will become master. 2. if synchronization is completed at the same time, the one with big priority will become master. E.g. create backups for node A(192.168.0.100) and node B(192.168.0.100 ): node A's configuration:
node.backup {\n priority = 8 \n port = 10001\n members = [\n \"192.168.0.101\"\n ]\n}\n
node B's configuration: node.backup {\n priority = 5\n port = 10001\n members = [\n \"192.168.0.100\"\n ]\n}\n
You may refer to the source code of io.grpc.netty.NettyServerBuilder class to see details or just make a decision according to the brief comments above.
"},{"location":"developers/archive-manifest/","title":"Leveldb Startup Optimization Plugins","text":""},{"location":"developers/archive-manifest/#introduction","title":"Introduction","text":"With the operation of levelDB, manifest file will continue to grow, huge manifest file not only affects the node startup speed, but also may cause the problem of system exit with continuous memory growth. For this reason, leveldb startup optimization plugin is introduced since GreatVoyage-v4.3.0(Bacon), which optimizes the file size of manifest and the startup process of LevelDB, reduces the memory occupation and improves the node startup speed.
Remember stop the FullNode process before any operation. This tool provides the ability to reformat the manifest according to the current database.
For more design details, please refer to: TIP298.
"},{"location":"developers/archive-manifest/#usage","title":"Usage","text":""},{"location":"developers/archive-manifest/#options-for-plug-in","title":"Options For Plug-in","text":" -b | --batch-size: [ int ] specify the batch manifest size,default\uff1a80000.-d | --database-directory: [ string ] Specify the database directory to be processed,default\uff1aoutput-directory/database.-m | --manifest-size: [ int ] Specify the minimum required manifest file size \uff0cunit:M\uff0cdefault\uff1a0.-h | --help: [ bool ] for usage help\uff0cdefault\uff1afalse.
"},{"location":"developers/archive-manifest/#how-to-get","title":"How to get","text":" - build by yourself. Under java-tron, execute
. /gradlew build, you can get Toolkit.jar under build/libs/. - Download directly. Links
"},{"location":"developers/archive-manifest/#use-steps","title":"Use Steps","text":" -
- Stop the FullNode service.
-
- Execute the Toolkit command.
-
- Start the FullNode service.
Note: Step ii is not required every time, but it is recommended to run it every time to optimize the experience.
"},{"location":"developers/archive-manifest/#how-to-use","title":"How to use","text":"After FullNode runs, the default database directory: output-directory, the optimization plugin will work with the output-directory/database directory. Developers can choose one of the following two ways according to actual situation.
"},{"location":"developers/archive-manifest/#use-it-independently","title":"Use it Independently","text":""},{"location":"developers/archive-manifest/#1stop-the-fullnode-service","title":"1.Stop the FullNode service","text":"Use kill -15 to shutdown the FullNode.jar .
Query the pid: ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}'
"},{"location":"developers/archive-manifest/#2execute-the-toolkit-command","title":"2.Execute the Toolkit command","text":"# Full command\njava -jar Toolkit.jar [-b batchSize] [-d databaseDirectory] [-m manifestSize] [-h]\n# examples\n java -jar Toolkit.jar #1. use default settings\n java -jar Toolkit.jar -d /tmp/db/database #2. Specify the database directory as /tmp/db/database\n java -jar Toolkit.jar -b 64000 #3. Specify the batch size to 64000 when optimizing Manifest\n java -jar Toolkit.jar -m 128 #4. Specify optimization only when Manifest exceeds 128M\n
After the command is executed, archive.log will be generated in the ./logs directory, you can see the result.
Note: After the command is executed\uff0cIf successful, the log will display something similar to the following, and will run generally within 120s, depending on how long the FullNode service keeps running, and if it fails there will be a corresponding error message
[main] [archive](ArchiveManifest.java:144) DatabaseDirectory:output-directory/database, maxManifestSize:0, maxBatchSize:80000,database reopen use 80 seconds total.
"},{"location":"developers/archive-manifest/#3start-the-fullnode-service","title":"3.Start the FullNode service","text":" #FullNode\nnohup java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c main_net_config.conf </dev/null &>/dev/null &\n #SR Node\nnohup java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -p private key --witness -c main_net_config.conf </dev/null &>/dev/null &\n
"},{"location":"developers/archive-manifest/#integrated-startup-script","title":"Integrated startup script","text":"#!/bin/bash\n\nAPP=$1\n\nMANIFEST_OPT=$2\n\nALL_OPT=$*\n\nNEED_REBUILD=0\n\nif [[ $1 == '--rewrite--manifest' ]] ; then\n APP=''\n NEED_REBUILD=1\n\n elif [[ $2 == '--rewrite--manifest' ]] ; then\n NEED_REBUILD=1\n fi\n\n\nrebuildManifest() {\n\n if [[ $NEED_REBUILD == 1 ]] ; then\n buildManifest\n fi\n\n}\n\n\nbuildManifest() {\n\n ARCHIVE_JAR='Toolkit.jar'\n\n java -jar $ARCHIVE_JAR $ALL_OPT\n\n if [ $? == 0 ] ; then\n\n echo 'rebuild manifest success'\n\n else\n\n echo 'rebuild manifest fail, log in logs/archive.log'\n\n fi\n\n}\n\n\n\nAPP=${APP:-\"FullNode\"}\n\nSTART_OPT=`echo ${@:2}`\n\nJAR_NAME=\"$APP.jar\"\n\nMAX_STOP_TIME=60\n\nMEM_OPT=''\n\n\n\n\n\ncheckpid() {\n\n pid=`ps -ef | grep $JAR_NAME |grep -v grep | awk '{print $2}'`\n\n return $pid\n\n}\n\ncheckPath(){\n path='output-directory/database'\n flag=1\n for p in ${ALL_OPT}\n do\n if [[ $flag == 0 ]] ; then\n path=`echo $p`\n break\n fi\n if [[ $p == '-d' || $p == '--database-directory' ]] ; then\n path=''\n flag=0\n fi\n done\n\n if [[ -z \"${path}\" ]]; then\n echo '-d /path or --database-directory /path'\n return 1\n fi\n\n if [[ -d ${path} ]]; then\n return 0\n else\n echo $path 'not exist'\n return 1\n fi\n}\n\n\n\nstopService() {\n\n count=1\n\n while [ $count -le $MAX_STOP_TIME ]; do\n\n checkpid\n\n if [ $pid ]; then\n\n kill -15 $pid\n\n sleep 1\n\n else\n\n echo \"java-tron stop\"\n\n return\n\n fi\n\n count=$[$count+1]\n\n if [ $count -eq $MAX_STOP_TIME ]; then\n\n kill -9 $pid\n\n sleep 1\n\n fi\n\n done\n\n}\n\nstartService() {\n echo `date` >> start.log\n\n total=16*1024*1024\n\n xmx=`echo \"$total/1024/1024*0.6\" | bc |awk -F. '{print $1\"g\"}'`\n\n directmem=`echo \"$total/1024/1024*0.1\" | bc |awk -F. '{print $1\"g\"}'`\n\n logtime=`date +%Y-%m-%d_%H-%M-%S`\n\n export LD_PRELOAD=\"/usr/lib64/libtcmalloc.so\"\n\n nohup java -Xms$xmx -Xmx$xmx -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -Xloggc:./gc.log\\\n -XX:+PrintGCDateStamps -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m -XX:+UseCodeCacheFlushing\\\n $MEM_OPT -XX:MaxDirectMemorySize=$directmem -XX:+HeapDumpOnOutOfMemoryError -jar $JAR_NAME $START_OPT -c config.conf >> start.log 2>&1 &\n\n pid=`ps -ef |grep $JAR_NAME |grep -v grep |awk '{print $2}'`\n\n echo \"start java-tron with pid $pid on $HOSTNAME\"\n\n}\n\n#1.Stop the FullNode service\nstopService\n\ncheckPath\n\n#2.Execute the Toolkit plugin\nif [[ 0 == $? ]] ; then\n rebuildManifest\nelse\n exit -1\nfi\n\nsleep 5\n# Start the FullNode service\nstartService\n
example Note: Save above script as start.sh, In the above script the --rewrite--manifest argument is fixed in the first or second argument.
OPTIONS
--rewrite--manifest enable leveldb startup optimization plugins\uff0cThe above plug-in option `-d -m -b -h` will take effect iff this option(--rewrite--manifest) is turned on\n
# Full command\n./start.sh [FullNode|SolidityNode] [--rewrite--manifest] [-b batchSize] [-d databaseDirectory] [-m manifestSize]\n# examples\n ./start.sh #1. Start the FullNode.jar service without the plugin\n ./start.sh SolidityNode #2. Start the SolidityNode.jar service without the plugin\n ./start.sh FullNode --rewrite--manifest #3. Execute the optimization plugin with default settings and start the FullNode.jar service\n ./start.sh --rewrite--manifest -d /tmp/db/database #4. Specify the database directory as /tmp/db/database, execute the optimization plugin, and start the FullNode.jar service\n ./start.sh --rewrite--manifest -b 64000 #5. Specify the batch size to 64000 when optimizing Manifest, and start the FullNode.jar service\n ./start.sh --rewrite--manifest -m 128 #6. Specify that optimization is performed only when the Manifest exceeds 128M, and start the FullNode.jar service\n
"},{"location":"developers/code-structure/","title":"java-tron Core Modules","text":""},{"location":"developers/code-structure/#code-structure","title":"Code Structure","text":"java-tron is a TRON network client developed based on the Java language. It implements all the functions mentioned in the TRON white paper, including consensus mechanism, cryptography, database, TVM virtual machine, network management, etc. We can run a TRON node by starting java-tron. In this article, we will describe the code structure of java-tron in detail, and introduce the functions of its various modules, to facilitate the subsequent code analysis and development of developers.
java-tron adopts a modular code structure; the code structure is clear and easy to maintain and expand. Currently java-tron is divided into 7 modules: protocol, common, chainbase, consensus, actuator, crypto, framework, the following introduces the functions of each module and its code organization.
"},{"location":"developers/code-structure/#protocol","title":"protocol","text":"For a distributed network such as blockchain, a concise and efficient data interaction protocol is very important. The protocol module defines:
- Inter-node communication protocol
- Communication protocol between modules within the node
- Agreement for Services Provided Externally
The above protocols adopt the Google Protobuf data exchange format. Compared with JSON and XML, the Google Protobuf format is more efficient and flexible and can be compiled by the ProtoBuf compiler to generate language-specific serialization and deserialization source code for the defined protocol files. Protobuf is the basis for java-tron to achieve cross-language and cross-platform.
protocol module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/protocol , its directory structure is as follows:
|-- protos\n |-- api\n | |-- api.proto\n | |-- zksnark.proto\n |-- core\n |-- Discover.proto\n |-- Tron.proto\n |-- TronInventoryItems.proto\n |-- contract\n
protos/api/ - The gRPC interface and data structure provided by the java-tron node externallyprotos/core/ - Data structure for communication between nodes and between modules within nodes Discover.proto - Node discovers related data structuresTronInventoryItems.proto - Data structure related to block transferring between nodescontract/ - Contract related data structuresTron.proto - Other important data structures, including accounts, blocks, transactions, resources, super representatives, voting, and proposals...
"},{"location":"developers/code-structure/#common","title":"common","text":"The common module encapsulates common components and tools, such as exception handling, metrics monitoring tools, etc which make it easy to use by other modules.
common module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/common, its directory structure is as follows:
|-- /common/src/main/java/org/tron\n |-- common\n | |-- args\n | |-- config\n | |-- entity\n | |-- logsfilter\n | |-- overlay\n | |-- parameter\n | |-- prometheus\n | |-- runtime\n | |-- setting\n | |-- utils\n |-- core\n |-- config\n |-- db\n |-- db2\n |-- exception\n
common/prometheus - Prometheus metrics monitoringcommon/utils - The wrapper class of basic data typecore/config - Node configuration related classescore/exception - All exception handling related classes
"},{"location":"developers/code-structure/#chainbase","title":"chainbase","text":"Chainbase is a database module. For probabilistic consensus algorithms such as PoW, PoS and DPoS, situations of switching to a new chain, however unlikely, are inevitable. Because of this, chainbase defines an interface standard supporting databases that can roll back. This interface requires databases to have a state rollback mechanism, a checkpoint-based disaster tolerant mechanism and so on.
In addition, the chainbase module features a well-designed abstract interface. Any database that implements the interface can be used for underlying storage on the blockchain, granting more flexibility to developers. LevelDB and RocksDB are two default implementations.
chainbase module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/chainbase, its directory structure is as follows:
|-- chainbase.src.main.java.org.tron\n |-- common\n | |-- bloom\n | |-- error\n | |-- overlay\n | |-- runtime\n | |-- storage\n | | |-- leveldb\n | | |-- rocksdb\n | |-- utils\n | |-- zksnark\n |-- core\n |-- actuator\n |-- capsule\n |-- db\n | |-- RevokingDatabase.java\n | |-- TronStoreWithRevoking.java\n | |-- ......\n |-- db2\n | |-- common\n | |-- core\n | |-- SnapshotManager.java\n | |-- ......\n |-- net\n |-- service\n |-- store\n
common/ - Common components, such as exception handling, tools, etc storage/leveldb/ Implemented the use of LevelDB as the underlying storage databasestorage/rocksdb/ Implemented the use of RocksDB as the underlying storage database
-
core/ - The core code of the chainbase module
-
capsule/
The encapsulation class of each data structure, such as AccountCapsule, BlockCapsule, etc. AccountCapsule is the encapsulation class of Account data structure, which provides modification and query of account data; BlockCapsule is the encapsulation class of Block data structure, which provides modification and query of block data.
-
store/
Various databases, such as AccountStore, ProposalStore, etc. AccountStore is the account database, the database name is account, which stores all account information in the TRON network; ProposalStore is the proposal database, and the database name is proposal, which stores all the proposal information in the TRON network.
-
db/ and db2/
Implemented rollbackable databases, including two rollbackable databases: AbstractRevokingStore located in the db/ directory and SnapshotManager located in the db2/ directory. Compared with AbstractRevokingStore, SnapshotManager has a more stable data rollback function and supports the extension of the underlying database. Therefore, java-tron uses SnapshotManager to roll back the database. Several important interfaces and implementation classes are as follows:
RevokingDatabase.java - It is the interface of the database container, used to manage all rollbackable databases, SnapshotManager is an implementation of this interfaceTronStoreWithRevoking.java - It is the base class that supports rollbackable databases. All rollbackable databases are their implementations, such as BlockStore, TransactionStore, etc
"},{"location":"developers/code-structure/#consensus","title":"consensus","text":"The consensus mechanism is a crucial module in blockchains. Common ones are PoW, PoS, DPoS and PBFT, etc. While Paxos, Raft, etc, are applied to consortium blockchains and other trusted networks. The consensus mechanism should match the business scenario. For instance, PoW is not suitable for real-time games that are sensitive to consensus efficiency, while PBFT can make an optimized choice for exchanges demanding high real-time capability. In this sense, a replaceable consensus is a creative innovation and an essential link in building application-specific blockchains. Even star blockchain programs like Cosmos SDK are still at a stage where the application layer provides developers with limited autonomy and the consensus at the base level is subject to Tendermint. Therefore, the ultimate goal of the consensus module is to make consensus switch as easy as configuring parameters for application developers.
consensus module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/consensus, its directory structure is as follows:
|-- consensus/src/main/java/org/tron/consensus\n |-- Consensus.java\n |-- ConsensusDelegate.java\n |-- base\n | |-- ConsensusInterface.java\n | |-- ......\n |-- dpos\n |-- pbft\n
consensus module divides the consensus process into several important parts that are defined in ConsensusInterface: start - start the consensus service with customizable startup parametersstop - stop the consensus servicereceiveBlock - define the consensus logic of receiving blocksvalidBlock - define the consensus logic of validating blocksapplyBlock - define the consensus logic of processing blocks
Currently, java-tron implements DPOS consensus and PBFT consensus based on the ConsensusInterface interface, which is located in the dpos/ and pbft/ directories respectively. Developers can also implement the ConsensusInterface interface according to their own business needs to customize the consensus mechanism.
"},{"location":"developers/code-structure/#actuator","title":"actuator","text":"Ethereum was the first to introduce the virtual machine and define the smart contract. However, smart contracts are constrained in terms of their functions and not flexible enough to accommodate the needs of complex applications. This is one of the reasons why java-tron supports the creation of a chain of applications. For the reasons mentioned, java-tron includes a separate module, Actuator, offering application developers a brand new way of development. They can choose to implant their application codes into a chain instead of running them on virtual machines.
Actuator is the executor of transactions, while applications can be viewed as a cluster of different types of transactions, each of which is executed by a corresponding actuator.
actuator module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/actuator, its directory structure is as follows:
|-- actuator/src/main/java/org/tron/core\n |-- actuator\n | |-- AbstractActuator.java\n | |-- ActuatorCreator.java\n | |-- ActuatorFactory.java\n | |-- TransferActuator.java\n | |-- VMActuator.java\n | |-- ......\n |-- utils\n |-- vm\n
actuator/ - The executors of various types of transactions in the TRON network which define the processing logic of different types of transactions. For example, TransferActuator is the processing class for transferring TRX, and FreezeBalanceV2Actuator is the processing class for staking TRX to obtain resourceutils/ - tools needed to execute transactionvm/ - TRON virtual machine related code
Actuator module defines the Actuator interface, which includes 4 different methods:
execute - execute specific actions of transactions, such as state modification, communication between modules, logic execution, etc.validate - validate authenticity of transactionsgetOwnerAddress - acquire the address of transaction initiatorscalcFee - define the logic of calculating transaction fees
Depending on their businesses, developers may set up Actuator accordingly and customize the processing of different types of transactions.
"},{"location":"developers/code-structure/#crypto","title":"crypto","text":"Crypto is a relatively independent module, but it is also a very important module. Data security in java-tron is almost entirely guaranteed by this module. Currently, SM2 and ECKey encryption algorithms are supported.
crypto module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/crypto, its directory structure is as follows:
|-- crypto/src/main/java/org/tron/common/crypto\n |-- Blake2bfMessageDigest.java\n |-- ECKey.java\n |-- Hash.java\n |-- SignInterface.java\n |-- SignUtils.java\n |-- SignatureInterface.java\n |-- cryptohash\n |-- jce\n |-- sm2\n |-- zksnark\n
sm2 and jce - Provide SM2 and ECKey encryption algorithm and signature algorithmzksnark - Provide a zero-knowledge proof algorithm
"},{"location":"developers/code-structure/#framework","title":"framework","text":"The framework is the core module of java-tron and the entrance of the node. The framework module is responsible for the initialization of each module and business logic. The framework module includes the services provided externally, the node discovery and node management process related to the P2P network, and the block broadcasting and processing procedures.
framework module's source code is located at: https://github.com/tronprotocol/java-tron/tree/develop/framework, its directory structure is as follows:
|-- framework/src/main/java/org/tron\n |-- common\n | |-- application\n | |-- backup\n | |-- logsfilter\n | |-- net\n | |-- overlay\n | | |-- client\n | | |-- discover\n | | |-- message\n | | |-- server\n | |-- runtime\n | |-- zksnark\n |-- core\n | |-- Wallet.java\n | |-- capsule\n | |-- config\n | |-- consensus\n | |-- db\n | |-- metrics\n | |-- net\n | |-- services\n | |-- trie\n | |-- zen\n |-- keystore\n |-- program\n | |-- FullNode.java\n |-- tool\n
program/FullNode.java - It is the entry point of the program and initializes external HTTP, gRPC and json-rpc interface servicescore/services - Defines the externally provided services, its subdirectory http/ contains all http interface processing classes, json-rpc/ contains all json-rpc interface processing classescommon/overlay/discover - Node discovery logiccommon/overlay/server - Node management and block synchronization logic among nodescore/net - Message processing, its subdirectory /service is transaction and block broadcasting, block fetching and synchronization logiccore/db/Manager.java - Transaction and block verification and processing logic
"},{"location":"developers/code-structure/#summary","title":"Summary","text":"This article mainly introduces the code structure of java-tron, as well as the function, location and directory structure of each functional module. Through this article, you will have a general understanding of the overall structure and key interfaces of java-tron, which is helpful for subsequent code analysis and development.
"},{"location":"developers/code-structure/#chainbase_1","title":"ChainBase","text":""},{"location":"developers/code-structure/#introduction","title":"Introduction","text":"As we all know, the blockchain is essentially a non-tamperable distributed ledger, which is very suitable for solving the problem of trust. In reality, blockchain is often used for bookkeeping and transactions. For example, many applications use BTC, ETH, TRX, and other cryptos to carry out economic activities to ensure the openness and transparency of funds.
The realization of such an immutable distributed ledger is a very complex system engineering, involving many technical fields: such as p2p networks, smart contracts, databases, cryptography, consensus mechanisms, etc. Among them, the database is the basis of the underlying storage, and various blockchain teams are exploring the design and optimization of the database level.
The database module of java-tron is also called the ChainBase module. This article mainly introduces some background knowledge and shows developers the implementation details of the ChainBase module by introducing logic such as transaction processing, state rollback, and data persistence.
"},{"location":"developers/code-structure/#prerequisites","title":"Prerequisites","text":"The database is an important part of the blockchain system. It stores all the data on the blockchain and is the basis for the normal operation of the blockchain system. Each fullnode stores a full amount of data, including block data, state data, etc. java-tron uses the Account model to save the user's account state.
"},{"location":"developers/code-structure/#account-models","title":"Account Models","text":"There are currently two mainstream account models,
- UTXO
- Account Model
The UTXO model is stateless, makes it easier to process transactions concurrently, and has better privacy, but it is not programming-friendly.
In the Account Model, user data is stored in the corresponding account, and smart contracts are also stored in the account in the form of code. This model is more intuitive and easier for developers to understand. For programmability, flexibility, and other considerations, java-tron adopts the Account Model.
"},{"location":"developers/code-structure/#consensus_1","title":"Consensus","text":"The current mainstream consensus is PoW, PoS, DPoS, etc. PoW is proof of work, all nodes participate in the calculation of an expected hash result, and the node that first calculates the result has the right to produce a block, but as the computing power continues to increase, the energy consumption required to calculate the hash is also increasing. Moreover, large mining farms monopolize most of the computing power, which also goes against the original intention of decentralization.
To solve the problems faced by PoW, some people proposed PoS (Proof of Stake), which is simply understood as the more coins that the node holds, the greater the probability of obtaining the right to produce blocks, but this will lead to monopoly problems as well. In order to improve, DPoS (Delegated Proof of Stake) is proposed: the decentralization feature is guaranteed by the elected super representative, and the super representative is responsible for the block production in turn to improve the efficiency. java-tron currently adopts the DPoS consensus mechanism.
To learn more, please refer to Delegated Proof of Stake.
"},{"location":"developers/code-structure/#persistent-storage","title":"Persistent Storage","text":"There are certain differences between blockchain and traditional Internet business. The blockchain does not have particularly complex processing logic at the database level, but there are a large number of key-value read and write operations in the blockchain so there are higher requirements for data read and write performance.
Based on this consideration, java-tron uses LevelDB as the underlying data storage by default, and java-tron has a good architecture design. The interface-oriented programming mode makes the chainbase module have better scalability. All databases implemented the chainbase interface can be used as the underlying storage engine of java-tron. For example, in the chainbase v2 version, a database implementation based on RocksDB is provided.
"},{"location":"developers/code-structure/#transaction-validation","title":"Transaction Validation","text":"As we all know, the blockchain mainly stores transaction data. Before introducing the chainbase module, you need to understand the transaction processing logic in java-tron.
The transaction will be distributed to each node through network broadcast. After receiving the transaction, the node will first validate the signature of the transaction. If successful, the transaction needs to be pre-executed to determine whether the transaction is legal.
Note: The specific implementation of java-tron deviates from the above figure, and for the sake of convenience, this article collectively refers to the FullNode and SR as the nodes.
For example, to process a transfer transaction: user A transfers 100 TRX to user B, and it needs to validate whether user A has enough balance to make the transfer.
The account library in the database stores the account information of all users, including the user's balance information. How to judge whether this transfer transaction is legal? The logic of java-tron is: when a transaction is received from the network, the transaction operation will be executed immediately, that is, the account information will be modified in the local database: (accountA - 100TRX, accountB + 100TRX). If this operation can be executed successfully, it means that the transaction is legal at least in the current state, and can be packed into the block.
"},{"location":"developers/code-structure/#glossary","title":"Glossary","text":"SR\uff1a Super Representative, is responsible for block production.
FullNode\uff1a stores all block data, is responsible for transactions, block broadcasting and validation, and provides query services.
TRX\uff1a TRON native token.
"},{"location":"developers/code-structure/#state-rollback","title":"State Rollback","text":"Above we mentioned that java-tron validates whether the transaction is legal through pre-execution, but what we need to know is that the transaction is successfully validated on a certain node does not mean that the transaction has been successfully chained because the transaction has not been packed into the consensus blocks, there is a risk of being rolled back.
The consensus of java-tron follows a principle: that is, the transactions in the blocks that are approved by more than 2/3 of the SRs are the ones that are really successful on the chain. can also be understood as below,
- transactions are packed into a block
- the block is approved by more than 2/3 of the SRs
A transaction that satisfies the above two points is a successful transaction on the chain. A transaction in java-tron is finally confirmed through three stages,
- transaction validating
- transaction packing into the block
- block being accepted and applied
This also leads to a problem: in the implementation of java-tron, if a node validates the transaction, its database state changes accordingly. If the transaction is not packed into the block yet or the block it is packed into has not been approved by more than 2/3 of SR, the state of this node will be inconsistent with the state of the entire network.
Therefore, except for the processing transaction data in blocks approved by more than 2/3 SRs, all other data state changes resulting from transaction processing may need to be rolled back. There are three kinds of scenarios in total:
- after receiving a new block, roll back the state changes generated by transaction validation
- after producing a block, roll back the state changes generated by transaction validation
- if a forked takes place, roll back the state changes generated by the transactions of the blocks in the forked chain
The data state changes caused by these three scenarios may need to be rolled back and the following section explains why.
"},{"location":"developers/code-structure/#rollback-after-receiving-a-new-block","title":"Rollback after Receiving a New Block","text":"When receiving a new block, the node needs to roll back to the state at the end of the previous block and roll back all transactions validated afterward. As shown below,
If the account balance of accountA is 100 at the block height is 1000, the node receives and validates a transaction 't1', in which accountA transfers 100TRX to accountB. After receiving the new block1001, the block contains a transaction 't2', in which accountA transfers 50TRX to accountC. In theory, t2 has been packed into the block, and the priority is higher than t1. However, if no operation is done, the validation of t2 will fail because accountA does not have enough balance. Therefore, after receiving the new block 1001, the state change generated by transaction t1 needs to be rolled back.
"},{"location":"developers/code-structure/#rollback-after-producing-a-new-block","title":"Rollback after Producing a New Block","text":"First of all, readers may have a question: the validated transaction can be directly packed into the block, and it will not change the database state. Why is there a change in the database state?
Because java-tron does a secondary validation of the transaction when it is packed into the block. The secondary validation is due to the timeliness of the transaction. Still taking the above figure as an example, it can be seen from the figure, that after 1001 is received, the transaction t1 was rolled back, and the balance of accountA was deducted by 50. And then, it was the node's turn to produce a block, but t1 had become an illegal transaction at this time because the balance in accountA was not enough to transfer 100 TRX, it is not advisable to directly pack t1 into the block. So the transaction needs to be validated again, which is why the transaction needs to be validated twice when producing a block.
After the block is packed successfully, the node will broadcast the block to the network and apply the block locally. And the logic of applying will re-check the transactions in the block. So after the block is packed, a rollback operation still needs to be performed.
"},{"location":"developers/code-structure/#rollback-when-forking","title":"Rollback when Forking","text":"This is the last rollback situation, and the blockchain will inevitably fork, especially the blockchain system based on DPoS with a faster block production speed that is more prone to fork.
java-tron maintains a data structure in memory as below,
java-tron holds all blocks that have not reached consensus recently. When a forked chain occurs, according to the longest chain principle: if the block height of the forked chain is greater than the current main chain block height, the forked chain needs to be switched to the main chain. Part of the blocks on the previous main chain needs to roll back up to their common parent blocks when switching, and then apply new main chain blocks sequentially from the parent block.
As shown in the figure, fork A in the dark part was originally the main chain. Because the height of fork B continues to grow and eventually exceeds the height of A, it is necessary to roll back the data in those three blocks with heights 1003, 1002, and 1001 in fork A. Then apply fork blocks 1001', 1002', 1003', and 1004' in B in sequence.
"},{"location":"developers/code-structure/#state-rollback-implementation","title":"State Rollback Implementation","text":"This chapter explains receiving and validating transactions, block production, validating and saving blocks from the perspective of code, to further analyze the chainbase module of java-tron. If there is no further declaration, the default description is dedicated to all the Fullnode (including SR).
"},{"location":"developers/code-structure/#receiving-transactions","title":"Receiving Transactions","text":"After the node receives a transaction, it puts the transaction into the local pushTransactionQueue cache queue by calling the pushTransaction(final TransactionCapsule trx) function of the manager class and validates the transaction at the same time. And the return of this method is sort of elegant:
- if validation is successful, \u2018true' is returned
- for the transaction sent by the user to the node through the API, if the transaction validation fails, an exception will be returned to the user; for transactions received from other nodes through the network, exceptions will only be recorded locally
After the transaction validation is successful, the transactions without problems will be put into the pendingTransactionQueue, and the pendingTransactionQueue is responsible for providing the transaction set when producing blocks. If the node is an SR node, when producing a block, it will take out all or part of it from the pendingTransactionQueue (depending on how many transactions are in the pendingTransactionQueue) to generate a block.
"},{"location":"developers/code-structure/#rollback-when-receiving-blocks","title":"Rollback when Receiving Blocks","text":"A node would receive transactions broadcasted from other nodes before receiving a new block, the transactions need to be validated to determine whether they can be executed correctly. Validation means that the state needs to be changed, and a successful validation does not mean that the transaction will be finally executed, and it will be considered successful after packing into a block and the block become solidified. This step can be considered to filter out those obviously wrong transactions in advance. This is just validation. When a new block arrives, the state changed by transaction validations should be rolled back. Only the state changed when applying new blocks will not be rolled back.
When rolling back, java-tron move the transactions in the pendingTransactionQueue to rePushTransactions, and clear the pendingTransactionQueue, see the figure for a detailed explanation.
Why does the pendingTransactionQueue need to be emptied after a new block arrives? First of all, it is clear that the pendingTransactionQueue queue is responsible for providing transaction data when generating blocks, that is to say, it stores validated transactions that can be directly packed into blocks. Since the new block will also change the account state, those validated transactions in pendingTransactionQueue may not pass the validation after applying the new block (the simplest example: a transaction in the new block is that accountA spends a part of the token, resulting in a transaction amount of accountA in the queue that is not enough to pay ). After the transaction is moved to rePushTransactions, a background thread will be responsible for re-validating the transaction in the queue. If nothing is wrong, it will be put into the pendingTransactionQueue again to provide data for block production.
There is a session object in java-tron. A session represents the change in the state of a block. The session object is mainly used for rollback. For example,rolling back the state to the state of the previous block needs to be operated throughout the session, as shown in the following figure,
In the above figure, you can see that there are many different types of databases in persistent storage. These data are jointly organized into a complete blockchain. For example, blocks are stored in khasodb and blockStore, and account information is stored in accountStore...
The node maintains a session chain table, which stores the change information corresponding to the block/transaction, and the node can roll back through the change information. In the above figure, session1 is the status change of the current highest block. When a transaction is received, a new session2 will be generated. Each transaction that comes later will generate a temporary tmpSession, and after the transaction is validated, the tmpSession corresponded will be merged to session2. Before a new block is received again, all status changes generated by transaction validation will be saved in session2. When a new block arrives, directly execute the reset method of the session2 to roll back the state to the previous block.
"},{"location":"developers/code-structure/#rollback-when-producing-blocks","title":"Rollback when Producing Blocks","text":"SR needs to roll back before producing blocks. The reasons are more complicated. Let's consider a scenario first:
- The pendingTransactionQueue stores the currently validated transactions, so when an SR node produces a block, it only needs to directly pack the transactions in the pendingTransactionQueue into the block, and then roll back the state to the state of the previous block after packing.
However, there is a problem with this scheme: if the SR node has just received and applied a new block, the pendingTransactionQueue will be cleared. At this time, it is the turn of the SR to pack the block, but there is no transaction in pendingTransactionQueue. Therefore, the real implementation is that not only reads transactions from pendingTransactionQueue when generating blocks but also reads transactions from rePushTransactions and puts them into blocks if there are few transactions in pendingTransactionQueue. The above analysis shows that transactions in rePushTransactions may not be possible to pass the validation, so the transactions need to be validated again. Due to this validation logic, the state needs to be rolled back before the block is produced.
In the process of producing the block, the transaction will be validated again, so there will be a state change, but this is just block production, and the block needs to be broadcast as well, and those blocks who received the broadcast will actually change the state, so the state changes incurred by block production also need to be rolled back. As shown in the figure above, when the block production is completed, session2\" needs to be rolled back.
"},{"location":"developers/code-structure/#block-solidity","title":"Block Solidity","text":"java-tron adopts the DPoS consensus mechanism. The DPoS of java-tron is to vote for 27 nodes as block producers (also known as SR), SR has the right and obligation to produce blocks, and blocks approved by more than 2/3 of SR are considered to reach a consensus. These blocks, which are no longer rolled back are called solidified blocks. Only solidified blocks can be written to the database.
SnapshotManager in java-tron is the key entry to the storage module, holds references to all current business databases, and stores database references in a list. Each database instance supports adding a new layer of state set on its own called SnapshotImpl. It is an in-memory hashmap, multiple SnapshotImpl are associated in the form of a linked list, and one SnapshotImpl retains the data modification (in-merging or merging) involved in one state change, and SnapshotImpl is independent of each other. They are separated through this data structure, as shown in the following figure,
The SnapshotRoot in the above figure is the encapsulation class for the persistent database, which is responsible for storing the solidified data.
In the previous chapters, we talked about sessions. A session represents the changes of state in a block. In fact, a session contains the SnapshotImpl corresponding to each database. For example, all SnapshotImpl in the layer of block 5 in the above figure together constitutes the changes of block 5 to the entire database.
The changes generated after the node receives a new block will not be directly stored in the persistent storage (SnapshotRoot), but will first be stored in snapshotImpl. Each block received corresponds to a snapshotImpl. Continuously receiving blocks will lead to more and more snapshotImpl. When will they be written to persistent storage?
There are two variables in SnapshotManager: 'size' and 'maxSize'. Here we simply understand 'size' as how many layers of snapshotImpl are there currently in memory, and 'maxSize' represents the difference between the height of the current solidified block and the latest block.
This is obvious. If 'size' > 'maxSize', it means that the blocks corresponding to the first (size-maxSize) snapshotImpl are already solidified blocks, they can be placed on the disk, and then the snapshotImpl will be merged into the persistent storage. This ensures that snapshotImpl does not occupy too much memory, and also ensures that the solidified block can be persisted in time.
"},{"location":"developers/code-structure/#atomicity","title":"Atomicity","text":"The database storage of java-tron is slightly different from other public chains. For example, the Ethereum persistence layer uses only one database instance, and different types of data in Ethereum are distinguished by prefixes and stored in one database instance. However, java-tron currently stores data of different business types in its own database instances.
The two implementations have their own advantages. A single instance is easy to maintain and can be written uniformly, but the disadvantages are also obvious. For example, the amount of data in a single database continues to grow over time, and frequent access to some business databases may drag down the read-and-write performance of other businesses.
Multi-instance does not have the problem of the mutual influence of each business data read and write, and can configure different parameters according to their respective data volume and performance requirements to maximize performance, and can also independently split the database with a large amount of data. Alleviate data bloat problems. But there is a serious problem with multiple database instances: there is no native tool to support atomic writes among multiple database instances.
In order to ensure the atomic writing of multiple database instances, java-tron has added a checkpoint mechanism, which writes the changed data to the checkpoint uniformly before the multiple instances are placed on the disk. If an accident occurs in writing to multiple database instances, the changed data will be recovered from the checkpoint when the service is restarted to ensure the atomicity of writing.
The process of writing the snapshotImpl of the solidified block to the database in the previous section mainly includes two steps,
- create a checkpoint
- place snapshotImpl on disk
The operation of creating a checkpoint is more critical. A checkpoint is to persistently store the snapshotImpl in memory that needs to be written to the database in a tmp database (currently, the underlying implementation is leveldb and rocksdb). After the checkpoint is successfully created, the snapshotImpl will place on the disk. If the machine is down while placing, it will first search for the existence of tmp checkpoint data when the node restart. And if so, the data in the checkpoint will be played back to snapshotRoot.
A checkpoint data structure,
Checkpoint stores all data of a state change in one database. Different types of data are distinguished by prefixes. In order to ensure that all changed data can be placed on disk this time, the bottom layer of the database calls writeBatch() when writing.
This solution can be summarized as,
- the atomicity of writes cannot be guaranteed among multiple database instances, but a single database (most mainstream databases) supports atomic writes
- the data set that needs to be guaranteed to be written atomically is first written to a temporary database by atomic writing, and then the data is written to different database instances; if an accident occurs, it can be recovered through the data of the temporary database
"},{"location":"developers/code-structure/#summary_1","title":"Summary","text":"This article analyzes the implementation details of rollback and database writing in the chainbase module through the processing flow of transactions and blocks and also analyzes the principle of atomic writing among multiple instances of the database to prevent database damage caused by accidental downtime. We hope that reading this article can help developers to further understand and develop the java-tron database.
"},{"location":"developers/code-structure/#network","title":"Network","text":""},{"location":"developers/code-structure/#overview","title":"Overview","text":"P2P is a distributed network in which participants in the network share a part of the hardware resources they own, such as processing power, storage capacity, network connection capacity, printers, etc. These shared resources need to be provided services and content by the network, which can be accessed by other peers directly without going through an intermediate entity. Participants in this network are both providers and acquirers of service and content.
Different from the traditional Client/Server central server structure, the status of each node in the P2P network is equal. While serving as a client, each node can also serve as a server to provide services to other nodes, which greatly improves the utilization of resources.
"},{"location":"developers/code-structure/#blockchain-network","title":"Blockchain Network","text":"P2P is the network layer in the blockchain structure. The main purpose of the network layer is to realize information broadcast, verification and communication between nodes. The blockchain network is essentially a P2P network, and each node can both receive and generate information. Nodes keep communication by maintaining common blockchain data.
As the foundation of the blockchain, the P2P network brings the following advantages to the blockchain:
- Prevent single-point attack
- High fault tolerance
- Better compatibility and scalability
"},{"location":"developers/code-structure/#tron-network","title":"TRON Network","text":"The architecture diagram of TRON is as follows:
As the most fundamental module of TRON, the P2P network directly determines the stability of the entire blockchain network. The network module can be divided into the following four parts according to the function:
- Node Discovery
- Node Connection
- Block Synchronization
- Block and Transaction Broadcast
Below will separately introduce these four functional parts.
"},{"location":"developers/code-structure/#node-discovery","title":"Node Discovery","text":"Node discovery is the first step for nodes to access the blockchain network. The blockchain network is a structured P2P network which organizes all nodes in an orderly manner, such as forming a ring network or a tree-like network. Structured networks are generally implemented based on the DHT (Distributed Hash Table) algorithm. Specific implementation algorithms include Chord, Pastry, CAN, Kademlia and so on. The TRON network uses the Kademlia algorithm.
"},{"location":"developers/code-structure/#kademlia-algorithm","title":"Kademlia Algorithm","text":"Kademlia is an implementation of Distributed Hash Table (DHT), it is the core routing technology in the decentralized P2P network and can quickly find target nodes in the network without a central server.
For a detailed introduction to the algorithm, please refer to Kademlia.
"},{"location":"developers/code-structure/#kademlia-implementation-by-tron","title":"Kademlia Implementation by TRON","text":"The main points of the Kademlia algorithm implemented by TRON are as follows:
- Node ID: Randomly generated 512bit ID
- Node Distance: The node distance is obtained through the XOR operation of two nodes' ID. The formula is:
Node distance = 256 - the number of leading 0s in the node ID XOR result, if the calculation result is negative, the distance is equal to 0. - K-Bucket: The node routing table. According to the distance between the nodes, the remote nodes are divided into different buckets. The remote nodes with the same distance as the current node are recorded in the same bucket, and each bucket can accommodate up to 16 nodes. According to the calculation formula of node distance, it can be seen that the Kademlia algorithm implemented by TRON maintains a total of 256 buckets.
The node discovery protocol of TRON includes the following four UDP messages:
DISCOVER_PING - used to detect if a node is onlineDISCOVER_PONG - used in response to DISCOVER_PING messageDISCOVER_FIND_NODE - used to find other nodes closest to the target nodeDISCOVER_NEIGHBORS - used in response to DISCOVER_FIND_NODE message, will return one or more nodes, up to 16
"},{"location":"developers/code-structure/#initialize-k-buckets","title":"Initialize K-Buckets","text":"After the node is started, it will read the seed nodes configured in the node configuration file and the peer nodes recorded in the database, and then send DISCOVER_PING message to them respectively. If the reply message DISCOVER_PONG from a peer is received, and at the condition that the K bucket is not full, it will then write the peer node into the K bucket; But if the corresponding bucket has already been full (that is the bucket has reached 16 nodes), it will challenge to the earliest node in the bucket. If the challenge is successful, the old node will be deleted, and the new node will be added to the K bucket. That is the K bucket initialization process, then the node discovery process is performed.
"},{"location":"developers/code-structure/#send-discover_find_node-to-find-more-nodes","title":"Send DISCOVER_FIND_NODE to Find More Nodes","text":"The node discovery service will start two scheduled tasks (DiscoverTask and RefreshTask) to periodically perform the node discovery process to update k buckets.
DiscoverTask is to discover more nodes that are closer to myself. It is executed every 30s. The execution flow is as follows: RefreshTask is to expand the local k-bucket by random node ID, that is, to find nodes that are closer to the random node ID. It is executed every 7.2s. The execution process is as follows:
The node discovery algorithm used in DiscoverTask and RefreshTask will be executed 8 rounds in one call, and each round sends DISCOVER_FIND_NODE message to the 3 nodes closest to the target node ID in the K bucket, and waits for a reply.
"},{"location":"developers/code-structure/#receive-neighbors-messages-and-update-k-bucket","title":"Receive Neighbors' Messages and Update K Bucket","text":"When the local node receives the DISCOVER_NEIGHBORS message replied by the remote node, it will send the DISCOVER_PING message to the received neighbor node in turn, and then if it receives the reply message DISCOVER_PONG, it will judge whether the corresponding K-bucket is full, if the K-bucket is not full, it will add the new node to the K bucket, if the K bucket is full, it will challenge one of the nodes, if the challenge is successful (send a DISCOVER_PING message to the old node, if it fails to receive the reply message DISCOVER_PONG, the challenge is successful, otherwise the challenge fails), the old node will be deleted from the K bucket, and the new node will be added to the K bucket.
Nodes periodically perform node discovery tasks, continuously update K-buckets, and build their own node routing tables. The next step is to establish a connection with nodes.
"},{"location":"developers/code-structure/#node-connection","title":"Node Connection","text":"Before understanding how to establish a TCP connection between nodes, we need to first understand the peer node type.
"},{"location":"developers/code-structure/#peer-node-management","title":"Peer Node Management","text":"The local node needs to manage and classify peer nodes for efficient and stable node connection. Remote nodes can be divided into the following categories:
- Active nodes: specified in the configuration file. After the system starts, it will actively establish connections with the nodes. If the connection fails to be established, it will retry in each scheduled TCP connection task.
- Passive nodes: specified in the configuration file. The local node will passively accept connections from them.
- Trust nodes: specified in the configuration file, both Active nodes and Passive nodes are trusted nodes. When receiving a connection request from a trusted node, some other condition checks are skipped and the request is accepted directly.
- BadNodes: When an abnormal protocol packet is received, the sending node will be added to the badNodes list, valid for 1 hour. When a connection request from badNodes is received, the request will be rejected directly
- RecentlyDisconnectedNodes: When a connection is disconnected, the peer node will be added to the recentlyDisconnectedNodes list, valid for 30s, when a connection request from recentlyDisconnectedNodes is received, the request will be rejected directly
"},{"location":"developers/code-structure/#establish-tcp-connection-with-peers","title":"Establish TCP Connection with Peers","text":"After the node is started, a scheduled task poolLoopExecutor will be created to establish a TCP connection with nodes. It will select nodes and establish connections with them. The working process is as follows:
The TCP connection can be mainly divided into two steps: first, determine the node list which the node will establish a connection with. The list needs to contain the active nodes that have not successfully established a connection, and then calculate the number of connections that also need to be established, and filter out the nodes from discovered neighbors according to the node filtering strategy, then score and sort them according to the node scoring strategy, and the corresponding number of nodes with the highest score is added to the request list. Finally, TCP connections are established with the nodes in the request list.
"},{"location":"developers/code-structure/#node-filtering-strategy","title":"Node Filtering Strategy","text":"When establishing a node connection, it is necessary to filter out the following types of nodes and determine whether the node's own connection number has reached the maximum value.
- Myself
- Nodes in the recentlyDisconnectedNodes list
- Nodes in badNodes list
- Nodes that have already established a connection
- The number of connections established with the node IP has already reached the upper limit (maxConnectionsWithSameIp)
But for trusted nodes, some filtering policies are ignored and connections are always established.
"},{"location":"developers/code-structure/#node-scoring-strategy","title":"Node Scoring Strategy","text":"The node score is used to determine the priority of nodes to establish a connection. The higher the score, the higher the priority. Scoring dimensions include:
- Packet loss rate: The lower the packet loss rate, the better the communication quality. The score is inversely proportional to the packet loss rate. The highest score is 100 and the lowest is 0.
- Network delay: The smaller the network delay, the better the network quality. The score is inversely proportional to the average network latency. The highest score is 20 and the lowest is 0.
- TCP traffic: The larger the TCP traffic, the more active the communication. The score is proportional to the TCP traffic, with a maximum score of 20 and a minimum of 0
- Disconnection times: The fewer disconnection times, the more stable the node is. The score is inversely proportional to the number of disconnections. The score is 10 times the number of disconnections.
- Handshake: Nodes that have been handshake successfully before indicate that they have the same blockchain information, so it is preferred to establish a connection with them. When the number of successful Handshakes is greater than 0, the Handshake score is 20, otherwise, the score is 0.
- Penalty state: A node in the Penalty state has a score of 0 and does not participate in scoring in other dimensions. The following situations will be regarded as in the Penalty state:
- Node disconnection time is less than 60s
- The node is in the badNodes list
- Inconsistent blockchain information
When calculating the node score, first determine whether the node is in the Penalty state, if so, the score is counted as 0, otherwise, the node score is the sum of the scores of each dimension.
"},{"location":"developers/code-structure/#handshake","title":"Handshake","text":"After the TCP connection is successfully established, the node that actively initiates the TCP connection request will send a handshake message P2P_HELLO to the neighbor node, in order to confirm whether the blockchain information between the nodes is consistent and whether it is necessary to initiate the block synchronization process.
When the neighbor node receives P2P_HELLO, it will compare with the local information, such as checking whether the p2p version and the genesis block information are consistent. If all the check conditions are passed, it will reply to the P2P_HELLO message, and then perform the block synchronization or broadcast; otherwise, it will disconnect the connection.
"},{"location":"developers/code-structure/#channel-keep-alive","title":"Channel Keep-Alive","text":"Channel keep-alive is accomplished through P2P_PING, P2P_PONG TCP messages. When a node establishes a TCP connection with a neighbor node and handshakes successfully, the node will open a thread pingTask for the connection and periodically send P2P_PING messages to maintain the TCP connection, which is scheduled every 10s. If the P2P_PONG message replied is not received within the timeout period, the connection will be terminated.
"},{"location":"developers/code-structure/#block-synchronization","title":"Block Synchronization","text":"After completing the handshake with the peer node, if the peer node's blockchain is longer than the local blockchain, the block synchronization process syncService.startSync will be triggered according to the longest chain principle. The message interaction during the synchronization process is as follows:
Node A sends an SYNC_BLOCK_CHAIN message to peer node B to announce the blockchain summary information of the local chain. After the peer node B receives it, it calculates the list of missing blocks of node A, and sends the lost block ID list to node A through the BLOCK_CHAIN_INVENTORY message, carrying a maximum of 2000 block ids at a time.
After node A receives the BLOCK_CHAIN_INVENTORY message, it gets the missing block id, and sends a FETCH_INV_DATA message to node B asynchronously to request the missing block, up to 100 blocks at a time. If there are still blocks that need to be synchronized (that is, the remain_num in the BLOCK_CHAIN_INVENTORY message is greater than 0), a new round of block synchronization process will be triggered.
After node B receives the FETCH_INV_DATA message from node A, it sends the block to node A through the BLOCK message. After node A receives the BLOCK message, it asynchronously processes the block.
"},{"location":"developers/code-structure/#blockchain-summary-and-list-of-missing-blocks","title":"Blockchain Summary and List of Missing Blocks","text":"Below will take several different block synchronization scenarios as examples to illustrate the generation of the blockchain summary and the lost block ID list.
- Blockchain summary: an ordered list of block IDs, including the highest solidified block, the highest non-solidified block, and the blocks corresponding to the dichotomy.
- List of missing blocks: The neighbor node compares its own chain with the received blockchain summary, determines the missing blocks list of peers, and returns a set of consecutive block IDs and the number of remaining blocks.
"},{"location":"developers/code-structure/#normal-synchronization-scene","title":"Normal Synchronization Scene","text":"The height of the local header block is 1018, and the height of the solidified block is 1000. The two nodes have just established a connection, so the height of the common block is 0. The local blockchain summary of node A obtained by the dichotomy is 1000, 1010, 1015, 1017, and 1018.
After node B receives the blockchain summary of node A, combined with the local chain, it can produce the list of blocks that node A lacks: 1018, 1019, 1020, and 1021. Then, node A requests to synchronize blocks 1019, 1020, and 1021 according to the list of missing blocks.
"},{"location":"developers/code-structure/#chain-switching-scene","title":"Chain-Switching Scene","text":"The head block height of the local main chain is 1018, and the height of the solidified block is 1000. The two nodes have just established a connection, so the height of the common block is 0. The local blockchain summary of node A obtained by the dichotomy is 1000, 1010, 1015, 1017, and 1018.
After node B receives the chain summary of node A, it finds that the local main chain is not the same as the main chain of node A, compares the chain summary of node A and finds that the common block height is 1015, then it computes the list of blocks that node A lacks are 1015, 1016', 1017', 1018', and 1019'. Then, node A requests to synchronize blocks 1018' and 1019' according to the list of missing blocks.
In another switching chain scenario, the height of the local main chain header block is 1018, the height of the solidified block is 1000, and the common block is 1017', which is located on the fork chain. The local blockchain summary of node A obtained by the dichotomy is 1000, 1009, 1014, 1016', and 1017'.
After node B receives the chain summary of node A, combined with the local chain, it can produce the list of blocks that node A lacks 1017', 1018', and 1019'. Then, node A requests to synchronize blocks 1018', and 1019' according to the list of missing blocks.
"},{"location":"developers/code-structure/#block-and-transaction-broadcast","title":"Block and Transaction Broadcast","text":"When the super representative node produces a new block, or the fullnode receives a new transaction initiated by the user, the transaction & block broadcasting process will be initiated. When a node receives a new block or new transaction, it will forward the corresponding block or transaction, and the forwarding process is the same as that of broadcasting. The message interaction is shown in the following figure:
The types of messages involved include:
INVENTORY - broadcast list: list of block or transaction idsFETCH_INV_DATA - the list data that the node needs to get: block or transaction id listBLOCK - block dataTRXS - transaction data
Node A sends the transaction or block to be broadcast to Node B via the INVENTORY list message. After node B receives the INVENTORY list message, it needs to check the status of the peer node, and if it can receive the message, it puts the blocks/transactions in the list into the \"to be fetched queue\" invToFetch. If it is a block list, it will also trigger the \"get block & transaction task\" immediately to send a FETCH_INV_DATA message to node A to get the block & transaction.
After node A receives the FETCH_INV_DATA message, it will check whether an \"INVENTORY\" message has been sent to the peer. If it has been sent, it will send a transaction or block message to node B according to the list data. After node B receives the transaction or block message, it processes the message and triggers the forwarding process.
"},{"location":"developers/code-structure/#summary_2","title":"Summary","text":"This article introduces the implementation details related to the P2P network, the lowest level module of TRON, including node discovery, node connection, block synchronization, and the process of block and transaction broadcasting. I hope that reading this article can help developers to further understand and develop java-tron network-related modules.
"},{"location":"developers/demo/","title":"Development Example","text":"This article will take adding a new setPeer HTTP interface as an example to illustrate how to participate in the development of java-tron. Before developing, please configure the InteliJ IDE development environment.
Sometimes java-tron nodes may not be able to connect to peers due to network reasons, if you can add trusted nodes while the node is running, this will allow the node to connect to the peer even if the node discovery function is not working.
"},{"location":"developers/demo/#fork-java-tron-repository","title":"Fork java-tron Repository","text":"Fork a new repository from the https://github.com/tronprotocol/java-tron project to your personal repository, and then use the following command Clone the code locally:
$ git clone https://github.com/yourname/java-tron.git\n$ git remote add upstream https://github.com/tronprotocol/java-tron.git\n
"},{"location":"developers/demo/#sync-repository","title":"Sync Repository","text":"Before developing new features, please synchronize your fork repository with the upstream repository.
$ git fetch upstream \n$ git checkout develop \n$ git merge upstream/develop --no-ff\n
"},{"location":"developers/demo/#create-new-branch","title":"Create New Branch","text":"Pull a new branch from the develop branch of your own repository for local development, please refer to branch naming convention. In this example, the name of the new branch is: feature/ add-new-http-demo.
$ git checkout -b feature/add-new-http-demo develop\n
"},{"location":"developers/demo/#code-development","title":"Code Development","text":"Open the java-tron project in IDEA. Create a new servlet file in the java-tron/framework/src/main/java/org/tron/core/services/http directory to process HTTP requests: SetPeerServlet.java, the file should contain two functions doGet and doPost. doGet is used to handle http get requests and doPost is used to handle http post requests. If one of these types of requests is not supported, the method content can be empty.
@Component\n@Slf4j(topic = \"API\")\npublic class SetPeerServlet extends HttpServlet {\n protected void doGet(HttpServletRequest request, HttpServletResponse response) \n {}\n protected void doPost(HttpServletRequest request, HttpServletResponse response) \n {}\n}\n
In this example, the setPeer request should be sent by post, so you need to add processing logic in the doPost method, and the content of the doGet method keeps empty. The processing logic of the doPost method is:
- Get the incoming parameters
- Add peer information to the list of trusted nodes through the addPeer method
- Return the processing result of addPeer to the front-end user
@Component\n@Slf4j(topic = \"API\")\npublic class SetPeerServlet extends HttpServlet {\n @Autowired\n private ChannelManager channelManager;\n\n protected void doPost(HttpServletRequest request, HttpServletResponse response) {\n try {\n PostParams params = PostParams.getPostParams(request);\n\n JSONObject jsonObject = JSONObject.parseObject(params.getParams());\n String peerIpPort = String.valueOf(jsonObject.get(\"peer\"));\n\n boolean res = addPeer(peerIpPort);\n if (res) {\n response.getWriter().println(\"Success to set trusted peer:\" + peerIpPort);\n } else {\n response.getWriter().println(\"Fail to set the trusted peer:\" + peerIpPort);\n }\n\n } catch (Exception e) {\n logger.error(\"Exception occurs when setting peer: {}\", e.getMessage());\n try {\n response.getWriter().println(Util.printErrorMsg(e));\n } catch (IOException ioe) {\n logger.error(\"IOException occurs when setting peer: {}\", ioe.getMessage());\n }\n }\n }\n ......\n}\n
Put the processing logic of adding trust nodes in the addPeer method, which not only makes the code logic clearer, but also easier to test.
The logic of the addPeer method is:
- Check the parameters the user entered to ensure that the node ip and port are not empty
- Construct node information through
Node.instanceOf(peerIP) - Make sure that the added trust node is not self
- Add the node to the trusted node list
boolean addPeer(String peerIP) {\n try {\n if (peerIP != \"\") {\n Node node = Node.instanceOf(peerIP);\n if (!(CommonParameter.PARAMETER.nodeDiscoveryBindIp.equals(node.getHost())\n || CommonParameter.PARAMETER.nodeExternalIp.equals(node.getHost())\n || Constant.LOCAL_HOST.equals(node.getHost()))\n || CommonParameter.PARAMETER.nodeListenPort != node.getPort()) {\n\n InetAddress address = new InetSocketAddress(node.getHost(), node.getPort()).getAddress();\n channelManager.getTrustNodes().put(address, node);\n return true;\n }\n }\n } catch (Exception e) {\n logger.error(\"addPeer error - {}\", e.getMessage());\n }\n return false;\n }\n}\n
After completing the implementation of SetPeerServlet, you also need to register it in the node HTTP API service, FullNodeHttpApiService is the registration entry for the node HTTP API. Call the context.addServlet method in the start function of the FullNodeHttpApiService class to register the SetPeerServlet to the service. The name of the HTTP interface is defined as /wallet/setpeer.
public class FullNodeHttpApiService implements Service {\n ......\n @Autowired\n private SetPeerServlet setPeerServlet;\n .......\n\n @Override\n public void start() {\n ......\n context.addServlet(new ServletHolder(setPeerServlet), \"/wallet/setpeer\");\n .......\n }\n\n}\n
Then you can debug the above code, start the java-tron node in IDEA, and interact with the node through the below Curl command in the terminal: $ curl --location --request POST 'http://127.0.0.1:16667/wallet/setpeer' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"peer\":\"192.163.3.2:16667\"\n}'\n
Return: Success to set trusted peer:192.163.3.2:16667\n
At this point, the code development is complete, and then you need to write unit tests for the changes. For simple changes, unit tests can be written after the development code is completed, but for larger changes, it is recommended to write unit tests at the same time as development.
"},{"location":"developers/demo/#write-unit-test","title":"Write Unit Test","text":"The unit test of the java-tron project is based on the JUnit framework. For the usage of JUnit, please refer to JUnit official website. The following is a brief introduction to the java-tron unit test case specification and common annotations.
"},{"location":"developers/demo/#java-tron-unit-test-cases-writing-specification","title":"java-tron Unit Test Cases Writing Specification","text":"When writing java-tron unit test cases, please follow the below guidelines:
- All test classes should be placed in the test directory, and the package of the test class should be consistent with the package structure of the tested code. Generally, use
Test as the suffix of a class name - The test method must be decorated with
@Test and it must be public void type. Generally, test is used as the prefix of the method name - Each test method in the test class must be independently testable, and there must be no dependencies between methods
"},{"location":"developers/demo/#common-annotations","title":"Common Annotations","text":"The following are descriptions of some commonly used annotations. For other annotations, please refer to JUnit official website documentation.
@Test - transforms a normal method into a test method@Ignore - the decorated test method will be ignored by the test runner@BeforeClass - the method will be executed before all methods, static method (only executed once globally, and it is the first running one)@AfterClass - the method will be executed after all methods, static methods ( only executed once globally, and it will be the last running one)@Before - it will be executed once before each test method@After - it will be executed once after each test method
"},{"location":"developers/demo/#the-composition-of-the-unit-test-class","title":"The Composition Of The Unit Test Class","text":"A unit test class should contain the following three parts:
@Before or @BeforeClass decorated function, used for initialization before test case execution@After or @BeforeClass decorated function, used to process data cleaning after the test case execution- Test method decorated by
@Test
public class demoTest {\n\n @Before\n public void init() {\n // Initialization work before test case execution\n }\n @After\n public void destroy() {\n // Destroy work after test case execution\n\n }\n @Test\n public void testDemoMethod() { \n }\n}\n
For this example in the article, a new file should be created in the framework/src/test/java/org/tron/core/services/http/ directory: SetPeerServletTest.java used to write test cases.
public class SetPeerServletTest {\n private static TronApplicationContext context;\n private static Application appT;\n public static ChannelManager channelManager;\n @Before\n public void init() {\n\n Args.setParam(new String[]{}, Constant.TEST_CONF);\n context = new TronApplicationContext(DefaultConfig.class);\n channelManager = context.getBean(ChannelManager.class);\n appT = ApplicationFactory.create(context);\n appT.initServices(Args.getInstance());\n appT.startServices();\n appT.startup();\n\n }\n @After\n public void destroy() {\n Args.clearParam();\n appT.shutdownServices();\n appT.shutdown();\n\n }\n @Test\n public void testAddPeer() {\n SetPeerServlet setPeerServlet = new SetPeerServlet();\n Assert.assertFalse(setPeerServlet.addPeer(\"127.0.0.1\"));\n }\n}\n
"},{"location":"developers/demo/#code-style-check","title":"Code Style Check","text":"Check the modified files one by one, and select Check Current File in the right-click menu. If there are code style problems, please modify them one by one according to the prompts.
Fix the code style warning in the picture, and then check the file again until there is no warning.
"},{"location":"developers/demo/#commit-code","title":"Commit Code","text":"Submit the code after development complete, please refer to the commit specification.
git add .\ngit commit -m 'add a new http api setpeer'\n
Push the new branch to the personal remote repository:
git push origin feature/add-new-http-demo\n
"},{"location":"developers/demo/#submit-pull-request","title":"Submit Pull Request","text":"Submit a pull request (PR) from your repository to tronprotocol/java-tron.
"},{"location":"developers/deployment/","title":"Deployment","text":""},{"location":"developers/deployment/#premise","title":"Premise","text":"Create separate directories for fullnode and soliditynode
NOTE: SolidityNode is deprecated. Now a FullNode supports all RPCs of a SolidityNode. New developers should deploy FullNode only.
/deploy/fullnode\n/deploy/soliditynode\n
Create two folders for fullnode and soliditynode.
Clone the latest master branch of https://github.com/tronprotocol/java-tron and extract it to
/deploy/java-tron\n
Make sure you have the proper dependencies.
- JDK 1.8 (JDK 1.9+ is not supported yet)
- On Linux Ubuntu system (e.g. Ubuntu 16.04.4 LTS), ensure that the machine has Oracle JDK 8, instead of having Open JDK 8 in the system. If you are building the source code by using Open JDK 8, you will get Build Failed result.
- Open UDP ports for connection to the network
- MINIMUM 2 CPU Cores
"},{"location":"developers/deployment/#deployment-guide","title":"Deployment Guide","text":"1.\u00a0Build the java-tron project
cd /deploy/java-tron\n./gradlew build\n
2.\u00a0Copy the FullNode.jar and SolidityNode.jar along with configuration files into the respective directories
download your needed configuration file from https://github.com/tronprotocol/TronDeployment.\n\nmain_net_config.conf is the configuration for MainNet, and test_net_config.conf is the configuration for TestNet.\n\nplease rename the configuration file to `config.conf` and use this config.conf to start FullNode and SolidityNode.\n\ncp build/libs/FullNode.jar ../fullnode\n\ncp build/libs/SolidityNode.jar ../soliditynode\n
3.\u00a0You can now run your FullNode using the following command
java -jar FullNode.jar -c config.conf // make sure that your config.conf is downloaded from https://github.com/tronprotocol/TronDeployment\n
4.\u00a0Configure the SolidityNode configuration file
You need to edit config.conf to connect to your local FullNode. Change trustNode in node to local 127.0.0.1:50051, which is the default rpc port. Set listen.port to any number within the range of 1024-65535. Please don't use any ports between 0-1024 since you'll most likely hit conflicts with other system services. Also change rpc port to 50052 or something to avoid conflicts. Please forward the UDP port 18888 for FullNode.
rpc {\n port = 50052\n }\n
5.\u00a0You can now run your SolidityNode using the following command\uff1a
java -jar SolidityNode.jar -c config.conf //make sure that your config.conf is downloaded from https://github.com/tronprotocol/TronDeployment\n
6.\u00a0Running a Super Representative Node for mainnet
java -jar FullNode.jar -p your private key --witness -c your config.conf(Example\uff1a/data/java-tron/config.conf)\nExample:\njava -jar FullNode.jar -p 650950B193DDDDB35B6E48912DD28F7AB0E7140C1BFDEFD493348F02295BD812 --witness -c /data/java-tron/config.conf\n
This is similar to running a private testnet, except that the IPs in the config.conf are officially declared by TRON.
7.\u00a0Running a Super Representative Node for private testnet
You should modify the config.conf:
- Replace existing entry in genesis.block.witnesses with your address
- Replace existing entry in seed.node ip.list with your ip list
- The first Super Node start, needSyncCheck should be set false
- Set p2pversion to 61
cd build/libs\njava -jar FullNode.jar -p your private key --witness -c your config.conf (Example\uff1a/data/java-tron/config.conf)\nExample:\njava -jar FullNode.jar -p 650950B193DDDDB35B6E48912DD28F7AB0E7140C1BFDEFD493348F02295BD812 --witness -c /data/java-tron/config.conf\n
"},{"location":"developers/deployment/#logging-and-network-connection-verification","title":"Logging and Network Connection Verification","text":"Logs for both nodes are located in /deploy/\\*/logs/tron.log. Use tail -f /logs/tron.log/ to follow along with the block syncing.
You should see something similar to this in your logs for block synchronization:
FullNode
12:00:57.658 INFO [pool-7-thread-1] [o.t.c.n.n.NodeImpl](NodeImpl.java:830) Success handle block Num:236610,ID:0000000000039c427569efa27cc2493c1fff243cc1515aa6665c617c45d2e1bf\n
SolidityNode 12:00:40.691 INFO [pool-17-thread-1] [o.t.p.SolidityNode](SolidityNode.java:88) sync solidity block, lastSolidityBlockNum:209671, remoteLastSolidityBlockNum:211823\n
"},{"location":"developers/deployment/#stop-node-gracefully","title":"Stop Node Gracefully","text":"Create file stop.sh\uff0cuse kill -15 to close FullNode.jar(or SolidityNode.jar). You need to modify pid=ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}' to find the correct pid.
#!/bin/bash\nwhile true; do\n pid=`ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}'`\n if [ -n \"$pid\" ]; then\n kill -15 $pid\n echo \"The java-tron process is exiting, it may take some time, forcing the exit may cause damage to the database, please wait patiently...\"\n sleep 1\n else\n echo \"java-tron killed successfully!\"\n break\n fi\ndone\n
"},{"location":"developers/deployment/#fullnode-and-soliditynode-fast-deployment","title":"FullNode and SolidityNode Fast Deployment","text":"Download fast deployment script, run the script according to different types of node.
Scope of use This script could be used on Linux/MacOS, but not on Windows. Just Support FullNode and SolidityNode.
Download and run script wget https://raw.githubusercontent.com/tronprotocol/TronDeployment/master/deploy_tron.sh -O deploy_tron.sh\n
Parameter Illustration bash deploy_tron.sh --app [FullNode|SolidityNode] --net [mainnet|testnet|privatenet] --db [keep|remove|backup] --heap-size <heapsize>\n\n--app Optional, Running application. The default node is Fullnode and it could be FullNode or SolidityNode.\n--net Optional, Connecting network. The default network is mainnet and it could be mainnet, testnet.\n--db Optional, The way of data processing could be keep, remove and backup. Default is keep. If you launch two different networks, like from mainnet to testnet or from testnet to mainnet, you need to delete database.\n--trust-node Optional, It only works when deploying SolidityNode. Default is 127.0.0.1:50051. The specified gRPC service of Fullnode, like 127.0.0.1:50051 or 13.125.249.129:50051.\n--rpc-port Optional, Port of grpc. Default is 50051. If you deploy SolidityNode and FullNode on the same host\uff0cyou need to configure different ports.\n--commit Optional, commitid of project.\n--branch Optional, branch of project. Mainnet default is latest release and Testnet default is master.\n--heap-size Optional, jvm option: Xmx. The default heap-size is 0.8 * memory size.\n--work_space Optional, default is current directory.\n
Deployment of FullNode on the one host wget https://raw.githubusercontent.com/tronprotocol/TronDeployment/master/deploy_tron.sh -O deploy_tron.sh\nbash deploy_tron.sh\n
Deployment of SolidityNode on the one host wget https://raw.githubusercontent.com/tronprotocol/TronDeployment/master/deploy_tron.sh -O deploy_tron.sh\n# User can self-configure the IP and Port of GRPC service in the trust-node field of SolidityNode. trust-node is the fullnode you just deploy.\nbash deploy_tron.sh --app SolidityNode --trust-node <grpc-ip:grpc-port>\n
Deployment of FullNode and SolidityNode on the same host # You need to configure different gRPC ports on the same host because gRPC port is available on SolidityNode and FullNodeConfigure and it cannot be set as default value 50051. In this case the default value of rpc port is set as 50041.\nwget https://raw.githubusercontent.com/tronprotocol/TronDeployment/master/deploy_tron.sh -O deploy_tron.sh\nbash deploy_tron.sh --app FullNode\nbash deploy_tron.sh --app SolidityNode --rpc-port 50041\n
"},{"location":"developers/deployment/#grpc-gateway-deployment","title":"Grpc Gateway Deployment","text":"Summary This script helps you download the code from https://github.com/tronprotocol/grpc-gateway and deploy the code on your environment.
Pre-requests Please follow the guide on https://github.com/tronprotocol/grpc-gateway Install Golang, Protoc, and set $GOPATH environment variable according to your requirement.
Download and run script wget https://raw.githubusercontent.com/tronprotocol/TronDeployment/master/deploy_grpc_gateway.sh -O deploy_grpc_gateway.sh\n
Parameter Illustration bash deploy_grpc_gateway.sh --rpchost [rpc host ip] --rpcport [rpc port number] --httpport [http port number]\n\n--rpchost The fullnode or soliditynode IP where the grpc service is provided. Default value is \"localhost\".\n--rpcport The fullnode or soliditynode port number grpc service is consuming. Default value is 50051.\n--httpport The port intends to provide http service provided by grpc gateway. Default value is 18890.\n
Example Use default configuration\uff1a
bash deploy_grpc_gateway.sh\n
Use customized configuration\uff1a bash deploy_grpc_gateway.sh --rpchost 127.0.0.1 --rpcport 50052 --httpport 18891\n
"},{"location":"developers/deployment/#event-subscribe-plugin-deployment","title":"Event Subscribe plugin Deployment","text":"This is an implementation of TRON eventsubscribe model.
- api module defines IPluginEventListener, a protocol between java-tron and event plugin.
- app module is an example for loading plugin, developers could use it for debugging.
- kafkaplugin module is the implementation for kafka, it implements IPluginEventListener, it receives events subscribed from java-tron and relay events to kafka server.
- mongodbplugin mongodbplugin module is the implementation for mongodb.
Setup/Build - Clone the repo
git clone https://github.com/tronprotocol/event-plugin.git - Go to eventplugin
cd event-plugin -
run ./gradlew build
-
This will produce one plugin zip, named plugin-kafka-1.0.0.zip, located in the event-plugin/build/plugins/ directory.
Edit **config.conf** of java-tron\uff0c add the following fields: event.subscribe = {\n path = \"\" // absolute path of plugin\n server = \"\" // target server address to receive event triggers\n dbconfig=\"\" // dbname|username|password\n topics = [\n {\n triggerName = \"block\" // block trigger, the value can't be modified\n enable = false\n topic = \"block\" // plugin topic, the value could be modified\n },\n {\n triggerName = \"transaction\"\n enable = false\n topic = \"transaction\"\n },\n {\n triggerName = \"contractevent\"\n enable = true\n topic = \"contractevent\"\n },\n {\n triggerName = \"contractlog\"\n enable = true\n topic = \"contractlog\"\n }\n ]\n\n filter = {\n fromblock = \"\" // the value could be \"\", \"earliest\" or a specified block number as the beginning of the queried range\n toblock = \"\" // the value could be \"\", \"latest\" or a specified block number as end of the queried range\n contractAddress = [\n \"\" // contract address you want to subscribe, if it's set to \"\", you will receive contract logs/events with any contract address.\n ]\n\n contractTopic = [\n \"\" // contract topic you want to subscribe, if it's set to \"\", you will receive contract logs/events with any contract topic.\n ]\n }\n}\n
* path: is the absolute path of \"plugin-kafka-1.0.0.zip\" * server: Kafka server address * topics: each event type maps to one Kafka topic, we support four event types subscribing, block, transaction, contractlog and contractevent. * dbconfig: db configuration information for mongodb, if using kafka, delete this one; if using Mongodb, add like that dbname|username|password * triggerName: the trigger type, the value can't be modified. * enable: plugin can receive nothing if the value is false. * topic: the value is the kafka topic to receive events. Make sure it has been created and Kafka process is running * filter: filter condition for process trigger. note: if the server is not 127.0.0.1, pls set some properties in config/server.properties file remove comment and set listeners=PLAINTEXT://:9092 remove comment and set advertised.listeners to PLAINTEXT://host_ip:9092"},{"location":"developers/deployment/#kafka","title":"Install Kafka Run Kafka Create topics to receive events, the topic is defined in config.conf Kafka consumer Load plugin in java-tron Event filter","text":"On Mac:
brew install kafka\n
On Linux:
cd /usr/local\nwget http://archive.apache.org/dist/kafka/0.10.2.2/kafka_2.10-0.10.2.2.tgz\ntar -xzvf kafka_2.10-0.10.2.2.tgz\nmv kafka_2.10-0.10.2.2 kafka\n\nadd \"export PATH=$PATH:/usr/local/kafka/bin\" to end of /etc/profile\nsource /etc/profile\n\n\nkafka-server-start.sh /usr/local/kafka/config/server.properties &\n
Note: make sure the version of Kafka is the same as the version set in build.gradle of eventplugin project.(kafka_2.10-0.10.2.2 kafka) On Mac:
zookeeper-server-start /usr/local/etc/kafka/zookeeper.properties & kafka-server-start /usr/local/etc/kafka/server.properties\n
On Linux:
zookeeper-server-start.sh /usr/local/kafka/config/zookeeper.properties &\nSleep about 3 seconds\nkafka-server-start.sh /usr/local/kafka/config/server.properties &\n
On Mac:
kafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic block\nkafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic transaction\nkafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic contractlog\nkafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic contractevent\n
On Linux:
kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic block\nkafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic transaction\nkafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic contractlog\nkafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic contractevent\n
On Mac:
kafka-console-consumer --bootstrap-server localhost:9092 --topic block\nkafka-console-consumer --bootstrap-server localhost:9092 --topic transaction\nkafka-console-consumer --bootstrap-server localhost:9092 --topic contractlog\nkafka-console-consumer --bootstrap-server localhost:9092 --topic contractevent\n
On Linux:
kafka-console-consumer.sh --zookeeper localhost:2181 --topic block\nkafka-console-consumer.sh --zookeeper localhost:2181 --topic transaction\nkafka-console-consumer.sh --zookeeper localhost:2181 --topic contractlog\nkafka-console-consumer.sh --zookeeper localhost:2181 --topic contractevent\n
- add --es to command line, for example:
java -jar FullNode.jar -p privatekey -c config.conf --es\n
which is defined in config.conf, path: event.subscribe
filter = {\n fromblock = \"\" // the value could be \"\", \"earliest\" or a specified block number as the beginning of the queried range\n toblock = \"\" // the value could be \"\", \"latest\" or a specified block number as end of the queried range\n contractAddress = [\n \"TVkNuE1BYxECWq85d8UR9zsv6WppBns9iH\" // contract address you want to subscribe, if it's set to \"\", you will receive contract logs/events with any contract address.\n ]\n\n contractTopic = [\n \"f0f1e23ddce8a520eaa7502e02fa767cb24152e9a86a4bf02529637c4e57504b\" // contract topic you want to subscribe, if it's set to \"\", you will receive contract logs/events with any contract topic.\n ]\n }\n
"},{"location":"developers/deployment/#mongo","title":"Download and install MongoDB","text":"** Suggested Configuration **
- CPU/ RAM: 16Core / 32G
- DISK: 500G
- System: CentOS 64
The version of MongoDB is 4.0.4, below is the command:
- cd /home/java-tron
- curl -O https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-4.0.4.tgz
- tar zxvf mongodb-linux-x86_64-4.0.4.tgz
- mv mongodb-linux-x86_64-4.0.4 mongodb
** Set environment ** - export MONGOPATH=/home/java-tron/mongodb/ - export PATH=PATH:MONGOPATH/bin
** Create mongodb config ** The path is : /etc/mongodb/mgdb.conf
- cd /etc/mongodb
- touch mgdb.conf
Create data&log folder for mongodb Create data, log subfolder in mongodb directory, and add their absolute path to mgdb.conf
** Example: **
- dbpath=/home/java-tron/mongodb/data
- logpath=/home/java-tron/mongodb/log/mongodb.log
- port=27017
- logappend=true
- fork=true
- bind_ip=0.0.0.0
- auth=true
- wiredTigerCacheSizeGB=2
** Note: ** - bind_ip must be configured to 0.0.0.0\uff0cotherwise remote connection will be refused. - wiredTigerCacheSizeGB, must be configured to prevent OOM
** Launch MongoDB ** - mongod --config /etc/mongodb/mgdb.conf
** Create admin account: ** - mongo - use admin - db.createUser({user:\"root\",pwd:\"admin\",roles:[{role:\"root\",db:\"admin\"}]})
** Create eventlog and its owner account **
- db.auth(\"root\", \"admin\")
- use eventlog
- db.createUser({user:\"tron\",pwd:\"123456\",roles:[{role:\"dbOwner\",db:\"eventlog\"}]})
database: eventlog, username:tron, password: 123456
** Firewall rule: ** - iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 27017 -j ACCEPT
** Remote connection via mongo: **
- mongo 47.90.245.68:27017
- use eventlog
- db.auth(\"tron\", \"123456\")
- show collections
- db.block.find()
** Query block trigger data: **
- db.block.find({blockNumber: {$lt: 1000}}); // return records whose blockNumber less than1000
** Set database index to speedup query: **
cd /{projectPath} sh insertIndex.sh
"},{"location":"developers/deployment/#event-query-service-deployment","title":"Event query service deployment","text":"Download sourcecode Download sourcecode
git clone https://github.com/tronprotocol/tron-eventquery.git cd troneventquery
Build - mvn package
After the build command is executed successfully, troneventquery jar to release will be generated under troneventquery/target directory.
Configuration of mongodb \"config.conf\" should be created for storing mongodb configuration, such as database name, username, password, and so on. We provided an example in sourcecode, which is \" troneventquery/config.conf \". Replace with your specified configuration if needed.
Note:
Make sure the relative path of config.conf and troneventquery jar. The config.conf 's path is the parent of troneventquery jar.
- mongo.host=IP
- mongo.port=27017
- mongo.dbname=eventlog
- mongo.username=tron
- mongo.password=123456
- mongo.connectionsPerHost=8
- mongo.threadsAllowedToBlockForConnectionMultiplier=4
Any configuration could be modified except mongo.dbname, \"eventlog\" is the specified database name for event subscribe.
Run - troneventquery/deploy.sh is used to deploy troneventquery
- troneventquery/insertIndex.sh is used to setup mongodb index to speedup query.
"},{"location":"developers/deployment/#advanced-configurations","title":"Advanced Configurations","text":"Read the Advanced Configuration
"},{"location":"developers/governance/","title":"Governance","text":"The governance of the TRON network is accomplished by modifying the network parameters. The modification of network parameters is also called a network upgrade. Anyone can propose a discussion on modifying one or several network parameters, however, only super representatives or super representative partners can submit voting requests on-chain. Before the voting deadline, 27 super representatives can vote on the proposal. After the voting deadline arrives and the number of votes meets the requirement, the proposal will take effect.
You can view the list of the past completed proposals here.
Please according to the following process to propose a voting request:
- Initiate a discussion on proposal
- Community discussion
- Initiate a voting request
- Voting and taking effective
"},{"location":"developers/governance/#initiate-a-discussion-on-a-proposal","title":"Initiate a discussion on a proposal","text":"Any TRON network participant can initiate a discussion on a proposal. Please create a proposal discussion issue in TIP repository. The Issue is used to introduce the proposal in detail, including the motivation of this proposal, the TRON network parameters to be modified and their values, technical specifications, and the impact of the modification, etc. for a new proposal, please refer to this example to create an issue for discussion.
Below are the specifications of how to write an issue for proposal discussion.
"},{"location":"developers/governance/#title","title":"Title","text":"We hope that all users of the TRON ecosystem can participate in network governance. In order to be able to better publicize in the community, it is recommended to name the proposal and put the name at the beginning of the title. Here is an example:
Palma Upgrade: proposal to change the unit price of energy to 210 sun\n
"},{"location":"developers/governance/#body","title":"Body","text":"In the issue body, the content of the proposal should be introduced in detail, including motivation, estimated time to initiate the proposal vote and effective time of the proposal, how to initiate a proposal vote, technical specifications or background information of the proposal, etc.
# Simple Summary\nBriefly introduce the parameters to be modified by this proposal and their values, and summarize the issue it wants to solve\n\n# Motivation\nDescribe the motivation for the proposal, what is the problem encountered now, that is, why one or some dynamic parameters need to be modified.\n\n# Timeline\nIndicate when to initiate the proposal voting request, and the estimated effective date of the proposal. After the issue is proposed, two weeks are generally reserved for community discussion. Therefore, the proposal initiation time set in the Issue should be two weeks after the issue is proposed.\n\n# How to Initialize the Voting Request\nIndicates the command to initiate the proposal voting request.\n\n# Technical Specification / Background\nThe specific technical specifications or background information of the proposal\n
"},{"location":"developers/governance/#community-discussion","title":"Community discussion","text":"After the proposal issue is initiated, the initiator of the issue should try his best to promote it in the community, attract community users to participate in the discussion on the proposal, and update the proposal according to the results of the discussion.
"},{"location":"developers/governance/#initiate-a-voting-request","title":"Initiate a voting request","text":"Generally, the initiation time of the voting request set in the proposal is two weeks after the proposed issue is initiated. When the community has already fully discussed on the proposal and formed a community consensus, the super representative or super representative partner will initiate a voting request on the chain.
"},{"location":"developers/governance/#vote-and-take-effect","title":"Vote and take effect","text":"The validity period of the voting request initiated on-chain is 3 days. During the validity period, all 27 super representatives can vote for the proposal. When the voting deadline is reached, if the number of votes obtained is equal to or greater than 18 votes, the proposal will take effect.
"},{"location":"developers/issue-workflow/","title":"Issue Work Flow","text":"We encourage community contributors to participate in the submission and discussion of java-tron issues. You can submit your questions or ideas in the form of issues, or participate in issue discussions or help to provide solutions. Your every question or comment is driving java-tron's development. We thank you for your contribution to java-tron.
"},{"location":"developers/issue-workflow/#submit-an-issue","title":"Submit an Issue","text":"If you encounter java-tron related problems or find related bugs, you are welcome to submit an Issue, but please respect the following rules:
-
Search for existing issues
Please check to see if someone has already reported your issue or requested your idea, this will not only solve your problem quickly but also avoid duplicate issues.
-
Submit an issue
Please select the type of issue you want to report and fill in the issue content according to the template requirements.
Ask a question - Please elaborate on the problem you encountered, the results you expected, and the results you actually saw, so community participants can better understand your problem and come up with a solution faster.Report a bug - In addition to clarifying the problem, the expected behaviour, and the actual behaviour, the steps to reproduce the bug should also be described, and the java-tron log and backtrace when the problem occurs should be attached.Request a feature - Please clarify why should this feature exist\uff0cwhat are the use-cases\uff0cdo you have ideas regarding the implementation of this feature and are you willing to implement this feature.
"},{"location":"developers/issue-workflow/#issue-handling-process","title":"Issue Handling Process","text":"The issue handling process is as follows:
- Tag Issues - We hold weekly meetings to categorize Issues and tag Issues with appropriate Labels.
- Assign an Issue - Assign an Issue to one or several community core developers, and the core developers will participate in Issue investigations and discussions.
- Community Discussion - anyone can participate in the investigation and discussion of the Issue, and write their thoughts or opinions in the comments, and the solution to the problem can be obtained from the community discussion.
- Close the Issue - Issue submitters can close the Issue at any time. When the issue is resolved, or it has not been discussed by the community for a long time, we will close the Issue. Issue submitters or other users can also reopen the Issue as needed.
"},{"location":"developers/issue-workflow/#issue-labels","title":"Issue Labels","text":"Use the following labels according to the Issue feature:
- topic
topic: Block/Transactiontopic: Buildtopic: Consensustopic: DBtopic: Deploymenttopic: Documentationtopic: Event subscribetopic: gRPC/HTTP apitopic: Nettopic: Performancetopic: Resource managetopic: Shielded Transactiontopic: Smart contracttopic: Soliditytopic: Testnet/Privatenet
-
type
type: Announcementtype: Bugtype: Enhancementtype: Feature Requesttype: Manualtype: Othertype: Question
-
resolution
resolution: Duplicatedresolution: Needs More Informationresolution: Wontfix
improvement
"},{"location":"developers/java-tron/","title":"Developer Guide","text":"Thank you for considering to help out with the source code! We welcome contributions from anyone, and are grateful for even the smallest of fixes!
GitHub is used to track issues and contribute code, suggestions, feature requests or documentation. If you want to participate in java-tron development, please follow the Github code submission process as follows:
- Fork java-tron repository
- Fix the code
- Commit the code
- Send a pull request
- The maintainers review and merge into the main code base
For small fixes, you can send a pull request (PR) directly, but make sure the PR includes a detailed description. For more complex changes, you need to submit an issue to the TIP repository detailing your motivations, implementation plans, etc. For how to submit a TIP issue, please refer to TIP Specification.
We encourage java-tron developers to submit PRs as soon as possible. Even if they are not fully developed, you can submit a PR first, so that other developers can know that the TIP Issue corresponding to this PR is in the state of In Progress.
Developers should develop and submit a PR based on the develop branch, reviewers will review the PR according to Code Review Guidelines.
"},{"location":"developers/java-tron/#key-branches","title":"Key Branches","text":"java-tron only has master, develop, release-*, feature-*, and hotfix-* branches, which are described below:
-
develop branch
The develop branch only accepts merge requests from other forked branches orrelease_* branches. It is not allowed to directly push changes to the develop branch. A release_* branch has to be pulled from the develop branch when a new build is to be released.
-
master branch
release_* branches and hotfix/* branches should only be merged into the master branch when a new build is released.
-
release branch
release_* is a branch pulled from the develop branch for release. It should be merged into master after a regression test and will be permanently kept in the repository. If a bug is identified in a release_* branch, its fixes should be directly merged into the release_* branch. After the fixes passing the regression test, the release_* branch should be merged back into the develop branch. Essentially, a release_* branch serves as a snapshot for each release.
-
feature branch
feature/* is an important feature branch pulled from the develop branch. After the feature/* branch is code-complete, it should be merged back to the develop branch. The feature/* branch is maintainable.
-
hotfix branch
It is pulled from the master branch and should be merged back into the master branch and the develop branch. Only pull requests of the fork repository (pull requests for bug fixes) should be merged into the hotfix/ branch. hotfix/ branches are used only for fixing bugs found after release.
"},{"location":"developers/java-tron/#submitting-code","title":"Submitting Code","text":"If you want to contribute codes to java-tron, please follow the following steps:
-
Fork java-tron repository
Fork a new repository from tronprotocol/java-tron to your personal code repository
$ git clone https://github.com/yourname/java-tron.git\n\n$ git remote add upstream https://github.com/tronprotocol/java-tron.git (\"upstream\" refers to upstream projects repositories, namely tronprotocol's repositories, and can be named as you like it. We usually call it \"upstream\" for convenience) \n
-
Edit the code in the fork repository
Before developing new features, please synchronize your fork repository with the upstream repository.
git fetch upstream \ngit checkout develop \ngit merge upstream/develop --no-ff (Add --no-ff to turn off the default fast merge mode)\n
Pull a new branch from the develop branch of your repository for local development. Please refer to Branch Naming Conventions\u3002
git checkout -b feature/branch_name develop\n
Write and commit the new code when it is completed. Please refer to Commit Messages
git add .\ngit commit -m 'commit message'\n
Commit the new branch to your personal remote repository
git push origin new_feature\n
-
Push code
Submit a pull request (PR) from your repository to tronprotocol/java-tron. Please be sure to click on the link in the red box shown below. Select the base branch for tronprotocol and the compare branch for your personal fork repository.
"},{"location":"developers/java-tron/#code-review-guidelines","title":"Code Review Guidelines","text":"The only way to get code into java-tron is to send a pull request. Those pull requests need to be reviewed by someone. The following guide explains our expectations around PRs for both authors and reviewers.
"},{"location":"developers/java-tron/#the-process","title":"The Process","text":"The first decision to make for any PR is whether it\u2019s worth including at all. To make the decision we must understand what the PR is about. If there isn\u2019t enough description content or the diff is too large, request an explanation. Anyone can do this part.
We expect that reviewers check the style and functionality of the PR, providing comments to the author using the GitHub review system. Reviewers should follow up with the PR until it is in good shape, then approve the PR. Approved PRs can be merged by the code maintainer.
When communicating with authors, be polite and respectful.
"},{"location":"developers/java-tron/#functional-checks","title":"Functional Checks","text":"For PRs that fix an issue, reviewers should try reproduce the issue and verify that the pull request actually fixes it. Authors can help with this by including a unit test that fails without (and passes with) the change.
For PRs adding new features, reviewers should attempt to use the feature and comment on how it feels to use it. For example: if a PR adds a new command line flag, use the program with the flag and comment on whether the flag feels useful.
We expect appropriate unit test coverage. Reviewers should verify that new code is covered by unit tests.
"},{"location":"developers/java-tron/#code-style","title":"Code Style","text":"We would like all developers to follow a standard development flow and coding style. Therefore, we suggest the following:
- Review the code with coding style checkers.
- Review the code before submission.
- Run standardized tests.
Sonar-scanner and Travis CI continuous integration scanner will be automatically triggered when a pull request has been submitted. When a PR passes all the checks, the java-tron maintainers will then review the PR and offer feedback and modifications when necessary. Once adopted, the PR will be closed and merged into the develop branch.
We are glad to receive your pull requests and will try our best to review them as soon as we can. Any pull request is welcome, even if it is for a typo.
Please kindly address the issue you find. We would appreciate your contribution.
Please do not be discouraged if your pull request is not accepted, as it may be an oversight. Please explain your code as detailed as possible to make it easier to understand.
Please make sure your submission meets the following code style:
- The code must conform to Google Code Style.
- The code must have passed the Sonar scanner test.
- The code has to be pulled from the
develop branch.
"},{"location":"developers/java-tron/#branch-naming-conventions","title":"Branch Naming Conventions","text":"Branch naming should follow the following guidelines:
- Always name the
master branch and develop branch as \"master\" and \"develop\". - Name the
release_* branch using version numbers, which are assigned by the project lead (e.g., Odyssey-v3.1.3, 3.1.3, etc.). - Use
hotfix/ as the prefix of the hotfix branch, briefly describe the bug in the name, and connect words with underline (e.g., hotfix/typo, hotfix/null_point_exception, etc.). - Use
feature/ as the prefix of the feature branch, briefly describe the feature in the name, and connect words with underline (e.g., feature/new_resource_model, etc.).
"},{"location":"developers/java-tron/#pull-request-guidelines","title":"Pull Request Guidelines","text":"Pull Requests should follow the following specifications:
- Create one PR for one issue.
- Avoid massive PRs.
- Write an overview of the purpose of the PR in its title.
- Write a description of the PR for future reviewers.
- Elaborate on the feedback you need (if any).
"},{"location":"developers/java-tron/#commit-messages","title":"Commit Messages","text":"Commit messages should follow the rule below, we provide a template with corresponding instructions.
Template:
<commit type>(<scope>): <subject>\n<BLANK LINE>\n<body>\n<BLANK LINE>\n<footer>\n
The message header is a single line that contains a succinct description of the change containing a commit type, an optional scope and a subject.
commit type describes the kind of change that this commit is providing: * feat (new feature) * fix (bug fix) * docs (changes to documentation) * style (formatting, missing semi colons, etc. no code change) * refactor (refactoring production code) * test (adding or refactoring tests. no production code change) * chore (updating grunt tasks etc. no production code change)
The scope can be anything specifying place of the commit change. For example:protobuf,api,test,docs,build,db,net.You can use * if there isn't a more fitting scope.
The subject contains a succinct description of the change: 1. Limit the subject line, which briefly describes the purpose of the commit, to 50 characters. 2. Start with a verb and use first-person present-tense (e.g., use \"change\" instead of \"changed\" or \"changes\"). 3. Do not capitalize the first letter. 4. Do not end the subject line with a period. 5. Avoid meaningless commits. It is recommended to use the git rebase command.
Message body use the imperative, present tense: \"change\" not \"changed\" nor \"changes\". The body should include the motivation for the change and contrast this with previous behavior.
Here is an example:
feat(block): optimize the block-producing logic\n\n1. increase the priority that block producing thread acquires synchronization lock\n2. add the interruption exception handling in block-producing thread\n\nCloses #1234\n
If the purpose of this submission is to modify one issue, you need to refer to the issue in the footer, starting with the keyword Closes, such as Closes #1234, if multiple bugs have been modified, separate them with commas, such as Closes #123, #245, #992."},{"location":"developers/java-tron/#special-situations-and-how-to-deal-with-them","title":"Special Situations And How To Deal With Them","text":"As a reviewer, you may find yourself in one of the situations below. Here\u2019s how to deal with those:
- The author doesn\u2019t follow up: ping them after a while (i.e. after a few days). If there is no further response, close the PR or complete the work yourself.
- Author insists on including refactoring changes alongside bug fixes: We can tolerate small refactorings alongside any change. If you feel lost in the diff, ask the author to submit the refactoring as an independent PR, or at least as an independent commit in the same PR.
- Author keeps rejecting your feedback: You may close the PR.
"},{"location":"developers/java-tron/#conduct","title":"Conduct","text":"While contributing, please be respectful and constructive, so that participation in our project is a positive experience for everyone.
Examples of behavior that contributes to creating a positive environment include:
- Using welcoming and inclusive language Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members
Examples of unacceptable behavior include:
- The use of sexualized language or imagery and unwelcome sexual attention or advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others\u2019 private information, such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
"},{"location":"developers/run-in-idea/","title":"Configure the IntelliJ IDEA IDE","text":"For Java development, in order to reduce development difficulty and improve development efficiency, developers should first select and configure a Java integrated development environment, such as IntelliJ IDEA, NetBeans or Eclipse, etc. This article will take InteliJ IDEA as an example to introduce how to configure java-tron integration development environment.
This article describes the configuration of the java-tron integrated development environment in InteliJ IDEA. java-tron nodes support to be deployed on Linux or MacOS operating systems, and rely on Oracle JDK 1.8, other versions of JDK are not supported. Before configuring the InteliJ IDE development environment, please ensure the following prerequisites:
- Configure the development environment on
Linux or MacOS operating system Oracle JDK 1.8, git, InteliJ IDEA are installed
"},{"location":"developers/run-in-idea/#configure-intelij-idea","title":"Configure InteliJ IDEA","text":"The IntelliJ IDEA configuration steps are as follows:
-
Install Lombok plugin
Search for lombok in [IDEA]->[Preferences]->[Plugins] to install Lombok plugin, Lombok makes java-tron code more concise by adding annotations.
-
Enable Enable annotation processing configuration item
-
Check the JDK version and make sure that Oracle JDK 1.8 is used in IntelliJ IDEA
-
Download java-tron source code
Clone the java-tron source code locally and switch to the develop branch.
$ git clone https://github.com/tronprotocol/java-tron.git\n$ git checkout -t origin/develop\n
"},{"location":"developers/run-in-idea/#configure-the-code-style-check-plugin","title":"Configure the code style check plugin","text":"The java-tron code style needs to meet the Google check style specification. In IDEA, you can use the Checkstyle plugin to check whether the code conforms to the Google check style specification. The installation and configuration process of the plugin is as follows:
-
Search for checkstyle in [IDEA]->[Preferences]->[Plugins] to install the plugin
-
Code style configuration
First, download the java-tron code style check configuration file, then in the Checkstyle configuration page, click \"+ \", choose to use the \"checkStyleAll.xml\" just downloaded, after adding that, you can see this file in the \"Configuration Files\" list, and finally click \"Apply\" to complete the configuration.
After configuring the Checkstyle plugin, you can use Checkstyle to check the code. Checkstyle can check a module or the whole project, and can also check a single file. Select \"Check Current File\" in the right-click menu of the file editor, and Checkstyle will check the file. If a code problem is detected, you need to modify it according to the prompts. Code can only be submitted when there are no code problems.
"},{"location":"developers/run-in-idea/#compile-java-tron","title":"Compile java-tron","text":"You can use the terminal to compile java-tron with the following command in the java-tron project directory:
$ ./gradlew clean build\n
The above compile command will execute all test cases, you can use -x test to skip the execution of test cases: $ ./gradlew clean build -x test\n
You can also compile java-tron in IDEA: Open the java-tron project in IDEA and click \"Build\" -> \"Build Project\" to compile the project.
"},{"location":"developers/run-in-idea/#run-and-debug","title":"Run and Debug","text":"Before running java-tron, you need to create a working directory to store the database files and log files generated when the node is running.
$ mkdir /Users/javatrondeploy\n
In the \"Run/Debug Configurations\" configuration panel, specify the JDK version running java-tron as java 8, and then configure the command parameters for running java-tron, for example, specify the node configuration file through the -c parameter as config.conf.
\"Working directory\" is configured as the working directory of java-tron created earlier. When java-tron starts, it will look for the config.conf configuration file in this directory. Please make sure that config.conf has already been in this directory.
After the setting, click the \"Apply\" button to complete the configuration. Then you can click \"Run\"->\"Run FullNode\" in IDEA to start the java-tron node or click \"Run\"->\"Debug FullNode\" to start the node in debug mode. After the node is started, java-tron logs are stored in the working directory.
If you want to debug the java-tron code, you can set breakpoints in the java-tron code and start it in debug mode, so that you can trace the debug code line by line.
"},{"location":"developers/tips/","title":"TRON Improvement Proposals (TIPs)","text":"TIP stands for TRON Improvement Proposal. TIPs record the entire process of TRON improvement, including the process of community making suggestions, discussions, and adoption. A TIP is a design document about a proposal, including the rationale and technical specifications of the proposal. Community users can read the TIP document to learn more about the proposal.
TIPs are the unit around which governance happens in TRON\uff0canyone is free to propose one, and then community participants will debate to determine if it should be adopted as a standard or included in a network upgrade. The TIP author is responsible for building consensus within the community and documenting dissenting opinions.
"},{"location":"developers/tips/#tip-types","title":"TIP Types","text":"TIPs are mainly divided into Standard Track and Informational:
-
Standard Track : Describes any change that affects most or all TRON implementations, such as a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using TRON. Furthermore, Standard TIPs can be broken down into the following categories.
Core: Improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to \"core dev\" discussions.Networking: Improvements around network protocol.Interface: Improvements around client API/RPC specifications and standards.TRC\uff1aApplication-level standards and conventions, including contract standards such as token standards (TRC-20).TVM\uff1amprovements around TRON Virtual Machine.
-
Informational: Describes a TRON design issue, or provides general guidelines or information to the TRON community, but does not propose a new feature.
"},{"location":"developers/tips/#tip-work-flow","title":"TIP Work Flow","text":"Before you submit a TIP, you need to create an issue for comment and add the issue URL to your TIP header. The format of a TIP issue is consistent with the content of TIP. The process of submitting TIP is as follows:
- Fork the TIP repository by clicking \"Fork\" in the top right.
- Add your TIP to your fork of the repository. There is a TIP template here.
- Submit a Pull Request to TRON's TIPs repository.
Please use markdown to write TIP in strict accordance with the requirements of template. Make sure you include a discussions-to header with the URL to a discussion forum or open GitHub issue where people can discuss the TIP as a whole. If a TIP is about the feature development of java-tron, and a PR of the development exists, in your TIP and your java-tron's PR you need to refer each other's github link to make the requirements analysis of new features and development code traceable.
Your first PR for a new TIP will be in the state of draft. It must meet the formatting criteria enforced by the build. An editor will manually review it and assign it a number before merging it.
When you believe your TIP is mature and ready to progress past the draft phase, you should do one of two things:
- For a Standards Track TIP of type Core, ask to have your issue added to the agenda of an upcoming All Core Devs meeting, where it can be discussed for inclusion in a future hard fork. If core devs agree to include it, the TIP editors will update the state of your TIP to
Accepted. - For all other TIPs, open a PR changing the state of your TIP to
Final(non-Core). An editor will review your draft and ask if anyone objects to its being finalized. If the editor decides there is no rough consensus, they may close the PR and request you fix the issues in the draft before trying again.
"},{"location":"developers/tips/#tip-status","title":"TIP Status","text":"A TIP may go through the following states:
Draft: A TIP that is undergoing rapid iteration and changes.Last Call: A TIP that is done with its initial iteration and ready for review by a wide audience.Accepted: A core TIP that has been in the Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode a TIP into their clients as part of a hard fork is not part of the TIP process. If such a decision is made, the TIP will move to the final.Final (non-Core): A TIP that has been in the Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. Final (Core): A TIP that the Core Devs have decided to implement and release in a future version or has already been released.Active: If the TIPs are never meant to be completed, the TIPs may have a status of Active.Abandoned: If a TIP is no longer pursued by the original authors or it may not be a (technically) preferred option anymore.Rejected: A TIP that is fundamentally broken or a Core TIP that was rejected by the Core Devs and will not be implemented.Superseded: A TIP which was previously Final but is no longer considered state-of-the-art. Another TIP will be in the Final status and cite the Superseded TIP.Deferred: A TIP which isn't accepted now, may be accepted in the future.
"},{"location":"developers/tips/#tip-structure","title":"TIP Structure","text":"A TIP consists of a title preamble and body content.
"},{"location":"developers/tips/#tip-header-preamble","title":"TIP Header Preamble","text":"The TIP header preamble contains the TIP number, a short descriptive title (limited to a maximum of 44 characters), author details, discussion link, TIP status, TIP type, creation time, etc. Please refer to the specific format:
---\ntip: <to be assigned>\ntitle: <TIP title>\nauthor: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s), e.g. (use with the parentheses or triangular brackets): FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>\ndiscussions-to: <URL>\nstatus: <Draft | Last Call | Accepted | Final | Deferred>\ntype: <Standards Track (Core, Networking, Interface, TRC, VM) | Informational>\ncategory (*only required for Standard Track): <Core | Networking | Interface | TRC | VM>\ncreated: <date created on, in ISO 8601 (yyyy-mm-dd) format>\nrequires (*optional): <TIP number(s)>\nreplaces (*optional): <TIP number(s)>\n--- \n
"},{"location":"developers/tips/#tip-body","title":"TIP Body","text":"TIP body should have the following parts:
Simple Summary\uff1aProvide a simplified explanation of the TIP.Abstract\uff1a A short (~200 word) description of the technical issue being addressed. It should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.Motivation: (optional) A motivation section is critical for TIPs. It should clearly explain why the existing protocol specification is inadequate to address the problem that the TIP solves. This section may be omitted if the motivation is evident.Specification\uff1aThe technical specification should detail the syntax and semantics of any new feature.Rationale\uff1aThe rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should discuss important objections or concerns raised during the discussion around the TIP.Backwards Compatibility \uff1a(optional) All TIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their consequences. The TIP must explain how the author proposes to deal with these incompatibilities. Test Cases \uff1a(optional) Test cases for an implementation are mandatory for TIPs that are affecting consensus changes. This section may be omitted for non-Core proposals.Implementation\uff1aThe implementations must be completed before any TIP is given the status Final, but it need not be completed before the TIP is accepted. The principle of \"rough consensus and running code\" is still useful when it comes to resolving many discussions of API details.
"},{"location":"developers/tips/#linking-to-external-resources","title":"Linking to External Resources","text":"Links to external resources SHOULD NOT be included. External resources may disappear, move, or change unexpectedly.
"},{"location":"developers/tips/#linking-to-other-tips","title":"Linking to other TIPs","text":"References to other TIPs should follow the format TIP-N where N is the TIP number you are referring to. Each TIP that is referenced in a TIP MUST be accompanied by a relative markdown link. The link MUST always be done via relative paths so that the links work in TIP GitHub repository and forks of TIP repository. For example, you would link to TIP-1 with [TIP-1](/TIPS/tip-1).
"},{"location":"developers/tips/#auxiliary-files","title":"Auxiliary Files","text":"Images, diagrams and auxiliary files should be included in a subdirectory of the assets folder for that TIP as follows: assets/tip-N (where N is to be replaced with the TIP number). When linking to an image in the TIP, use relative links such as ../assets/tip-1/image.png.
"},{"location":"getting_started/getting_started_with_javatron/","title":"Getting Started with java-tron","text":"This page mainly explains how to start the java-tron node and use the command line tool wallet-cli to execute basic commands to interact with the java-tron node. Regarding the installation of java-tron, you can download the runnable file directly or build it from source code. Instructions for installing java-tron can be found on the Install and Build page. This tutorial on this page assumes java-tron and associated developer tools have been successfully installed.
This page covers the basics of using java-tron, which includes generating accounts, joining the TRON Nile testnet, and sending TRX between accounts. wallet-cli is also used in this document. wallet-cli is a command-line tool of the TRON network. This tool provides user interactive commands, which can be used to interact with java-tron more conveniently.
java-tron is a TRON network client written in Java. This means a computer running java-tron will become a TRON network node. TRON is a distributed network where information is shared directly between nodes rather than being managed by a central server. After the super representative's node generates a new block, it will send the block to its peers. On receiving a new block, each node checks that it is valid and adds it to their database. java-tron uses the information provided by each block to update its \"state\" - the balance of each account on the TRON network. There are two types of accounts on the TRON network: externally owned accounts and contract accounts. The contract account executes the contract code when a transaction is received. An external account is an account that a user manages locally in order to sign and submit transactions. Each external account is a public-private key pair, where the public key is used to derive a unique address for the user, and the private key is used to protect the account and securely sign messages. Therefore, in order to use the TRON network, it is first necessary to generate an external account (hereinafter referred to as \"account\"). This tutorial will guide users on how to create an account, deposit TRX tokens, and transfer TRX.
"},{"location":"getting_started/getting_started_with_javatron/#generate-account","title":"Generate account","text":"There are various ways to generate a TRON network account, here we will demonstrate how to generate an account using wallet-cli. An account is a pair of keys (public and private keys).
Enter the command java -jar wallet-cli.jar in the terminal to start a wallet-cli:
$ java -jar wallet-cli.jar\n\nWelcome to TRON wallet-cli\nPlease type one of the following commands to proceed.\nLogin, RegisterWallet or ImportWallet\n\nYou may also use the Help command at anytime to display a full list of commands.\n\nwallet> \n
Enter the command: registerwallet, and then enter the password as prompted. This command will generate a TRON network account and register it with wallet-cli, that is, wallet-cli will save the private key of this account, and then you can use the private key to sign transactions.
wallet> registerwallet\nPlease input password.\npassword: \nuser defined config file doesn't exists, use default config file in jar\nWalletApi getRpcVsersion: 2\nPlease input password again.\npassword: \nRegister a wallet successful, keystore file name is UTC--2022-07-04T06-35-35.304000000Z--TQXjm2J8K2DKTV49MdfT2anjUehbU3WDJz.json\nwallet> \n
"},{"location":"getting_started/getting_started_with_javatron/#login-wallet-cli","title":"Login wallet-cli","text":"After the registration is complete, enter the login command to log in to wallet-cli.
wallet> login\n
Select the account you want to login, and then enter the password. If the password is entered correctly, you will see the following result to the terminal: \"Login successful !!!\".
Please choose between 1 and 3\n2\nPlease input your password.\npassword: \nLogin successful !!!\nwallet> \n
After logging in, you can view the login account address through the getaddress command:
wallet> getaddress\nGetAddress successful !!\naddress = TQXjm2J8K2DKTV49MdfT2anjUehbU3WDJz\nwallet> \n
Then you can use the backupwallet command to view the private key of the account, you need to enter the password according to the prompt. It is recommended to save the private key."},{"location":"getting_started/getting_started_with_javatron/#run-a-java-tron-node","title":"Run a java-tron node","text":"java-tron is a TRON network client that enables computers to connect to the TRON network. The network in this tutorial refers to the TRON Nile testnet. To start java-tron, you need first obtain the java-tron executable file, please refer to the Installation and Deployment chapter, and then run the following command to start java-tron.
$ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c nile_net_config.conf\n
After java-tron starts, the logs will include the following: 11:07:58.758 INFO [main] [app](Args.java:1143) ************************ Net config ************************\n11:07:58.758 INFO [main] [app](Args.java:1144) P2P version: 201910292\n11:07:58.758 INFO [main] [app](Args.java:1145) Bind IP: 192.168.20.101\n11:07:58.758 INFO [main] [app](Args.java:1146) External IP: 203.12.203.3\n11:07:58.758 INFO [main] [app](Args.java:1147) Listen port: 18888\n11:07:58.758 INFO [main] [app](Args.java:1148) Discover enable: true\n
The above logs indicate that java-tron has started and connected to the Nile testnet, then it will look for peers to connect to. Once it has found peers, it can request blocks from them, and the logs confirm this:
11:08:42.547 INFO [TronJClientWorker-1] [net](Channel.java:116) Finish handshake with /123.56.3.74:18888.\n11:08:42.547 INFO [TronJClientWorker-1] [net](ChannelManager.java:161) Add active peer /123.56.3.74:18888 | fea80a0298b465a54fd332ff36819545d850115e77b327858b5306c9a58c6b8c2e7c08df76ab508a7594ed3577a8f4157727108442877077ab499b102b488467, total active peers: 1\n11:08:42.549 INFO [TronJClientWorker-1] [net](Channel.java:208) Peer /123.56.3.74:18888 status change to SYNCING.\n11:08:42.566 INFO [TronJClientWorker-1] [DB](Manager.java:1636) headNumber:23113867\n11:08:42.566 INFO [TronJClientWorker-1] [DB](Manager.java:1638) syncBeginNumber:23113867\n11:08:42.567 INFO [TronJClientWorker-1] [DB](Manager.java:1642) solidBlockNumber:23113849\n11:08:42.567 INFO [TronJClientWorker-1] [net](SyncService.java:179) Get block chain summary, low: 23113867, highNoFork: 23113867, high: 23113867, realHigh: 23113867\n11:08:42.572 INFO [TronJClientWorker-1] [net](MessageQueue.java:106) Send to /123.56.3.74:18888, type: SYNC_BLOCK_CHAIN\nsize: 1, start block: Num:23113867,ID:000000000160b08b510b6c501c980a2567bff1229eed62ca79874c9ca7828e9c \n11:08:42.631 INFO [TronJClientWorker-1] [net](MessageQueue.java:121) Receive from /123.56.3.74:18888, type: BLOCK_CHAIN_INVENTORY\nsize: 2001, first blockId: Num:23113867,ID:000000000160b08b510b6c501c980a2567bff1229eed62ca79874c9ca7828e9c, end blockId: Num:23115867,ID:000000000160b85b587ef18d00a1905d8022ec0a8fd174f3980b78f6aacf0ede\n\n......\n\n11:08:43.478 INFO [pool-49-thread-1] [net](MessageQueue.java:106) Send to /123.56.3.74:18888, type: FETCH_INV_DATA\ninvType: BLOCK, size: 100, First hash: 000000000160b08c6eeba60eced4fb13d7c56e46a3c5220a67bb2801a05e5679, End hash: 000000000160b0efd90560e389d1f6e5b3c8d3877709ce375a8e063f5db73af9 \n11:08:43.502 INFO [TronJClientWorker-1] [net](MessageQueue.java:121) Receive from /123.56.3.74:18888, type: BLOCK\nNum:23113868,ID:000000000160b08c6eeba60eced4fb13d7c56e46a3c5220a67bb2801a05e5679, trx size: 1\n\n11:08:43.504 INFO [TronJClientWorker-1] [net](MessageQueue.java:121) Receive from /123.56.3.74:18888, type: BLOCK\nNum:23113869,ID:000000000160b08d231e450ae1993a72ba19eb8f3c748fa70d105dadd0c9fd5f, trx size: 0\n\n11:08:43.504 INFO [TronJClientWorker-1] [net](MessageQueue.java:121) Receive from /123.56.3.74:18888, type: BLOCK\nNum:23113870,ID:000000000160b08e37cb9951d31a4233f106c7e77e0535c597dbb6a16f163699, trx size: 0\n
These logs show that java-tron is running as expected. You can determine whether the node has been started and check the status of the node by sending the following http request to the java-tron node:
$ curl http://127.0.0.1:16887/wallet/getnodeinfo\n
If no error messages are reported in the node logs, everything is fine. In order for users to interact with the TRON network, the java-tron node must be running and in a normal state of synchronization. Whether the node is synchronized with other nodes in the network, you can query the current block height in Tronscan and compare it with the result of the local java-tron node /wallet/getnowblock. If they are equal, it means that the synchronization status of the local node is normal. If you want to shut down java-tron node, please use this command: kill -15 process id.
"},{"location":"getting_started/getting_started_with_javatron/#obtain-trx","title":"Obtain TRX","text":"In order to make some transactions, the user must fund their account with TRX. On TRON mainnet, TRX can only be obtained in three ways: 1. Rewards for block production by SRs/rewards for voting for SRs\uff1b 2. Another TRON account transfers TRX to it; 3. Obtained from the exchange.
In the TRON testnet, TRX has no real value and can be obtained for free through faucet.
"},{"location":"getting_started/getting_started_with_javatron/#interact-with-java-tron-node","title":"Interact with java-tron node","text":""},{"location":"getting_started/getting_started_with_javatron/#interact-by-using-wallet-cli","title":"Interact by using wallet-cli","text":"java-tron provides http interface and grpc interface externally, which is convenient for users to interact with TRON network. wallet-cli uses the grpc interface.
"},{"location":"getting_started/getting_started_with_javatron/#get-account-information","title":"Get account information","text":"After entering the getaccount command in wallet-cli, it will request account information data from the java-tron node, and then display the result in the terminal.
wallet> getaccount TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\n
Result: {\n \"address\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"balance\": 93643857919,\n \"create_time\": 1619681898000,\n \"latest_opration_time\": 1655358327000,\n \"is_witness\": true,\n \"asset_issued_name\": \"TestTRC10T\",\n \"latest_consume_free_time\": 1652948766000,\n \"account_resource\": {\n \"latest_consume_time_for_energy\": 1655358327000\n },\n\n ......\n}\n
"},{"location":"getting_started/getting_started_with_javatron/#get-account-balance","title":"Get account balance","text":"Get the balance of an account with the getbalance command:
wallet> getbalance\nBalance = 93642857919\nwallet> \n
"},{"location":"getting_started/getting_started_with_javatron/#transferring-trx","title":"Transferring TRX","text":"To transfer TRX through the sendcoin command, enter the transfer address, and the amount:
wallet> sendcoin TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf 1000000\n{\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"amount\":1000000,\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"to_address\":\"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\"\n },\n \"type_url\":\"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\":\"TransferContract\"\n }\n ],\n \"ref_block_bytes\":\"cbc3\",\n \"ref_block_hash\":\"8581ae7e29258a52\",\n \"expiration\":1656917577000,\n \"timestamp\":1656917518232\n },\n \"raw_data_hex\":\"0a02cbc322088581ae7e29258a5240a89aefbf9c305a67080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca121541d0b69631440f0a494bb51f7eee68ff5c593c00f018c0843d7098cfebbf9c30\"\n}\nbefore sign transaction hex string is 0a85010a02cbc322088581ae7e29258a5240a89aefbf9c305a67080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca121541d0b69631440f0a494bb51f7eee68ff5c593c00f018c0843d7098cfebbf9c30\nPlease confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\n
This command returns the transaction of transferring TRX. After confirmation, enter y to confirm, and other letters indicate to cancel the transaction. If you enter y, then according to the prompt, choose which account's private key to use for signing, and finally enter the password to complete the signing of the transaction, and wallet-cli will send the signed transaction to the java-tron node.
Please confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction.\ny\nPlease choose your key for sign.\nThe 1th keystore file name is .DS_Store\nThe 2th keystore file name is UTC--2022-07-04T06-35-35.304000000Z--TQXjm2J8K2DKTV49MdfT2anjUehbU3WDJz.json\nThe 3th keystore file name is UTC--2022-06-21T09-51-26.367000000Z--TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM.json\nPlease choose between 1 and 3\n3\nPlease input your password.\npassword: \nafter sign transaction hex string is 0a85010a02cbc322088581ae7e29258a5240dbfc91ca9c305a67080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca121541d0b69631440f0a494bb51f7eee68ff5c593c00f018c0843d7098cfebbf9c301241241a3ce4797ccc2fedf49ae41af28b49df1e15a476e4948af4df5aadf23a1e940ad5cc2133f501c08f2bab6a2231cdc82a745fed0fc6a012dc19310532d9138600\ntxid is 21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4\nSend 1000000 Sun to TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf successful !!\nwallet> \n
"},{"location":"getting_started/getting_started_with_javatron/#query-transaction-by-transaction-id","title":"Query transaction by transaction id","text":"The above step sends a transferring TRX transaction through the sendcoin command, and prints the id of the transaction on the wallet-cli terminal:21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4. Next, you can query the transaction through gettransactionbyid, or query the result of the transaction through gettransactioninfobyid.
wallet> gettransactionbyid 21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4\n{\n \"ret\":[\n {\n \"contractRet\":\"SUCCESS\"\n }\n ],\n \"signature\":[\n \"241a3ce4797ccc2fedf49ae41af28b49df1e15a476e4948af4df5aadf23a1e940ad5cc2133f501c08f2bab6a2231cdc82a745fed0fc6a012dc19310532d9138600\"\n ],\n \"txID\":\"21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4\",\n \"raw_data\":{\n \"contract\":[\n {\n \"parameter\":{\n \"value\":{\n \"amount\":1000000,\n \"owner_address\":\"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"to_address\":\"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\"\n },\n \"type_url\":\"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\":\"TransferContract\"\n }\n ],\n \"ref_block_bytes\":\"cbc3\",\n \"ref_block_hash\":\"8581ae7e29258a52\",\n \"expiration\":1656939118171,\n \"timestamp\":1656917518232\n },\n \"raw_data_hex\":\"0a02cbc322088581ae7e29258a5240dbfc91ca9c305a67080112630a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412320a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca121541d0b69631440f0a494bb51f7eee68ff5c593c00f018c0843d7098cfebbf9c30\"\n}\nwallet> \n
wallet> gettransactioninfobyid 21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4\n{\n \"id\": \"21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca145adcd464ea155a4\",\n \"blockNumber\": 27773932,\n \"blockTimeStamp\": 1656917586000,\n \"contractResult\": [\n \"\"\n ],\n \"receipt\": {\n \"net_usage\": 267\n }\n}\nwallet> \n
"},{"location":"getting_started/getting_started_with_javatron/#interact-by-using-curl","title":"Interact by using Curl","text":"The above describes how to use wallet-cli to interact with java-tron. Compared with sending grpc/http commands directly, this tool provides more friendly interactive commands, allowing users to send commands to java-tron more conveniently. But, how to send HTTP requests directly to the java-tron node? Curl is a command line tool for sending HTTP requests. This chapter will explain how to check account balances and send transactions through Curl.
"},{"location":"getting_started/getting_started_with_javatron/#get-account-balance_1","title":"Get account balance","text":"You can query the TRX balance information of the account through the node HTTP interface wallet/getaccount. The balance field in the returned result is the TRX balance, in sun:
curl -X POST http://127.0.0.1:16887/wallet/getaccount -d \n '{\"address\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"visible\": true\n }'\n
Result\uff1a {\"account_name\": \"testacc2\",\"address\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\"balance\": 1000000000000000,\"account_resource\": {}}\n
"},{"location":"getting_started/getting_started_with_javatron/#send-transactions","title":"Send transactions","text":"Sending a transaction through the http interface requires a total of three steps:
- Create a transaction
- Sign the transaction
- Broadcast transaction
The following takes the transferring TRX as an example to illustrate how to send a transaction to java-tron node.
Create an unsigned TRX transferring transaction through the fullnode HTTP interface wallet/createtransaction:
curl -X POST http://127.0.0.1:16887/wallet/createtransaction -d \n '{\n \"to_address\": \"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\", \n \"owner_address\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\", \n \"amount\": 10000000,\n \"visible\":true\n }'\n
Returns an unsigned TRX transferring transaction: {\n \"visible\": true,\n \"txID\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\",\n \"raw_data\": {\n \"contract\": [\n {\n \"parameter\": {\n \"value\": {\n \"amount\": 10000000,\n \"owner_address\": \"TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1\",\n \"to_address\": \"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\"\n },\n \"type_url\": \"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\": \"TransferContract\"\n }\n ],\n \"ref_block_bytes\": \"193b\",\n \"ref_block_hash\": \"aaecd88e4e0e7528\",\n \"expiration\": 1656580476000,\n \"timestamp\": 1656580418228\n },\n \"raw_data_hex\": \"0a02193b2208aaecd88e4e0e752840e098909f9b305a68080112640a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412330a154198927ffb9f554dc4a453c64b2e553a02d6df514b121541d0b69631440f0a494bb51f7eee68ff5c593c00f01880ade20470b4d58c9f9b30\"\n}\n
Then sign the transaction offline. Finally, Broadcast the signed transaction to the java-tron node through the wallet/broadcasttransaction interface to complete the sending of the TRX transferring transaction.
curl --location --request POST 'http://127.0.0.1:16887/wallet/broadcasttransaction' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"visible\": true,\n \"signature\": [\n \"e12996cfaf52f8b49e64400987f9158a87b1aa809a11a75e01bb230722db97a26204334aea945b1ece0851a89c96459872e56229b0bd725c4f6a0577bfe331c301\"\n ],\n \"txID\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\",\n \"raw_data\": {\n \"contract\": [\n {\n \"parameter\": {\n \"value\": {\n \"amount\": 10000000,\n \"owner_address\": \"TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1\",\n \"to_address\": \"TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf\"\n },\n \"type_url\": \"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\": \"TransferContract\"\n }\n ],\n \"ref_block_bytes\": \"193b\",\n \"ref_block_hash\": \"aaecd88e4e0e7528\",\n \"expiration\": 1656580476000,\n \"timestamp\": 1656580418228\n },\n \"raw_data_hex\": \"0a02193b2208aaecd88e4e0e752840e098909f9b305a68080112640a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412330a154198927ffb9f554dc4a453c64b2e553a02d6df514b121541d0b69631440f0a494bb51f7eee68ff5c593c00f01880ade20470b4d58c9f9b30\"\n}'\n
Result\uff1a {\n \"result\": true,\n \"txid\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\"\n}\n
The return result is true, indicating that the transaction broadcast was successful."},{"location":"getting_started/getting_started_with_javatron/#query-transaction-by-transaction-id_1","title":"Query transaction by transaction id","text":"Query the content of the transaction through the http interface wallet/gettransactionbyid:
curl --location --request POST 'http://127.0.0.1:16887/wallet/gettransactionbyid' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"value\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\"\n}'\n
Result: {\n \"ret\": [\n {\n \"contractRet\": \"SUCCESS\"\n }\n ],\n \"signature\": [\n \"e12996cfaf52f8b49e64400987f9158a87b1aa809a11a75e01bb230722db97a26204334aea945b1ece0851a89c96459872e56229b0bd725c4f6a0577bfe331c301\"\n ],\n \"txID\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\",\n \"raw_data\": {\n \"contract\": [\n {\n \"parameter\": {\n \"value\": {\n \"amount\": 10000000,\n \"owner_address\": \"4198927ffb9f554dc4a453c64b2e553a02d6df514b\",\n \"to_address\": \"41d0b69631440f0a494bb51f7eee68ff5c593c00f0\"\n },\n \"type_url\": \"type.googleapis.com/protocol.TransferContract\"\n },\n \"type\": \"TransferContract\"\n }\n ],\n \"ref_block_bytes\": \"193b\",\n \"ref_block_hash\": \"aaecd88e4e0e7528\",\n \"expiration\": 1656580476000,\n \"timestamp\": 1656580418228\n },\n \"raw_data_hex\": \"0a02193b2208aaecd88e4e0e752840e098909f9b305a68080112640a2d747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e5472616e73666572436f6e747261637412330a154198927ffb9f554dc4a453c64b2e553a02d6df514b121541d0b69631440f0a494bb51f7eee68ff5c593c00f01880ade20470b4d58c9f9b30\"\n}\n
Query transaction results and transaction receipts through the http interface wallet/gettransactioninfobyid:
curl --location --request POST 'http://127.0.0.1:16887/wallet/gettransactioninfobyid' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"value\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\"\n}'\n
Result: {\n \"id\": \"c558bd35978267d8999baf6148703cbc94786f3f2e22893637588ca05437d7f0\",\n \"blockNumber\": 27662687,\n \"blockTimeStamp\": 1656580470000,\n \"contractResult\": [\n \"\"\n ],\n \"receipt\": {\n \"net_usage\": 268\n }\n}\n
"},{"location":"mechanism-algorithm/account/","title":"Account Model","text":""},{"location":"mechanism-algorithm/account/#introduction","title":"Introduction","text":"TRON uses the account model. The address is the unique identifier of an account, and a private key signature is required to operate an account. An account has many attributes, including TRX & TRC10 token balances, bandwidth, energy, Etc. An account can send transactions to increase or reduce its TRX or TRC10 token balances, deploy smart contracts, and trigger the smart contracts released by itself or others. All TRON accounts can apply to be Super Representatives or vote for the elected Super Representatives. Accounts are the basis of all activities on TRON.
"},{"location":"mechanism-algorithm/account/#how-to-create-an-account","title":"How to Create an Account","text":" - Use a wallet application(TronLink is recommended) to generate a pair of address and private key. To active the account, you need to transfer TRX or other token to it.
- Use an account already existed in TRON network to create an account
If you have enough staked BandWidth Points, creating an account only consume your staked BandWidth Points, otherwise, it burns 0.1 TRX.
"},{"location":"mechanism-algorithm/account/#key-pair-generation","title":"Key-pair Generation","text":"TRON signature algorithm is ECDSA, curve used is SECP256K1. Private key is a random number, public key is a point in the elliptic curve. The process is: first generate a random number d to be the private key, then calculate P = d * G as the public key, G is the elliptic curve base point.
"},{"location":"mechanism-algorithm/account/#address-format","title":"Address Format","text":"Use the public key P as the input, by SHA3 get the result H. The length of the public key is 64 bytes, SHA3 uses Keccak256. Use the last 20 bytes of H, and add a byte of 0x41 in front of it, then the address come out. Do basecheck to address, here is the final address. All addresses start with 'T'.
basecheck process: first do sha256 calculation to address to get h1, then do sha256 to h1 to get h2, use the first 4 bytes as check to add it to the end of the address to get address||check, do base58 encode to address||check to get the final result.
character map: ALPHABET = \"123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz\"
"},{"location":"mechanism-algorithm/account/#signature","title":"Signature","text":""},{"location":"mechanism-algorithm/account/#steps","title":"Steps","text":" - Get the rawdata of the transaction, then transfer it to
byte[] - Do sha256 calculation to the rawdata
- Use the private key to sign the result gained from step 2
- Add the signature back into the transaction
"},{"location":"mechanism-algorithm/account/#algorithm","title":"Algorithm","text":" - ECDSA, SECP256K
-
Example:
priKey:::8e812436a0e3323166e1f0e8ba79e19e217b2c4a53c970d4cca0cfb1078979df\npubKey::04a5bb3b28466f578e6e93fbfd5f75cee1ae86033aa4bbea690e3312c087181eb366f9a1d1d6a437a9bf9fc65ec853b9fd60fa322be3997c47144eb20da658b3d1\nhash:::159817a085f113d099d3d93c051410e9bfe043cc5c20e43aa9a083bf73660145\nr:::38b7dac5ee932ac1bf2bc62c05b792cd93c3b4af61dc02dbb4b93dacb758123f\ns:::08bf123eabe77480787d664ca280dc1f20d9205725320658c39c6c143fd5642d\nv:::0\n
Note: The size of the signature result is 65 bytes. r 32 bytes, s 32 bytes, v 1 bytes.
-
fullnode will verify the signature, it generates an address with the value of hash and r\u3001s\u3001v, then it compares with the address in the transaction.
"},{"location":"mechanism-algorithm/account/#demo","title":"Demo","text":"public static Transaction sign(Transaction transaction, ECKey myKey) {\n Transaction.Builder transactionBuilderSigned = transaction.toBuilder();\n byte[] hash = sha256(transaction.getRawData().toByteArray());\n List<Contract> listContract = transaction.getRawData().getContractList();\n\n for (int i = 0; i < listContract.size(); i++) {\n ECDSASignature signature = myKey.sign(hash);\n ByteString bsSign = ByteString.copyFrom(signature.toByteArray());\n\n // Each contract may be signed with a different private key in the future.\n transactionBuilderSigned.addSignature(bsSign);\n }\n}\n
"},{"location":"mechanism-algorithm/dex/","title":"Decentralized Exchange(DEX)","text":"TRON network supports decentralized exchange(DEX) using Bancor protocol. DEX is composed of many exchange pairs. You can find the api below in HTTP API.
"},{"location":"mechanism-algorithm/dex/#what-is-an-exchange-pair","title":"What is an Exchange Pair","text":"The term of 'Exchange Pair' describes a trade between one token with another, like A/B, A/TRX.
"},{"location":"mechanism-algorithm/dex/#exchange-pair-creation","title":"Exchange Pair Creation","text":"Any account can create an exchange pair, it burns 1024 TRX.
Please refer to 'wallet/exchangecreate'.
"},{"location":"mechanism-algorithm/dex/#exchange-pair-transaction","title":"Exchange Pair Transaction","text":"Any account can trade in the DEX. The trade follows Bancor protocol.
Please refer to 'wallet/exchangetransaction'.
"},{"location":"mechanism-algorithm/dex/#exchange-pair-injection","title":"Exchange Pair Injection","text":"The exchange pair creator can inject more tokens into the exchange pair. Injection can decrease the range of ratio fluctuation. If one token is injected, the other one will be injected automatically to keep the current ratio of the two tokens unchanged.
Please refer to 'wallet/exchangeinject'.
"},{"location":"mechanism-algorithm/dex/#exchange-pair-withdrawal","title":"Exchange Pair Withdrawal","text":"The exchange pair creator can withdraw tokens from the exchange pair. Withdrawal can increase the range of ratio fluctuation. If one token is withdrawn, the other one will be withdrawn automatically to keep the current ratio of the two tokens unchanged.
Please refer to 'wallet/exchangewithdraw'.
"},{"location":"mechanism-algorithm/dex/#query","title":"Query","text":""},{"location":"mechanism-algorithm/dex/#transaction-query","title":"Transaction Query","text":"ListExchanges: Query the list of all the exchange pairs.
GetPaginatedExchangeList: Query the list of all the exchange pairs by pagination.
GetExchangeById: Query an exchange pair by exchange pair id.
"},{"location":"mechanism-algorithm/dex/#price-calculation","title":"Price Calculation","text":"The token price is determined by the ratio of the balance of the two tokens.
"},{"location":"mechanism-algorithm/dex/#calculate-the-amount-of-token-you-can-get","title":"Calculate the Amount of Token You Can Get","text":"sellTokenQuant is the amount of the first_token you want to sell.
buyTokenQuant is the amount of second_token you can get.
supply = 1,000,000,000,000,000,000L\n\nsupplyQuant = -supply * (1.0 - Math.pow(1.0 + (double) sellTokenQuant/(firstTokenBalance + sellTokenQuant, 0.0005))\n\nbuyTokenQuant = (long)balance * (Math.pow(1.0 + (double) supplyQuant / supply, 2000.0) - 1.0)\n
"},{"location":"mechanism-algorithm/dpos/","title":"DPoS","text":""},{"location":"mechanism-algorithm/dpos/#overview","title":"Overview","text":"Blockchain is a distributed accounting system. In a blockchain system, there can be thousands of nodes, each of which independently stores the same ledger. If new transaction data is to be written into the ledger, approvals from these nodes are needed. Achieving this goal in an untrusted distributed environment is a complicated systematic quest. The blockchain system operates normally means each node in the blockchain can always keep the same ledger, provided that most nodes in the system are honest and reliable. In order to ensure that honest and reliable nodes can jointly supervise the transaction data written into the ledgers, each blockchain system needs to build its own consensus, which is equivalent to the constitution of the blockchain. As long as the vast majority of nodes comply with the consensus requirements, it is able to guarantee the results will certainly be credible, even in an untrusted distributed environment. Therefore, the significance of the consensus is that the honest nodes in the blockchain can ultimately achieve the agreement of the ledgers as long as they strictly abide by this consensus.
There are several types of consensus, and the most commonly used are POW, POS, and DPoS. Definitely, different blockchain systems will have a unique way of implementation. This article will mainly introduce the DPoS consensus on which TRON based. We will also explain the basic components and mechanisms of DPoS.
The role of consensus is to select SRs(Super Representatives) in the blockchain system. SRs(Super Representatives) verify the transaction data and keep it in a leger, then broadcast the leger to other nodes in the network and obtain the approval of the leger from other nodes. As a specific implementation of consensus, DPoS works in the following way:
The DPoS consensus selects some nodes as SRs(Super Representatives) in the blockchain system based on the number of votes they obtain. First, when the blockchain system starts to operate, a certain number of tokens will be issued, and then the tokens will be given to nodes in the blockchain system. A node can apply to be a super representative candidate in the blockchain system with a portion of the tokens. Any token-holding node in the blockchain system can vote for these candidates. Every t period of time, the votes for all the candidates will be counted. Top N candidate nodes with the most votes will become SR(Super Representatives) for the next t period. After t period of time, the votes will be counted again to elect the new SR(Super Representatives), and the cycle continues.
Let's see how it's implemented in the context of TRON:
"},{"location":"mechanism-algorithm/dpos/#definition","title":"Definition","text":" -
TRON: refers to the TRON network. The document does not distinguish between TRON, TRON blockchain, TRON blockchain system, etc.
-
TRON token: refers to the equity token issued by and circulating in TRON, known as TRX.
-
super representative candidates: nodes eligible for becoming super representatives in TRON.
-
SR(Super Representatives): nodes in TRON qualified for book-keeping. They are usually called super representatives in DPoS consensus. In TRON, there will be 27 super representatives, which are also called super nodes (or SR). Here, we will not distinguish between bookkeeper, witness, supernode, SR, etc.
-
Bookkeeping: the process of verifying transactions and recording them in a ledger. Because ledgers in TRON are carried by blocks, the bookkeeping process is also called block generation. We will not distinguish between bookkeeping and block generation in the document.
-
Bookkeeping order: block generation order. The descending order of the 27 super representatives based on the number of votes they receive.
-
Slot: In TRON, every 3 seconds is regarded as one slot. Under normal circumstances, each SR will produce a block within the corresponding slot time. Therefore, the average block interval of TRON is approximately 3 seconds. If an SR fails to produce a block for some reasons, the corresponding slot will be vacant and the next SR will produce a block in the following slot. During the maintenance period, block production will skip two slots.
-
Epoch: TRON sets an Epoch to be 6 hours. The last 2 block time of an Epoch is the maintenance period, during which block generating order for the next Epoch will be decided.
-
The maintenance period: TRON sets the period to be 2 block time, which is 6 seconds. This period of time is used to count the votes for candidates. There are 4 Epochs in 24 hours, and naturally, 4 maintenance periods. During the maintenance period, no block is generated and block generation order for the next Epoch is decided.
"},{"location":"mechanism-algorithm/dpos/#block-production-process","title":"Block Production Process","text":"The SR(Super Representatives) of the blockchain network collect the newly generated transactions in the blockchain network and verify the legality of these transactions, then package the transactions in a block, record them as a new page on the ledger, and broadcast the page to the entire blockchain network. Other nodes will receive the new page and verify the legality of the transaction data on the page and add it to their own ledger. The SR(Super Representatives) will repeat this process so all new transaction data in the blockchain system can be recorded in the ledger.
"},{"location":"mechanism-algorithm/dpos/#sr-election-mechanism","title":"SR Election Mechanism","text":" - Vote
In TRON, 1 TRX equals 1 vote.
- Voting process
In TRON, voting for candidates is a special transaction. Nodes can vote for candidates through generating a voting transaction.
- Vote counting
During each maintenance period, the votes for candidates will be counted. The top 27 candidates with the most votes will be the super representatives for the next Epoch.
"},{"location":"mechanism-algorithm/dpos/#block-generation-mechanism","title":"Block Generation Mechanism","text":"During each Epoch, the 27 super representatives will take turns to generate blocks according to the bookkeeping order. Each super representative can only generate blocks when it is their turn. Super representatives package the data of multiple verified transactions into each block. The hash of the previous block will be included in each new block as the parentHash. The super representative will sign the data of this block with his/her private key and fill in witness_signature, along with the address of the super representative, the block height, and the time that block is generated, etc.
Through storing the hash of the previous block, blocks are logically connected. Eventually, they form a chain. A typical blockchain structure is shown in the following picture:
In ideal circumstances, the bookkeeping process in a DPoS consensus-based blockchain system proceeds according to the bookkeeping order calculated in advance. Blocks are generated by super representatives in turn (see figure a). However, in reality, the blockchain network is a distributed and untrusted complex system in the following three ways. - Due to poor network environment, blocks generated by some super representatives cannot be received by other super representatives in valid time (see figure b1 and b2). - The normal operation of a certain super representative cannot always be guaranteed (see figure c). - Some malicious super representatives will generate fork blocks in order to fork the chain (see figure d).
As mentioned above, the basis for the blockchain system to operate normally is that most of the nodes in the system are honest and reliable. Furthermore, the primary guarantee for the security of the blockchain system is the security of the ledger, meaning that illegal data cannot be written into the ledger maliciously and ledger copies saved on each node should be consistent as well. Based on the DPoS consensus, the bookkeeping process is carried out by super representatives. Therefore, the safety of TRON depends on the reliability of the majority of the super representatives. TRON has put confirmed blocks in the system which are irreversible. At the same time, in order to resist the malicious behaviors of a small number of super representatives nodes, TRON recognizes the longest chain as the main chain based on \"the longest chain principle\".
"},{"location":"mechanism-algorithm/dpos/#the-confirmed-block-principle","title":"The Confirmed Block Principle","text":"The newly produced blocks are in unconfirmed state, and only those blocks that are \"approved\" by at least 70% of the 27 super representatives(i.e. 27 * 70% = 19, rounded up)) are considered to be irreversible blocks, commonly referred to as solidified blocks, and the transactions contained in the solidified blocks have been confirmed by the entire blockchain network. The way to \"approve\" the unconfirmed state block is that the SR producing subsequent blocks after it, as shown in Figure d, the SR C produces block 103, the SR E produces 104' on the basis of block 103, the block 105', 106', and 107' produced respectively by the SR G, A and B, are also subsequent blocks of the 103rd block, which means these four blocks approve the 103rd block. It can be seen that when the block of height 121 is produced, the 103rd block becomes a solidified block, since by this time the 103rd block has 19 subsequent blocks, and the point to be emphasized here is that the super representatives producing these 19 blocks must be different from each other and from the super representatives producing the 103rd block.
"},{"location":"mechanism-algorithm/dpos/#the-longest-chain-principle","title":"The Longest Chain Principle","text":"When a fork occurs, an honest super representative would always choose to produce blocks on the longest chain.
"},{"location":"mechanism-algorithm/dpos/#incentive-model","title":"Incentive Model","text":"To ensure the safe and efficient operation of the blockchain system, TRON sets up an incentive model to encourage more nodes to join the network, thereby expanding the scale of the network. Every time a block is generated by the TRON network, a block reward of 16 TRX will be awarded to the super representative who produced the block, and a voting reward of 160 TRX will be awarded to all super representatives and super partners (super representative candidates who ranking 28th~ 127th are also called super partners), and they share the voting rewards proportionally according to the number of votes they get. At the same time, super representatives and partners will also deduct the rewards according to their commission ratio, and distribute the remaining part to voters according to the voter voting ratio.
"},{"location":"mechanism-algorithm/dpos/#proposal-based-parameter-adjustment","title":"Proposal-based Parameter Adjustment","text":"An important characteristic of DPoS is that any parameter adjustment can be proposed on the chain, and super representatives will decide whether to approve the proposal by starting a vote. The advantage of this method is that it avoids hard fork upgrades when adding new features. For the current dynamic parameters and values \u200b\u200bof the TRON network, as well as past proposals, please refer to here.
"},{"location":"mechanism-algorithm/dpos/#reference-documentations","title":"Reference Documentations","text":" - The Basics of TRON\u2019s DPoS Consensus Algorithm
"},{"location":"mechanism-algorithm/multi-signatures/","title":"Account Permission Management","text":""},{"location":"mechanism-algorithm/multi-signatures/#background","title":"Background","text":"Account permission management functions allow for permission grading, and each permission can correspond to multiple private keys. This makes it possible to achieve multi-person joint control of accounts. This guide walks the user through TRON's account permission management implementation and design.
"},{"location":"mechanism-algorithm/multi-signatures/#concept","title":"Concept","text":"There are three types of permission: owner\u3001witness and active. Owner permission has the right to execute all the contracts. Witness permission is for SR. Active permission contains a set of contracts selected execution permissions.
"},{"location":"mechanism-algorithm/multi-signatures/#protocol-definition","title":"Protocol Definition","text":""},{"location":"mechanism-algorithm/multi-signatures/#account","title":"Account","text":"message Account {\n // ...\n Permission owner_permission = 31;\n Permission witness_permission = 32;\n repeated Permission active_permission = 33;\n}\n
Three attributes are added, owner_permission\u3001witness_permission and active_permission. active_permission is a list, the length can not be bigger than 8.
"},{"location":"mechanism-algorithm/multi-signatures/#contracttype","title":"ContractType","text":"message Transaction {\n message Contract {\n enum ContractType {\n AccountCreateContract = 0;\n // ...\n AccountPermissionUpdateContract = 46;\n }\n }\n}\n
The definition of ContractType can be found here. AccountPermissionUpdateContract is a ContractType used to update the account permission.
"},{"location":"mechanism-algorithm/multi-signatures/#accountpermissionupdatecontract","title":"AccountPermissionUpdateContract","text":"message AccountPermissionUpdateContract {\n bytes owner_address = 1;\n Permission owner = 2;\n Permission witness = 3;\n repeated Permission actives = 4;\n}\n
owner_address: The address of the account whose permissions are to be modifiedowner: Owner permissionwitness: Witness permission (only used by witness)actives: Active permission
This will override the Original account permission. Therefore, if you only want to modify the owner permission, witness (if it is a SR account) and active permission also need to be set
"},{"location":"mechanism-algorithm/multi-signatures/#permission","title":"Permission","text":"message Permission {\n enum PermissionType {\n Owner = 0;\n Witness = 1;\n Active = 2;\n }\n PermissionType type = 1;\n int32 id = 2;\n string permission_name = 3;\n int64 threshold = 4;\n int32 parent_id = 5;\n bytes operations = 6;\n repeated Key keys = 7;\n}\n
PermissionType: Permission typeid: Generated by system. Owner id=0, Witness id=1, Active id increases from 2. Specifying using which permission to execute a contract by setting id. For instance, using owner permission, set id=0permission_name: Permission name, 32 bytes length limitthreshold: The threshold of the signature weightparent_id: Current 0-
operations: used by active permission, a hexadecimal coded sequence (little-endian byte order), 32 bytes (256 bits), and each bit represents the authority of a ContractType. The nth bit indicates the authority of the ContractType with ID n, its value 1 means that it has the authority to execute the ContractType, its value 0 means it doesn't have the authority. To make it easier for users to read, start with the binary big-endian byte order to illustrate how to calculate the value of operations. The number of digits starts from 0, and corresponds to the ID of the ContractType from left to right. Convert a binary big-endian byte sequence to a hexadecimal little-endian byte sequence, that will be the value of operations. Below is an example of how to calculate the operations of active permission with operation TransferContract(ID=1) and operation VoteWitnessContract(ID=4) allowed. The mapping between ContractType and its ID can be seen in the above definition link of ContractType.
Operations Allowed Binary Code(big-endian) Binary Code(little-endian) Hex Code(little-endian) TransferContract(1) & VoteWitnessContract(4) 01001000 00000000 00000000 ... 00010010 00000000 00000000 ... 12 00 00 ... -
keys: The accounts and weights that all own the permission, 5 keys at most.
"},{"location":"mechanism-algorithm/multi-signatures/#key","title":"Key","text":"message Key {\n bytes address = 1;\n int64 weight = 2;\n}\n
address: The account addressweight: The signature weight
"},{"location":"mechanism-algorithm/multi-signatures/#transaction","title":"Transaction","text":"message Transaction {\n // ...\n int32 Permission_id = 5;\n}\n
Permission_id is added. It is corresponding to Permission.id 1 is not allowed, because witness permission is only used to produce blocks, not for transaction signature.
"},{"location":"mechanism-algorithm/multi-signatures/#owner-permission","title":"Owner Permission","text":"Owner permission is the top permission of an account. It is used to control account ownership, adjust permission structure. Owner Permission has the right to execute all the contracts.
Owner permission's features:
- The account that has owner permission can change the owner permission
- When owner permission is null, the default owner of the account owns the owner permission
- When you create a new account, the address will be insert into owner permission automatically, default weight is 1, keys field only contains this address and also weight is 1.
- If a permissionId is not specified when a contract is executed, using owner permission by default.
"},{"location":"mechanism-algorithm/multi-signatures/#witness-permission","title":"Witness Permission","text":"Super representatives can use this permission to manage block producing. Only SR(Super Representative) account has this permission.
Usage scenario example: A super representative deploys a witness node on cloud server. In order to keep the account on the cloud server safe, you can only give the block producing permission to the account you put on cloud server. Because this account only owns block producing permission, no TRX transfer permission, so even if the account on the cloud server is leaked, the TRX will not be lost.
Witness node configuration: when start a fullnode as witness, localwitness in the config file is filled in with the private key of the witness account and localWitnessAccountAddress is commented on as below:
# config.conf\n//localWitnessAccountAddress = \nlocalwitness = [\n xxx // private key of the witness account\n]\n
- If witness permission is not modified, there is no need to change config file.
-
If witness permission is modified, two modifications are required as follows:
localwitness needs to be changed to the private key of the account authorized with witness permissionlocalWitnessAccountAddress shoule be explicitly set as the address of the witness account
Below is an example of how to configure witness account TCbxHgibJutCjVZUprvexKZZ4Rc6sJ4Xrk which authorize its witness permission to account TSwCH45gi2HvtqDYX3Ff39yHeu5moEqQDJ.
#config.conf\nlocalWitnessAccountAddress = TCbxHgibJutCjVZUprvexKZZ4Rc6sJ4Xrk\nlocalwitness = [\n yyy // private key of TSwCH45gi2HvtqDYX3Ff39yHeu5moEqQDJ\n]\n
Notice: Only one private key can be added to localwitness when witness permission is modified.
"},{"location":"mechanism-algorithm/multi-signatures/#active-permission","title":"Active Permission","text":"Active permission is composed of a set of contract execution permission, like creating an account, transfer function, etc.
Active permission's features:
- the account owns owner permission can change active permission
- the account owns the execution permission of AccountPermissionUpdateContract can also change active permission
- 8 permissions at most
- permissionId increases from 2 automatically
- when a new account is created, an active permission will be created automatically, and the address will be inserted into it, default weight is 1, keys field only contains this address and weight is 1
"},{"location":"mechanism-algorithm/multi-signatures/#fee","title":"Fee","text":" - Using AccountPermissionUpdateContract costs 100TRX
- If a transaction contains 2 or more than 2 signatures, it charges an extra 1 TRX besides the transaction fee
- The fee can be modified by proposing
"},{"location":"mechanism-algorithm/multi-signatures/#api","title":"API","text":""},{"location":"mechanism-algorithm/multi-signatures/#change-permission","title":"Change Permission","text":"AccountPermissionUpdateContract, steps:
- call
getaccount to query the account, get the original permission - change permission
- build transaction and sign
- send transaction
Demo HTTP request:
// POST to http://{{host}}:{{port}}/wallet/accountpermissionupdate\n\n{\n \"owner_address\": \"41ffa9466d5bf6bb6b7e4ab6ef2b1cb9f1f41f9700\",\n \"owner\": {\n \"type\": 0,\n \"id\": 0,\n \"permission_name\": \"owner\",\n \"threshold\": 2,\n \"keys\": [{\n \"address\": \"41F08012B4881C320EB40B80F1228731898824E09D\",\n \"weight\": 1\n },\n {\n \"address\": \"41DF309FEF25B311E7895562BD9E11AAB2A58816D2\",\n \"weight\": 1\n },\n {\n \"address\": \"41BB7322198D273E39B940A5A4C955CB7199A0CDEE\",\n \"weight\": 1\n }\n ]\n },\n \"witness\": {\n \"type\": 1,\n \"id\": 1,\n \"permission_name\": \"witness\",\n \"threshold\": 1,\n \"keys\": [{\n \"address\": \"41F08012B4881C320EB40B80F1228731898824E09D\",\n \"weight\": 1\n }\n ]\n },\n \"actives\": [{\n \"type\": 2,\n \"id\": 2,\n \"permission_name\": \"active0\",\n \"threshold\": 3,\n \"operations\": \"7fff1fc0037e0000000000000000000000000000000000000000000000000000\",\n \"keys\": [{\n \"address\": \"41F08012B4881C320EB40B80F1228731898824E09D\",\n \"weight\": 1\n },\n {\n \"address\": \"41DF309FEF25B311E7895562BD9E11AAB2A58816D2\",\n \"weight\": 1\n },\n {\n \"address\": \"41BB7322198D273E39B940A5A4C955CB7199A0CDEE\",\n \"weight\": 1\n }\n ]\n }]\n}\n
"},{"location":"mechanism-algorithm/multi-signatures/#calculate-the-active-permissions-operations","title":"Calculate the Active Permission's Operations","text":"public static void main(String[] args) {\n\n //you need to specify the id of the contract you need to give permission to by referring to the definition of Transaction.ContractType in proto to get the id of the contract, below includes all the contract except AccountPermissionUpdateContract(id=46)\n\n Integer[] contractId = {0, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 30, 31,\n 32, 33, 41, 42, 43, 44, 45};\n List<Integer> list = new ArrayList<>(Arrays.asList(contractId));\n byte[] operations = new byte[32];\n list.forEach(e -> {\n operations[e / 8] |= (1 << e % 8);\n });\n\n //7fff1fc0033e0000000000000000000000000000000000000000000000000000\n System.out.println(ByteArray.toHexString(operations));\n}\n
"},{"location":"mechanism-algorithm/multi-signatures/#contract-execution","title":"Contract Execution","text":"(1). Create transaction, the same as none multi-signatures
(2). Specify Permission_id, default 0, represent owner permission, demo
(3). User A sign the transaction, and then send it to user B
(4). User B sign the transaction gets from A, and then send it to user C
......
(n). The last users that signs the transaction broadcast it to the node
(n+1). The node will verify if the sum of the weight of all signatures is bigger than threshold, if true, the transaction is accepted, otherwise, is rejected
"},{"location":"mechanism-algorithm/multi-signatures/#other-apis","title":"Other APIs","text":"Please refer to HTTP API and RPC API for more information.
-
query the addresses that already signed a transaction
> curl -X POST http://127.0.0.1:8090/wallet/getapprovedlist -d '{\"transaction\"}'\n
rpc GetTransactionApprovedList(Transaction) returns (TransactionApprovedList) { }\n
-
query the signature weight of a transaction
> curl -X POST http://127.0.0.1:8090/wallet/getsignweight -d '{\"transaction\"}'\n
rpc GetTransactionSignWeight (Transaction) returns (TransactionSignWeight) {}\n
"},{"location":"mechanism-algorithm/resource/","title":"Resource Model","text":""},{"location":"mechanism-algorithm/resource/#introduction","title":"Introduction","text":"Voting Right, bandwidth and energy are important system resources of the TRON network. Among them, voting rights are used to vote for super representatives; Bandwidth is the unit that measures the size of the transaction bytes stored in the blockchain database. The larger the transaction, the more bandwidth resources will be consumed. Energy is the unit that measures the amount of computation required by the TRON virtual machine to perform specific operations on the TRON network. Since smart contract transactions require computing resources to execute, each smart contract transaction requires to pay for the energy fee.
Note
- Ordinary transaction only consumes Bandwidth points
- Smart contract related transaction not only consumes Bandwidth points, but also Energy
"},{"location":"mechanism-algorithm/resource/#voting-right","title":"Voting Right","text":"Before any account can vote for super representatives, it needs to obtain voting rights, that is, TRON Power (TP). Voting rights can be obtained by staking TRX. In addition to obtaining bandwidth or energy, staking TRX will also obtain voting rights at the same time. Voters who stake 1TRX will receive 1TP. For how to stake, please refer to the Staking on TRON Network chapter.
Voters can stake multiple times, and the voting rights obtained by multiple stake will be added to the voter's account. Voters can query the total number of voting rights owned by the account and the number of used voting rights through the wallet/getaccountresource interface.
"},{"location":"mechanism-algorithm/resource/#bandwidth-points","title":"Bandwidth Points","text":"The transaction information is stored and transmitted in the form of byte array, Bandwidth Points consumed = the number of bytes of the transaction * Bandwidth Points rate. Currently Bandwidth Points rate = 1.
Such as if the number of bytes of a transaction is 200, so this transaction consumes 200 Bandwidth Points.
Note
Due to the change of the total amount of the staked TRX in the network and the self-staked TRX amount, the Bandwidth Points an account possesses is not fixed.
"},{"location":"mechanism-algorithm/resource/#1-how-to-get-bandwidth-points","title":"1. How to Get Bandwidth Points","text":" - By staking TRX to get Bandwidth Points, Bandwidth Points = the amount of TRX self-staked / the total amount of TRX staked for Bandwidth Points in the network * 43,200,000,000
- Every account has a fixed amount of free Bandwidth Points(600) every day
"},{"location":"mechanism-algorithm/resource/#2-bandwidth-points-consumption","title":"2. Bandwidth Points Consumption","text":"Except for query operation, any transaction consumes Bandwidth points.
Bandwidth points consumption sequence for TRC-10 transfer:
-
Free Bandwidth points.
-
TRC-10 issuer's Bandwidth points(if possible.)
-
Bandwidth points TRX staking.
-
Bandwidth points obtained by TRX burning, the rate = the number of bytes of the transaction * 1,000 SUN;
Bandwidth points consumption sequence for other transactions:
-
Free Bandwidth points.
-
Bandwidth points TRX staking.
-
Bandwidth points obtained by TRX burning, the rate = the number of bytes of the transaction * 1,000 SUN;
"},{"location":"mechanism-algorithm/resource/#3-bandwidth-points-recovery","title":"3. Bandwidth Points Recovery","text":"After the account's free bandwidth and the bandwidth obtained by staking TRX are consumed, they will gradually recover within 24 hours.
"},{"location":"mechanism-algorithm/resource/#4-account-bandwidth-balance-query","title":"4. Account Bandwidth Balance Query","text":"First, call the node HTTP interface wallet/getaccountresource to obtain the current resource status of the account, and then calculate the bandwidth balance by the following formula:
Free bandwidth balance = freeNetLimit - freeNetUsed\n\nBandwidth balance obtained by staking TRX = NetLimit - NetUsed\n
Note: If the result returned by the interface does not contain the parameters in the above formula, it means that the parameter value is 0.
"},{"location":"mechanism-algorithm/resource/#energy","title":"Energy","text":"Each command of smart contract consume system resource while running, we use 'Energy' as the unit of the consumption of the resource.
"},{"location":"mechanism-algorithm/resource/#1-how-to-get-energy","title":"1. How to Get Energy","text":"Stake TRX to get energy.
Example (Using wallet-cli):
freezeBalanceV2 frozen_balance [ResourceCode:0 BANDWIDTH,1 ENERGY]\n
stake TRX to get energy, energy obtained = user's TRX staked amount / total amount of staked TRX in TRON * 180,000,000,000.
Example:
If there are only two users, A stakes 2 TRX, B stakes 2 TRX\nthe energy they can get is:\nA: 75,000,000,000 and energy_limit is 90,000,000,000\nB: 75,000,000,000 and energy_limit is 90,000,000,000\n\nwhen C stakes 1 TRX:\nthe energy they can get is:\nA: 60,000,000,000 and energy_limit is 72,000,000,000\nB: 60,000,000,000 and energy_limit is 72,000,000,000\nC: 30,000,000,000 and energy_limit is 36,000,000,000\n
"},{"location":"mechanism-algorithm/resource/#energy-consumption","title":"Energy Consumption","text":"When the contract is executed, Energy is calculated and deducted according to instruction one by one. The priority of account energy consumption is as follows:
- Energy obtained by staking TRX
- Burn TRX
First, the energy obtained by staking TRX will be consumed. If this part of energy is not enough, the account's TRX will continue to be burned to pay for the energy resources required for the transaction, according to the unit price of 0.00021TRX per energy.
If the contract exits due to throwing a revert exception while execution, only the energy consumed by instructions that have already been executed will be deducted. But for abnormal contracts, such as contract execution timeout, or abnormal exit due to bug, the maximum available energy of this transaction will be deducted. You can limit the maximum energy cost of this transaction by setting the fee_limit parameter of the transaction.
"},{"location":"mechanism-algorithm/resource/#energy-recovery","title":"Energy Recovery","text":"After the energy resource of the account is consumed, it will gradually recover within 24 hours.
"},{"location":"mechanism-algorithm/resource/#account-energy-balance-query","title":"Account Energy Balance Query","text":"First call the node HTTP interface wallet/getaccountresource to obtain the current resource status of the account, and then calculate the energy balance by the following formula:
Energy Balance = EnergyLimit - EnergyUsed\n
Note: If the result returned by the interface does not contain the parameters in the above formula, it means that the parameter value is 0.
"},{"location":"mechanism-algorithm/resource/#2-how-to-set-fee-limit-caller-must-read","title":"2. How to Set Fee Limit (Caller Must Read)","text":"Within the scope of this section, the smart contract developer will be called \"developer\", the users or other contracts which call the smart contract will be called \"caller\"
The amount of energy consumed while call the contract can be converted to TRX or SUN, so within the scope of this section, when refer to the consumption of the resource, there's no strict difference between Energy, TRX and SUN, unless they are used as a number unit.
Set a rational fee limit can guarantee the smart contract execution. And if the execution of the contract cost great energy, it will not consume too much energy from the caller. Before you set fee limit, you need to know several conception:
- The legal fee limit is a integer between 0 - 15*10^9, unit is SUN.
- Different smart contracts consume different amount of energy due to their complexity. The same trigger in the same contract almost consumes the same amount of energy[^1], however, due to the dynamic energy model mechanism, for popular contracts, different energy may be required for execution at different times. For details, please refer to the Dynamic Energy Model Chapter. When the contract is triggered, the commands will be executed one by one and consume energy. If it reaches the fee limit, commands will fail to be executed, and energy is not refundable.
- Currently fee limit only refers to the energy converted to SUN that will be consumed from the caller[^2]. The energy consumed by triggering contract also includes developer's share.
- For a vicious contract, if it encounters execution timeout or bug crash, all it's energy will be consumed.
- Developer may undertake a proportion of energy consumption(like 90%). But if the developer's energy is not enough for consumption, the rest of the energy consumption will be undertaken by caller completely. Within the fee limit range, if the caller does not have enough energy, then it will burn equivalent amount of TRX [^2].
To encourage caller to trigger the contract, usually developer has enough energy.
"},{"location":"mechanism-algorithm/resource/#example","title":"Example","text":"How to estimate the fee limit:
- Assume contract C's last execution consumes 18000 Energy, so estimate the energy consumption limit to be 20000 Energy.
- When to burn TRX, since the unit price of energy is currently 210sun, 21 trx can be exchanged for 100,000 Energy.
Assume developer undertake 90% energy consumption, and developer has enough energy.
Then the way to estimate the fee limit is:
- A = 20000 energy * 210sun = 4,200,000 sun = 4.2 trx
- Developer undertakes 90% energy consumption, caller undertakes 10% energy consumption,
So, the caller is suggested to set fee limit to 4,200,000 sun * 10% = 420,000 sun.
"},{"location":"mechanism-algorithm/resource/#3-energy-calculation-developer-must-read","title":"3. Energy Calculation (Developer Must Read)","text":" -
In order to punish the vicious developer, for the abnormal contract, if the execution times out (more than 80ms) or quits due to bug (revert not included), the maximum available energy will be deducted. If the contract runs normally or revert, only the energy needed for the execution of the commands will be deducted.
-
Developer can set the proportion of the energy consumption it undertakes during the execution, this proportion can be changed later. If the developer's energy is not enough, it will consume the caller's energy.
-
Currently, the total energy available when trigger a contract is composed of caller fee limit and developer's share
Note
- If the developer is not sure about whether the contract is normal, do not set caller's energy consumption proportion to 0%, in case all developer's energy will be deducted due to vicious execution[^1].
- We recommend to set caller's energy consumption proportion to 10% ~ 100%[^2].
** Example 1 **
A has an account with a balance of 90 TRX(90000000 SUN) and 10 TRX staked for 100000 energy.
Smart contract C set the caller energy consumption proportion to 100% which means the caller will pay for the energy consumption completely.
A triggers C, the fee limit set is 30000000 (unit SUN, 30 TRX)
So during this trigger the energy A can use is from two parts:
- A's energy by staking TRX;
- The energy converted from the amount of TRX burning according to a fixed rate;
If fee limit is greater than the energy obtained from staking TRX, then it will burn TRX to get energy. The fixed rate is: 1 Energy = 210 SUN, fee limit still has (30 - 10) TRX = 20 TRX available, so the energy it can keep consuming is 20 TRX / 210 SUN = 95238 energy.
Finally, in this call, the energy A can use is (100000 + 95238) = 195238 energy.
If contract executes successfully without any exception, the energy needed for the execution will be deducted. Generally, it is far more less than the amount of energy this trigger can use.
If Assert-style error come out, it will consume the whole number of energy set for fee limit.
** Example 2 **
A has an account with a balance of 90 TRX(90000000 SUN) and 10 TRX staked for 100000 energy.
Smart contract C set the caller energy consumption proportion to 40% which means the developer will pay for the rest 60% energy consumption.
Developer D stakes 50 TRX to get 500000 energy.
A triggers C, the fee limit set is 200000000 (unit SUN, 200 TRX).
So during this trigger the energy A can use is from three parts:
- A's energy by staking TRX -- X;
-
The energy converted from the amount of TRX burning according to a fixed rate -- Y;
If fee limit is greater than the energy obtained from staking TRX, then it will burn TRX to get energy. The fixed rate is: 1 Energy = 210 sun, fee limit still has (200 - 10) TRX = 190 TRX available, but A only has 90 TRX left, so the energy it can keep consuming is 90 TRX / 210 sun = 428571 energy;
-
D's energy by staking TRX -- Z;
There are two situation: if (X + Y) / 40% >= Z / 60%, the energy A can use is X + Y + Z if (X + Y) / 40% < Z / 60%, the energy A can use is (X + Y) / 40%
If contract executes successfully without any exception, the energy needed for the execution will be deducted. Generally, it is far more less than the amount of energy this trigger can use.
If Assert-style error comes out, it will consume the whole number of energy set for fee limit.
Note: when developer create a contract, do not set consume_user_resource_percent to 0, which means developer will undertake all the energy consumption. If Assert-style error comes out, it will consume all energy from the developer itself. To avoid unnecessary lost, 10 - 100 is recommended for consume_user_resource_percent.
"},{"location":"mechanism-algorithm/resource/#dynamic-energy-model","title":"Dynamic Energy Model","text":"The dynamic energy model is a resource balancing mechanism of the TRON network, which can dynamically adjust the energy consumption of each contract according to the resource occupancy of the contract, so as to make the allocation of energy resources on the chain more reasonable and prevent excessive concentration of network resources on a few popular contracts. For more details, please refer to Introduction to Dynamic Energy Model.
"},{"location":"mechanism-algorithm/resource/#principle","title":"Principle","text":"If a contract uses too many resources in one maintenance cycle, then in the next maintenance cycle, 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.
Each contract has an energy_factor field, which indicates the increase ratio of the energy consumption of the smart contract transaction relative to the base energy consumption and the initial value is 0. When the energy_factor of the contract is 0, it means that the contract is using resources reasonably, and there will be no additional energy consumption for calling the contract. When the energy_factor is greater than 0, it means that the contract is already a popular contract, and additional energy will be consumed when calling the contract. The energy_factor of a contract can be queried through the getcontractinfo API.
The calculation formula for the final energy consumed by the contract invocation transaction is as follows:
energy consumption by a contract invocation transaction = the basic energy consumption generated by the transaction * \uff081 + energy_factor\uff09\n
The dynamic energy model introduces the following three parameters of the TRON network , which jointly control the energy_factor field of the contract:
threshold: The threshold of contract basic energy consumption. In a maintenance cycle, if the basic energy consumption of the contract exceeds this threshold, the energy consumption of the contract will increase at the next maintenance cycle.increase_factor: If the basic energy consumption of the contract exceeds the threshold during a certain maintenance cycle, the energy_factor will increase by a certain percentage according to the increase_factor in the next maintenance cycle.max_factor: the maximum value of energy_factor.
There is also a variable decrease_factor used to reduce the energy_factor of the contract:
decrease_factor: 1/4 of increase_factor. After the basic energy consumption of the contract falls below the threshold, energy_factor will be reduced by a certain percentage according to decrease_factor.
When the basic energy consumption of the contract exceeds threshold during a maintenance cycle, its energy_factor will increase in the next maintenance cycle, but the maximum will not be Exceeding max_factor, the calculation formula is:
energy_factor = min((1 + energy_factor) * (1 + increaese_factor)-1, max_factor)\n
When the basic energy consumption of the contract drops below the threshold in a maintenance cycle, the energy_factor will decrease in the next maintenance cycle, but the minimum value will not be lower than 0. The calculation formula is as follows:
energy_factor = max((1 + energy_factor) * (1 - decrease_factor)- 1, 0)\n
The dynamic energy model has been enabled on the main network, and the relevant parameters are set as follows:
threshold\uff1a5,000,000,000increase_factor\uff1a0.2max_factor\uff1a3.4
Since the energy consumption of popular contracts is different in different maintenance cycles, it is necessary to set the appropriate feelimit parameter for the transaction when calling the contract.
"},{"location":"mechanism-algorithm/resource/#staking-on-tron-network","title":"Staking on TRON network","text":""},{"location":"mechanism-algorithm/resource/#how-to-stake-to-obtain-system-resources","title":"How to stake to obtain system resources","text":"Energy and bandwidth resources are obtained by the account owner through staking, please use wallet/freezebalancev2 to complete the stake operation through HTTP API, use Stake2.0 Solidity API to complete the stake operation through the contract.
TRON allocates resources through the staking mechanism. In addition to obtaining bandwidth or energy resources, staking TRX will also obtain voting rights (TRON Power, TP for short) equal to the amount staked. Staking 1 TRX, you will get 1TP. The energy or bandwidth resources obtained by staking are used to pay transaction fees, and the obtained voting rights are used to vote for super representatives to obtain voting rewards.
The unstaking operation will release the corresponding resources.
"},{"location":"mechanism-algorithm/resource/#how-to-delegate-resources","title":"How to delegate resources","text":"After the account obtains energy or bandwidth resources through staking, it can delegate resources to other addresses through delegateresource, and can also take back allocated resources through undelegateresource. Please pay attention to the following situations when delegating resource:
- Only energy and bandwidth can be delegated to other addresses, voting rights cannot be delegated
- Only unused resources obtained by staking through Stake2.0 can be delegated to other addresses
- Energy/Bandwidth can only be delegated to an activated external account address, not to a contract address
You can use the wallet/getcandelegatedmaxsize interface to query the available delegation share of a certain resource type in the account. Time lock can be used when delegating resources. If time lock is used, after the resource delegating is completed, the resource delegation for the address only can be canceled after 3 days. During the locking period, if the user performs resource delegating for the same address again, it will Reset the 3-days waiting period. If the time lock is not used, the delegation can be canceled immediately after the resource is delegated.
"},{"location":"mechanism-algorithm/resource/#how-to-unstake-trx","title":"How to unstake TRX","text":"After completing the TRX staking, you can unstake at any time. After unstaking, you need to wait for 14 days before you can withdraw the unstaked TRX into your account. 14 days is the No.70 parameter of TRON network which can be voted on by network governance proposals. Please use unfreezebalancev2 to complete unfreeze balance through HTTP API.
The staked TRX can be partially unstaked multiple times, but only a maximum of 32 unstaking operations are allowed at the same time. That is to say, when a user initiates the first unstake operation, before the TRX of the first unstaking arrives and is ready to be withdrawn to his or her account, he or she can only initiate another 31 unstake operations. The remaining counts of unfreeze can be queried through the getavailableunfreezecount interface.
The TRX that have been delegated cannot be unstaked. In addition to losing the same amount of resource shares, the unstaking will also lose the same amount of TP resources.
When unstaking, if there are unclaimed voting rewards, the voting rewards will be automatically withdrawn to the account. If there is a previously unstaked principal that has passed the lock-up period, then this unstake operation will also withdraw the unstaked principal that has passed the lock-up period to the account at the same time. You can use the gettransactioninfobyidAPI to query the voting reward extracted in this transaction in withdraw_amount field and the withdrawn amount of unstaked TRX that has expired the lock-up period in withdraw_expire_amount field.
"},{"location":"mechanism-algorithm/resource/#tron-power-reclaim","title":"TRON Power Reclaim","text":"After unstaking the TRX staked in the Stake2.0 stage, the same amount of voting rights will be lost. The system will first reclaim the idle voting rights in the account. If the idle TP is insufficient, it will continue to reclaim the used TP. If the user has voted for multiple super representatives, a certain number of votes will be withdrawn in proportion from each super representative, and the corresponding voting rights will be recovered. The calculation formula for withdrawing votes for each SR is,
The number of votes withdrawn from the current super representative = total number of votes to be withdrawn * (number of votes for the current super representative / total number of votes of this account)\n
For example, Suppose A staked 2,000TRX and obtained 2,000 TRON Power, of which 1,000 TRON Power voted for 2 super representatives, 600 votes and 400 votes respectively, and 1,000 TRON Power remained in the account. At this time, A unstakes 1,500TRX, which means that 1,500 TRON Power needs to be reclaimed from A\u2019 account. In this case, the idle 1,000 TP in A\u2019s account will be withdrawn first, and the spared 500 TP will be withdrawn from the voted TP, which is 300 TP and 200 TP respectively from the two super representatives. Here's how the votes are calculated:
- Number of votes withdrawn by Super Representative 1 = 500 * (600 / 1,000) = 300
- Number of votes withdrawn by Super Representative 2 = 500 * (400 / 1,000) = 200
At present, the TRON network uses the Stake2.0 stake mechanism, but the resources and votes obtained by Stake1.0 are still valid. The TRX staked at Stake1.0 can still be withdrawal through Stake1.0 API unfreezebalance, but it should be noted that if the TRX staked in Stake 1.0 is unstaked, all votes in the account will be revoked.
"},{"location":"mechanism-algorithm/resource/#how-to-cancel-unstaking","title":"How to cancel unstaking","text":"Stake2.0 supports canceling all unstakes after the user unstakes TRX, which will make the assets be used for stake again to obtain corresponding resources, without having to wait for the unstaked funds to pass the lock-up period before withdrawing the funds to the account , and then stake them again. Please use cancelallunfreezev2 to cancel all unstaking operations.
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\u2019s account. Users can query the canceled unstaked principal amount cancel_unfreezeV2_amount, and the withdrawn principal amount that has expired the lock-up period withdraw_expire_amount through the gettransactioninfobyid interface.
"},{"location":"mechanism-algorithm/resource/#api","title":"API","text":"The following table shows the relevant interfaces of the stake model and their descriptions:
API Description freezebalancev2 Stake TRX unfreezebalancev2 Unstake TRX delegateresource Delegate resources undelegateresource Undelegate resources withdrawexpireunfreeze Withdraw unfrozen balance getavailableunfreezecount Query the remaining times of executing unstake operation getcanwithdrawunfreezeamount Query the withdrawable balance getcandelegatedmaxsize Query the amount of delegatable resources share of the specified resource Type getdelegatedresourcev2 Query the amount of resource delegated by fromAddress to toAddress getdelegatedresourceaccountindexv2 Query the resource delegation index by an account getaccount Query the account stake status, resource share, unstake status, and voting status getaccountresource Query the total amount of resources, the amount of used, and the amount of available cancelallunfreezev2 Cancel unstaking"},{"location":"mechanism-algorithm/shielded-transaction/","title":"Shielded Transaction","text":""},{"location":"mechanism-algorithm/shielded-transaction/#introduction","title":"Introduction","text":"TRON shielded transaction uses zk-SNARK(Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) to implement a completely anonymous transaction. TronZ is the name of shielded trc10 token.
In shielded transaction of transferring TronZ, the sender and the receiver's address and transfer amount can both be completely confidential.
In shielded transaction of transferring TronZ, there are two types of address:
- \"t-addr\" (Transparent Address)
- \"z-addr\" (Shielded Address)
\"t-addr\" address uses TRON account model. \"z-addr\" address uses Anonymous account model.
In shielded transaction of transferring TronZ, there are three types of transfer transaction: - From \"t-addr\" to \"z-addr\": The transaction information of \"t-addr\" can be tracked, \"z-addr\" can not be tracked.
-
From \"z-addr\" to \"z-addr\": The transaction information of both \"z-addr\" can not be tracked.
-
From \"z-addr\" to \"t-addr\": The transaction information of both \"t-addr\" can be tracked, \"z-addr\" can not be tracked.
From \"t-addr\" to \"t-addr\" are not supported.
"},{"location":"mechanism-algorithm/shielded-transaction/#usage-guide","title":"Usage Guide","text":"1.\u00a0The sender can only spend one note in each transfer. The receiver can receive two notes in each transfer at most.
2.\u00a0When you transfer from \"z-addr\" to \"t-addr\", if no note returns to \"z-addr\" as a change, it will generate a note of zero value automatically, and send it to a random black hole address.
3.\u00a0The fee for each shielded transaction is xx.
The doc below describes how to use TRON Shielded Transaction with http api.
"},{"location":"mechanism-algorithm/shielded-transaction/#transfer-from-transparent-address-to-shielded-address","title":"Transfer from transparent address to shielded address","text":"Step 1. Call api: wallet/createshieldedtransaction to build the transaction Method: Post Parameters:
{\n \"transparent_from_address\":\"41A7D8A35B260395C14AA456297662092BA3B76FC0\",\n \"from_amount\":100000000,\n \"ovk\":\"798ba79bfec55e154fa69b4e6a96247288f727b5e4ecc5cd848aefc0afab02b6\",\n \"shielded_receives\":[{\n \"note\":\n {\n \"value\": 500000000,\n \"payment_address\": \"ztron1jld8fmvujrz2vgkc867zuwklmewy4ypw0wtwgweqs2paee0uhc8f3azy90el770arksa2kunl02\",\n \"rcm\": \"723053bcbfecdf5da66c18ab0376476ef308c61b7abe891b2c01e903bcb87c0e\"\n }\n }]\n}\n
Return: {\"txID\":\"1967c40954e8c6c4761c377a021ec3a6ad0545d8b4443f0ccdd1bec4dcbaa497\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"transparent_from_address\":\"41a7d8a35b260395c14aa456297662092ba3b76fc0\",\"binding_signature\":\"5407f7f7d43ae313bf54b8d6a8cf716f65390171e39c11c07b4c90e5ae7d5d114b1729d44a3bc58f6e40c413b972e8ab61a8e66502b30df35937f64957c0da0a\",\"from_amount\":100000000,\"fee\":10000000,\"receive_description\":[{\"value_commitment\":\"5a1cd384edab9c38901d0250ebdf96d4f29889094b7096a7ce2dd6af919afd21\",\"note_commitment\":\"f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b62\",\"epk\":\"e7ff2357376eafdabc6db3fdabc079e42dd14c61a9a08c6cd38405d086086b4b\",\"c_enc\":\"d1aaf220f531f31bd2d9ff6f6d59998e78f3f0d30c852258441c5d54fc6790af7620b8860f6ec48d93fedb4c9bbb0e43c8144a9e304ceee399ac6da0bb91dbace3c8a93e03f1d2a5a88b0998704a09a51ab147096a994420741e87168cda4f45f8ed03c816e947909f2997d48e2ceaed45c539463e5e8caf6a0a1529615afbfa01df0a89c6360512519aea8a1b30a367a8749b24946fcd2fbbc6cfbbb6562ed6aa16db5d9e76b1872683a841ebda3a16dda6083474c2ea5a81f4e5c04e6af6ed582f58cab36bc016cfcf03337bc64b5411c7cb6f6f55e17d96bfead8becb0b7661768e122c943159ff2854c0e6efdd408b5bd5afc9d629645bfff8d4a240591fa9adc37e4a5bc046fcf31f8088f3616dd2f69860e401221585fd1a5ebe88080742802ae4696b8ba5e826ddd42841dce71b4b3ebe47b1f254103ae49f0bd9d61f5c0193441c471d29535247c26ab9297975497f6051466dbc591c4cd7b4246604e445d7d3a1dd77538c1989a8c48f829c6a1ce0dee84019ef68b7407def2492f5c867f659b0f8f58cc1081706453bf3a1ec719927c6b3defdcc002e9f2f63b4bdb7f69a00db742d2571d7293bae3faffc43ea0ff032e1b262a3597290c6c9117a006c91074a455c80a3a8089d93aed5bd48bd04bb30ad68fc87ff2bb4e5c20fe4bc0ad1b586aef3d1183170dec490c6bc82ec85d4031e292782f8778f21252a7cb6730da2d8fb175017e213eb10527b104bf333767cfed23c7c993391d9029f404947a793c37c1880a6be5cc26cc447ea020db8832239aa09aad9876ec17c4095857971ae\",\"c_out\":\"8e3df70e1feaf8da5da72062d13c5200ab09f43e45d2ba1aac8a56c8e9d033d786cfe3ed7d2b30d8b6124afe2646c7af25b60ed02c3a50b2cb62637461e00b153b92f868f2194b46c49e9a1c9e987d5a\",\"zkproof\":\"8b338777245e733183101027436ea41ea15f61537f38a35109fe6e53806c7913c69f186a86ba1d63997c5301c650089aa888cdf939573b0e7aceefff59757f8ba2275bd4469de04174f1b450a53017260b4bbc4a27cd8aac45d5ff2e5f5ab0eb14ffc59cf0fa10cd32363ef9a9fb9bf68431c4ee1c2ca15797ba4c18dbde24ae451797b25f13a73a231783f72b6f7a429026e191a49619057b250fab6b7010fc58dfcf922b04ad83756e2b8780100dccaafc65e4ef0357c6aae57f4f5c790607\"}]},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"0245\",\"ref_block_hash\":\"b1ea272768028540\",\"expiration\":1558691289000,\"timestamp\":1558691230861},\"raw_data_hex\":\"0a0202452208b1ea27276802854040a8aff6c9ae2d5ae708083312e2080a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e747261637412a8080a1541a7d8a35b260395c14aa456297662092ba3b76fc01080c2d72f22c2070a205a1cd384edab9c38901d0250ebdf96d4f29889094b7096a7ce2dd6af919afd211220f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b621a20e7ff2357376eafdabc6db3fdabc079e42dd14c61a9a08c6cd38405d086086b4b22c404d1aaf220f531f31bd2d9ff6f6d59998e78f3f0d30c852258441c5d54fc6790af7620b8860f6ec48d93fedb4c9bbb0e43c8144a9e304ceee399ac6da0bb91dbace3c8a93e03f1d2a5a88b0998704a09a51ab147096a994420741e87168cda4f45f8ed03c816e947909f2997d48e2ceaed45c539463e5e8caf6a0a1529615afbfa01df0a89c6360512519aea8a1b30a367a8749b24946fcd2fbbc6cfbbb6562ed6aa16db5d9e76b1872683a841ebda3a16dda6083474c2ea5a81f4e5c04e6af6ed582f58cab36bc016cfcf03337bc64b5411c7cb6f6f55e17d96bfead8becb0b7661768e122c943159ff2854c0e6efdd408b5bd5afc9d629645bfff8d4a240591fa9adc37e4a5bc046fcf31f8088f3616dd2f69860e401221585fd1a5ebe88080742802ae4696b8ba5e826ddd42841dce71b4b3ebe47b1f254103ae49f0bd9d61f5c0193441c471d29535247c26ab9297975497f6051466dbc591c4cd7b4246604e445d7d3a1dd77538c1989a8c48f829c6a1ce0dee84019ef68b7407def2492f5c867f659b0f8f58cc1081706453bf3a1ec719927c6b3defdcc002e9f2f63b4bdb7f69a00db742d2571d7293bae3faffc43ea0ff032e1b262a3597290c6c9117a006c91074a455c80a3a8089d93aed5bd48bd04bb30ad68fc87ff2bb4e5c20fe4bc0ad1b586aef3d1183170dec490c6bc82ec85d4031e292782f8778f21252a7cb6730da2d8fb175017e213eb10527b104bf333767cfed23c7c993391d9029f404947a793c37c1880a6be5cc26cc447ea020db8832239aa09aad9876ec17c4095857971ae2a508e3df70e1feaf8da5da72062d13c5200ab09f43e45d2ba1aac8a56c8e9d033d786cfe3ed7d2b30d8b6124afe2646c7af25b60ed02c3a50b2cb62637461e00b153b92f868f2194b46c49e9a1c9e987d5a32c0018b338777245e733183101027436ea41ea15f61537f38a35109fe6e53806c7913c69f186a86ba1d63997c5301c650089aa888cdf939573b0e7aceefff59757f8ba2275bd4469de04174f1b450a53017260b4bbc4a27cd8aac45d5ff2e5f5ab0eb14ffc59cf0fa10cd32363ef9a9fb9bf68431c4ee1c2ca15797ba4c18dbde24ae451797b25f13a73a231783f72b6f7a429026e191a49619057b250fab6b7010fc58dfcf922b04ad83756e2b8780100dccaafc65e4ef0357c6aae57f4f5c7906072a405407f7f7d43ae313bf54b8d6a8cf716f65390171e39c11c07b4c90e5ae7d5d114b1729d44a3bc58f6e40c413b972e8ab61a8e66502b30df35937f64957c0da0a4080ade204708de9f2c9ae2d\"}\n
Step 2. Sign the transaction using SDK Step 3. Call api: wallet/broadcasttransaction to broadcast the transaction Method: Post Parameters:
{\"signature\":[\"5c1939e2e1177f44a6d168b5e473bd193ea099aa369ffe27727d560f1c72a3226dd4be61c19a09cabbe3f4a7433932df11cf3e54c4fc04cff0eea6906f04c32a00\"],\"txID\":\"1967c40954e8c6c4761c377a021ec3a6ad0545d8b4443f0ccdd1bec4dcbaa497\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"transparent_from_address\":\"41a7d8a35b260395c14aa456297662092ba3b76fc0\",\"binding_signature\":\"5407f7f7d43ae313bf54b8d6a8cf716f65390171e39c11c07b4c90e5ae7d5d114b1729d44a3bc58f6e40c413b972e8ab61a8e66502b30df35937f64957c0da0a\",\"from_amount\":100000000,\"fee\":10000000,\"receive_description\":[{\"value_commitment\":\"5a1cd384edab9c38901d0250ebdf96d4f29889094b7096a7ce2dd6af919afd21\",\"note_commitment\":\"f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b62\",\"epk\":\"e7ff2357376eafdabc6db3fdabc079e42dd14c61a9a08c6cd38405d086086b4b\",\"c_enc\":\"d1aaf220f531f31bd2d9ff6f6d59998e78f3f0d30c852258441c5d54fc6790af7620b8860f6ec48d93fedb4c9bbb0e43c8144a9e304ceee399ac6da0bb91dbace3c8a93e03f1d2a5a88b0998704a09a51ab147096a994420741e87168cda4f45f8ed03c816e947909f2997d48e2ceaed45c539463e5e8caf6a0a1529615afbfa01df0a89c6360512519aea8a1b30a367a8749b24946fcd2fbbc6cfbbb6562ed6aa16db5d9e76b1872683a841ebda3a16dda6083474c2ea5a81f4e5c04e6af6ed582f58cab36bc016cfcf03337bc64b5411c7cb6f6f55e17d96bfead8becb0b7661768e122c943159ff2854c0e6efdd408b5bd5afc9d629645bfff8d4a240591fa9adc37e4a5bc046fcf31f8088f3616dd2f69860e401221585fd1a5ebe88080742802ae4696b8ba5e826ddd42841dce71b4b3ebe47b1f254103ae49f0bd9d61f5c0193441c471d29535247c26ab9297975497f6051466dbc591c4cd7b4246604e445d7d3a1dd77538c1989a8c48f829c6a1ce0dee84019ef68b7407def2492f5c867f659b0f8f58cc1081706453bf3a1ec719927c6b3defdcc002e9f2f63b4bdb7f69a00db742d2571d7293bae3faffc43ea0ff032e1b262a3597290c6c9117a006c91074a455c80a3a8089d93aed5bd48bd04bb30ad68fc87ff2bb4e5c20fe4bc0ad1b586aef3d1183170dec490c6bc82ec85d4031e292782f8778f21252a7cb6730da2d8fb175017e213eb10527b104bf333767cfed23c7c993391d9029f404947a793c37c1880a6be5cc26cc447ea020db8832239aa09aad9876ec17c4095857971ae\",\"c_out\":\"8e3df70e1feaf8da5da72062d13c5200ab09f43e45d2ba1aac8a56c8e9d033d786cfe3ed7d2b30d8b6124afe2646c7af25b60ed02c3a50b2cb62637461e00b153b92f868f2194b46c49e9a1c9e987d5a\",\"zkproof\":\"8b338777245e733183101027436ea41ea15f61537f38a35109fe6e53806c7913c69f186a86ba1d63997c5301c650089aa888cdf939573b0e7aceefff59757f8ba2275bd4469de04174f1b450a53017260b4bbc4a27cd8aac45d5ff2e5f5ab0eb14ffc59cf0fa10cd32363ef9a9fb9bf68431c4ee1c2ca15797ba4c18dbde24ae451797b25f13a73a231783f72b6f7a429026e191a49619057b250fab6b7010fc58dfcf922b04ad83756e2b8780100dccaafc65e4ef0357c6aae57f4f5c790607\"}]},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"0245\",\"ref_block_hash\":\"b1ea272768028540\",\"expiration\":1558691289000,\"timestamp\":1558691230861},\"raw_data_hex\":\"0a0202452208b1ea27276802854040a8aff6c9ae2d5ae708083312e2080a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e747261637412a8080a1541a7d8a35b260395c14aa456297662092ba3b76fc01080c2d72f22c2070a205a1cd384edab9c38901d0250ebdf96d4f29889094b7096a7ce2dd6af919afd211220f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b621a20e7ff2357376eafdabc6db3fdabc079e42dd14c61a9a08c6cd38405d086086b4b22c404d1aaf220f531f31bd2d9ff6f6d59998e78f3f0d30c852258441c5d54fc6790af7620b8860f6ec48d93fedb4c9bbb0e43c8144a9e304ceee399ac6da0bb91dbace3c8a93e03f1d2a5a88b0998704a09a51ab147096a994420741e87168cda4f45f8ed03c816e947909f2997d48e2ceaed45c539463e5e8caf6a0a1529615afbfa01df0a89c6360512519aea8a1b30a367a8749b24946fcd2fbbc6cfbbb6562ed6aa16db5d9e76b1872683a841ebda3a16dda6083474c2ea5a81f4e5c04e6af6ed582f58cab36bc016cfcf03337bc64b5411c7cb6f6f55e17d96bfead8becb0b7661768e122c943159ff2854c0e6efdd408b5bd5afc9d629645bfff8d4a240591fa9adc37e4a5bc046fcf31f8088f3616dd2f69860e401221585fd1a5ebe88080742802ae4696b8ba5e826ddd42841dce71b4b3ebe47b1f254103ae49f0bd9d61f5c0193441c471d29535247c26ab9297975497f6051466dbc591c4cd7b4246604e445d7d3a1dd77538c1989a8c48f829c6a1ce0dee84019ef68b7407def2492f5c867f659b0f8f58cc1081706453bf3a1ec719927c6b3defdcc002e9f2f63b4bdb7f69a00db742d2571d7293bae3faffc43ea0ff032e1b262a3597290c6c9117a006c91074a455c80a3a8089d93aed5bd48bd04bb30ad68fc87ff2bb4e5c20fe4bc0ad1b586aef3d1183170dec490c6bc82ec85d4031e292782f8778f21252a7cb6730da2d8fb175017e213eb10527b104bf333767cfed23c7c993391d9029f404947a793c37c1880a6be5cc26cc447ea020db8832239aa09aad9876ec17c4095857971ae2a508e3df70e1feaf8da5da72062d13c5200ab09f43e45d2ba1aac8a56c8e9d033d786cfe3ed7d2b30d8b6124afe2646c7af25b60ed02c3a50b2cb62637461e00b153b92f868f2194b46c49e9a1c9e987d5a32c0018b338777245e733183101027436ea41ea15f61537f38a35109fe6e53806c7913c69f186a86ba1d63997c5301c650089aa888cdf939573b0e7aceefff59757f8ba2275bd4469de04174f1b450a53017260b4bbc4a27cd8aac45d5ff2e5f5ab0eb14ffc59cf0fa10cd32363ef9a9fb9bf68431c4ee1c2ca15797ba4c18dbde24ae451797b25f13a73a231783f72b6f7a429026e191a49619057b250fab6b7010fc58dfcf922b04ad83756e2b8780100dccaafc65e4ef0357c6aae57f4f5c7906072a405407f7f7d43ae313bf54b8d6a8cf716f65390171e39c11c07b4c90e5ae7d5d114b1729d44a3bc58f6e40c413b972e8ab61a8e66502b30df35937f64957c0da0a4080ade204708de9f2c9ae2d\"}\n
Return: {\"result\": true}\n
"},{"location":"mechanism-algorithm/shielded-transaction/#transfer-from-shielded-address-to-shielded-address","title":"Transfer from shielded address to shielded address","text":"Step 1. Call api: wallet/getmerkletreevoucherinfo to get the voucher of the shield address, this info will be used when create shielded transaction Method: Post Parameter:
{\n \"out_points\":[{\n \"hash\":\"1967c40954e8c6c4761c377a021ec3a6ad0545d8b4443f0ccdd1bec4dcbaa497\",\n \"index\":0\n }],\n \"block_num\":1\n}\n
Return: {\"vouchers\": [{\"tree\": {\"left\": {\"content\": \"7efdc58818923de35ec35b4ef8e6a508f6952b9dd2a86af30a93dcd67e13ed35\"},\"right\": {\"content\": \"f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b62\"}},\"rt\": \"72eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e\"}],\"paths\": [\"2020b2eed031d4d6a4f02a097f80b54cc1541d4163c6b6f5971f88b6e41d35c538142012935f14b676509b81eb49ef25f39269ed72309238b4c145803544b646dca62d20e1f34b034d4a3cd28557e2907ebf990c918f64ecb50a94f01d6fda5ca5c7ef722028e7b841dcbc47cceb69d7cb8d94245fb7cb2ba3a7a6bc18f13f945f7dbd6e2a20a5122c08ff9c161d9ca6fc462073396c7d7d38e8ee48cdb3bea7e2230134ed6a20d2e1642c9a462229289e5b0e3b7f9008e0301cbb93385ee0e21da2545073cb582016d6252968971a83da8521d65382e61f0176646d771c91528e3276ee45383e4a20fee0e52802cb0c46b1eb4d376c62697f4759f6c8917fa352571202fd778fd712204c6937d78f42685f84b43ad3b7b00f81285662f85c6a68ef11d62ad1a3ee0850200769557bc682b1bf308646fd0b22e648e8b9e98f57e29f5af40f6edb833e2c492008eeab0c13abd6069e6310197bf80f9c1ea6de78fd19cbae24d4a520e6cf3023208d5fa43e5a10d11605ac7430ba1f5d81fb1b68d29a640405767749e841527673206aca8448d8263e547d5ff2950e2ed3839e998d31cbc6ac9fd57bc6002b15921620cd1c8dbf6e3acc7a80439bc4962cf25b9dce7c896f3a5bd70803fc5a0e33cf00206edb16d01907b759977d7650dad7e3ec049af1a3d875380b697c862c9ec5d51c201ea6675f9551eeb9dfaaa9247bc9858270d3d3a4c5afa7177a984d5ed1be245120d6acdedf95f608e09fa53fb43dcd0990475726c5131210c9e5caeab97f0e642f20bd74b25aacb92378a871bf27d225cfc26baca344a1ea35fdd94510f3d157082c201b77dac4d24fb7258c3c528704c59430b630718bec486421837021cf75dab65120ec677114c27206f5debc1c1ed66f95e2b1885da5b7be3d736b1de98579473048204777c8776a3b1e69b73a62fa701fa4f7a6282d9aee2c7a6b82e7937d7081c23c20ba49b659fbd0b7334211ea6a9d9df185c757e70aa81da562fb912b84f49bce722043ff5457f13b926b61df552d4e402ee6dc1463f99a535f9a713439264d5b616b207b99abdc3730991cc9274727d7d82d28cb794edbc7034b4f0053ff7c4b68044420d6c639ac24b46bd19341c91b13fdcab31581ddaf7f1411336a271f3d0aa52813208ac9cf9c391e3fd42891d27238a81a8a5c1d3a72b1bcbea8cf44a58ce738961320912d82b2c2bca231f71efcf61737fbf0a08befa0416215aeef53e8bb6d23390a20e110de65c907b9dea4ae0bd83a4b0a51bea175646a64c12b4c9f931b2cb31b4920d8283386ef2ef07ebdbb4383c12a739a953a4d6e0d6fb1139a4036d693bfbb6c20ffe9fc03f18b176c998806439ff0bb8ad193afdb27b2ccbc88856916dd804e3420817de36ab2d57feb077634bca77819c8e0bd298c04f6fed0e6a83cc1356ca155207efdc58818923de35ec35b4ef8e6a508f6952b9dd2a86af30a93dcd67e13ed350100000000000000\"]}\n
Step 2. Call api: wallet/createshieldedtransaction to create transaction Method: Post Parameter: {\n \"ask\": \"f9302122162221f59a7668e0d740245dcabaeb51dd157ba995eecd02f4b60b06\",\n \"nsk\": \"050fc9a42909e60fefb9d548fe12718cb759e3ee28d1b92ceaeaffc23d200a0d\",\n \"ovk\": \"a0da0cc6294dc900e93887b9f08ac42a162234359fdaf523b98382602c92513c\",\n\n \"shielded_spends\": [\n {\n \"note\": {\n \"value\": 90000000,\n \"payment_address\": \"ztron1jld8fmvujrz2vgkc867zuwklmewy4ypw0wtwgweqs2paee0uhc8f3azy90el770arksa2kunl02\",\n \"rcm\": \"e48836a3cfae0e1b27b5230460199b46ebd88ad650fa9db5ac1eafb20b516302\"\n },\n\n\n \"alpha\": \"2608999c3a97d005a879ecdaa16fd29ae434fb67b177c5e875b0c829e6a1db04\",\n \"voucher\": {\"tree\": {\"left\": {\"content\": \"7efdc58818923de35ec35b4ef8e6a508f6952b9dd2a86af30a93dcd67e13ed35\"},\"right\": {\"content\": \"f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b62\"}},\"rt\": \"72eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e\"},\n \"path\": \"2020b2eed031d4d6a4f02a097f80b54cc1541d4163c6b6f5971f88b6e41d35c538142012935f14b676509b81eb49ef25f39269ed72309238b4c145803544b646dca62d20e1f34b034d4a3cd28557e2907ebf990c918f64ecb50a94f01d6fda5ca5c7ef722028e7b841dcbc47cceb69d7cb8d94245fb7cb2ba3a7a6bc18f13f945f7dbd6e2a20a5122c08ff9c161d9ca6fc462073396c7d7d38e8ee48cdb3bea7e2230134ed6a20d2e1642c9a462229289e5b0e3b7f9008e0301cbb93385ee0e21da2545073cb582016d6252968971a83da8521d65382e61f0176646d771c91528e3276ee45383e4a20fee0e52802cb0c46b1eb4d376c62697f4759f6c8917fa352571202fd778fd712204c6937d78f42685f84b43ad3b7b00f81285662f85c6a68ef11d62ad1a3ee0850200769557bc682b1bf308646fd0b22e648e8b9e98f57e29f5af40f6edb833e2c492008eeab0c13abd6069e6310197bf80f9c1ea6de78fd19cbae24d4a520e6cf3023208d5fa43e5a10d11605ac7430ba1f5d81fb1b68d29a640405767749e841527673206aca8448d8263e547d5ff2950e2ed3839e998d31cbc6ac9fd57bc6002b15921620cd1c8dbf6e3acc7a80439bc4962cf25b9dce7c896f3a5bd70803fc5a0e33cf00206edb16d01907b759977d7650dad7e3ec049af1a3d875380b697c862c9ec5d51c201ea6675f9551eeb9dfaaa9247bc9858270d3d3a4c5afa7177a984d5ed1be245120d6acdedf95f608e09fa53fb43dcd0990475726c5131210c9e5caeab97f0e642f20bd74b25aacb92378a871bf27d225cfc26baca344a1ea35fdd94510f3d157082c201b77dac4d24fb7258c3c528704c59430b630718bec486421837021cf75dab65120ec677114c27206f5debc1c1ed66f95e2b1885da5b7be3d736b1de98579473048204777c8776a3b1e69b73a62fa701fa4f7a6282d9aee2c7a6b82e7937d7081c23c20ba49b659fbd0b7334211ea6a9d9df185c757e70aa81da562fb912b84f49bce722043ff5457f13b926b61df552d4e402ee6dc1463f99a535f9a713439264d5b616b207b99abdc3730991cc9274727d7d82d28cb794edbc7034b4f0053ff7c4b68044420d6c639ac24b46bd19341c91b13fdcab31581ddaf7f1411336a271f3d0aa52813208ac9cf9c391e3fd42891d27238a81a8a5c1d3a72b1bcbea8cf44a58ce738961320912d82b2c2bca231f71efcf61737fbf0a08befa0416215aeef53e8bb6d23390a20e110de65c907b9dea4ae0bd83a4b0a51bea175646a64c12b4c9f931b2cb31b4920d8283386ef2ef07ebdbb4383c12a739a953a4d6e0d6fb1139a4036d693bfbb6c20ffe9fc03f18b176c998806439ff0bb8ad193afdb27b2ccbc88856916dd804e3420817de36ab2d57feb077634bca77819c8e0bd298c04f6fed0e6a83cc1356ca155207efdc58818923de35ec35b4ef8e6a508f6952b9dd2a86af30a93dcd67e13ed350100000000000000\"\n\n }\n ],\n \"shielded_receives\": [\n {\n \"note\": {\n \"value\": 80000000,\n \"payment_address\": \"ztron1wd46s6fwmz99gulqpxul6zffqtevzfpl93ng3s5834fhwf6e7w5l6zmjhmpvtwsc4wxa7dusmvr\",\n \"rcm\": \"ccced07d36641fc93cba33cddda7064cb82f6962a0bdf15a4240a4a742770e03\"\n }\n }\n ]\n}\n
Return: {\"txID\":\"5a057fde4a1add0da38eda9978f6c3d035f7ca4807adae4b8c57e34499dfedfb\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"binding_signature\":\"b77c81fdb8af64075a7d95e8f04ef28660bb2f3f2bfb884baf17abd87ae7f212de091016ae6147edbff280b52515a1a52515bd1fa118de2964412f87b6a5790c\",\"spend_description\":[{\"value_commitment\":\"ddc8138f73323eff8d2f0367070c63f5e2659538fa431d6aa06d62696845e529\",\"anchor\":\"72eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e\",\"nullifier\":\"29269506e140e7cc70699443c9b80eb161048ec0126e308d458245991242478c\",\"rk\":\"c76c88d21edb0f5b2b04c960668cf1053feda5954a00d70e7d329025323bf463\",\"spend_authority_signature\":\"518def6477325d78b77b00aac6142bfc7b9a5f3eaaff5b8b4b8f2c46114ed85d1cc15a314028f58ce0c42e9f030f465063bbc0c41d01c92edd639d02575f6b08\",\"zkproof\":\"82eda1b9baeaa5b08b3b33f157ae7a117e2561c702520e615a92e65098615eba1809a20e0b518fef286268d4c6f15a8eaa1b2a15630dd673fcfdde503a12daf80dfc157e6a0ea9333dedc2c365368847f2e7d8e3e648cc65cf5e805cd2343077051d70fcd140a8c665760f8cf066edb32036de7421e6755f3b64f44621aaa47d7e0f2012069ad374a7addb00b841b759b9e567c7b8b2642110eabd22358d22f4d3b4002a1ba4e9f6c018c58a5c1242acbc0169cf4aa0bf1423ed4a0b688928ad\"}],\"fee\":10000000,\"receive_description\":[{\"value_commitment\":\"6b082c7b9d01338d60fc4f5d434a152f9d8bf5c05c22422e23d3c74d36c2b925\",\"note_commitment\":\"e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f02\",\"epk\":\"36b1cb275228b3ab8275d6b04b3e2e93c04d5c0cc0ab1f41421093228b94f758\",\"c_enc\":\"1f91dd5cdf0731c99318a2a87b169b7159230c4dee4e47e8b0717fc51c604ccc7a2df9c873a91903e59528756e2c2f3bd07ec5aa9b994ae5d8492ad779d6a00d4a71e7cb742c1ae416e4d983554fade0e04b0213880da2e96be402a5351ca3a5d78e5a975d20cb5ec1475c7ed35dc09c0b04a3a2e8a65595d8d77652f2881a4b93ed99cff007b3923b36967be6819721ed3daea2190fca744423ffb77d1a579f569bfb30c77ad0dadc0ca484a7a89318e15d50e540744927e19c5f6f08be2e97e77cd9c6ce3e05bdbeeb6f6d7b53f83a2283f56786ea8544c98b648300dfb8554e7a2611204598ddc37c4e61ce5881e63ab171ec83c1aedf97166596d014b1fc8193ff30d4e1c7aff8a3c3638e3a41b2a4040828a8d9568ab0fe4aef08a97872ca84c6c247635a1774efde8b8ed16177393879c8626a8ea0075fa2db5af58754d712ccd5a94dcf87c019faffa2c8f3143a9a9d540de4a705c87fc16dc5efa0c387f1e6ed9dad12b84f2ca7bb09cd95a10a2e412fc410aa7ebf676f6a74f03a7334a0a1697067cc88ccd968bdf6d8c20ed7d7bd9687bda89fb28c2849e45734d30395fead9f955649a3e3f1deb15eb02f28dad608d6d0ef2943ae9fd9e14f2507e9b871a3bebe5d15ba41a8dafc7dd18cd594eb69ad89192e776fc35a3d6eb48c2446d78258fed12cbb61200ddf0c3d2dbbf73fc82a4a2e96f619fa1ad479e6da108ddab453c02fa2fa8e96721585b791f6478966e36d2d75a6677858a64672dde9bb72feb64b58b7723c13c75f70cf7333c3331d46951633a2686b108e48215eb5d56653\",\"c_out\":\"bbbf78f926fa2cae70ed68ef644487c32a82da230b5b8e2be26aa3102627ffc2db26f45f29c2379b20595ef26c60801f33508e17f03f66694cfdf15f606e5fabfe1d76593c1a8543593c10160f4ae4a0\",\"zkproof\":\"b5597534076320a98ef1a546253185011f17cc7d175a8937736bfe1daee1c33e25411346996e64d0bf1887c4553b49bb815cc8ef57b6811e7213b8c7f81c9853a4663703bf2b2989688a9ae5cabcc56c2316d411f6b910722169609d76890a2b0fc9b3fb536c3be378eb4100b925d9ae6a4a9e08eee591066f881c726a0416861ad41f69148619d187ee4d8f0f8b111da8f0d5bd4f781c2ddfdd7e4b3544b09ec2c9548cef85c28cd1129bf60f1f421c9ac7ed7f36b20984038fb33fcb409956\"}]},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"029b\",\"ref_block_hash\":\"027c45a7dc0875f7\",\"expiration\":1558691547000,\"timestamp\":1558691489292},\"raw_data_hex\":\"0a02029b2208027c45a7dc0875f740f88e86caae2d5adb0b083312d60b0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e7472616374129c0b1a8d030a20ddc8138f73323eff8d2f0367070c63f5e2659538fa431d6aa06d62696845e529122072eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e1a2029269506e140e7cc70699443c9b80eb161048ec0126e308d458245991242478c2220c76c88d21edb0f5b2b04c960668cf1053feda5954a00d70e7d329025323bf4632ac00182eda1b9baeaa5b08b3b33f157ae7a117e2561c702520e615a92e65098615eba1809a20e0b518fef286268d4c6f15a8eaa1b2a15630dd673fcfdde503a12daf80dfc157e6a0ea9333dedc2c365368847f2e7d8e3e648cc65cf5e805cd2343077051d70fcd140a8c665760f8cf066edb32036de7421e6755f3b64f44621aaa47d7e0f2012069ad374a7addb00b841b759b9e567c7b8b2642110eabd22358d22f4d3b4002a1ba4e9f6c018c58a5c1242acbc0169cf4aa0bf1423ed4a0b688928ad3240518def6477325d78b77b00aac6142bfc7b9a5f3eaaff5b8b4b8f2c46114ed85d1cc15a314028f58ce0c42e9f030f465063bbc0c41d01c92edd639d02575f6b0822c2070a206b082c7b9d01338d60fc4f5d434a152f9d8bf5c05c22422e23d3c74d36c2b9251220e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f021a2036b1cb275228b3ab8275d6b04b3e2e93c04d5c0cc0ab1f41421093228b94f75822c4041f91dd5cdf0731c99318a2a87b169b7159230c4dee4e47e8b0717fc51c604ccc7a2df9c873a91903e59528756e2c2f3bd07ec5aa9b994ae5d8492ad779d6a00d4a71e7cb742c1ae416e4d983554fade0e04b0213880da2e96be402a5351ca3a5d78e5a975d20cb5ec1475c7ed35dc09c0b04a3a2e8a65595d8d77652f2881a4b93ed99cff007b3923b36967be6819721ed3daea2190fca744423ffb77d1a579f569bfb30c77ad0dadc0ca484a7a89318e15d50e540744927e19c5f6f08be2e97e77cd9c6ce3e05bdbeeb6f6d7b53f83a2283f56786ea8544c98b648300dfb8554e7a2611204598ddc37c4e61ce5881e63ab171ec83c1aedf97166596d014b1fc8193ff30d4e1c7aff8a3c3638e3a41b2a4040828a8d9568ab0fe4aef08a97872ca84c6c247635a1774efde8b8ed16177393879c8626a8ea0075fa2db5af58754d712ccd5a94dcf87c019faffa2c8f3143a9a9d540de4a705c87fc16dc5efa0c387f1e6ed9dad12b84f2ca7bb09cd95a10a2e412fc410aa7ebf676f6a74f03a7334a0a1697067cc88ccd968bdf6d8c20ed7d7bd9687bda89fb28c2849e45734d30395fead9f955649a3e3f1deb15eb02f28dad608d6d0ef2943ae9fd9e14f2507e9b871a3bebe5d15ba41a8dafc7dd18cd594eb69ad89192e776fc35a3d6eb48c2446d78258fed12cbb61200ddf0c3d2dbbf73fc82a4a2e96f619fa1ad479e6da108ddab453c02fa2fa8e96721585b791f6478966e36d2d75a6677858a64672dde9bb72feb64b58b7723c13c75f70cf7333c3331d46951633a2686b108e48215eb5d566532a50bbbf78f926fa2cae70ed68ef644487c32a82da230b5b8e2be26aa3102627ffc2db26f45f29c2379b20595ef26c60801f33508e17f03f66694cfdf15f606e5fabfe1d76593c1a8543593c10160f4ae4a032c001b5597534076320a98ef1a546253185011f17cc7d175a8937736bfe1daee1c33e25411346996e64d0bf1887c4553b49bb815cc8ef57b6811e7213b8c7f81c9853a4663703bf2b2989688a9ae5cabcc56c2316d411f6b910722169609d76890a2b0fc9b3fb536c3be378eb4100b925d9ae6a4a9e08eee591066f881c726a0416861ad41f69148619d187ee4d8f0f8b111da8f0d5bd4f781c2ddfdd7e4b3544b09ec2c9548cef85c28cd1129bf60f1f421c9ac7ed7f36b20984038fb33fcb4099562a40b77c81fdb8af64075a7d95e8f04ef28660bb2f3f2bfb884baf17abd87ae7f212de091016ae6147edbff280b52515a1a52515bd1fa118de2964412f87b6a5790c4080ade204708ccc82caae2d\"}\n
Step 3. Call api: wallet/broadcasttransaction to broadcast this transaction(no need to sign this transaction) Method: Post Parameter: {\"txID\":\"791d30b7123448a54c56407a11857d4f3885cb699a071ee5f265f7db408dec6c\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"binding_signature\":\"231cc2ddbf2715b51d07ed63e142ad874e7e173ec0c5d681b49e3060ca33bd65cf39921355dfaacc62dac7aa810c49daafbf8db8a1adc168da4a833eba0d7504\",\"spend_description\":[{\"value_commitment\":\"f4c543df8f0fe9b71b1bbd6aa2f06f87e07605dcd339b0eaa48afd9e2488b140\",\"anchor\":\"72eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e\",\"nullifier\":\"29269506e140e7cc70699443c9b80eb161048ec0126e308d458245991242478c\",\"rk\":\"c76c88d21edb0f5b2b04c960668cf1053feda5954a00d70e7d329025323bf463\",\"spend_authority_signature\":\"2f50449f92e4bf541c9ba7d82b93f6dd416208449ea8996dc45614c1cb90a7911264fece30446da875d8a864224f1a3870e3654ec8a4005305faa329224f4c08\",\"zkproof\":\"984779ad18c87d71dd79b78564e49c1c18d6f871ef45f79bdb012f73439d6402593dd7cda308d9d5412e2b64b0be461192eb2a8d2ffdcc700475a1c8b8912220f628af41bf44a7c010a8dda2a65f98b4aaf8c375c4046afd1af3e6bbe4b33b9210c68298f46999322174b9ba76b0be4d6ef2c74ff5d16370a8c30fa17c5c3bbeab217610de5cc680b1d64d557c4d53a4a3f73294699ac6a00b37c3d8076a20362ab09c77c94f08bb00db2648ade72f224821ecc190627222cf58130b9bcf639b\"}],\"fee\":10000000,\"receive_description\":[{\"value_commitment\":\"3f4465801b357f9b8334eb3025bd8b3cd84247355c099133c08d53a8cffd3595\",\"note_commitment\":\"e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f02\",\"epk\":\"3ece31615aec76e7711e25b05b05f5b7fb99d75f3812fe56702291633e5f474c\",\"c_enc\":\"4fc57e65bfdd91e2ae0284cfc2926d5df63d51b8f864e9191f368404db390e28ce15fefc9bd210aca4e7f42b30140bc4b1650d9a79bcbfb1670288c68d4678ba5c34266ce1bd4fd1f4e4040508b072cdca87d69e4921af8c8305f982aa7f37897a29c69cce06c311eafb2ef5928f07d5b8f207e5f46c32237f6e9b0eadc2597e0cd8d884cd3f4a35d86145e75565913b9d4a2e613523c9f377fe3bdf6f1d9e6789605e6bdaf9526412632e52a1994fec98dd086596c62ba028508d45933943f3446c83f463f56e860f29d2ea0eb3b87a55a0602974b7df6b58905872cb97a757f24515f05d2b12d932a0ac038e0c0b15b9c8b324c8e31d4ddf8bf39bfb65bd9d495eac1818b281822c9ad85adbe8a90f62adfbb6723fae7a7d91760a5b2d146f180d5ca4d85653449089f4788459752e899abd4abd395842e8b5315dd3738eee0b4e0f758698aabb92df587b703e85774048f290ea366696de3dde665eefb6fce6c2776e4e9ad18662b8d95af4203a10e9af54085ee498c77ad7e7b5824f91aaeb8f138d8c90d95f57e71dc15c177b602c45e38f12e402cc65c2c55b80c9a7d908332baa30b2871a0d6cf417bcaf0be6ae5c451c2468e945273151da500aaccd7235a29c7fcd0da4ac4d6ceefda59cf568f7a362b49654a5793c552bd970681a6489a1951ad75e22215b22d5cd511a030d751892b4b5746d66f048d6b6889c2ddcd5da908417b91ef52c0507b2ce8b1214567b71963c5d6ace1f6e858ce02b11fcf0f839cbe8183fa71b9a239f70c5e98642f6e9b9b6eb31f12a752829ebecf0f12df040\",\"c_out\":\"5fc1926bb6501f8ec4dc796d56786d7f019db9e43ccde07bbbddd95444df4f099310ef3f8d86a0a25ff72de0385563e44b9cb9e5e477299891959d24060a3b08b41aa36c29ce7297f0806a74f11aa99e\",\"zkproof\":\"b924ae84aba3af2c4d6529c22ebd6ba900ac63c629723e035ab843295d41aec1e9ebb2906fa7471473dbdae7e182fbd7a9f14a2f599a79456a3dbb949203d9923c3c3600225f12217e38b69b88a080b5b5751d78ac84375c9a03ad0bc61492850c49488a654c376c49701abdde20d5658bce851e9a6fd1bee5429b9b4d4b55ed1eb888a43f435740b8f063ea6e2e7e81b53f12e67e3eac60020aab5c3ff45d34ff2c3dde4eb76ed2893df22232993deb1b9397d1d4f9cc1eb8405f7cbef5a24b\"}]},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"0328\",\"ref_block_hash\":\"833c24d9f1019cd0\",\"expiration\":1558691970000,\"timestamp\":1558691911355},\"raw_data_hex\":\"0a0203282208833c24d9f1019cd040d0f79fcaae2d5adb0b083312d60b0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e7472616374129c0b1a8d030a20f4c543df8f0fe9b71b1bbd6aa2f06f87e07605dcd339b0eaa48afd9e2488b140122072eca442bd775b022636fb9ae967c8e749c002660133e76193680d7f8b81fc0e1a2029269506e140e7cc70699443c9b80eb161048ec0126e308d458245991242478c2220c76c88d21edb0f5b2b04c960668cf1053feda5954a00d70e7d329025323bf4632ac001984779ad18c87d71dd79b78564e49c1c18d6f871ef45f79bdb012f73439d6402593dd7cda308d9d5412e2b64b0be461192eb2a8d2ffdcc700475a1c8b8912220f628af41bf44a7c010a8dda2a65f98b4aaf8c375c4046afd1af3e6bbe4b33b9210c68298f46999322174b9ba76b0be4d6ef2c74ff5d16370a8c30fa17c5c3bbeab217610de5cc680b1d64d557c4d53a4a3f73294699ac6a00b37c3d8076a20362ab09c77c94f08bb00db2648ade72f224821ecc190627222cf58130b9bcf639b32402f50449f92e4bf541c9ba7d82b93f6dd416208449ea8996dc45614c1cb90a7911264fece30446da875d8a864224f1a3870e3654ec8a4005305faa329224f4c0822c2070a203f4465801b357f9b8334eb3025bd8b3cd84247355c099133c08d53a8cffd35951220e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f021a203ece31615aec76e7711e25b05b05f5b7fb99d75f3812fe56702291633e5f474c22c4044fc57e65bfdd91e2ae0284cfc2926d5df63d51b8f864e9191f368404db390e28ce15fefc9bd210aca4e7f42b30140bc4b1650d9a79bcbfb1670288c68d4678ba5c34266ce1bd4fd1f4e4040508b072cdca87d69e4921af8c8305f982aa7f37897a29c69cce06c311eafb2ef5928f07d5b8f207e5f46c32237f6e9b0eadc2597e0cd8d884cd3f4a35d86145e75565913b9d4a2e613523c9f377fe3bdf6f1d9e6789605e6bdaf9526412632e52a1994fec98dd086596c62ba028508d45933943f3446c83f463f56e860f29d2ea0eb3b87a55a0602974b7df6b58905872cb97a757f24515f05d2b12d932a0ac038e0c0b15b9c8b324c8e31d4ddf8bf39bfb65bd9d495eac1818b281822c9ad85adbe8a90f62adfbb6723fae7a7d91760a5b2d146f180d5ca4d85653449089f4788459752e899abd4abd395842e8b5315dd3738eee0b4e0f758698aabb92df587b703e85774048f290ea366696de3dde665eefb6fce6c2776e4e9ad18662b8d95af4203a10e9af54085ee498c77ad7e7b5824f91aaeb8f138d8c90d95f57e71dc15c177b602c45e38f12e402cc65c2c55b80c9a7d908332baa30b2871a0d6cf417bcaf0be6ae5c451c2468e945273151da500aaccd7235a29c7fcd0da4ac4d6ceefda59cf568f7a362b49654a5793c552bd970681a6489a1951ad75e22215b22d5cd511a030d751892b4b5746d66f048d6b6889c2ddcd5da908417b91ef52c0507b2ce8b1214567b71963c5d6ace1f6e858ce02b11fcf0f839cbe8183fa71b9a239f70c5e98642f6e9b9b6eb31f12a752829ebecf0f12df0402a505fc1926bb6501f8ec4dc796d56786d7f019db9e43ccde07bbbddd95444df4f099310ef3f8d86a0a25ff72de0385563e44b9cb9e5e477299891959d24060a3b08b41aa36c29ce7297f0806a74f11aa99e32c001b924ae84aba3af2c4d6529c22ebd6ba900ac63c629723e035ab843295d41aec1e9ebb2906fa7471473dbdae7e182fbd7a9f14a2f599a79456a3dbb949203d9923c3c3600225f12217e38b69b88a080b5b5751d78ac84375c9a03ad0bc61492850c49488a654c376c49701abdde20d5658bce851e9a6fd1bee5429b9b4d4b55ed1eb888a43f435740b8f063ea6e2e7e81b53f12e67e3eac60020aab5c3ff45d34ff2c3dde4eb76ed2893df22232993deb1b9397d1d4f9cc1eb8405f7cbef5a24b2a40231cc2ddbf2715b51d07ed63e142ad874e7e173ec0c5d681b49e3060ca33bd65cf39921355dfaacc62dac7aa810c49daafbf8db8a1adc168da4a833eba0d75044080ade20470bbad9ccaae2d\"}\n
Return: {\"result\": true}\n
"},{"location":"mechanism-algorithm/shielded-transaction/#transfer-from-shielded-address-to-transparent-address","title":"Transfer from shielded address to transparent address","text":"Step 1. Call api: wallet/getmerkletreevoucherinfo to get the voucher of the shield address, this info will be used when create shielded transaction Method: Post Parameter:
{\n \"out_points\":[{\n \"hash\":\"791d30b7123448a54c56407a11857d4f3885cb699a071ee5f265f7db408dec6c\",\n \"index\":0\n }],\n \"block_num\":1\n}\n
Return: {\"vouchers\": [{\"tree\": {\"left\": {\"content\": \"e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f02\"},\"parents\": [{\"content\": \"c835053e32be73852e67a65f4cd40407a11f4a7a38bb84b8d3e8a1f57acdbf61\"}]},\"rt\": \"8bdf96ac1241f30d5cd54d4ece7f10867d9eef854121ef77d1015f0ab2a26b1b\"}],\"paths\": [\"2020b2eed031d4d6a4f02a097f80b54cc1541d4163c6b6f5971f88b6e41d35c538142012935f14b676509b81eb49ef25f39269ed72309238b4c145803544b646dca62d20e1f34b034d4a3cd28557e2907ebf990c918f64ecb50a94f01d6fda5ca5c7ef722028e7b841dcbc47cceb69d7cb8d94245fb7cb2ba3a7a6bc18f13f945f7dbd6e2a20a5122c08ff9c161d9ca6fc462073396c7d7d38e8ee48cdb3bea7e2230134ed6a20d2e1642c9a462229289e5b0e3b7f9008e0301cbb93385ee0e21da2545073cb582016d6252968971a83da8521d65382e61f0176646d771c91528e3276ee45383e4a20fee0e52802cb0c46b1eb4d376c62697f4759f6c8917fa352571202fd778fd712204c6937d78f42685f84b43ad3b7b00f81285662f85c6a68ef11d62ad1a3ee0850200769557bc682b1bf308646fd0b22e648e8b9e98f57e29f5af40f6edb833e2c492008eeab0c13abd6069e6310197bf80f9c1ea6de78fd19cbae24d4a520e6cf3023208d5fa43e5a10d11605ac7430ba1f5d81fb1b68d29a640405767749e841527673206aca8448d8263e547d5ff2950e2ed3839e998d31cbc6ac9fd57bc6002b15921620cd1c8dbf6e3acc7a80439bc4962cf25b9dce7c896f3a5bd70803fc5a0e33cf00206edb16d01907b759977d7650dad7e3ec049af1a3d875380b697c862c9ec5d51c201ea6675f9551eeb9dfaaa9247bc9858270d3d3a4c5afa7177a984d5ed1be245120d6acdedf95f608e09fa53fb43dcd0990475726c5131210c9e5caeab97f0e642f20bd74b25aacb92378a871bf27d225cfc26baca344a1ea35fdd94510f3d157082c201b77dac4d24fb7258c3c528704c59430b630718bec486421837021cf75dab65120ec677114c27206f5debc1c1ed66f95e2b1885da5b7be3d736b1de98579473048204777c8776a3b1e69b73a62fa701fa4f7a6282d9aee2c7a6b82e7937d7081c23c20ba49b659fbd0b7334211ea6a9d9df185c757e70aa81da562fb912b84f49bce722043ff5457f13b926b61df552d4e402ee6dc1463f99a535f9a713439264d5b616b207b99abdc3730991cc9274727d7d82d28cb794edbc7034b4f0053ff7c4b68044420d6c639ac24b46bd19341c91b13fdcab31581ddaf7f1411336a271f3d0aa52813208ac9cf9c391e3fd42891d27238a81a8a5c1d3a72b1bcbea8cf44a58ce738961320912d82b2c2bca231f71efcf61737fbf0a08befa0416215aeef53e8bb6d23390a20e110de65c907b9dea4ae0bd83a4b0a51bea175646a64c12b4c9f931b2cb31b4920d8283386ef2ef07ebdbb4383c12a739a953a4d6e0d6fb1139a4036d693bfbb6c20ffe9fc03f18b176c998806439ff0bb8ad193afdb27b2ccbc88856916dd804e3420c835053e32be73852e67a65f4cd40407a11f4a7a38bb84b8d3e8a1f57acdbf612001000000000000000000000000000000000000000000000000000000000000000200000000000000\"]}\n
Step 2. Call api: wallet/createshieldedtransaction to create transaction Method: Post Parameter:
{\n \"ask\": \"653b3a3fdd40b60d2f53ba121df8840f6590384993f8fa9a0ecb0dfb23496604\",\n \"nsk\": \"428ff3c9e101dc1fca08f7b0e3387b23b68016746ae565aefc19d112b696db01\",\n \"ovk\": \"1274dcc5c7307bf0fd0ead466e9dd5641fed4a51391f681862370e2f2654cc61\",\n \"shielded_spends\": [\n {\n \"note\": {\n \"value\": 80000000,\n \"payment_address\": \"ztron1wd46s6fwmz99gulqpxul6zffqtevzfpl93ng3s5834fhwf6e7w5l6zmjhmpvtwsc4wxa7dusmvr\",\n \"rcm\": \"ccced07d36641fc93cba33cddda7064cb82f6962a0bdf15a4240a4a742770e03\"\n },\n \"alpha\": \"3ad5406efd6efcd81d27696d5f91efc07ba5c98ea6fb0f787b93e557b51df405\",\n \"voucher\": {\n \"tree\": {\n \"left\": {\n \"content\": \"f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b62\"\n },\n \"right\": {\n \"content\": \"e4d02525ef586e77765e5cde77c4a25f8393508e749c2398aa91b8cea0a14f02\"\n }\n },\n \"rt\": \"774d05ec02749475672a94a8fb2daaa11c323defa09df121b7359353f0c3a567\"\n },\n \"path\": \"2020b2eed031d4d6a4f02a097f80b54cc1541d4163c6b6f5971f88b6e41d35c538142012935f14b676509b81eb49ef25f39269ed72309238b4c145803544b646dca62d20e1f34b034d4a3cd28557e2907ebf990c918f64ecb50a94f01d6fda5ca5c7ef722028e7b841dcbc47cceb69d7cb8d94245fb7cb2ba3a7a6bc18f13f945f7dbd6e2a20a5122c08ff9c161d9ca6fc462073396c7d7d38e8ee48cdb3bea7e2230134ed6a20d2e1642c9a462229289e5b0e3b7f9008e0301cbb93385ee0e21da2545073cb582016d6252968971a83da8521d65382e61f0176646d771c91528e3276ee45383e4a20fee0e52802cb0c46b1eb4d376c62697f4759f6c8917fa352571202fd778fd712204c6937d78f42685f84b43ad3b7b00f81285662f85c6a68ef11d62ad1a3ee0850200769557bc682b1bf308646fd0b22e648e8b9e98f57e29f5af40f6edb833e2c492008eeab0c13abd6069e6310197bf80f9c1ea6de78fd19cbae24d4a520e6cf3023208d5fa43e5a10d11605ac7430ba1f5d81fb1b68d29a640405767749e841527673206aca8448d8263e547d5ff2950e2ed3839e998d31cbc6ac9fd57bc6002b15921620cd1c8dbf6e3acc7a80439bc4962cf25b9dce7c896f3a5bd70803fc5a0e33cf00206edb16d01907b759977d7650dad7e3ec049af1a3d875380b697c862c9ec5d51c201ea6675f9551eeb9dfaaa9247bc9858270d3d3a4c5afa7177a984d5ed1be245120d6acdedf95f608e09fa53fb43dcd0990475726c5131210c9e5caeab97f0e642f20bd74b25aacb92378a871bf27d225cfc26baca344a1ea35fdd94510f3d157082c201b77dac4d24fb7258c3c528704c59430b630718bec486421837021cf75dab65120ec677114c27206f5debc1c1ed66f95e2b1885da5b7be3d736b1de98579473048204777c8776a3b1e69b73a62fa701fa4f7a6282d9aee2c7a6b82e7937d7081c23c20ba49b659fbd0b7334211ea6a9d9df185c757e70aa81da562fb912b84f49bce722043ff5457f13b926b61df552d4e402ee6dc1463f99a535f9a713439264d5b616b207b99abdc3730991cc9274727d7d82d28cb794edbc7034b4f0053ff7c4b68044420d6c639ac24b46bd19341c91b13fdcab31581ddaf7f1411336a271f3d0aa52813208ac9cf9c391e3fd42891d27238a81a8a5c1d3a72b1bcbea8cf44a58ce738961320912d82b2c2bca231f71efcf61737fbf0a08befa0416215aeef53e8bb6d23390a20e110de65c907b9dea4ae0bd83a4b0a51bea175646a64c12b4c9f931b2cb31b4920d8283386ef2ef07ebdbb4383c12a739a953a4d6e0d6fb1139a4036d693bfbb6c20ffe9fc03f18b176c998806439ff0bb8ad193afdb27b2ccbc88856916dd804e3420817de36ab2d57feb077634bca77819c8e0bd298c04f6fed0e6a83cc1356ca15520f21a987214b4aa8f041e6a8fde656396dbbf7ce6ee3394b6f9fbfb43f0e39b620100000000000000\"\n }\n ],\n \"transparent_to_address\": \"41A7D8A35B260395C14AA456297662092BA3B76FC0\",\n \"to_amount\": 70000000\n}\n
Return: {\"txID\":\"4dbdc95574a155434baeaf5e690e2d0c77a2b883a048d8d0103ab5c7fed8d866\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"to_amount\":70000000,\"binding_signature\":\"780be5a118c7b96847a6b1932f1ab6f559ce3648e321821f22570dbde7d59c58559aae93a2f334537544b6c85218c83397b0779926247848560c3e9ef5ba8203\",\"spend_description\":[{\"value_commitment\":\"086c712a60d5aa0d16276fb18b5504a875d97cecb2a0afa8219c8031aec94bd9\",\"anchor\":\"774d05ec02749475672a94a8fb2daaa11c323defa09df121b7359353f0c3a567\",\"nullifier\":\"fa07f704bd34a8a7c1804601f322e6c1415247bfaa2f0d04715b9b4ac65b3587\",\"rk\":\"41132c4e6bc24faae1cb8cdee2c7f84bd4b3aa27e50c099ca205c1c0538ca2d4\",\"spend_authority_signature\":\"b928f855d397ab758b60251ee3ce40f951df51a6111064ad90fe4aa467cd69ec649c55ebb59c034c0c72daca0e9063da72383108942c79f7bd1b0f6b22f30207\",\"zkproof\":\"b3552325eb9212097ba3f56a4e0770c92cd28a8d6974e3a30436115b2a49adae7e1f49a0f2920042145bfe4a127ada22b3000ba0faa15b408340ca5c377943e3b3c8566ad471d84321b9d24c0a47b6b42b83d562523b07a16401cb5f4e51aa040b1300f443d963150db7f08b2606f3e17ba386d1308720c20901d74e8b94b47a78c00f416c71b4fffed1fd6d7b41ebb0993bbd1fa05754514d05575e09ce8f6a6438b8b158a1067d01b195c6631b25434f64360aedcdcfacb163efe866a05ee1\"}],\"fee\":10000000,\"transparent_to_address\":\"41a7d8a35b260395c14aa456297662092ba3b76fc0\"},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"00dc\",\"ref_block_hash\":\"a45c748f93fa2854\",\"expiration\":1558928754000,\"timestamp\":1558928695327},\"raw_data_hex\":\"0a0200dc2208a45c748f93fa285440d08a94bbaf2d5ab204083312ad040a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e747261637412f3031a8d030a20086c712a60d5aa0d16276fb18b5504a875d97cecb2a0afa8219c8031aec94bd91220774d05ec02749475672a94a8fb2daaa11c323defa09df121b7359353f0c3a5671a20fa07f704bd34a8a7c1804601f322e6c1415247bfaa2f0d04715b9b4ac65b3587222041132c4e6bc24faae1cb8cdee2c7f84bd4b3aa27e50c099ca205c1c0538ca2d42ac001b3552325eb9212097ba3f56a4e0770c92cd28a8d6974e3a30436115b2a49adae7e1f49a0f2920042145bfe4a127ada22b3000ba0faa15b408340ca5c377943e3b3c8566ad471d84321b9d24c0a47b6b42b83d562523b07a16401cb5f4e51aa040b1300f443d963150db7f08b2606f3e17ba386d1308720c20901d74e8b94b47a78c00f416c71b4fffed1fd6d7b41ebb0993bbd1fa05754514d05575e09ce8f6a6438b8b158a1067d01b195c6631b25434f64360aedcdcfacb163efe866a05ee13240b928f855d397ab758b60251ee3ce40f951df51a6111064ad90fe4aa467cd69ec649c55ebb59c034c0c72daca0e9063da72383108942c79f7bd1b0f6b22f302072a40780be5a118c7b96847a6b1932f1ab6f559ce3648e321821f22570dbde7d59c58559aae93a2f334537544b6c85218c83397b0779926247848560c3e9ef5ba8203321541a7d8a35b260395c14aa456297662092ba3b76fc03880bbb0214080ade204709fc090bbaf2d\"}\n
Step 3. Call api: wallet/broadcasttransaction to broadcast this transaction(no need to sign this transaction) Method: Post Parameter:
{\"txID\":\"4dbdc95574a155434baeaf5e690e2d0c77a2b883a048d8d0103ab5c7fed8d866\",\"raw_data\":{\"contract\":[{\"parameter\":{\"value\":{\"to_amount\":70000000,\"binding_signature\":\"780be5a118c7b96847a6b1932f1ab6f559ce3648e321821f22570dbde7d59c58559aae93a2f334537544b6c85218c83397b0779926247848560c3e9ef5ba8203\",\"spend_description\":[{\"value_commitment\":\"086c712a60d5aa0d16276fb18b5504a875d97cecb2a0afa8219c8031aec94bd9\",\"anchor\":\"774d05ec02749475672a94a8fb2daaa11c323defa09df121b7359353f0c3a567\",\"nullifier\":\"fa07f704bd34a8a7c1804601f322e6c1415247bfaa2f0d04715b9b4ac65b3587\",\"rk\":\"41132c4e6bc24faae1cb8cdee2c7f84bd4b3aa27e50c099ca205c1c0538ca2d4\",\"spend_authority_signature\":\"b928f855d397ab758b60251ee3ce40f951df51a6111064ad90fe4aa467cd69ec649c55ebb59c034c0c72daca0e9063da72383108942c79f7bd1b0f6b22f30207\",\"zkproof\":\"b3552325eb9212097ba3f56a4e0770c92cd28a8d6974e3a30436115b2a49adae7e1f49a0f2920042145bfe4a127ada22b3000ba0faa15b408340ca5c377943e3b3c8566ad471d84321b9d24c0a47b6b42b83d562523b07a16401cb5f4e51aa040b1300f443d963150db7f08b2606f3e17ba386d1308720c20901d74e8b94b47a78c00f416c71b4fffed1fd6d7b41ebb0993bbd1fa05754514d05575e09ce8f6a6438b8b158a1067d01b195c6631b25434f64360aedcdcfacb163efe866a05ee1\"}],\"fee\":10000000,\"transparent_to_address\":\"41a7d8a35b260395c14aa456297662092ba3b76fc0\"},\"type_url\":\"type.googleapis.com/protocol.ShieldedTransferContract\"},\"type\":\"ShieldedTransferContract\"}],\"ref_block_bytes\":\"00dc\",\"ref_block_hash\":\"a45c748f93fa2854\",\"expiration\":1558928754000,\"timestamp\":1558928695327},\"raw_data_hex\":\"0a0200dc2208a45c748f93fa285440d08a94bbaf2d5ab204083312ad040a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e536869656c6465645472616e73666572436f6e747261637412f3031a8d030a20086c712a60d5aa0d16276fb18b5504a875d97cecb2a0afa8219c8031aec94bd91220774d05ec02749475672a94a8fb2daaa11c323defa09df121b7359353f0c3a5671a20fa07f704bd34a8a7c1804601f322e6c1415247bfaa2f0d04715b9b4ac65b3587222041132c4e6bc24faae1cb8cdee2c7f84bd4b3aa27e50c099ca205c1c0538ca2d42ac001b3552325eb9212097ba3f56a4e0770c92cd28a8d6974e3a30436115b2a49adae7e1f49a0f2920042145bfe4a127ada22b3000ba0faa15b408340ca5c377943e3b3c8566ad471d84321b9d24c0a47b6b42b83d562523b07a16401cb5f4e51aa040b1300f443d963150db7f08b2606f3e17ba386d1308720c20901d74e8b94b47a78c00f416c71b4fffed1fd6d7b41ebb0993bbd1fa05754514d05575e09ce8f6a6438b8b158a1067d01b195c6631b25434f64360aedcdcfacb163efe866a05ee13240b928f855d397ab758b60251ee3ce40f951df51a6111064ad90fe4aa467cd69ec649c55ebb59c034c0c72daca0e9063da72383108942c79f7bd1b0f6b22f302072a40780be5a118c7b96847a6b1932f1ab6f559ce3648e321821f22570dbde7d59c58559aae93a2f334537544b6c85218c83397b0779926247848560c3e9ef5ba8203321541a7d8a35b260395c14aa456297662092ba3b76fc03880bbb0214080ade204709fc090bbaf2d\"}\n
Return: {\"result\": true}\n
"},{"location":"mechanism-algorithm/sr/","title":"Super Representative","text":""},{"location":"mechanism-algorithm/sr/#how-to-become-a-super-representative","title":"How to Become a Super Representative","text":"Block producers in the TRON network, also called super representatives, are elected by voting. Any account can apply to become a super representative candidate by paying 9999 TRX and then participate in the super representative election. Any account can vote for super representative candidates, and the top 27 candidates with the most votes become super representatives, and they have the right to produce blocks. Super representative needs to run a TRON node to participate in block production, and will also receive block rewards and voting rewards. Voters who vote to super representatives will receive voting rewards.
The super representative candidates ranked 28th to 127th are also called super representative partners. Super representative partners do not participate in block production and packaging transactions, but will receive voting rewards. Voters who vote to super representative partners will also receive voting rewards.
The votes will be counted every 6 hours, so super representatives and super representative partners will be changed every 6 hours.
"},{"location":"mechanism-algorithm/sr/#super-representative-election","title":"Super Representative Election","text":"To vote, you need to have TRON Power(TP). To get TRON Power, you need to stake TRX. Every 1 staked TRX accounts for one TRON Power(TP). Every account in TRON network has the right to vote for a super representative candidate. After you unstake your staked TRX, you will lose the corresponding TRON Power(TP), so your previous vote will be invalid.
Note: Only your latest vote will be counted in TRON network which means your previous vote will be over written by your latest vote.
Example (Using wallet-cli):
> freezebalancev2 10,000,000 3 // Stake 10 TRX to get 10 TRON Power(TP)\n> votewitness SR1 4 SR2 6 // Vote 4 votes for SR1, 6 votes for SR2\n> votewitness SR1 3 SR2 7 // Vote 3 votes for SR1, 7 votes for SR2\n
The final output above is: Vote 3 votes for SR1, 7 votes for SR2.
"},{"location":"mechanism-algorithm/sr/#super-representatives-brokerage","title":"Super Representatives Brokerage","text":"The default ratio is 20%. Super representatives and super representative partners can query the brokerage ratio through the wallet/getBrokerage interface, and can also modify the brokerage ratio through the wallet/updateBrokerage interface.
If a SR(Super Representatives) get 20% of the rewards, and the other 80% will be awarded to the voters. If the brokerage ratio is set to 100%, the rewards are all obtained by the SR; if set to 0, the rewards are all sent to the voters.
"},{"location":"mechanism-algorithm/sr/#rewards-for-srsuper-representatives","title":"Rewards for SR(Super Representatives)","text":"The following calculations are all based on the situation where brokerage ratio is equal to 20%.
"},{"location":"mechanism-algorithm/sr/#vote-rewards","title":"Vote Rewards","text":"Vote rewards are 160 TRX for every block, with a block generated every 3 seconds, the total vote rewards per day is 4,608,000 TRX.
For each SR and Partner, the daily vote rewards = 4,608,000 * ( votes / total votes) x 20% TRX
"},{"location":"mechanism-algorithm/sr/#block-producing-rewards","title":"Block Producing Rewards","text":"Every time after a super representative produces a block, it will be rewarded 16 TRX. The 27 super representatives take turns to produce blocks every 3 seconds. The annual block producing rewards is 168,192,000 TRX in total.
Every time after a super representative produces a block, the 16 TRX block producing rewards will be sent to it's sub-account. The sub-account is a read-only account, it allows a withdraw action from sub-account to super representative account every 24 hours.
The daily total block producing rewards = 16 (TRX/block) * 28,800 (blocks/day) = 460,800 (TRX/day)
For each super representative, the daily block producing rewards = (460,800 / 27) * 20%TRX.
Rewards may be less than the theoretical number due to missed blocks and maintenance period.
"},{"location":"mechanism-algorithm/sr/#rewards-for-voter","title":"Rewards for Voter","text":"If you vote for a SR(Super Representative), you will have both vote rewards and block producing rewards:
vote rewards = ((the number of votes you vote to a SR / total votes) * 4,608,000 * 80%) TRX
block producing rewards = ((the number of votes you vote to a SR) / (the total number of votes a SR receives) * ((460,800 / 27) * 80%)) TRX
daily rewards for voter = vote rewards + block producing rewards
If you vote for a SR Partner, you will only have vote rewards:
daily rewards for voter = (((the number of votes you vote to a SR Partner) * 4,608,000 / total votes) * 80%) TRX
Notice: the above total votes refers to the combined votes of SRs and SR Partners, not including SR Candidates
"},{"location":"mechanism-algorithm/sr/#committee","title":"Committee","text":""},{"location":"mechanism-algorithm/sr/#what-is-committee","title":"What is Committee","text":"Committee can modify the TRON network parameters, like transacton fees, block producing reward amount, etc. Committee is composed of the current 27 super representatives. Every SR has the right to create and vote a proposal. The proposal will be passed after it gets at least 18 approves from the super representatives and will become valid in the next maintenance period.
"},{"location":"mechanism-algorithm/sr/#create-a-proposal","title":"Create a Proposal","text":"In addition to SR, SR Partner and SR Candidate also have the right to create a proposal, and only they have this right.
Please refer to here for TRON network dynamic parameters and their values.
Example (Using wallet-cli):
> createproposal id value\n# id: the serial number\n# value: the parameter value\n
"},{"location":"mechanism-algorithm/sr/#vote-for-a-proposal","title":"Vote for a Proposal","text":"Proposal only support YES vote. Since the creation time of the proposal, the proposal is valid within 3 days. If the proposal does not receive enough YES votes within the period of validity, the proposal will be invalid beyond the period of validity. Yes vote can be cancelled.
Example (Using wallet-cli):
> approveProposal id is_or_not_add_approval\n# id: proposal id\n# is_or_not_add_approval: YES vote or cancel YES vote\n
"},{"location":"mechanism-algorithm/sr/#cancel-proposal","title":"Cancel Proposal","text":"Proposal creator can cancel the proposal before it is passed.
Example (Using wallet-cli):
> deleteProposal id\n# id: proposal id\n
"},{"location":"mechanism-algorithm/sr/#query-proposal","title":"Query Proposal","text":" - Query all the proposals list (ListProposals)
- Query all the proposals list by pagination (GetPaginatedProposalList)
- Query a proposal by proposal id (GetProposalById)
For more API detail, please refer to HTTP API.
"},{"location":"mechanism-algorithm/system-contracts/","title":"System Contracts","text":"The TRON network supports many different types of transactions, such as TRX transfer transactions, TRC10 transfer transactions, creating smart contract transactions, triggering smart contract transactions, staking TRX transactions, and more. To create different types of transactions, you need to call different API. For example, the type of smart contract deployment transaction is CreateSmartContract, you need to call wallet/deploycontractAPI to create a transaction; the type of stake TRX transactions is FreezeBalanceV2Contract, you need to callwallet/freezebalancev2API to create transactions, we collectively refer to the implementation of these different transaction types as system contracts, the following are the types of system contracts and their contents:
"},{"location":"mechanism-algorithm/system-contracts/#accountcreatecontract","title":"AccountCreateContract","text":" message AccountCreateContract {\n bytes owner_address = 1;\n bytes account_address = 2;\n AccountType type = 3;\n }\n
owner_address: The owner of the current account.account_address: The target address to create.type: Account type. 0 means normal account; 1 means the Genesis account; 2 means smart contract account.
"},{"location":"mechanism-algorithm/system-contracts/#transfercontract","title":"TransferContract","text":" message TransferContract {\n bytes owner_address = 1;\n bytes to_address = 2;\n int64 amount = 3;\n }\n
owner_address: The owner of the current account.to_address: The target address to transfer.amount: The amount of TRX to transfer.
"},{"location":"mechanism-algorithm/system-contracts/#transferassetcontract","title":"TransferAssetContract","text":" message TransferAssetContract {\n bytes asset_name = 1;\n bytes owner_address = 2;\n bytes to_address = 3;\n int64 amount = 4;\n }\n
asset_name: The token id to transfer.owner_address: The owner of the current account.to_address: The target address to transfer.amount: The amount of token to transfer.
"},{"location":"mechanism-algorithm/system-contracts/#votewitnesscontract","title":"VoteWitnessContract","text":" message VoteWitnessContract {\n message Vote {\n bytes vote_address = 1;\n int64 vote_count = 2;\n }\n bytes owner_address = 1;\n repeated Vote votes = 2;\n bool support = 3;\n }\n
owner_address: The owner of the current account.vote_address: The SR or candidate's address.vote_count: The votes number.support: Constant true, not used.
"},{"location":"mechanism-algorithm/system-contracts/#witnesscreatecontract","title":"WitnessCreateContract","text":" message WitnessCreateContract {\n bytes owner_address = 1;\n bytes url = 2;\n }\n
owner_address: The owner of the current account.url: The website url of the witness.
"},{"location":"mechanism-algorithm/system-contracts/#assetissuecontract","title":"AssetIssueContract","text":" message AssetIssueContract {\n message FrozenSupply {\n int64 frozen_amount = 1;\n int64 frozen_days = 2;\n }\n bytes owner_address = 1;\n bytes name = 2;\n bytes abbr = 3;\n int64 total_supply = 4;\n repeated FrozenSupply frozen_supply = 5;\n int32 trx_num = 6;\n int32 num = 8;\n int64 start_time = 9;\n int64 end_time = 10;\n int64 order = 11; // the order of tokens of the same name\n int32 vote_score = 16;\n bytes description = 20;\n bytes url = 21;\n int64 free_asset_net_limit = 22;\n int64 public_free_asset_net_limit = 23;\n int64 public_free_asset_net_usage = 24;\n int64 public_latest_free_net_time = 25;\n }\n
owner_address: The owner of the current account.name: The token name to issue.abbr: The abbreviation of the token name.total_supply: The amount of token to issue.frozen_supply: The amount of token and staked days to stake.trx_num: trx_num/num defines the token price.num: trx_num/num defines the token price.start_time: ICO starts time.end_time: ICO ends time.order: Deprecated.vote_score: Deprecated.description: The description of the token.url: The website url of the token.free_asset_net_limit: The free bandwidth limit each account owns when transfers asset.public_free_asset_net_limit: The free bandwidth limit all the accounts can use.public_free_asset_net_usage: The free bandwidth usage of all the accounts.public_latest_free_net_time: The latest bandwidth consumption time of token transfer.
"},{"location":"mechanism-algorithm/system-contracts/#witnessupdatecontract","title":"WitnessUpdateContract","text":" message WitnessUpdateContract {\n bytes owner_address = 1;\n bytes update_url = 12;\n }\n
owner_address: The owner of the current account.update_url: The website url of the witness.
"},{"location":"mechanism-algorithm/system-contracts/#participateassetissuecontract","title":"ParticipateAssetIssueContract","text":" message ParticipateAssetIssueContract {\n bytes owner_address = 1;\n bytes to_address = 2;\n bytes asset_name = 3;\n int64 amount = 4;\n }\n
owner_address: The owner of the current account.to_address: The token owner address.account_name: The token id.amount: The amount of token to purchase.
"},{"location":"mechanism-algorithm/system-contracts/#accountupdatecontract","title":"AccountUpdateContract","text":" // Update account name. Account name is unique now.\n message AccountUpdateContract {\n bytes account_name = 1;\n bytes owner_address = 2;\n }\n
owner_address: The owner of the current account.account_name: Account name.
"},{"location":"mechanism-algorithm/system-contracts/#deprecatedfreezebalancecontract","title":"(Deprecated)FreezeBalanceContract","text":" message FreezeBalanceContract {\n bytes owner_address = 1;\n int64 frozen_balance = 2;\n int64 frozen_duration = 3;\n ResourceCode resource = 10;\n bytes receiver_address = 15;\n }\n
owner_address: The owner of the current account.frozen_balance: The amount of TRX to stake.frozen_duration: The stake duration.resource: The type of resource get by staking TRX.receiver_address: The account address to receive resource.
"},{"location":"mechanism-algorithm/system-contracts/#unfreezebalancecontract","title":"UnfreezeBalanceContract","text":" message UnfreezeBalanceContract {\n bytes owner_address = 1;\n ResourceCode resource = 10;\n bytes receiver_address = 13;\n }\n
owner_address: The owner of the current account.resource: The type of resource to unfree.receiver_address: The account address to receive resource.
"},{"location":"mechanism-algorithm/system-contracts/#withdrawbalancecontract","title":"WithdrawBalanceContract","text":" message WithdrawBalanceContract {\n bytes owner_address = 1;\n }\n
owner_address: The owner of the current account.
"},{"location":"mechanism-algorithm/system-contracts/#unfreezeassetcontract","title":"UnfreezeAssetContract","text":" message UnfreezeAssetContract {\n bytes owner_address = 1;\n }\n
owner_address: The owner of the current account.
"},{"location":"mechanism-algorithm/system-contracts/#updateassetcontract","title":"UpdateAssetContract","text":" message UpdateAssetContract {\n bytes owner_address = 1;\n bytes description = 2;\n bytes url = 3;\n int64 new_limit = 4;\n int64 new_public_limit = 5;\n }\n
owner_address: The owner of the current account.description: The description of the token.url: The website url of the token.new_limit: The bandwidth consumption limit of each account when transfers asset.new_public_limit: The bandwidth consumption limit of the accounts.
"},{"location":"mechanism-algorithm/system-contracts/#proposalcreatecontract","title":"ProposalCreateContract","text":" message ProposalCreateContract {\n bytes owner_address = 1;\n map<int64, int64> parameters = 2;\n }\n
owner_address: The owner of the current account.parameters: The proposal.
"},{"location":"mechanism-algorithm/system-contracts/#proposalapprovecontract","title":"ProposalApproveContract","text":" message ProposalApproveContract {\n bytes owner_address = 1;\n int64 proposal_id = 2;\n bool is_add_approval = 3; // add or remove approval\n }\n
owner_address: The owner of the current account.proposal_id: The proposal id.is_add_approval: Whether to approve.
"},{"location":"mechanism-algorithm/system-contracts/#proposaldeletecontract","title":"ProposalDeleteContract","text":" message ProposalDeleteContract {\n bytes owner_address = 1;\n int64 proposal_id = 2;\n }\n
owner_address: The owner of the current account.proposal_id: The proposal id.
"},{"location":"mechanism-algorithm/system-contracts/#setaccountidcontract","title":"SetAccountIdContract","text":" // Set account id if the account has no id. Account id is unique and case insensitive.\n message SetAccountIdContract {\n bytes account_id = 1;\n bytes owner_address = 2;\n }\n
owner_address: The owner of the current account.account_id: The account id.
"},{"location":"mechanism-algorithm/system-contracts/#createsmartcontract","title":"CreateSmartContract","text":" message CreateSmartContract {\n bytes owner_address = 1;\n SmartContract new_contract = 2;\n int64 call_token_value = 5;\n int64 token_id = 6;\n }\n
owner_address: The owner of the current account.new_contract: the smart contract.call_token_value : The amount of TRC-10 token to send to the contract when triggers.token_id : The id of the TRC-10 token to be sent to the contract.
"},{"location":"mechanism-algorithm/system-contracts/#triggersmartcontract","title":"TriggerSmartContract","text":" message TriggerSmartContract {\n bytes owner_address = 1;\n bytes contract_address = 2;\n int64 call_value = 3;\n bytes data = 4;\n int64 call_token_value = 5;\n int64 token_id = 6;\n }\n
owner_address: The owner of the current account.contract_address: The contract address.call_value: The amount of TRX to send to the contract when triggers.data: The parameters to trigger the contract.call_token_value : The amount of TRC-10 token to send to the contract when triggers.token_id : The id of the TRC-10 token to be sent to the contract.
"},{"location":"mechanism-algorithm/system-contracts/#updatesettingcontract","title":"UpdateSettingContract","text":" message UpdateSettingContract {\n bytes owner_address = 1;\n bytes contract_address = 2;\n int64 consume_user_resource_percent = 3;\n }\n
owner_address: The owner of the current account.contract_address: The address of the smart contract.consume_user_resource_percent: The percentage of resource consumption ratio.
"},{"location":"mechanism-algorithm/system-contracts/#exchangecreatecontract","title":"ExchangeCreateContract","text":" message ExchangeCreateContract {\n bytes owner_address = 1;\n bytes first_token_id = 2;\n int64 first_token_balance = 3;\n bytes second_token_id = 4;\n int64 second_token_balance = 5;\n }\n
owner_address: The owner of the current account.first_token_id: First token id.first_token_balance: First token balance.second_token_id: Second token id.second_token_balance: Second token balance.
"},{"location":"mechanism-algorithm/system-contracts/#exchangeinjectcontract","title":"ExchangeInjectContract","text":" message ExchangeInjectContract {\n bytes owner_address = 1;\n int64 exchange_id = 2;\n bytes token_id = 3;\n int64 quant = 4;\n }\n
owner_address: The owner of the current account.exchange_id: The token pair id.token_id: The token id to inject.quant: The token amount to inject.
"},{"location":"mechanism-algorithm/system-contracts/#exchangewithdrawcontract","title":"ExchangeWithdrawContract","text":" message ExchangeWithdrawContract {\n bytes owner_address = 1;\n int64 exchange_id = 2;\n bytes token_id = 3;\n int64 quant = 4;\n }\n
owner_address: The owner of the current account.exchange_id: The token pair id.token_id: The token id to withdraw.quant: The token amount to withdraw.
"},{"location":"mechanism-algorithm/system-contracts/#exchangetransactioncontract","title":"ExchangeTransactionContract","text":" message ExchangeTransactionContract {\n bytes owner_address = 1;\n int64 exchange_id = 2;\n bytes token_id = 3;\n int64 quant = 4;\n }\n
owner_address: The owner of the current account.exchange_id: The token pair id.token_id: The token id to sell.quant: The token amount to sell.
"},{"location":"mechanism-algorithm/system-contracts/#shieldedtransfercontract","title":"ShieldedTransferContract","text":" message ShieldedTransferContract {\n bytes transparent_from_address = 1;\n int64 from_amount = 2;\n repeated SpendDescription spend_description = 3;\n repeated ReceiveDescription receive_description = 4;\n bytes binding_signature = 5;\n bytes transparent_to_address = 6;\n int64 to_amount = 7;\n }\n
transparent_from_address: The transparent address of the sender.from_amount: The amount to send.spend_description: Shielded spend information.receive_description: Shielded receive information.binding_signature: The binding signature.transparent_to_address: The transparent address of the receiver.to_amount: The amount to receive.
message SpendDescription {\n bytes value_commitment = 1;\n bytes anchor = 2;\n bytes nullifier = 3;\n bytes rk = 4;\n bytes zkproof = 5;\n bytes spend_authority_signature = 6;\n}\n
value_commitment: value commitment of spender's transfer amount.anchor: root of the note commitment Merkle tree at some block.nullifier: nullifier of spender's note, to prevent double-spent.rk: public key, to verify spender's Spend Authorization Signature.zkproof: zero-knowledge proof of spender's note, prove that this note exists and could be spent.spend_authority_signature: the spender's Spend Authorization Signature.
message ReceiveDescription {\n bytes value_commitment = 1;\n bytes note_commitment = 2;\n bytes epk = 3;\n bytes c_enc = 4;\n bytes c_out = 5;\n bytes zkproof = 6;\n}\n
value_commitment: value commitment of receiver's transfer amount.note_commitment: commitment of the receiver's not.epk: ephemeral public key, in order to generate note's decryption key.c_enc: part of note ciphertext, encryption of diversifier, receiver's transfer amount, rcm, and memo.c_out: part of note ciphertext, encryption of the receiver's public key and ephemeral private key.zkproof: zero-knowledge proof of the receiver's note.
"},{"location":"mechanism-algorithm/system-contracts/#account-permission-management","title":"Account Permission Management","text":"Account Permission Management
"},{"location":"mechanism-algorithm/system-contracts/#clearabicontract","title":"ClearABIContract","text":" message ClearABIContract {\n bytes owner_address = 1;\n bytes contract_address = 2;\n }\n
owner_address: The owner of the current account.account_address: The target contract address to clear ABI.
"},{"location":"mechanism-algorithm/system-contracts/#updatebrokeragecontract","title":"UpdateBrokerageContract","text":" message UpdateBrokerageContract {\n bytes owner_address = 1;\n int32 brokerage = 2;\n }\n
owner_address: The owner of the current account.brokerage: Commission rate, from 0 to 100,1 mean 1%.
"},{"location":"mechanism-algorithm/system-contracts/#updateenergylimitcontract","title":"UpdateEnergyLimitContract","text":" message UpdateEnergyLimitContract {\n bytes owner_address = 1;\n bytes contract_address = 2;\n int64 origin_energy_limit = 3;\n }\n
owner_address: The owner of the current account.contract_address: The contract address.origin_energy_limit: The target energy limit to change.
"},{"location":"mechanism-algorithm/system-contracts/#freezebalancev2contract","title":"FreezeBalanceV2Contract","text":" message FreezeBalanceV2Contract {\n bytes owner_address = 1;\n int64 frozen_balance = 2;\n ResourceCode resource = 3;\n }\n
owner_address\uff1aOwner addressfrozen_balance\uff1aTRX stake amount, the unit is sunresource\uff1a Resource type
"},{"location":"mechanism-algorithm/system-contracts/#unfreezebalancev2contract","title":"UnfreezeBalanceV2Contract","text":" message UnfreezeBalanceV2Contract {\n bytes owner_address = 1;\n int64 unfreeze_balance = 2;\n ResourceCode resource = 3;\n }\n
owner_address\uff1aOwner addressunfreeze_balance\uff1aThe amount of TRX to unstake, in sunresource\uff1a Resource type
"},{"location":"mechanism-algorithm/system-contracts/#withdrawexpireunfreezecontract","title":"WithdrawExpireUnfreezeContract","text":" message WithdrawExpireUnfreezeContract {\n bytes owner_address = 1;\n }\n
owner_address\uff1aOwner address
"},{"location":"mechanism-algorithm/system-contracts/#delegateresourcecontract","title":"DelegateResourceContract","text":" message DelegateResourceContract {\n bytes owner_address = 1;\n ResourceCode resource = 2;\n int64 balance = 3;\n bytes receiver_address = 4;\n bool lock = 5;\n }\n
owner_address\uff1aOwner addressresource\uff1a Resource typebalance\uff1a Amount of TRX staked for resources to be delegated, unit is sunreceiver_address\uff1aResource receiver addresslock\uff1aWhether it is locked, if it is set to true, the delegated resources cannot be undelegated within 3 days. When the lock time is not over, if the owner delegates the same type of resources using the lock to the same address, the lock time will be reset to 3 days
"},{"location":"mechanism-algorithm/system-contracts/#undelegateresourcecontract","title":"UnDelegateResourceContract","text":" message UnDelegateResourceContract {\n bytes owner_address = 1;\n ResourceCode resource = 2;\n int64 balance = 3;\n bytes receiver_address = 4;\n }\n
owner_address\uff1aOwner addressresource\uff1a Resource typebalance\uff1aundelegated TRX, unit is sunreceiver_address\uff1aResource receiver address
"},{"location":"releases/history/","title":"History","text":"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"},{"location":"releases/history/#greatvoyage-480kant","title":"GreatVoyage-4.8.0(Kant)","text":"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.
"},{"location":"releases/history/#ethereum-cancun-upgrade-support","title":"Ethereum Cancun Upgrade Support","text":""},{"location":"releases/history/#1-tip-650-implement-eip-1153-transient-storage-instructions","title":"1. TIP-650: Implement EIP-1153 Transient Storage Instructions","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-650.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/6185 https://github.com/tronprotocol/java-tron/pull/6195 https://github.com/tronprotocol/java-tron/pull/6214
"},{"location":"releases/history/#2-tip-651-implement-eip-5656-mcopy-memory-copying-instruction","title":"2. TIP-651: Implement EIP-5656 MCOPY - Memory Copying Instruction","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-651.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/6185 https://github.com/tronprotocol/java-tron/pull/6194
"},{"location":"releases/history/#3-tip-745-introduce-eip-4844-instruction-and-eip-7516-instruction","title":"3. TIP-745: Introduce EIP-4844 Instruction and EIP-7516 Instruction","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-745.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/6232 https://github.com/tronprotocol/java-tron/pull/6247 https://github.com/tronprotocol/java-tron/pull/6270 https://github.com/tronprotocol/java-tron/pull/6283
"},{"location":"releases/history/#core","title":"Core","text":""},{"location":"releases/history/#1-enhanced-consensus-layer-verification","title":"1. Enhanced Consensus Layer Verification","text":""},{"location":"releases/history/#11-tip-694-enhance-verification-of-transaction-limitations-at-consensus-layer","title":"1.1 TIP-694: Enhance Verification of Transaction Limitations at Consensus Layer","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-694.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/6172 https://github.com/tronprotocol/java-tron/pull/6221
"},{"location":"releases/history/#12-enhanced-validation-of-block-production-during-maintenance-periods","title":"1.2 Enhanced Validation of Block Production during Maintenance Periods","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6187
"},{"location":"releases/history/#13-enhanced-block-header-validation","title":"1.3 Enhanced Block Header Validation","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6186
"},{"location":"releases/history/#14-optimized-super-representative-election-ranking-algorithm","title":"1.4 Optimized Super Representative Election Ranking Algorithm","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6173
"},{"location":"releases/history/#tvm","title":"TVM","text":""},{"location":"releases/history/#1-tip-652-announce-eip-6049-deprecate-selfdestruct","title":"1. TIP-652: Announce EIP-6049 Deprecate SELFDESTRUCT","text":"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
"},{"location":"releases/history/#net","title":"Net","text":""},{"location":"releases/history/#1-optimized-block-synchronization-logic","title":"1. Optimized Block Synchronization Logic","text":"Kant introduces two key optimizations to the block synchronization logic, significantly improving synchronization efficiency:
"},{"location":"releases/history/#11-optimized-p2p-protocol-discarding-solidified-block-lists-to-conserve-network-bandwidth","title":"1.1 Optimized P2P Protocol: Discarding Solidified Block Lists to Conserve Network Bandwidth","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6184
"},{"location":"releases/history/#12-faster-block-synchronization-task-scheduling-for-enhanced-efficiency","title":"1.2 Faster Block Synchronization Task Scheduling for Enhanced Efficiency","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6183
"},{"location":"releases/history/#2-enhanced-transaction-validity-verification-by-early-discarding-zero-contract-transactions","title":"2. Enhanced Transaction Validity Verification by Early Discarding Zero-Contract Transactions","text":"Kant strengthens transaction validity verification. Upon receiving a transaction message, the node will discard transactions with zero contracts and disconnect from the sender.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6181
"},{"location":"releases/history/#other-changes","title":"Other Changes","text":""},{"location":"releases/history/#1-enhanced-event-service-framework-v20-provision","title":"1. Enhanced Event Service Framework (V2.0) Provision","text":"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 \u2264 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\n
* 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 "},{"location":"releases/history/#2-cross-platform-consistent-javalangstrictmath-replacement-for-javalangmath","title":"2. Cross-Platform Consistent java.lang.StrictMath Replacement for java.lang.Math","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-697.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/6182 https://github.com/tronprotocol/java-tron/pull/6210
"},{"location":"releases/history/#3-optimized-node-exit-and-startup-logic","title":"3. Optimized Node Exit and Startup Logic","text":""},{"location":"releases/history/#31-optimized-node-exit-logic","title":"3.1 Optimized Node Exit Logic","text":"Kant standardizes the code logic for process termination while preserving original functionalities, enhancing code consistency and system stability.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6170 https://github.com/tronprotocol/java-tron/pull/6177 https://github.com/tronprotocol/java-tron/pull/6205
"},{"location":"releases/history/#32-optimized-node-startup-logic","title":"3.2 Optimized Node Startup Logic","text":"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\nnode.rpc.solidityEnable = true\nnode.rpc.PBFTEnable = true\nnode.http.PBFTEnable = true\n
* 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"},{"location":"releases/history/#4-dependency-library-security-upgrade","title":"4. Dependency Library Security Upgrade","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6180 https://github.com/tronprotocol/java-tron/pull/6207 https://github.com/tronprotocol/java-tron/pull/6257
"},{"location":"releases/history/#5-gradle-764-upgrade-with-dependency-integrity-verification","title":"5. Gradle 7.6.4 Upgrade with Dependency Integrity Verification","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5869 https://github.com/tronprotocol/java-tron/pull/5903 https://github.com/tronprotocol/java-tron/pull/6229
"},{"location":"releases/history/#6-null-pointer-exception-fix-during-startup","title":"6. Null Pointer Exception Fix During Startup","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6216
"},{"location":"releases/history/#7-internal-transaction-details-logging-for-cancelallunfreezev2-opcode","title":"7. Internal Transaction Details Logging for CANCELALLUNFREEZEV2 Opcode","text":"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}.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6191
"},{"location":"releases/history/#api","title":"API","text":""},{"location":"releases/history/#1-enhanced-compatibility-for-ethereum-json-rpc-interface","title":"1. Enhanced Compatibility for Ethereum JSON-RPC Interface","text":""},{"location":"releases/history/#11-support-for-querying-solidified-data-via-finalized-block-parameter-in-json-rpc-api","title":"1.1 Support for Querying Solidified Data via finalized Block Parameter in JSON-RPC API","text":"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\u201d 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:
- eth_getBalance
- eth_getCode
- eth_getStorageAt
- eth_call
-
eth_newFilter
-
Source Code: https://github.com/tronprotocol/java-tron/pull/6007 https://github.com/tronprotocol/java-tron/pull/6238 https://github.com/tronprotocol/java-tron/pull/6239
"},{"location":"releases/history/#12-new-limits-on-block-range-and-topics-quantity-for-json-rpc-log-queries","title":"1.2 New Limits on Block Range and \u201cTopics\u201d Quantity for JSON-RPC Log Queries","text":"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 \u201csub topics\u201d that can be set. The default value is 1000, meaning that a maximum of 1000 \u201csub topics\u201d 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\nnode.jsonrpc.maxSubTopics = 1000\n
Interfaces supporting maxBlockRange:
- eth_getLogs
Interfaces supporting maxSubTopics:
- eth_getLogs
-
eth_newFilter
-
Source Code: https://github.com/tronprotocol/java-tron/pull/6271 https://github.com/tronprotocol/java-tron/pull/6275
"},{"location":"releases/history/#13-optimized-eth_getlogs-to-resolve-data-retrieval-issue-in-rare-hash-collisions","title":"1.3 Optimized eth_getLogs to Resolve Data Retrieval Issue in Rare Hash Collisions","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6203
"},{"location":"releases/history/#2-non-null-payment-address-validation-in-shielded-transaction-creation-api","title":"2. Non-Null Payment Address Validation in Shielded Transaction Creation API","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/6174
Science is organized knowledge. Wisdom is organized life.
---Immanuel Kant
"},{"location":"releases/history/#greatvoyage-477epicurus","title":"GreatVoyage-4.7.7(Epicurus)","text":"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.
"},{"location":"releases/history/#core_1","title":"Core","text":""},{"location":"releases/history/#1-migrate-pow-operation-from-javalangmath-to-javalangstrictmath-for-cross-platform-computational-consistency","title":"1. Migrate pow operation from java.lang.Math to java.lang.StrictMath for cross-platform computational consistency","text":"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
"},{"location":"releases/history/#other-changes_1","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-event-subscription-processing-logic","title":"1. Optimize event subscription processing logic","text":"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
"},{"location":"releases/history/#2-support-graceful-shutdown-with-signal-15-sigterm-for-nodes-enabling-backup","title":"2. Support graceful shutdown with signal -15 (SIGTERM) for nodes enabling backup.","text":"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
"},{"location":"releases/history/#3-improve-duration-metrics-accuracy-of-grpc-interfaces","title":"3. Improve duration metrics accuracy of gRPC interfaces","text":"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
"},{"location":"releases/history/#greatvoyage-v476anaximander","title":"GreatVoyage-v4.7.6(Anaximander)","text":"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.
"},{"location":"releases/history/#other-changes_2","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-the-statistical-logic-of-node-http-request-monitoring-metric","title":"1. Optimize the statistical logic of node HTTP request monitoring metric","text":"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
"},{"location":"releases/history/#2-improve-stability-of-gradle-test-task","title":"2. Improve stability of Gradle test task","text":"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
"},{"location":"releases/history/#3-add-tcp-outflow-monitoring-metric-for-prometheus-and-add-udp-inflow-traffic-statistic-to-monitorgetstatsinfo-api","title":"3. Add TCP outflow monitoring metric for Prometheus and add UDP inflow traffic statistic to /monitor/getstatsinfo API","text":"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
"},{"location":"releases/history/#4-optimize-peer-node-idle-judgment-logic","title":"4. Optimize peer node idle judgment logic","text":"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
"},{"location":"releases/history/#5-optimize-peer-sorting-logic","title":"5. Optimize peer sorting logic","text":"Anaximander optimizes the peers\u2019 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
"},{"location":"releases/history/#6-optimize-check-logic-for-fetching-block-inventory-message","title":"6. Optimize check logic for fetching block inventory message","text":"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
"},{"location":"releases/history/#7-optimize-block-processing-logic","title":"7. Optimize block processing logic","text":"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
"},{"location":"releases/history/#8-optimize-random-disconnection-strategy","title":"8. Optimize random disconnection strategy","text":"When a node\u2019s latest block height is higher than all peers\u2019 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
"},{"location":"releases/history/#greatvoyage-v475cleobulus","title":"GreatVoyage-v4.7.5(Cleobulus)","text":"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.
"},{"location":"releases/history/#core_2","title":"Core","text":""},{"location":"releases/history/#1-optimize-block-synchronization-and-production-logic","title":"1. Optimize block synchronization and production logic","text":"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
"},{"location":"releases/history/#2-strengthen-size-check-of-account-creation-transactions","title":"2. Strengthen size check of account creation transactions","text":"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
"},{"location":"releases/history/#tvm_1","title":"TVM","text":""},{"location":"releases/history/#1-adjust-energy-cost-for-some-opcodes-in-tvm","title":"1. Adjust energy cost for some opcodes in TVM","text":"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
"},{"location":"releases/history/#other-changes_3","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-synchronization-logic-among-threads","title":"1. Optimize synchronization logic among threads","text":"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
"},{"location":"releases/history/#2-remove-redundant-code","title":"2. Remove redundant code","text":"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
"},{"location":"releases/history/#greatvoyage-v474bias","title":"GreatVoyage-v4.7.4(Bias)","text":"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.
"},{"location":"releases/history/#core_3","title":"Core","text":""},{"location":"releases/history/#1-optimize-voting-reward-withdrawal-performance","title":"1. Optimize voting reward withdrawal performance","text":"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
"},{"location":"releases/history/#2-add-check-function-for-the-number-of-unsolidified-blocks","title":"2. Add check function for the number of unsolidified blocks","text":"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\nnode.maxUnsolidifiedBlocks = 54\n
Source Code: https://github.com/tronprotocol/java-tron/pull/5643
"},{"location":"releases/history/#api_1","title":"API","text":""},{"location":"releases/history/#1-supply-block_unsolidified-in-code-for-walletbroadcasttransaction-api","title":"1. Supply BLOCK_UNSOLIDIFIED in code for /wallet/broadcasttransaction API","text":"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
"},{"location":"releases/history/#other-changes_4","title":"Other Changes","text":""},{"location":"releases/history/#1-add-field-codeversion-to-hellomessage-to-declare-code-version","title":"1. Add field codeVersion to HelloMessage to declare code version","text":"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
"},{"location":"releases/history/#2-bump-libp2p-to-version-221","title":"2. Bump libp2p to version 2.2.1","text":"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
"},{"location":"releases/history/#3-bump-jetty-to-9453v20231009","title":"3. Bump jetty to 9.4.53.v20231009","text":"The Bias version bumps the jetty dependency library to v9.4.53.v20231009.
Source Code: https://github.com/tronprotocol/java-tron/pull/5571
"},{"location":"releases/history/#4-refactor-gradle-dependencies","title":"4. Refactor Gradle dependencies","text":"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
"},{"location":"releases/history/#5-provide-grpc-reflection-service","title":"5. Provide gRPC reflection service","text":"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\n
Source Code: https://github.com/tronprotocol/java-tron/pull/5583 "},{"location":"releases/history/#6-delete-the-litefullnodetool-related-code-under-the-framework-module","title":"6. Delete the LiteFullNodeTool related code under the framework module","text":"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 \n
Source Code: https://github.com/tronprotocol/java-tron/pull/5711
"},{"location":"releases/history/#7-remove-configuration-item-nodediscoverybindip","title":"7. Remove configuration item node.discovery.bind.ip","text":"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
"},{"location":"releases/history/#8-remove-redundant-ci-scripts","title":"8. Remove redundant CI scripts","text":"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
"},{"location":"releases/history/#9-initialize-the-api-service-first-during-the-node-startup","title":"9. Initialize the API service first during the node startup","text":"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
"},{"location":"releases/history/#10-optimize-log","title":"10. Optimize log","text":"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
"},{"location":"releases/history/#11-add-synchronization-control-when-writing-to-zeromq","title":"11. Add synchronization control when writing to ZeroMQ","text":"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
"},{"location":"releases/history/#12optimize-unexpected-exception-capture-process-of-scalingfactor-in-walletcreateshieldedcontractparameters-api","title":"12.Optimize unexpected exception capture process of scalingFactor in /wallet/createshieldedcontractparameters API.","text":"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
"},{"location":"releases/history/#greatvoyage-v4731solon","title":"GreatVoyage-v4.7.3.1(Solon)","text":"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.
"},{"location":"releases/history/#other-changes_5","title":"Other Changes","text":""},{"location":"releases/history/#1-more-stable-walletgetnodeinfo-interface","title":"1. More stable /wallet/getnodeinfo interface","text":"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
"},{"location":"releases/history/#2-optimize-lite-fullnode-data-pruning-tool","title":"2. Optimize Lite FullNode data pruning tool","text":"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
"},{"location":"releases/history/#greatvoyage-v473chilon","title":"GreatVoyage-v4.7.3(Chilon)","text":"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.
"},{"location":"releases/history/#core_4","title":"Core","text":""},{"location":"releases/history/#1-add-grpc-interfaces-for-resource-price-and-transaction-memo-fee-query","title":"1. Add gRPC interfaces for resource price and transaction memo fee query","text":"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
"},{"location":"releases/history/#2-supplement-disconnect-reasons","title":"2. Supplement disconnect reasons","text":"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
"},{"location":"releases/history/#3-discard-transactions-from-bad-peers-instead-of-disconnected-peers","title":"3. Discard transactions from bad peers instead of disconnected peers","text":"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
"},{"location":"releases/history/#4-optimize-stake-20-codes-and-error-messages","title":"4. Optimize Stake 2.0 codes and error messages","text":"The Chilon version standardizes Stake 2.0-related code and simplifies complex functions\uff0c improving the simplicity and readability of the code.
Source Code: https://github.com/tronprotocol/java-tron/pull/5426
"},{"location":"releases/history/#5-accelerate-bloomfilter-initialization-for-transaction-cache","title":"5. Accelerate bloomFilter initialization for transaction cache","text":"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
"},{"location":"releases/history/#6-fix-concurrency-issues-when-generating-chain-inventory","title":"6. Fix concurrency issues when generating chain inventory","text":"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
"},{"location":"releases/history/#7-correct-resource-disorder-closure-behavior-on-kill-15","title":"7. Correct resource disorder closure behavior on kill -15","text":"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
"},{"location":"releases/history/#api_2","title":"API","text":""},{"location":"releases/history/#1-optimize-http-interface-monitoring","title":"1. Optimize HTTP interface monitoring","text":"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
"},{"location":"releases/history/#2-provide-uniform-rate-limitation-configuration-for-all-http-and-grpc-apis","title":"2. Provide uniform rate limitation configuration for all HTTP and gRPC APIs","text":"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\n
Source Code: https://github.com/tronprotocol/java-tron/pull/5502
"},{"location":"releases/history/#3-optimize-http-interface-parameter-parsing","title":"3. Optimize HTTP interface parameter parsing","text":"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
"},{"location":"releases/history/#4-add-solidity-query-interfaces-of-resource-unit-price","title":"4. Add solidity query interfaces of resource unit price","text":"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
"},{"location":"releases/history/#5-optimize-the-processing-logic-of-some-http-interfaces","title":"5. Optimize the processing logic of some HTTP interfaces","text":"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
"},{"location":"releases/history/#other-changes_6","title":"Other Changes","text":""},{"location":"releases/history/#1-add-check-for-expired-transactions-when-fetching-transactions","title":"1. Add check for expired transactions when fetching transactions","text":"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
"},{"location":"releases/history/#2-fix-concurrency-issue-of-getheadblockid-method","title":"2. Fix concurrency issue of getHeadBlockId method","text":"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
"},{"location":"releases/history/#3-delete-unused-network-configurations","title":"3. Delete unused network configurations","text":"Chilon deleted four unused network parameters, including the three configuration items below, simplifying the complexity of using for developers.
node.discovery.public.home.node\nnode.discovery.ping.timeout\nnode.p2p.pingInterval\n
Source Code: https://github.com/tronprotocol/java-tron/pull/5441
"},{"location":"releases/history/#4-obtain-external-ip-through-libp2p","title":"4. Obtain external IP through Libp2p","text":"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
"},{"location":"releases/history/#5-add-address-parsing-for-stake-related-transactions-in-event-subscription","title":"5. Add address parsing for stake-related transactions in event subscription","text":"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
"},{"location":"releases/history/#6-adjust-default-number-of-cpu-cores-used-in-signature-validation","title":"6. Adjust default number of CPU cores used in signature validation","text":"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
"},{"location":"releases/history/#7-migrate-litefullnode-tool-related-unit-test-cases-to-plugins-module","title":"7. Migrate LiteFullNode tool related unit test cases to Plugins module","text":"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
"},{"location":"releases/history/#8-enhance-query-performance-of-properties-db","title":"8. Enhance query performance of properties DB","text":"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
"},{"location":"releases/history/#greatvoyage-v472periander","title":"GreatVoyage-v4.7.2(Periander)","text":"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.
"},{"location":"releases/history/#core_5","title":"Core","text":""},{"location":"releases/history/#1-upgrade-libp2p-to-v120","title":"1. Upgrade Libp2p to v1.2.0","text":"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\uff1a
-
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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-549.md
-
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 {\n # enable or disable dns publish, default false\n publish = true\n\n # dns domain to publish nodes, required if publish is enable\n dnsDomain = \"...\"\n\n # dns private key used to publish, required if publish is enable, hex string of length 64\n dnsPrivate = \"...\"\n\n # dns server to publish, required if publish is enable, only \u201daws\u201d or \u201caliyun\u201d is support\n serverType = \"...\"\n\n # access key id of aws or aliyun api, required if publish is enable, string\n accessKeyId = \"...\"\n\n # access key secret of aws or aliyun api, required if publish is enable, string\n accessKeySecret = \"...\"\n\n # if publish is enable and serverType is aliyun, it's endpoint of aws dns server, string\n aliyunDnsEndpoint = \"...\"\n\n # if publish is enable and serverType is aws, it's region of aws api, such as \"eu-south-1\", string\n awsRegion = \"...\"\n # if publish is enable and serverType is aws, it's host zone id of aws's domain, string\n awsHostZoneId = \"...\"\n\n # static nodes to published on dns\n staticNodes = [\n # Sample entries:\n # \"ip:port\",\n # \"ip:port\"\n ]\n\n # the range is from 1 to 5\n maxMergeSize = 2\n\n changeThreshold = 0.001\n}\n
Node discovery via DNS
To use the function of node discovery via DNS, you need to configure the following configuration items:
node.dns {\n # DNS URL to get nodes, URL format tree://{pubkey}@{domain}, default empty\n treeUrls = [......]\n}\n
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-548.md
-
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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-547.md
-
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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-550.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/5017
"},{"location":"releases/history/#2-support-canceling-unstaking-in-stake-20","title":"2. Support canceling unstaking in Stake 2.0","text":"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\u2019s 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 \\\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"visible\": true\n}'\n
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-541.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/5230 https://github.com/tronprotocol/java-tron/pull/5260 https://github.com/tronprotocol/java-tron/pull/5279
"},{"location":"releases/history/#3-resource-delegating-supports-customizable-lock-period","title":"3. Resource delegating supports customizable lock period","text":"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 \\\n'{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"receiver_address\": \"TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1\",\n \"balance\": 1000000,\n \"resource\": \"ENERGY\",\n \"lock\": true,\n \"lock_period\": 86400,\n \"visible\": true\n}'\n
- 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: \u201cThe 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!.\u201d
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-542.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/5255
"},{"location":"releases/history/#4-optimize-effective-peer-acquiring-strategy","title":"4. Optimize effective peer-acquiring strategy","text":"When the latest block heights of all connected remote nodes are lower than a node\u2019s, 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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5088
"},{"location":"releases/history/#tvm_2","title":"TVM","text":""},{"location":"releases/history/#1-implement-eip-3855-push0-instruction","title":"1. Implement EIP-3855 PUSH0 Instruction","text":"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.
- TIP: https://github.com/tronprotocol/tips/blob/master/tip-543.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/5175
"},{"location":"releases/history/#api_3","title":"API","text":""},{"location":"releases/history/#1-add-api-global-rate-limiter","title":"1. Add API global rate limiter","text":"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\nrate.limiter.global.qps =10 \n# QPS rate limit to all interfaces from the same IP address\nrate.limiter.global.ip.qps = 5 \n
- Source Code: https://github.com/tronprotocol/java-tron/pull/5093
"},{"location":"releases/history/#2-add-data-to-http-interfaces-for-smart-contract-interaction","title":"2. Add data to HTTP Interfaces for Smart Contract Interaction","text":"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 \\\n --url https://api.shasta.trongrid.io/wallet/triggersmartcontract \\\n --header 'accept: application/json' \\\n --header 'content-type: application/json' \\\n --data '\n{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"contract_address\": \"TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs\",\n \"function_selector\": \"balanceOf(address)\",\n \"parameter\": \"000000000000000000000000a614f803b6fd780986a42c78ec9c7f77e6ded13c\",\n \"visible\": true\n}\n'\n
-
Calling contract through data
curl --request POST \\\n --url https://api.shasta.trongrid.io/wallet/triggersmartcontract \\\n --header 'accept: application/json' \\\n --header 'content-type: application/json' \\\n --data '\n{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"contract_address\": \"TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs\",\n \"data\": \"70a08231000000000000000000000000a614f803b6fd780986a42c78ec9c7f77e6ded13c\",\n \"visible\": true\n}'\n
-
Estimate energy consumption of contract deployment transaction
curl --request POST \\\n --url https://api.shasta.trongrid.io/wallet/triggerconstantcontract \\\n --header 'accept: application/json' \\\n --header 'content-type: application/json' \\\n --data '\n{\n \"owner_address\": \"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g\",\n \"data\": \"608060405234801561001057600080fd5b50d3801561001d57600080fd5b50d2801561002a57600080fd5b506101c18061003a6000396000f3fe608060405234801561001057600080fd5b50d3801561001d57600080fd5b50d2801561002a57600080fd5b50600436106100455760003560e01c8063f8b2cb4f1461004a575b600080fd5b610064600480360381019061005f919061012a565b61007a565b6040516100719190610170565b60405180910390f35b60008173ffffffffffffffffffffffffffffffffffffffff16319050919050565b600080fd5b600074ffffffffffffffffffffffffffffffffffffffffff82169050919050565b6100ca816100a0565b81146100d557600080fd5b50565b600073ffffffffffffffffffffffffffffffffffffffff82169050919050565b6000610103826100d8565b9050919050565b600081359050610119816100c1565b610122816100f8565b905092915050565b6000602082840312156101405761013f61009b565b5b600061014e8482850161010a565b91505092915050565b6000819050919050565b61016a81610157565b82525050565b60006020820190506101856000830184610161565b9291505056fea26474726f6e58221220839f9be3efc349a3efd6bb491d0bee7bc34d86313c73f6e6eeddc4719ec69c0064736f6c63430008120033\",\n \"visible\": true\n}'\n
-
TIP: https://github.com/tronprotocol/tips/blob/master/tip-544.md
- Source Code: https://github.com/tronprotocol/java-tron/pull/5079
"},{"location":"releases/history/#3-optimize-getstorageat-interface","title":"3. Optimize getStorageAt interface","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5061
"},{"location":"releases/history/#other-changes_7","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-event-forwarding-logic-in-event-subscription","title":"1. Optimize event forwarding logic in event subscription","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5031
"},{"location":"releases/history/#2-support-dynamic-loading-according-to-nodeactive-and-nodepassive","title":"2. Support dynamic loading according to node.active and node.passive","text":"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\nnode.dynamicConfig.checkInterval = 600\n
- Source Code: https://github.com/tronprotocol/java-tron/pull/5090
"},{"location":"releases/history/#3-optimize-block-synchronization-logic","title":"3. Optimize block synchronization logic","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5094 https://github.com/tronprotocol/java-tron/pull/5097 https://github.com/tronprotocol/java-tron/pull/5102
"},{"location":"releases/history/#4-normalize-http-urls","title":"4. Normalize HTTP URLs","text":"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= [\n \"getaccount\",\n \"getnowblock2\"\n]\n
- Source Code: https://github.com/tronprotocol/java-tron/pull/5085
"},{"location":"releases/history/#5-optimize-block-fetching-logic","title":"5. Optimize block fetching logic","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5106
"},{"location":"releases/history/#6-add-a-new-node-startup-mode","title":"6. Add a new node startup mode","text":"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 \n
- Source Code: https://github.com/tronprotocol/java-tron/pull/5011
"},{"location":"releases/history/#7-upgrade-junit-to-4132","title":"7. Upgrade JUnit to 4.13.2","text":"The Periander version upgrades the unit testing framework and upgrades the JUnit dependency library from v4.12 to v4.13.2.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5244
"},{"location":"releases/history/#8-add-monitoring-metrics-for-json-rpc","title":"8. Add monitoring metrics for JSON-RPC","text":"The Periander version supports JSON-RPC interface latency monitoring metrics, allowing node deployers to monitor the latency of all types of interfaces.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5222
"},{"location":"releases/history/#9-optimize-the-database-module","title":"9. Optimize the database module","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5223
"},{"location":"releases/history/#10-optimize-checkpoint-v2-recovery-process","title":"10. Optimize checkpoint v2 recovery process","text":"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.
- Source Code: https://github.com/tronprotocol/java-tron/pull/5224
Forethought in all things.
---Periander
"},{"location":"releases/history/#greatvoyage-v4711-pittacus","title":"GreatVoyage-v4.7.1.1 (Pittacus)","text":"GreatVoyage-v4.7.1.1 (Pittacus) version optimized multiple interfaces and removed APIs involving sensitive information.
Please see the details below.
"},{"location":"releases/history/#api_4","title":"API","text":""},{"location":"releases/history/#1-remove-apis-involving-sensitive-information","title":"1. Remove APIs involving sensitive information","text":"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 passwordgenerateaddress: Create address randomlyeasytransfer: Transfer TRX with passwordeasytransferbyprivate: Transfer TRX with private keyeasytransferasset: Transfer TRC10 token with passwordeasytransferassetbyprivate: Transfer TRC10 token with private keygettransactionsign: Sign transaction with private keyaddtransactionsign: Sign transaction with private key which is mainly used to sign multi-signature transactions
- gRPC
CreateAddress: Create an address based on the specified passwordGenerateAddress: Create address randomlyEasyTransfer: Transfer TRX with passwordEasyTransferByPrivate: Transfer TRX with private keyEasyTransferAsset: Transfer TRC10 token with passwordEasyTransferAssetByPrivate: Transfer TRC10 token with private keyGetTransactionSign: Sign transaction with private keyGetTransactionSign2: Sign transaction with private keyAddSign: 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
"},{"location":"releases/history/#2-optimize-resource-delegate-information-query-interface","title":"2. Optimize resource delegate information query interface","text":"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
"},{"location":"releases/history/#other-changes_8","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-the-update-logic-of-the-origin_energy_usage-field-in-the-transaction-receipt","title":"1. Optimize the update logic of the origin_energy_usage field in the transaction receipt","text":"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
"},{"location":"releases/history/#greatvoyage-v471sartre","title":"GreatVoyage-v4.7.1(Sartre)","text":"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.
"},{"location":"releases/history/#cores","title":"Cores","text":""},{"location":"releases/history/#1-optimize-the-node-ip-setting","title":"1. Optimize the node IP setting","text":"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
"},{"location":"releases/history/#2-optimize-block-synchronization-logic","title":"2. Optimize block synchronization logic","text":"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\uff0cand 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
"},{"location":"releases/history/#api_5","title":"API","text":""},{"location":"releases/history/#1-optimize-the-list-of-solidified-block-apis","title":"1. Optimize the list of solidified block APIs","text":"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
"},{"location":"releases/history/#2-optimize-resource-delegation-relationship-api","title":"2. Optimize resource delegation relationship API","text":"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.
"},{"location":"releases/history/#other-changes_9","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-litefullnode-detection-logic","title":"1. Optimize LiteFullNode detection logic","text":"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
"},{"location":"releases/history/#2-optimize-node-log-output","title":"2. Optimize node log output","text":"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
"},{"location":"releases/history/#greatvoyage-v4701aristotle","title":"GreatVoyage-v4.7.0.1(Aristotle)","text":"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 \u2018Toolkit.jar\u2019 toolbox to bring users a more convenient development experience.
Please see the details below.
"},{"location":"releases/history/#cores_1","title":"Cores","text":""},{"location":"releases/history/#1-a-new-stake-model-stake-20","title":"1. A new stake model - Stake 2.0","text":"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\u2019s 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 \u2019N\u2019 days. After the \u2019N\u2019 days delay, the TRX released could be withdrawn to the owner\u2019s account. \u2019N\u2019 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.
- TIP: https://github.com/tronprotocol/tips/issues/467
- Source code: https://github.com/tronprotocol/java-tron/pull/4838
"},{"location":"releases/history/#2enhance-database-query-performance","title":"2.Enhance database query performance","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4740
"},{"location":"releases/history/#3-optimize-block-production-process","title":"3. Optimize block production process","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4756
"},{"location":"releases/history/#4-add-transaction-hash-cache","title":"4. Add transaction hash cache","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4792
"},{"location":"releases/history/#5-add-libp2p-module-as-java-tron-p2p-network-protocol-implementation","title":"5. Add libp2p module as java-tron p2p network protocol implementation","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4791
"},{"location":"releases/history/#tvm_3","title":"TVM","text":""},{"location":"releases/history/#1-add-new-instructions-to-support-stake-20","title":"1. Add new instructions to support Stake 2.0","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/467
- Source code: https://github.com/tronprotocol/java-tron/pull/4872
"},{"location":"releases/history/#2-dynamic-energy-model","title":"2. Dynamic energy model","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/491
- Source code: https://github.com/tronprotocol/java-tron/pull/4873
"},{"location":"releases/history/#3-optimize-the-return-value-of-the-chainid-opcode","title":"3. Optimize the return value of the chainId opcode","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/474
- Source code: https://github.com/tronprotocol/java-tron/pull/4863
"},{"location":"releases/history/#api_6","title":"API","text":""},{"location":"releases/history/#1-add-apis-to-support-stake-20","title":"1. Add APIs to support Stake 2.0","text":"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?
- TIP: https://github.com/tronprotocol/tips/issues/467
- Source code: https://github.com/tronprotocol/java-tron/pull/4838
"},{"location":"releases/history/#2-add-energy-estimation-api","title":"2. Add energy estimation API","text":"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' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"owner_address\": \"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM\",\n \"contract_address\": \"TXLAQ63Xg1NAzckPwKHvzw7CSEmLMEqcdj\",\n \"function_selector\": \"transfer(address,uint256)\",\n \"parameter\": \"0000000000000000000000002EEF13ADA48F286066F9066CE84A9AD686A3EA480000000000000000000000000000000000000000000000000000000000000004\",\n \"visible\": true\n}'\n
- Source code: https://github.com/tronprotocol/java-tron/pull/4873
"},{"location":"releases/history/#other-changes_10","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-gradle-compilation-parameters","title":"1. Optimize Gradle compilation parameters","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4837
"},{"location":"releases/history/#2-optimize-node-conditional-stop-function","title":"2. Optimize node conditional stop function","text":"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\u2019 settings.
- Source code: https://github.com/tronprotocol/java-tron/pull/4853 https://github.com/tronprotocol/java-tron/pull/4858
"},{"location":"releases/history/#3-delete-code-related-to-database-v1","title":"3. Delete code related to database v1","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4836
"},{"location":"releases/history/#4-optimize-database-log-output","title":"4. Optimize database log output","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4833
"},{"location":"releases/history/#5-make-snapshot-flush-speed-configurable","title":"5. Make snapshot flush speed configurable","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4834
"},{"location":"releases/history/#6-toolkitjar-integration","title":"6. Toolkit.jar Integration","text":"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\njava -jar Toolkit.jar db convert -h\n// convert FullNode data into LiteFullNode data\njava -jar Toolkit.jar db lite -h\n// Database copy\njava -jar Toolkit.jar db copy -h\n
- Source code: https://github.com/tronprotocol/java-tron/pull/4813
Courage is the first of human qualities because it is the quality that guarantees others.
--- Aristotle
"},{"location":"releases/history/#greatvoyage-v460-socrates","title":"GreatVoyage-v4.6.0 (Socrates)","text":"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.
"},{"location":"releases/history/#core_6","title":"Core","text":""},{"location":"releases/history/#1-optimize-delegate-relationship-index-structure","title":"1. Optimize delegate relationship index structure","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/476
- Source code: https://github.com/tronprotocol/java-tron/pull/4788
"},{"location":"releases/history/#2-add-transaction-memo-fee-proposal","title":"2. Add transaction memo fee proposal","text":"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 \u20180\u2019, and the unit is \u2018sun\u2019. It can be enabled by specifying a non-zero value by initiating a proposal, for example, \u20181000000\u2019, indicating that the transaction with memo will require an additional 1 TRX fee.
- TIP: https://github.com/tronprotocol/tips/issues/387
- Source code: https://github.com/tronprotocol/java-tron/pull/4758
"},{"location":"releases/history/#3-add-optimized-reward-algorithm-proposal","title":"3. Add optimized reward algorithm proposal","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/465
- Source code: https://github.com/tronprotocol/java-tron/pull/4694
"},{"location":"releases/history/#4-upgrade-checkpoint-mechanism-to-v2-in-database-module","title":"4. Upgrade checkpoint mechanism to v2 in database module","text":"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.
- TIP: https://github.com/tronprotocol/tips/issues/461
- Source code: https://github.com/tronprotocol/java-tron/pull/4614
"},{"location":"releases/history/#5-optimize-block-production-priority-between-active-and-backup-nodes","title":"5. Optimize block production priority between active and backup nodes","text":"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.
- Source code\uff1ahttps://github.com/tronprotocol/java-tron/pull/4630
"},{"location":"releases/history/#6optimize-the-kademlia-algorithm-for-the-network-module","title":"6.Optimize the Kademlia algorithm for the network module","text":"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 \u2018distance\u2019 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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4620 https://github.com/tronprotocol/java-tron/pull/4622
"},{"location":"releases/history/#other-changes_11","title":"Other Changes","text":""},{"location":"releases/history/#1-merge-archivemanifestjar-into-toolkitjar","title":"1. Merge ArchiveManifest.jar into Toolkit.jar","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4603
"},{"location":"releases/history/#2-add-prometheus-metrics-for-network-module","title":"2. Add prometheus metrics for network module","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4626
"},{"location":"releases/history/#3-add-the-help-command-option","title":"3. Add the --help command option","text":"GreatVoyage-v4.6.0(Socrates) adds \u2018help\u2019 command line options to check all parameters and instructions. Please check the example below,
$ java -jar FullNode.jar --help\n\nName:\n FullNode - the java-tron command line interface\n\nUsage: java -jar FullNode.jar [options] [seedNode <seedNode> ...]\n\nVERSION:\n4.5.2-d05f766\n\nTRON OPTIONS:\n-v, --version Output code version\n-h, --help Show help message\n-c, --config Config file (default:config.conf)\n--log-config Logback config file\n--es Start event subscribe server\n\nDB OPTIONS:\n-d, --output-directory Data directory for the databases (default:output-directory)\n\nWITNESS OPTIONS:\n-w, --witness Is witness node\n-p, --private-key Witness private key\n\nVIRTUAL MACHINE OPTIONS:\n--debug Switch for TVM debug mode. In debug model, TVM will not check for timeout. (default: false)\n
- Source code: https://github.com/tronprotocol/java-tron/pull/4606
"},{"location":"releases/history/#4-optimize-litefullnodetooljar","title":"4. Optimize LiteFullNodeTool.jar","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4607
"},{"location":"releases/history/#5-optimize-the-return-value-of-eth_getblockbyhash-and-eth_getblockbynumber-apis","title":"5. Optimize the return value of eth_getBlockByHash and eth_getBlockByNumber APIs","text":"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.
- Source code: https://github.com/tronprotocol/java-tron/pull/4642
To move the world we must move ourselves.
--- Socrates
"},{"location":"releases/history/#greatvoyage-v452aurelius","title":"GreatVoyage-v4.5.2(Aurelius)","text":"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.
"},{"location":"releases/history/#core_7","title":"Core","text":""},{"location":"releases/history/#1-optimize-block-processing","title":"1. Optimize block processing","text":"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
"},{"location":"releases/history/#2-optimize-transaction-cache","title":"2. Optimize transaction cache","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4538
"},{"location":"releases/history/#3-optimize-nodes-connection-strategy","title":"3. Optimize nodes connection strategy","text":"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
"},{"location":"releases/history/#4-optimize-block-generating-logic","title":"4. Optimize block generating logic","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4387
"},{"location":"releases/history/#5-optimize-fork-switching-logic","title":"5. Optimize fork switching logic","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4583
"},{"location":"releases/history/#6-add-database-storage-partition-tool","title":"6. Add database storage partition tool","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4545 https://github.com/tronprotocol/java-tron/pull/4559 https://github.com/tronprotocol/java-tron/pull/4563
"},{"location":"releases/history/#api_7","title":"API","text":""},{"location":"releases/history/#1-new-block-header-query-api","title":"1. New block header query API","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4492 https://github.com/tronprotocol/java-tron/pull/4552
"},{"location":"releases/history/#2-new-historical-bandwidth-unit-price-query-api","title":"2. New historical bandwidth unit price query API","text":"According to the bandwidth consumption rules, if the transaction initiator\u2019s 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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4556
"},{"location":"releases/history/#other-changes_12","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-block-synchronization-logic","title":"1. Optimize block synchronization logic","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4542 https://github.com/tronprotocol/java-tron/pull/4540
"},{"location":"releases/history/#2-optimize-eth_estimategas-and-eth_call-api","title":"2. Optimize eth_estimateGas and eth_call API","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4570
"},{"location":"releases/history/#3-enhance-the-fault-tolerance-of-the-interface","title":"3. Enhance the fault tolerance of the interface","text":"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\uff1ahttps://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
"},{"location":"releases/history/#greatvoyage-v451tertullian","title":"GreatVoyage-v4.5.1(Tertullian)","text":"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.
"},{"location":"releases/history/#core_8","title":"Core","text":""},{"location":"releases/history/#1-optimize-transaction-cache-loading","title":"1. Optimize transaction cache loading","text":"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
"},{"location":"releases/history/#2-optimize-account-trc-10-asset-storage-structure","title":"2. Optimize account TRC-10 asset storage structure","text":"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
"},{"location":"releases/history/#3-optimize-light-node-synchronization","title":"3. Optimize light node synchronization","text":"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
"},{"location":"releases/history/#4-optimize-block-broadcasting","title":"4. Optimize block broadcasting","text":"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
"},{"location":"releases/history/#5-optimize-fetch-block-process","title":"5. Optimize fetch block process","text":"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
"},{"location":"releases/history/#6-support-prometheus-metric-protocol-interface","title":"6. Support prometheus metric protocol interface","text":"Starting from the GreatVoyage-v4.5.1 (Tertullian) version, the node provides an open source system monitoring tool - prometheus\u2019s 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
"},{"location":"releases/history/#7-support-node-stop-at-specified-condition","title":"7. Support node stop at specified condition","text":"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\u2019s 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
"},{"location":"releases/history/#tvm_4","title":"TVM","text":""},{"location":"releases/history/#1-adjust-the-upper-limit-that-can-be-set-for-the-maximum-execution-time-of-tvm","title":"1. Adjust the upper limit that can be set for the maximum execution time of TVM","text":"\"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
"},{"location":"releases/history/#2-optimize-the-cache-structure-of-tvm","title":"2. Optimize the cache structure of TVM","text":"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
"},{"location":"releases/history/#greatvoyage-v446david","title":"GreatVoyage-v4.4.6(David)","text":"GreatVoyage-v4.4.6 (David) updated the version of the dependency library fastjson to ensure the security of using fastjson.
"},{"location":"releases/history/#other-changes_13","title":"Other Changes","text":""},{"location":"releases/history/#1-update-the-fastjson-dependency-library-to-the-latest-version","title":"1. Update the fastjson dependency library to the latest version","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4393
*Beauty in things exists in the mind which contemplates them. *
---David Hume
"},{"location":"releases/history/#greatvoyage-445cicero","title":"GreatVoyage-4.4.5(Cicero)","text":"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.
"},{"location":"releases/history/#other-changes_14","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-the-query-interface-of-the-node","title":"1. Optimize the query interface of the node","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4349
No one can give you better advice than yourself.
---Cicero
"},{"location":"releases/history/#greatvoyage-444plotinus","title":"GreatVoyage-4.4.4(Plotinus)","text":"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.
"},{"location":"releases/history/#core_9","title":"Core","text":""},{"location":"releases/history/#1-optimize-node-startup-time","title":"1. Optimize node startup time","text":"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
"},{"location":"releases/history/#2-optimize-memory-usage","title":"2. Optimize memory usage","text":"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
"},{"location":"releases/history/#3-optimize-the-block-producing-thread","title":"3. Optimize the block-producing thread","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4219
"},{"location":"releases/history/#tvm_5","title":"TVM","text":""},{"location":"releases/history/#1-tvm-support-multi-version-program-executors","title":"1. TVM support multi-version program-executors","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4257 https://github.com/tronprotocol/java-tron/pull/4259
"},{"location":"releases/history/#other-changes_15","title":"Other Changes","text":""},{"location":"releases/history/#1-optimize-log-storage","title":"1. Optimize log storage","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4245
"},{"location":"releases/history/#2-optimize-network-service-shutdown-logic","title":"2. Optimize network service shutdown logic","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4220
"},{"location":"releases/history/#3-improve-the-java-tron-upgrade-mechenism","title":"3. improve the java-tron upgrade mechenism","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4218
The world is knowable, harmonious, and good.
--- Plotinus
"},{"location":"releases/history/#greatvoyage-442augustinus","title":"GreatVoyage-4.4.2(Augustinus)","text":"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.
"},{"location":"releases/history/#tvm_6","title":"TVM","text":""},{"location":"releases/history/#1-tvm-opcode-execution-model-optimization","title":"1. TVM Opcode Execution Model Optimization","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4157
"},{"location":"releases/history/#api_8","title":"API","text":""},{"location":"releases/history/#1-newly-adding-eth-compatible-log-filter-for-json-rpc-apis","title":"1. Newly Adding ETH compatible log filter for JSON-RPC APIs.","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4153
"},{"location":"releases/history/#other-changes_16","title":"Other Changes","text":""},{"location":"releases/history/#1-leveldb-databases-performance-optimization","title":"1. LevelDB Databases Performance Optimization","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4154
Patience is the companion of wisdom.
--- Augustinus
"},{"location":"releases/history/#greatvoyage-440rousseau","title":"GreatVoyage-4.4.0(Rousseau)","text":"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.
"},{"location":"releases/history/#core_10","title":"Core","text":""},{"location":"releases/history/#1-optimize-the-block-broadcasting","title":"1. Optimize the block broadcasting","text":"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
"},{"location":"releases/history/#2-optimize-the-query-performance-of-dynamic-store","title":"2. Optimize the query performance of dynamic store","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/3993
"},{"location":"releases/history/#3-optimize-the-transaction-broadcasting-interface","title":"3. Optimize the transaction broadcasting interface","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4000
"},{"location":"releases/history/#4-optimize-the-parameters-of-the-database","title":"4. Optimize the parameters of the database","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4018 https://github.com/tronprotocol/java-tron/pull/3992
"},{"location":"releases/history/#tvm_7","title":"TVM","text":""},{"location":"releases/history/#1-provide-compatibility-with-evm","title":"1. Provide compatibility with EVM","text":"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 \u201cTransferContract\u201d to transfer TRX to the smart contract account.
TIP: https://github.com/tronprotocol/tips/blob/master/tip-272.md Source Code\uff1ahttps://github.com/tronprotocol/java-tron/pull/4032
NOTICE\uff1a By default, this feature is disabled, and the super representative or super partner will initiate a vote request to enable it in the future.
"},{"location":"releases/history/#2-adapt-to-ethereum-london-release","title":"2. Adapt to Ethereum London Release","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4032
NOTICE\uff1a By default, this feature is disabled, and the super representative or super partner will initiate a vote request to enable it in the future.
"},{"location":"releases/history/#3-in-constant-mode-energy-limit-supports-customization-and-the-default-value-is-increased","title":"3. In constant mode, Energy limit supports customization and the default value is increased","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4032
"},{"location":"releases/history/#api_9","title":"API","text":""},{"location":"releases/history/#1-support-ethereum-compatible-json-rpc-api","title":"1. Support Ethereum compatible JSON-RPC API","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4046
"},{"location":"releases/history/#2-fullnode-supports-disabling-apis","title":"2. FullNode supports disabling APIs","text":"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\uff1ahttps://github.com/tronprotocol/java-tron/pull/4045
"},{"location":"releases/history/#3-optimize-the-triggerconstantcontract-api","title":"3. Optimize the TriggerConstantContract API","text":"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\uff1a https://github.com/tronprotocol/java-tron/pull/4032
"},{"location":"releases/history/#changes","title":"Changes","text":""},{"location":"releases/history/#1-upgrade-event-plugin-to-support-bttc-data","title":"1. Upgrade event plugin to support BTTC data","text":"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
"},{"location":"releases/history/#2-increase-the-upper-limit-of-the-maxfeelimit-network-parameter","title":"2. Increase the upper limit of the MaxFeeLimit network parameter.","text":"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\uff1a https://github.com/tronprotocol/java-tron/pull/4032
NOTICE\uff1a By default, this feature is disabled, it will be enabled after the London upgrade proposal takes effect.
"},{"location":"releases/history/#3-optimize-the-quick-start-script-startsh","title":"3. Optimize the quick start script start.sh","text":"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
"},{"location":"releases/history/#greatvoyage-430bacon","title":"GreatVoyage-4.3.0(Bacon)","text":"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.
"},{"location":"releases/history/#core_11","title":"Core","text":""},{"location":"releases/history/#1-add-a-proposal-to-adjust-the-free-net-limit-in-an-account","title":"1. Add a proposal to adjust the free net limit in an account.","text":"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.
"},{"location":"releases/history/#2-add-a-proposal-to-adjust-the-total-net-limit","title":"2. Add a proposal to adjust the total net limit.","text":"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.
"},{"location":"releases/history/#3-optimize-the-account-data-structure","title":"3. Optimize the Account Data Structure","text":"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.
"},{"location":"releases/history/#tvm_8","title":"TVM","text":""},{"location":"releases/history/#1-add-vote-instructions-and-precompile-contracts-in-tvm","title":"1. Add Vote Instructions and Precompile Contracts in TVM","text":"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.
"},{"location":"releases/history/#2-add-a-new-type-error-in-smart-contract-abi","title":"2. Add a New Type: Error in Smart Contract ABI","text":"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
"},{"location":"releases/history/#api_10","title":"API","text":""},{"location":"releases/history/#1-add-a-new-field-energy_used-in-transactionextention","title":"1. Add a New Field: energy_used in TransactionExtention","text":"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
"},{"location":"releases/history/#changes_1","title":"Changes","text":""},{"location":"releases/history/#1-change-the-cryptography-library-to-bouncy-castle","title":"1. Change the Cryptography Library to Bouncy Castle","text":"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
"},{"location":"releases/history/#2-modify-the-calculation-of-net_usage-value-in-the-transactioninfo-when-creating-new-accounts","title":"2. Modify the Calculation of net_usage Value in the Transactioninfo when Creating New Accounts","text":"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
"},{"location":"releases/history/#3-optimize-the-block-verification","title":"3. Optimize the Block Verification","text":"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
"},{"location":"releases/history/#4-optimize-the-node-startup","title":"4. Optimize the Node Startup","text":"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
"},{"location":"releases/history/#5-optimize-transaction-processing-flow-to-reduce-memory-usage","title":"5. Optimize Transaction Processing Flow to Reduce Memory Usage","text":"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
"},{"location":"releases/history/#6-add-new-plugins-to-optimize-the-performance-of-levedb-startup","title":"6. Add New Plugins to Optimize the Performance of levedb Startup","text":"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
"},{"location":"releases/history/#greatvoyage-4221epictetus","title":"GreatVoyage-4.2.2.1(Epictetus)","text":"We have just released the version of GreatVoyage-v4.2.2.1(Epictetus). The main new features and modifications are as follows:
"},{"location":"releases/history/#core-protocol","title":"Core Protocol","text":""},{"location":"releases/history/#1-optimize-the-processing-logic-of-pending-transactions","title":"1. Optimize the processing logic of pending transactions.","text":"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.
- Source code: #3874
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
"},{"location":"releases/history/#greatvoyage-422lucretius","title":"GreatVoyage-4.2.2(Lucretius)","text":"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.
"},{"location":"releases/history/#core-protocol_1","title":"Core Protocol","text":""},{"location":"releases/history/#1-block-processing-optimization","title":"1. Block Processing optimization","text":"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
- Source code: #3827
"},{"location":"releases/history/#2-data-query-optimization","title":"2. Data Query optimization","text":"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.
"},{"location":"releases/history/#3-smart-contract-abi-storage-optimization","title":"3. Smart Contract ABI Storage optimization","text":"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
- Source code: #3836
"},{"location":"releases/history/#other-changes_17","title":"Other Changes","text":""},{"location":"releases/history/#1-system-contract-batchvalidatesign-initialization-process-optimization","title":"1. System Contract BatchValidateSign Initialization Process optimization","text":" - Source code: #3836
--- Truths kindle light for truths.
--- Lucretius
"},{"location":"releases/history/#greatvoyage-420plato","title":"GreatVoyage-4.2.0(Plato)","text":"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.
"},{"location":"releases/history/#core-protocol_2","title":"Core Protocol","text":""},{"location":"releases/history/#1-optimize-the-resource-model","title":"1. Optimize the resource model","text":"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\uff1a TIP-207
- Source Code: #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).
"},{"location":"releases/history/#tvm_9","title":"TVM","text":""},{"location":"releases/history/#1add-freezeunfreeze-instructions-in-tvm","title":"1\u3001Add Freeze/Unfreeze instructions in TVM","text":"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
- Source Code\uff1a #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.
"},{"location":"releases/history/#other-changes_18","title":"Other Changes","text":""},{"location":"releases/history/#1optimize-the-block-synchronization","title":"1\u3001Optimize the block synchronization.","text":" - Source code\uff1a#3732
The beginning is the most important part of the work.
--- Plato
"},{"location":"releases/history/#greatvoyage-413thales","title":"GreatVoyage-4.1.3(Thales)","text":"GreatVoyage-4.1.3(Thales) is released with the following new features and modifications:
"},{"location":"releases/history/#core-protocol_3","title":"Core Protocol","text":""},{"location":"releases/history/#1sorting-the-transactions-in-pending-pool-sr-will-prioritize-the-transactions-with-high-packing-fee","title":"1.Sorting the transactions in pending pool, SR will prioritize the transactions with high packing fee","text":"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.
"},{"location":"releases/history/#api_11","title":"API","text":""},{"location":"releases/history/#1add-new-api-to-support-transaction-query-in-pending-pool","title":"1.Add new API to support transaction query in pending pool.","text":"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.
"},{"location":"releases/history/#great-voyage-v412","title":"Great Voyage - v4.1.2","text":"GreatVoyage-version 4.1.2 is released with the following new features and modifications:
"},{"location":"releases/history/#i-core-protocol","title":"I. Core Protocol","text":""},{"location":"releases/history/#1reward-srs-with-the-transaction-fees-charged-for-bandwidth-and-energy","title":"1\u3001Reward SRs with the transaction fees charged for bandwidth and energy.","text":"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
- Source Code: #3532
"},{"location":"releases/history/#2support-account-history-balance-query","title":"2\u3001Support account history balance query.","text":"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 \uff1aquery account balance at a specific block.
- /wallet/getblockbalance \uff1a 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\uff1a#3538
- Guide \uff1a https://github.com/tronprotocol/documentation-en/blob/master/docs/api/http.md
"},{"location":"releases/history/#3optimized-the-blackhole-account-to-improve-transaction-execution-speed","title":"3\u3001Optimized the blackhole account to improve transaction execution speed","text":"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\uff1a #3617
"},{"location":"releases/history/#ii-tvm","title":"II. TVM","text":""},{"location":"releases/history/#1adopt-to-solidity060","title":"1\u3001Adopt to solidity0.6.0.","text":"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
- Source Code\uff1a #3351
"},{"location":"releases/history/#2make-max_fee_limit-configurable-as-a-chain-property","title":"2\u3001Make MAX_FEE_LIMIT configurable as a chain property.","text":"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].
- TIP\uff1a TIP-204
- Source code\uff1a #3534
"},{"location":"releases/history/#iii-others-changes","title":"III. Others Changes","text":""},{"location":"releases/history/#1use-the-jitpack-repository-to-provide-dependency-support-and-make-it-easy-for-developers-to-use-java-tron-as-a-dependency-for-their-projects","title":"1\u3001Use the jitpack repository to provide dependency support and make it easy for developers to use java-tron as a dependency for their projects.","text":" - Source code: #3554
"},{"location":"releases/history/#greatvoyage-v411","title":"GreatVoyage-v4.1.1","text":"GreatVoyage-version 4.1.1 is released with the following new features and modifications:
"},{"location":"releases/history/#i-core-protocol_1","title":"I. Core Protocol","text":""},{"location":"releases/history/#1-new-consensus-protocol","title":"1. New Consensus Protocol","text":"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
"},{"location":"releases/history/#2-new-node-type","title":"2. New Node Type","text":"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
"},{"location":"releases/history/#ii-tvm_1","title":"II. TVM","text":""},{"location":"releases/history/#achieved-compatibility-with-ethereum-istanbul-upgrade","title":"Achieved compatibility with Ethereum Istanbul upgrade","text":"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
"},{"location":"releases/history/#iii-mechanism","title":"III. Mechanism","text":" - Added two new system contracts, namely MarketSellAssetContract and MarketCancelOrderContract, for on-chain TRX/TRC10 transactions in decentralized exchanges.
- TIP: TIP-127
- Source code: #3302
"},{"location":"releases/history/#iv-other-modifications","title":"IV. Other Modifications","text":" - Added a few node performance indicators.
-
Source code: #3350
-
Added market order detail in the original transactionInfo interface.
- TIP: TIP-127
-
Source code: #3302
-
Improved the script for docker deployment.
- Source code: #3330
"},{"location":"releases/history/#greatvoyage-v400","title":"GreatVoyage-v4.0.0","text":"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.
"},{"location":"releases/history/#notices","title":"Notices","text":"Forced upgrade
"},{"location":"releases/history/#new-features","title":"New features","text":" - 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.\u00a0Create shielded contract parameters
rpc CreateShieldedContractParameters (PrivateShieldedTRC20Parameters) returns (ShieldedTRC20Parameters) {}\n
2.\u00a0Create shielded contract parameters without ask rpc CreateShieldedContractParametersWithoutAsk (PrivateShieldedTRC20ParametersWithoutAsk) returns (ShieldedTRC20Parameters) {}\n
3.\u00a0Scan shielded TRC20 notes by ivk rpc ScanShieldedTRC20NotesByIvk (IvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}\n
4.\u00a0Scan shielded TRC20 notes by ovk rpc ScanShieldedTRC20NotesByOvk (OvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}\n
5.\u00a0Check if the shielded TRC20 note is spent rpc IsShieldedTRC20ContractNoteSpent (NfTRC20Parameters) returns (NullifierResult) {}\n
6.\u00a0Get the trigger input for the shielded TRC20 contract rpc GetTriggerInputForShieldedTRC20Contract (ShieldedTRC20TriggerContractParameters) returns (BytesMessage) {}\n
- 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).
"},{"location":"releases/history/#changes_2","title":"Changes","text":" - Check if null before getInstance when get transaction info from DB to fix exception of
getTransactioninfoByBlkNum (#3165).
"},{"location":"releases/history/#odyssey-v37","title":"Odyssey-v3.7","text":"Odyssey-v3.7 is a non-mandatory upgrade, includes the following new features and improvements.
"},{"location":"releases/history/#modularization","title":"Modularization","text":"Odyssey-v3.7 has modularized the code organization structure, making it much easier for developers to develop customized module\uff0cseveral mainly modules are listed as follows\uff1a
"},{"location":"releases/history/#framework","title":"Framework","text":"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.
"},{"location":"releases/history/#protocol","title":"Protocol","text":"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\uff0cincluding 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
"},{"location":"releases/history/#consensus","title":"Consensus","text":"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.
"},{"location":"releases/history/#crypto","title":"Crypto","text":"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.
"},{"location":"releases/history/#actuator","title":"Actuator","text":"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.
"},{"location":"releases/history/#chainbase","title":"Chainbase","text":"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.
"},{"location":"releases/history/#new-event-subscription-trigger-for-solidified-block","title":"New event subscription trigger for solidified block","text":"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.
"},{"location":"releases/history/#two-new-http-apis-added","title":"Two new HTTP APIs added","text":"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
"},{"location":"releases/history/#a-new-rpc-api-added","title":"A new RPC API added","text":"Adding the GetTransactionInfoByBlockNum method both in Wallet WalletSolidity services\uff1a
rpc GetTransactionInfoByBlockNum (NumberMessage) returns (TransactionInfoList) {\n}\n
a code snippet\uff1a NumberMessage.Builder builder = NumberMessage.newBuilder();\nbuilder.setNum(blockNum);\nTransactionInfoList transactionInfoList = blockingStubFull.getTransactionInfoByBlockNum(builder.build());\n
"},{"location":"releases/history/#odyssey-v365","title":"Odyssey-v3.6.5","text":"Odyssey v3.6.5 Update includes the following new features and improvements
"},{"location":"releases/history/#1-new-delegation-mechanism","title":"1. New delegation mechanism","text":"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\u2019s 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.
"},{"location":"releases/history/#2-fairer-and-more-efficient-staking-rewards-mechanism","title":"2. Fairer and more efficient staking rewards mechanism","text":"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.
"},{"location":"releases/history/#3-fairer-incentive-mechanism","title":"3. Fairer incentive mechanism","text":"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.
"},{"location":"releases/history/#4-improvement-and-optimization-of-tvm","title":"4. Improvement and optimization of TVM","text":"(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\u2019 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.
"},{"location":"releases/history/#5-improvement-of-the-dynamic-adjustment-scheme-of-energy-upper-limit","title":"5. Improvement of the dynamic adjustment scheme of Energy upper limit","text":"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\u2019 costs of using TRON blockchain network and improving network efficiency.
"},{"location":"releases/signature_verification/","title":"Signature Verification of java-tron Release Package","text":"java-tron integrity verification is to check the reliability and integrity of the obtained java-tron executable file through signature verification. Signature verification needs to know three pieces of information: the executable file to be verified, the signature of the file, and the public key corresponding to the private key that signed the file. Signature verification is to reversely deduce the public key corresponding to the signature based on the content and signature of the executable file, and then compare it with the public key issued by TRON. If they are consistent, it means that the java-tron executable file you get is a complete file released by TRON.
The version of java-tron released after January 3, 2023 adopts the GPG method for signature and verification, and the version released before January 3, 2023 used the public-private key of a specified TRON account for signature and verification.
- Versions released after January 3, 2023: GPG Signature Verification Process
- Versions released before January 3, 2023: TRON Address Signature Verification Process
"},{"location":"releases/signature_verification/#gpg-signature-verification-process","title":"GPG signature verification process","text":"The java-tron executable file and its signature file are released together, you can get it at here, please follow the below process to verify the signature of the java-tron which released after January 3, 2023.
"},{"location":"releases/signature_verification/#install-gpg","title":"Install GPG","text":"If you have already installed GPG, please skip this step. If not, please refer to the following command to install it on MacOS:
$ brew install gpg\n
On Debian, Ubuntu and other Linux distributions: $ sudo apt install gpg\n
"},{"location":"releases/signature_verification/#import-public-key","title":"Import public key","text":"If you have imported the public key before, please skip this step, just import the public key once.
Please first obtain the public key Hash and uid of the GPG signature of the java-tron release package from here.
pub: 1254\u00a0F859\u00a0D2B1\u00a0BD9F\u00a066E7\u00a0107D\u00a0F859\u00a0BCB4\u00a04A28\u00a0290B\nuid: build@tron.network\n
Import the public key from the GPG public key server to the local according to the public key Hash, the command is: $ gpg --keyserver hkp://keys.openpgp.org --recv-keys \"1254\u00a0F859\u00a0D2B1\u00a0BD9F\u00a066E7\u00a0107D\u00a0F859\u00a0BCB4\u00a04A28\u00a0290B\"\n
If the import was successful, you will see the return result like this: gpg: key 785FB96D2C7C3CA5: public key \u201cbuild_tron <build@tron.network>\u201d imported\ngpg: Total number processed: 1\ngpg: imported: 1\n
"},{"location":"releases/signature_verification/#signature-verification","title":"Signature verification","text":"For example, if the executable file of a certain version is FullNode.jar and the signature file is FullNode.jar.sig, the signature verification command is:
$ gpg --verify FullNode.jar.sig FullNode.jar\n
If the signature verification is passed, the following will be returned: gpg: Signature made Fri. 1/ 6 12:21:51 2023 CST\ngpg: using RSA key 1254F859D2B1BD9F66E7107DF859BCB44A28290B\ngpg: Good signature from \u201cbuild_tron <build@tron.network>\u201d [unknown]\ngpg: WARNING: This key is not certified with a trusted signature!\ngpg: There is no indication that the signature belongs to the owner.\nPrimary key fingerprint: 07B2 3298 AEA4 E006 BD9A 42DE 785F B96D 2C7C 3CA5\nSubkey fingerprint: 1254 F859 D2B1 BD9F 66E7 107D F859 BCB4 4A28 290B\n
If the verification fails, it will display the words gpg: BAD signature from \u201cbuild_tron <build@tron.network>\u201d."},{"location":"releases/signature_verification/#tron-address-signature-verification-process","title":"TRON address signature verification process","text":"The java-tron version released before January 3, 2023 is signed by the TRON account TKeAcHxgErbVXrG3N3TZiSV6AT566BHTj2. The signing steps are as follows: first generate a sha256 hash value for the executable file of the release package, and then use the private key of the TRON account to sign the sha256 hash value. The sha256 hash value can be viewed in the Signatures of historical versions chapter, or in the https://github.com/tronprotocol/java-tron/releases page; the signature result please check in the Signatures of historical versions chapter.
tronweb provides the Trx.verifySignature interface to verify the signature. If the verification is passed, it will return true, otherwise, it will return false. Please follow the below process to verify.
"},{"location":"releases/signature_verification/#install-tronweb","title":"Install tronweb","text":"If you have already installed tronweb, please skip this step, if not, please refer to the following command to install.
npm install -g tronweb\n
"},{"location":"releases/signature_verification/#verify-the-integrity-of-the-release-package","title":"Verify the integrity of the release package","text":"Confirm the integrity of the release package by comparing the Hash value of the executable file and the hash value in the release information. Take Odyssey-3.7 version as an example:
- The release package file name:
FullNode.jar - The SHA256 value of the release package:
2fca93b09da4ac62641e03838e77fce99b4711ddb0c09aa91656c80fc9556d2e - Signature\uff1a
21435e32131feb6d00ba8048df04e112e02569ec851064d8ecad2d4dd5da44b7628ddce16823dadfff6fd683fc58cee74964970621a845ee459e2c96a750de551b
Execute the following command for verification under MacOS system:
$ sha256sum FullNode.jar \n
Execute the following command for verification under Debian, Ubuntu and other Linux distributions: $ shasum -a 256 FullNode.jar (macOS)\n
"},{"location":"releases/signature_verification/#signature-verification_1","title":"Signature verification","text":"Execute the following command to verify the signature of the release package:
# Trx.verifySignature(SHA256, ADDRESS, SIGNATURE));\nnode -e 'console.log(require(\"tronweb\").Trx.verifySignature(\n \"2fca93b09da4ac62641e03838e77fce99b4711ddb0c09aa91656c80fc9556d2e\",\n \"TKeAcHxgErbVXrG3N3TZiSV6AT566BHTj2\",\n \"21435e32131feb6d00ba8048df04e112e02569ec851064d8ecad2d4dd5da44b7628ddce16823dadfff6fd683fc58cee74964970621a845ee459e2c96a750de551b\"\n ))'\n
"},{"location":"releases/signature_verification/#signatures-of-historical-versions","title":"Signatures of historical versions","text":" - Odyssey-3.7
FullNode sha256sum: 2fca93b09da4ac62641e03838e77fce99b4711ddb0c09aa91656c80fc9556d2e\nFullNode signature: 21435e32131feb6d00ba8048df04e112e02569ec851064d8ecad2d4dd5da44b7628ddce16823dadfff6fd683fc58cee74964970621a845ee459e2c96a750de551b\nSolidityNode sha256sum: fcdea8b3e511306218ba442fb0828f0413574012d646c39c212a59f6ba5844bc\nSolidityNode signature: 6dcad6e02f17467e5cfebeefa0f9963da08e7da10feebefdec47d689fecc30f104c9b7f5e784b883e7ceb786fe55188356c42c306d727fb7819eed2a71f788361c\n
- GreatVoyage-4.0.0
FullNode sha256sum: d3f8f9fde64bdefaadae784d09de97172e5e8a3fe539217e12b89963983a530d\nFullNode signature: e788dbaf2fe35f099f65b2403cfb0d7cbe7f4611f8c5ff8151e4bd84ae468d2e541043c9cde9e74500003027ae9f25cdda81a9bcd60abb45ca7a69f965f4dcc71c\nSolidityNode sha256sum: adddf88423c6c31f1f25ed39b10779c24dd7cdcf37f2325c02b2f2ecfc97e1f6\nSolidityNode signature: e3b9859f178f7851dedb7a0a8deb715e5f1e3af10b1064c36f2727ec2b8825510df4fd7b09d7d049204e5df3e8d5b87778e83a15ca96ce786f7977a6cb48bca91b\n
- GreatVoyage-4.1.1
FullNode sha256sum: 30e716b86b879af1e006c2b463903ae3835e239e32e2b01c2a1b903a153897fe\nFullNode signature: 5faee65a448bb9aa77835992ca3d24e50d8a76b7934f80664ad38e83179c8114278fdef4494de7231f8e40de86461676a7aa4a54c795f4c692e91d90e156ec471b\nSolidityNode sha256sum: 10a160181053b421109ecace74df5fc0f8860bc8a70181add65fd9a292c35a44\nSolidityNode signature: 1d1413b13adf7778f9a720294eca066ac728ad636d166505276f5ff1f63973c100c04778f937f240f10107edb7de477604857867fc4dbdb68238169c978fc3da1b\n
- GreatVoyage-v4.1.2
FullNode sha256sum: 4ded44b6c1a3dbd25212e14ab413142b5463dcbf30a528f83ded529048542547\nFullNode signature: 57a094c1b8a5ec301ef913eb718de2498b5695eb999530863df05252ba8919ba6866c8490e29d36f7dbf34537c898ece5ef0111efb134419c3a5fd6fc9ec03b81c\nSolidityNode sha256sum: 3db36cadbd1f7641aafc8164983f28df4b7ceff8174e090327ed407012cf12cb\nSolidityNode signature: d07604f6811cbed628dd6e5c07880c2fdd3025848fd5365925531c7748467d5228fea2e18326864acc27f3b51c73b364fa44c450d8ec4b5080a7ddb7566724701c\n
- GreatVoyage-v4.1.3(Thales)
FullNode sha256sum: c5fb99ad5b024bb7877118f30fb6065f6e6febd11a3cfa241521cbed73cca181\nFullNode signature: d80ec371e791c4316925d80ff3400cf51b14c8a4d4c696b7817c517eb094823622932b45b9b37f9e9657513c3eddb1134fbbb1ee56727c0957e8a3b40c67409b1c\nSolidityNode sha256sum: 4b941d71b561a8b2e0b97d7498823d900eaf287910eea1eaafc649f5aad14036\nSolidityNode signature: f8a8e8d411b009d02986cad1e19e745f8107384a274f146bcae60c570111b13556ff9ab528eb5d1fb4734bd4ef488ade4038781d06ab6420e35f28be6135fe9b1c\n
- GreatVoyage-v4.2.0(Plato)
FullNode sha256sum:\nbbf103432be016b582452137b4862140af15ccf7c5daa9be738450705317fdb8\nFullNode signature:\n326701699a5eb8d497eb454b5b74c1559961417fb6f262b4e6314052d73f5977312e0450937fa485236f51f706b434acf8659ce1325d704097c5748629e736ef1c\nSolidityNode sha256sum:\n1db544cbca9dc814683ccf9bef28f7d6ca4469289052230394aaf4e3bcd08615\nSolidityNode signature:\n47fea27df940db0d2a4c0abf6d06969882c027bc4f17449205a28ae5cd25b8ba5339e21f105fe1c25e799d0f4ffea64a15046b9baf5b54341411b5180da439011b\n
- GreatVoyage-v4.2.1(Origen)
FullNode sha256sum:\n9888710c915a4027f1bc3dcb1d5d983e0c00d4c438f6fa307d412f62ff6862ea\nFullNode signature:\n6e7d8ef9d033ebf9213118b7511f4ecc5def97442844fbd34de3ef76dd417a0d45da3e2e70fc213475d7fc0a44df1c54732874d858ec980159c5dbffc975680a1c\nSolidityNode sha256sum:\nc70edffa3022e9c25bf845ee978e3500c3ada89b473d895a715acf1738b83f10\nSolidityNode signature:\n0e366acce33bb7c6b02fa143a57d9380c94d3513a9fba8692efe2862a8f7df93156edbddd075f1844f2f81398b14f2db6a03e21f0f6b8ab25649fae4dc16ae731b\n
- GreatVoyage-v4.2.2(Lucretius)
FullNode sha256sum:\n8a7f8143b3351ea6b5d8e3dfc857b09256d363d4907ba3ab0288f67f77c2a58f\nFullNode signature:\n71c6300ace5cbf16d78a32aa4602c3f129cb768e32acffaecd17b4134b5955bf37efda1d27025e894e521184a21174e5eddf4e7d1f86761657827795cbddfcfd1c\nSolidityNode sha256sum:\n2d0d5334a232b7b74df8ed3211d9e0ac957894f81e9172010732f2159da261ad\nSolidityNode signature:\n0696f8cb3c65324c4b04f9ecf89d939bf7e1b955144e3fe75eeca6bd4c639e463afbe24e31ae38a6889d4d0649ae03fafeeb7c337b34a36fbac33962f64651671b\n
- GreatVoyage-v4.2.2.1(Epictetus)
FullNode sha256sum:\n8bd040a8db16ccba3e957ed3558b82d145928153a53f9688302849658a72f9bc\nFullNode signature:\n3137a8ba8fa5556e4c4a7597aec8f5f46ebb79a64edcf9e2925d2e3314afde3e0f42fd4080e5e4f4d3d1eff263d30478b0322e6dbcc71c43b534f614004b5c561b\nSolidityNode sha256sum:\nee8abd39732e4901828a61124880f1d2eab62f7f3d97150f1e1921bf7da10e54\nSolidityNode signature:\n092b08184677449dd283a31cc486f994166cd9f5ad312a9c80d3e06689ec540774ac9a1334dffeb6412039ed70ee912ead39c4025dd69b688ea9df4dd831b5771c\n
- GreatVoyage-v4.3.0(Bacon)
FullNode sha256sum:\nb5e993800cea5ca040758dd6b3c7438def03cbf1358468beb76ea45399a59298\nFullNode signature:\n8da6ac58129d78d948810e4bc7372dd8aef5232bfbc4c33ad8fb21e88314e3d97dd77509e0f03a98da32679495152ccd4a9d07541589822e5cf5d3d4f61877191b\nSolidityNode sha256sum:\n446a4736901958a450e4e95aaca99a63957163854fb32d25eed84600e6996668\nSolidityNode signature:\nc27ffde8ce88ee14689e15a9d5c3fb2d2a9d180ea43b45046131df8ac5481fae2588621b395ad7031ed49d65ddd020b3ce084537e3f527d8a5a979f8c65265561c\n
- GreatVoyage-v4.4.0(Rousseau)
FullNode sha256sum:\nbf7f962846f75139dd89ac6da32074cad33b2e172c0749abbed8773cc1ab1a37\nFullNode signature:\n56ed97f3451e3d731f799bad952750d56aa78a9a91a2688b4d6b956328ede7e01bae78037ad6ef1f9c682b566e954dfb958271f006e5cf0dcace5768d76fda6e1b\nSolidityNode sha256sum:\n9dac37763ddf75c07335ec070f837b63ee46b698066dd25c4756ad40f8750d5f\nSolidityNode signature:\ncc4325c085719e3e5045b5c6c2553d7adc9c735419618f7afad06c3a532da0ed46906ae9b2dadb15d7f94150268d5ecdc7fd2741693991586d50da30a8d917071b\n
- GreatVoyage-v4.4.1(Protagoras)
FullNode sha256sum:\n4a32918849dc8a7fedcb637ff4939389363726cb16c6a581e39253260668ee04\nFullNode signature:\nfd747f61705ef045143bd2d55b278ca347904323711e2e86b11cf1dd203f198443ab1a399767a570005bd5b2ea283187ccc41557ffb79c959b018e8d798b96f81c\nSolidityNode sha256sum:\nb6a06d3b19f41591bd8c01f35e78b316ab8e9ad4c0740128fc95ba52d3106f34\nSolidityNode signature:\nd2836bda30fd25c89494ae7a12b5357bc9e725c9e2c655fb0a9158a4bee881693ea869defe650b0b4f190458a5268f1c121e73c8305cc81a408e62fca0d234c51b\n
- GreatVoyage-v4.4.2(Augustinus)
FullNode sha256sum:\n70eba12350fa21e1b261927093090e7bdf0765592d19433c594149bd3707ef0a\nFullNode signature:\n14430f463e6fab3dd247aca6267b6aaf2f1869b455d95aee297208bd1561c6c67559d9c535e63e74bbef604141cc4ceec78367a75e6ca4d4ceb6513019329c9b1b\nSolidityNode sha256sum:\nf08438e093cc1091859f0ee9dbc7e79b0d5d9068facd4e6485374baa3acf59d1\nSolidityNode signature:\nf3935dfe4af9601cf102c975ed2eebbd4b42160e8746c0d0b21ffbd2fbd4b6f374257b1bc0e948909a9ef343d2cc70671961c8f7a992b6cd123f9ad3c8c323391c\n
- GreatVoyage-v4.4.3(Pythagoras)
FullNode sha256sum:\nc07637a1a4a9a289218554f4714caef90032e267b068411c7dd818d4af45e39f\nFullNode signature:\n2bf8d65adf556fe2c04b739c1f4e6e73058914cf642a7806ff85e57be2ff122e35cbf3d67b0bc8bad4fb827198ffd8e06f60111a167ecb0b3db0d8e571b8c67b1c\nSolidityNode sha256sum:\n64f4614160b9330d0a9e984686b66fa16e9aecf7ae16e32b8cc7c32f52694eef\nSolidityNode signature:\ndc0f910555a23667d682a6775588de90592ede44f76a32b12ea8f89fa7dcc937274cc3a44b20da49726323cc9f476d42caa318c338858474f02bf98cc398bca81c\n
- GreatVoyage-v4.4.4(Plotinus)
FullNode sha256sum:\n0264d382489dae5bf1d340030c1892b0a7aeb9364cb9380c034e159c9eb9a269\nFullNode signature:\n70cdece8c3510ce4d7d84d5d2c8b53895397c0134d73d681b6b41d4de80d74ce2c2760fdf080ff0ce8c0989246377fca529cb1a2e85e1936755abef4be64f0971b\nSolidityNode sha256sum:\nb58e7b8b0f97eb2a7a0ce5c5aeb2ce070192ca82c96adc8568aabe4f3407d873\nSolidityNode signature:\n26da2e507bbd7e82e0170039cc1c0e42332fb2dfc755aeb385240f0a93125b6c0f1e943ccf1a4e9bfec7fdd4d8a26375a38e030e0b8b69af3e2c181bf08444111b\n
- GreatVoyage-v4.4.5(Cicero)
FullNode sha256sum:\n8115e887e5af5768e8ab967f8e7bc024af94bda31be7f3dbc30934b42489d988\nFullNode signature:\n1a02f26eb6065efe5697123528f32ea352d813f9e5acf5936407ad8899c4019539e31b257cafe34b9f8045602f5a4f381b3dd8252a30bb9daf52aeeb078b54711b\nSolidityNode sha256sum:\n95884a07dcbb1531ec7ae20b7162cab3bb9c4bd2e300447c01c4772e02b24a20\nSolidityNode signature:\n8adab9501bbb2a3d9f3055c91e819f86081df9b92228a86afb7f0a27165a42690dbeb50f0f1fd1f7180b51809a291c5ff3860e49f888cf0ba87b401d3dda6e271c\n
- GreatVoyage-v4.4.6(David)
FullNode sha256sum:\neaf213f6e6cd9913f9f27bf72a42209c1a0f0fce9841c1d6bd680d879d7d6f85\nFullNode signature:\n064abe833436b3a2e9b66406abf81d12a20f9d28ef669abe7c87c0d750e58cf10c1e65de6fbd0fc368022f93e4c330b42ea9775ead91962480436985c90ad3b11c\nSolidityNode sha256sum:\nc3e9ccc1a4d2aac4c081ae01db86a0901b6f3506e3f8a953315e47ae274a98c1\nSolidityNode signature:\na03d5d6f0e6c6b869f2e545d8c3ff8a4fed569508e9abe4219271d8bf25dfb015e242add8fd2ab6b8b412dd6b393639517957877e8eb7c07ff43a1351a88d62f1b\n
- GreatVoyage-v4.5.1(Tertullian)
FullNode sha256sum:\ndb3c75d7854dcf241558c2942b9a582f478c00a88b6f7a7e5ff8a653a8d4c59a\nFullNode signature:\n61ba205f28c3bc7fa228c27e4e3b4d460ef4fad75ca1d38d82540d45eea2d3d720196b607cd45c560db7a749d05bfe8089c61fba5843e98d61fec90f1591f2861b\nSolidityNode sha256sum:\n537a81bd781d416229de5e0875247160f2569c378c8eed703203d0acca5be5f1\nSolidityNode signature:\na736f9de5425562a2af188c547245f9b4da6d793728bc767242e3df75fa104f61ce978b62fc5cea7f6008bdb51faa9510ff5633702cdb1ddca29cb06a18920d21c\n
- GreatVoyage-v4.5.2 (Aurelius)
FullNode sha256sum:\n60e959ccde3ff90c10b503bb25edf37684845e358df2ad64b2b330712b30c177\nFullNode signature:\nf2f4b6050e639047857c5b5331eb006dcc9c1e0427bac4ae3d934f7436080785472ead691aa16e6a5aed3c2932fb279ce8ab3580449071b878e0d31fdf01f0371c\nSolidityNode sha256sum:\n4783b8abef12a6c7b8319f3e8960c1d3126edcc521ac1fc3429fe2870cab91b0\nSolidityNode signature:\nafb5db2467ce9f5445679df53e2fecfaed3c4a2d0ca2ba88b65e621aa2d37a9e6aab06b30052a9381087d0164cb5c347d710b2b1c59e6f7c7107deacfd1cfc961b\n
- GreatVoyage-v4.6.0 (Socrates)
FullNode sha256sum:\n598589d428085e25c838552970844b0ba00248ad92873bd2ad25b35f37db7a5b\nFullNode signature:\nd3bcfa1bea64b7e58cb94603563cb0c5e47bc20316f61b0dfc966fb64ae846f21b8f917a63328416993f524f4de55ddf5083f163b1fe1b811a9a6f4532725c8e1c\nSolidityNode sha256sum:\nee37a425a84677063b6ea44ed073b8260e336586a61debc10ce0b1544bf7db6a\nSolidityNode signature:\n332c273ef1cdae8dc39c76a83b38750a74b3dd1b915e49698e4ae6870cfed49a1449e8d8db995c7a6be2295e2603efedb0f3e8e906ac7681583c5023b28a521d1b\n
"},{"location":"releases/upgrade-instruction/","title":"New Version Deployment Manual of java-tron","text":"For the mandatory upgrade versions, please strictly follow this guide to deploy the new version. For the non-mandatory upgrade ones, you can decide whether to deploy it according to your needs.
Please directly refer to java-tron New version deployment Process to upgrade your node. If you have deployed 'Active and Backup nodes', please follow the process of Active and Backup Nodes Upgrade Guide.
"},{"location":"releases/upgrade-instruction/#new-version-deployment-process","title":"New version deployment Process","text":"Please follow the below steps to upgrade your FullNode, FullNode that produces blocks to the latest version.
"},{"location":"releases/upgrade-instruction/#1-prepare-the-executable-file-of-the-new-version","title":"1. Prepare the executable file of the new version","text":"You can directly download the java-tron executable file, or download the code of the latest version and compile it to get the executable file of the new version. Please download the latest version of the code or jar file to a file directory other than the java-tron running directory:
-
Way 1: Download the published executable file
Directly download the latest version of the executable file FullNode.jar from the release page https://github.com/tronprotocol/java-tron/releases.
Before using it, please verify the file signature first to ensure the consistency and integrity of the jar file. For the verification steps, please refer to java-tron Consistency Verification.
-
Way 2: Compile the source code
Download the source code and switch to the branch of the new version.
$ git clone https://github.com/tronprotocol/java-tron.git\n$ git checkout -b relase_vx.x.x\n
Compile the project: In the code directory of the new version, execute the following command to compile the project, and the compiled executable file will be generated in the build/libs directory.
$ ./gradlew clean build -x test\n
"},{"location":"releases/upgrade-instruction/#2-shut-down-the-java-tron-process","title":"2. Shut down the java-tron process","text":"Shut down the node process. Note: If a java-tron node has not been deployed on this machine before, please skip to step 5.
-
First, get the process ID of the java-tron node through the following command
$ ps -ef | grep java\n
-
Shut down the node process
$ kill -15 the process id\n
"},{"location":"releases/upgrade-instruction/#3-backup","title":"3. Backup","text":"Please back up the executable file, database, and configuration file before the upgrade in sequence. The backup data is used to restore to the old version when a problem is encountered that leads to fail deploying during the upgrade.
- Backup the current executable jar file
$ mv $JAVA_TRON.jar $JAVA_TRON.jar.`date \"+%Y%m%d%H%M%S\"`\n
- Backup the current database
output-directory $ tar cvzf output-directory.`date \"+%Y%m%d%H%M%S\"`.etgz output-directory\n
- Backup the current configuration file
$ mv $config.conf $config.conf.`date \"+%Y%m%d%H%M%S\"`\n
"},{"location":"releases/upgrade-instruction/#4-replace-old-version-files","title":"4. Replace old version files","text":"After preparing the executable file of the new version and backing up the original node data, please follow the steps below to replace the old files:
- Copy the newest jar package obtained in the previous step to the java-tron working directory to replace the old executable file.
- Replace the old configuration file with the latest configuration file. If you need to modify the configuration, such as adding a keystore file, private key, etc, please modify it yourself.
Note: For the database file, you can use the original database file in the java-tron working directory, or you can choose to use database backup snapshot.
"},{"location":"releases/upgrade-instruction/#5-start-the-nodes","title":"5. Start the nodes","text":"The startup commands of FullNode which produces blocks and ordinary FullNode are different, please choose the startup command according to the actual situation:
-
For the super representative's FullNode, the startup command is:
nohup java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -p private key --witness -c main_net_config.conf </dev/null &>/dev/null &\n
Note: It is not necessary to use the above command parameter to set the private key. If you use the keystore file or configure the private key in the configuration file, please set it up your way. -
For a FullNode, the startup command is:
nohup java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c main_net_config.conf </dev/null &>/dev/null &\n
"},{"location":"releases/upgrade-instruction/#6-wait-for-syncing-completion","title":"6. Wait for syncing completion","text":"After the node is successfully started, please wait patiently for the node block synchronization to complete.
"},{"location":"releases/upgrade-instruction/#7-upgrade-completed","title":"7. Upgrade completed","text":"After the node is synchronized to the latest block of the network, it means that the deployment of the new version is completed.
If you encounter any problems during the upgrade leading to fail deploying the new version, please use the data backed up in the third step to restore to the old version, and give your feedback in GitHub or the community in time to help you complete the deployment of the new version as soon as possible.
"},{"location":"releases/upgrade-instruction/#active-and-backup-nodes-upgrade-guide","title":"Active and Backup Nodes Upgrade Guide","text":"To upgrade the active and backup nodes, please follow the steps below:
-
Upgrade the backup node
Upgrade the backup node according to the java-tron new version deployment Process.
-
Shut down the master node
After the backup node is successfully upgraded to the new version, please wait for the completion of synchronization of the backup node before shutting down the master node. At this time, the backup node will automatically take over from the master node and become the active node.
-
Upgrade the master node
If the backup node works normally, follow java-tron New Version Deployment Process to upgrade the master node. Otherwise, shut down the backup node and start the master node. If an error occurs during the upgrade, please contact TRON technical support team and send the node\u2019s log for root cause analysis.
-
Shut down the backup node
After the master node is upgraded and fully synchronized, shut down the backup node. After the backup node shuts down, the master node will take over as the active node again.
-
Start the backup node
"},{"location":"using_javatron/backup_restore/","title":"Data Backup & Restore","text":"Everything java-tron persists gets written inside its data directory. The default data directory is: /output-directory/. If you need to specify other directories, you can add -d or --output-directory parameter to the java-tron node startup command to specify the data storage location.
$ java -jar fullnode.jar -d ./outputdir\n
"},{"location":"using_javatron/backup_restore/#data-backup","title":"Data Backup","text":"Please shut down the node process before backing up the node data, for details, please refer to the following steps:
First, use the command $ ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}' to get the process id of java-tron, and then use the command kill -15 process id to kill the process. Or use a stop script like this:
#!/bin/bash\nwhile true; do\n pid=`ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}'`\n if [ -n \"$pid\" ]; then\n kill -15 $pid\n echo \"The java-tron process is exiting, it may take some time, forcing the exit may cause damage to the database, please wait patiently...\"\n sleep 1\n else\n echo \"java-tron killed successfully!\"\n break\n fi\ndone\n
Then, backup the data by the following command.
$ tar cvzf output-directory.`date \"+%Y%m%d%H%M%S\"`.etgz output-directory\n
"},{"location":"using_javatron/backup_restore/#data-restore","title":"Data Restore","text":"When restoring the data, just copy the corresponding backup data to the node directory. Take the database backup file name output-directory.20220628152402.etgz as an example, the command to restore the database file is:
$ tar xzvf output-directory.20220628152402.etgz\n
"},{"location":"using_javatron/backup_restore/#public-backup-data","title":"Public Backup Data","text":"For the TRON mainnet and Nile testnet, since the amount of data to be synchronized is large after the new node is started, it takes a long time to synchronize the data. In order to facilitate rapid node deployment for developers, the community provides data snapshots on a regular basis. A data snapshot is a compressed file of the database backup of a TRON network node at a certain time. Developers can download and use the data snapshot to speed up the node synchronization process.
"},{"location":"using_javatron/backup_restore/#main-net-data-snapshot","title":"Main Net Data Snapshot","text":""},{"location":"using_javatron/backup_restore/#fullnode-data-snapshot","title":"FullNode Data Snapshot","text":"The following table shows the download address of Fullnode data snapshots. Please select a suitable data snapshot according to the location and node database type, and whether you need to query historical internal transactions.
Fullnode Data Source Download site Description Official data source (North America: Virginia) http://34.86.86.229/ LevelDB, exclude internal transactions Official data source (Singapore) http://34.143.247.77/ LevelDB, exclude internal transactions Official data source (North America: America) http://35.197.17.205/ RocksDB, exclude internal transactions Official data source (Singapore) http://35.247.128.170/ LevelDB, include internal transactions Official data source ((North America: Virginia)) http://34.48.6.163/ LevelDB, exclude internal transactions, include account history TRX balance Note\uff1aThe data of LevelDB and RocksDB are not allowed to be mixed. The database can be specified in the config file of the full node, set db.engine to LEVELDB or ROCKSDB.
"},{"location":"using_javatron/backup_restore/#lite-fullnode-data-snapshot","title":"Lite FullNode Data Snapshot","text":"The TRON Public Chain has supported the type of the Lite FullNode since the version of GreatVoyage-v4.1.0 release. All the data required by the Lite FullNode for running is whole of the status data and a little essential block data, so, it is much more lightweight (smaller database and faster startup) than the normal FullNode. TRON officially offers database snapshots of the Lite FullNode.
Lite Fullnode Data Source Download site Description Official data source (Singapore) http://34.143.247.77/ LevelDB Tips: You can split the data from the whole data with the help of the Lite FullNode Data Pruning Tool.
"},{"location":"using_javatron/backup_restore/#use-the-data-snapshot","title":"Use the Data Snapshot","text":"The steps for using data snapshots are as follows:
- Download the corresponding compressed backup database according to your needs.
- Decompress the compressed file of the backup database to the output-directory directory or to the corresponding directory according to your needs.
- Startup the node. The node reads the output-directory directory by default. If you need to specify another directory\uff0cplease add the
-d directory parameter when the node starts.
"},{"location":"using_javatron/backup_restore/#nile-testnet-data-snapshot","title":"Nile TestNet Data Snapshot","text":"For detailed information about the Nile TestNet data snapshot, please refer to the official website, for both FullNode and Lite FullNode. The usage method is the same as that of the Main Net.
"},{"location":"using_javatron/connecting_to_tron/","title":"Connect to TRON network","text":"The TRON network is mainly divided into the main network, the Shasta test network, the Nile test network and the private network. Therefore, for the java-tron client software, it can be connected to any TRON network by modifying the configuration items in the configuration file. At present, the Shasta testnet does not support adding a new node, but the Nile testnet supports it.
You need to set the following configuration items to connect java-tron to one of the TRON networks:
node.p2p.version : It is used to set the P2P network id. Only nodes with the same network id can shake hands successfully. - TRON mainnet:
node.p2p.version=11111 - Nile testnet:
node.p2p.version = 201910292 - Private network\uff1aset to other values
seed.node: set seed nodegenesis.block: Genesis block settings. To join a network, please ensure that the settings of the genesis block are the same as those of other nodes in the network, otherwise you cannot join the network.
"},{"location":"using_javatron/connecting_to_tron/#find-peers","title":"Find peers","text":"java-tron continuously attempts to connect to other nodes on the network until it has enough peers, at the same time, it will also accept connections from other nodes. java-tron finds peers using the discovery protocol. In the discovery protocol, nodes exchange connectivity details and then establish sessions and exchange TRON data.
If you want java-tron node to do node discovery, you need to enable the node discovery service in the node configuration file first:
node.discovery = {\n enable = true\n ...\n}\n
Then, for the new node that joins the TRON network, you can configure the seed node to make it easier for the current node to connect to the peer node, and then obtain the address information of other nodes through the peer node. Generally, the seed nodes are set as stable online fullnodes. For the TRON main network, community public nodes can be used as seed nodes, for example: seed.node = {\n # List of the seed nodes\n # Seed nodes are stable full nodes\n\n ip.list = [\n \"3.225.171.164:18888\",\n \"52.53.189.99:18888\",\n \"18.196.99.16:18888\",\n \"34.253.187.192:18888\",\n \"18.133.82.227:18888\",\n \"35.180.51.163:18888\",\n \"54.252.224.209:18888\",\n \"18.231.27.82:18888\",\n \"52.15.93.92:18888\",\n \"34.220.77.106:18888\",\n \"15.207.144.3:18888\",\n \"13.124.62.58:18888\", \n \"54.151.226.240:18888\",\n \"35.174.93.198:18888\",\n \"18.210.241.149:18888\",\n \"54.177.115.127:18888\",\n \"54.254.131.82:18888\",\n \"18.167.171.167:18888\",\n \"54.167.11.177:18888\",\n \"35.74.7.196:18888\",\n \"52.196.244.176:18888\",\n \"54.248.129.19:18888\",\n \"43.198.142.160:18888\",\n \"3.0.214.7:18888\",\n \"54.153.59.116:18888\",\n \"54.153.94.160:18888\",\n \"54.82.161.39:18888\",\n \"54.179.207.68:18888\",\n \"18.142.82.44:18888\",\n \"18.163.230.203:18888\"\n ]\n}\n
There are scenarios where disabling the discovery process is useful, for example for running a local test node or an experimental test network with known, fixed nodes. This can be configured by node.discovery.enable = false to close the node discovery process.
"},{"location":"using_javatron/connecting_to_tron/#peers-limit","title":"Peers limit","text":"node.maxActiveNodes indicates the maximum number of connections between the node and other nodes, the default value is 30. Setting a larger value can enable nodes to establish more connections, join the network more efficiently, and broadcast more efficiently. However, the bandwidth required to maintain the connection is also higher and the performance consumption is higher. Therefore, please set it according to the actual situation.
node {\n maxActiveNodes = 30\n}\n
"},{"location":"using_javatron/connecting_to_tron/#active-and-passive-connections","title":"Active and passive connections","text":"java-tron supports setting its actively connected nodes node.active as well as passively connected nodes node.passive. Configuring node.active and node.passive can greatly help improve the stability of the network connection of the node.
When java-tron starts, it will actively establish a connection with the peer node in node.active.
node {\n active = [\n # Active establish connection in any case\n # Sample entries:\n # \"ip:port\",\n # \"ip:port\"\n ]\n }\n
When a node in node.passive actively establishes a connection with the current node, the current node will accept it unconditionally.
node {\n passive = [\n # Passive accept connection in any case\n # Sample entries:\n # \"ip:port\",\n # \"ip:port\"\n ]\n }\n
"},{"location":"using_javatron/connecting_to_tron/#log-and-network-connection-verification","title":"Log and network connection verification","text":"The java-tron node log is /logs/tron.log in the java-tron installation directory. Under the java-tron installation directory, you can use the following commands to view the latest log of the node and check the block synchronization status of the node:
$ tail -f /logs/tron.log/\n
You will see the below block synchronization logs if java-tron is running as expected.
15:41:48.033 INFO [nioEventLoopGroup-6-2] [DB](Manager.java:1208) pushBlock block number:76, cost/txs:13/0 false\n15:41:48.033 INFO [nioEventLoopGroup-6-2] [net](TronNetDelegate.java:255) Success process block Num:76,ID:000000000000004c9e3899ee9952a7f0d9e4f692c7070a48390e6fea8099432f.\n
For the super representative's fullnode, you will see the following producing blocks log: 02:31:33.008 INFO [DPosMiner] [DB](Manager.java:1383) Generate block 79336 begin\n02:31:33.059 INFO [DPosMiner] [DB](SnapshotManager.java:315) flush cost:51, create checkpoint cost:49, refresh cost:2\n02:31:33.060 INFO [DPosMiner] [DB](Manager.java:1492) Generate block 79336 success, trxs:0, pendingCount: 0, rePushCount: 0, postponedCount: 0\n
If no error messages are reported in the node logs, means everything is fine. You can also send an http request to check whether the node has been started, and to view the status of the node: including the node configuration information, the information about the machine where the node is located, the connection status of the node peers, etc. $ curl http://127.0.0.1:16887/wallet/getnodeinfo\n
Returns\uff1a
{\n \"activeConnectCount\": 3,\n \"beginSyncNum\": 42518346,\n \"block\": \"Num:42518365,ID:000000000288c75d1967232f1efe606ff90b9dd76660d7de8cc091849be6bf10\",\n \"cheatWitnessInfoMap\": {\n ...\n },\n \"configNodeInfo\": {\n ...\n \"codeVersion\": \"4.5.1\",\n \"dbVersion\": 2,\n \"discoverEnable\": true,\n \"listenPort\": 18888,\n ...\n },\n \"currentConnectCount\": 18,\n \"machineInfo\": {\n ...\n },\n \"passiveConnectCount\": 15,\n \"peerList\": [\n ...\n ],\n \"solidityBlock\": \"Num:42518347,ID:000000000288c74b723398aef104c585bad1c7cbade7793c5551466bd916feee\",\n \"totalFlow\": 8735314\n}\n
In order for users to interact with the TRON network, the java-tron node must be running and in a normal state of synchronization. Whether the node is synchronized with other nodes in the network, you can query the current block height in Tronscan and compare it with the result of /wallet/getnowblock queried from the local java-tron node. If they are equal, it means that the synchronization status of the local node is normal."},{"location":"using_javatron/connecting_to_tron/#connection-problems","title":"Connection problems","text":"There are occasions when java-tron simply fails to connect to peers. The common reasons for this are:
- Local time might be incorrect. An accurate clock is required to participate in the TRON network. The local clock can be resynchronized using commands such as
sudo ntpdate -s time.nist.gov. - Some firewall configurations can prohibit UDP traffic. But the node discovery service is based on the UDP protocol, so you can make it possible to let the node connect to the network by configuring
node.active in the case of node discovery invalid. - By configuring
node.passive to accept active connections from trusted nodes. - The Shasta testnet does not currently support nodes joining the network. If you need to run nodes to join the public testnet, you can choose the Nile testnet.
"},{"location":"using_javatron/connecting_to_tron/#connect-to-private-network","title":"Connect to private network","text":"It is often useful for developers to connect to private test networks rather than public testnets or TRON mainnet. Because the private chain not only has no requirements for machine configuration, but also in the sandbox environment of the private chain network, it is easier to test various functions, and it gives freedom to break things without real-world consequences.
The private chain network needs to configure the configuration item node.p2p.version in the private chain configuration file to a value which is not used by any other existing public network (TRON mainnet, testnet). For detailed instructions on private chain construction, please refer to Private Chain Network.
"},{"location":"using_javatron/installing_javatron/","title":"Deploy a java-tron Node","text":"java-tron nodes support to be deployed on Linux or MacOS operating systems, and rely on Oracle JDK 1.8, other versions of JDK are not supported.
The minimum hardware configuration required to run a java-tron node is 8-core CPU, 16G memory, 3T SDD, the recommended configuration is: 16-core CPU, 32G memory, 3.5T+ SDD. The fullnode running by super representative to produce block recommends 32-core CPU and 64G memory.
"},{"location":"using_javatron/installing_javatron/#compile-the-source-code","title":"Compile the Source Code","text":"First, clone the java-tron repository to the local with the following git command, and switch to the master branch. Before executing the command, make sure you have installed the git tool.
$ git clone https://github.com/tronprotocol/java-tron.git\n$ git checkout -t origin/master\n
Then, compile the java-tron source code by executing the following command. The parameter -x test means to skip the execution of the test case. You can also remove this parameter to execute the test code during the compilation process, which will make the compilation time longer. After the compilation is complete, FullNode.jar will be generated in the java-tron/build/libs/ directory.
$ cd java-tron\n$ ./gradlew clean build -x test\n
"},{"location":"using_javatron/installing_javatron/#startup-a-java-tron-node","title":"Startup a java-tron Node","text":"You can choose different configuration files to connect java-tron nodes to different networks. The mainnet configuration file is: main_net_config.conf, other network configuration files can be found here.
"},{"location":"using_javatron/installing_javatron/#startup-a-fullnode","title":"Startup a fullnode","text":"Fullnode has full historical data, it is the entry point into the TRON network , it provides HTTP API and gRPC API for external query. You can interact with the TRON network through fullnode\uff1atransfer assets, deploy contracts, interact with contracts and so on. The mainnet fullnode startup command is as follows, and the configuration file of the fullnode is specified by the -c parameter:
$ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c main_net_config.conf\n
- -XX:+UseConcMarkSweepGC \uff1aSpecifies parallel garbage collection. To be placed before the -jar parameter, not at the end.
- -Xmx \uff1aThe maximum value of the JVM heap, which can be set to 80% of the physical memory.
"},{"location":"using_javatron/installing_javatron/#startup-a-fullnode-that-produces-blocks","title":"Startup a fullnode that produces blocks","text":"Adding the --witness parameter to the startup command, fullnode will run as a node which produces blocks. In addition to supporting all the functions of fullnode, the block-producing fullnode also supports block production and transaction packaging. Please make sure you have a super representative account and get the votes of others. If the votes ranks in the top 27, you need to start a full node that produces blocks to participate in block production.
Fill in the private key of the super representative address into the localwitness list in the main_net_config.conf, below is an example. But if you don't want to use this way of specifying the private key in plain text, you can use the keystore + password method, please refer to Others chapter.
localwitness = [\n 650950B193DDDDB35B6E48912DD28F7AB0E7140C1BFDEFD493348F02295BD812\n]\n
then run the following command to start the node:
$ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar --witness -c main_net_config.conf\n
Note: For the mainnet and nile testnet, since the amount of data to be synchronized is large after the new node is started, it will take a long time to synchronize the data. You can use Data Snapshots to speed up node synchronization. First download the latest data snapshot and extract it to the output-directory directory of the TRON project, and then start the node, so that the node will synchronize on the basis of the data snapshot.
"},{"location":"using_javatron/installing_javatron/#others","title":"Others","text":""},{"location":"using_javatron/installing_javatron/#how-to-use-keystore-password-to-specify-the-privatekey-of-witness-account","title":"How to use keystore + password to specify the privatekey of witness account","text":" - You should not use the nohup command because the interaction is required when running the node. It is recommended to use session keeping tools such as screen, tmux, etc.
- Comment the
localwitness item in main_net_config.conf and uncomment the localwitnesskeystore item. Fill in the path of the Keystore file. Note that the Keystore file needs to be placed in the current directory where the startup command is executed or its subdirectory. If the current directory is \"A\", the directory of the Keystore file is \"A/B/localwitnesskeystore.json\", it needs to be configured as: localwitnesskeystore = [\n \"B/localwitnesskeystore.json\"\n]\n
Note: For keystore + password generation, you can use the register wallet command of the wallet-cli. - Startup the fullnode which produces blocks
$ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar --witness -c main_net_config.conf\n
- Enter the password correctly to finish the node startup.
"},{"location":"using_javatron/installing_javatron/#optimize-memory-allocation-with-tcmalloc","title":"Optimize Memory Allocation with tcmalloc","text":"Memory allocation of java-tron can be optimized with tcmalloc. The method is as follows:
First install tcmalloc, then add the following two lines to the startup script, the path of tcmalloc is slightly different for different Linux distributions.
#!/bin/bash\n\nexport LD_PRELOAD=\"/usr/lib/libtcmalloc.so.4\"\nexport TCMALLOC_RELEASE_RATE=10\n\n# original start command\njava -jar .....\n
Instructions for each Linux distributions are as belows:
-
Ubuntu 20.04 LTS / Ubuntu 18.04 LTS / Debian stable Install
$ sudo apt install libgoogle-perftools4\n
In the startup script add the following:
export LD_PRELOAD=\"/usr/lib/x86_64-linux-gnu/libtcmalloc.so.4\"\nexport TCMALLOC_RELEASE_RATE=10\n
-
Ubuntu 16.04 LTS Same install command as above. In the startup script add the following:
export LD_PRELOAD=\"/usr/lib/libtcmalloc.so.4\"\nexport TCMALLOC_RELEASE_RATE=10\n
-
CentOS 7 Install
$ sudo yum install gperftools-libs\n
In the startup script add the following: export LD_PRELOAD=\"/usr/lib64/libtcmalloc.so.4\"\nexport TCMALLOC_RELEASE_RATE=10\n
"},{"location":"using_javatron/litefullnode/","title":"Lite FullNode","text":"Lite FullNode runs the same code with FullNode, the difference is that Lite FullNode only starts based on state data snapshot, which only contains all account state data and historical data of the latest 65536 blocks. The state data snapshot is small, only about 3% of the FullNode data. Therefore, Lite Fullnode has the advantages of occupying less disk space and starting up fast, but it does not provide historical block and transaction data query by default, and only provides part of HTTP API and GRPC API of FullNode. For APIs that are not supported by Lite Fullnode, please refer to HTTP, GRPC. But these APIs can be opened by configuring openHistoryQueryWhenLiteFN = true in the configuration file, because after the Lite Fullnode startup, the saved data by the Lite Fullnode is exactly the same as that of the FullNode, so after this configuration item is turned on, the Lite Fullnode supports querying the block data synchronized after the node startup, but still does not support querying the block data before the node startup.
Therefore, if developers only need to use node for block synchronization, processing and broadcasting transactions, or only query the blocks and transactions synchronized after the node starts up, then Lite Fullnoe will be a better choice.
"},{"location":"using_javatron/litefullnode/#lite-fullnode-deployment","title":"Lite FullNode Deployment","text":"The deployment steps and startup command of a Lite fullnode are the same as fullnode's, please refer to Deployment Instructions to deploy a Lite Fullnode. The only difference is the database. You need to obtain the Lite Fullnode database. You can download the Lite Fullnode data snapshot from the public backup data and use it directly; or use the Lite Fullnode data pruning tool to convert the Fullnode database to Lite Fullnode database.
"},{"location":"using_javatron/litefullnode/#lite-fullnode-maintenance","title":"Lite FullNode Maintenance","text":"Since the Lite Fullnode will save the same data as the FullNode's after startup, although the data volume of the Lite Fullnode is very small at startup, the data expansion rate in the later period is the same as that of the FullNode, so it may be necessary to periodically cut the data. Pruning Lite Fullnode data is also to use Lite Fullnode data pruning tool to split Lite Fullnode data into snapshot dataset, that is, to obtain the pruned Lite Fullnode data.
"},{"location":"using_javatron/metrics/","title":"java-tron Node Metrics Monitoring","text":"Starting from the GreatVoyage-4.5.1 (Tertullian) version, the node provides a series of interfaces compatible with the prometheus protocol, so that the node deployer can monitor the health status of the node more conveniently. If you want to monitor various indicators of the node, you first need to deploy a prometheus service to communicate with the java-tron node, and obtain the indicator data of the node through the node interface. Then you need to deploy a visualization tool, such as Grafana, to display the node data obtained by prometheus in the form of a graphical interface. The following will introduce the deployment process of the java-tron node monitoring system in detail.
"},{"location":"using_javatron/metrics/#configure-java-tron","title":"Configure java-tron","text":"To use the Prometheus tool to monitor the java-tron node, you first need to enable prometheus metric monitoring in the node configuration file and set the http port:
node {\n ... ...\n p2p {\n version = 11111 # 11111: mainnet; 20180622: testnet\n }\n ####### add for prometheus start.\n metrics{\n prometheus{\n enable=true \n port=\"9527\"\n }\n }\n ####### add for prometheus end.\n}\n
"},{"location":"using_javatron/metrics/#start-java-tron-node","title":"Start java-tron node","text":"Start java-tron node using below command\uff1a
$ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c main_net_config.conf\n
"},{"location":"using_javatron/metrics/#deploy-prometheus-service","title":"Deploy prometheus service","text":"prometheus officially provides precompiled binaries and docker images, you can download them directly from the official website or pull the docker images on dockerhub. For more detailed installation and configuration instructions, Please refer to the prometheus documentation. As a simple deployment instruction, this article will adopt the docker image deployment:
-
After installing docker, enter the following command to pull the prometheus image:
$ docker pull prom/prometheus\n
-
Download the prometheus configuration file
The following is a prometheus configuration file template prometheus.yaml:
global:\n scrape_interval: 30s\n scrape_timeout: 10s\n evaluation_interval: 30s\nscrape_configs:\n- job_name: java-tron\n honor_timestamps: true\n scrape_interval: 3s\n scrape_timeout: 2s\n metrics_path: /metrics\n scheme: http\n follow_redirects: true\n static_configs:\n - targets:\n - 127.0.0.1:9527\n labels:\n group: group-xxx\n instance: xxx-01\n - targets:\n - 172.0.0.2:9527\n labels:\n group: group-xxx\n instance: xxx-02\n
You can download and use this template and modify the configuration items targets, it is used to configure the ip and prometheus port of the java-tron node. If you deploy multiple java-tron nodes, you can configure multiple targets to monitor multiple nodes. -
Start a Prometheus container
Start a Prometheus container with the following command and specify to use the user-defined configuration file in the previous step:/Users/test/deploy/prometheus/prometheus.yaml
$ docker run --name prometheus \\\n -d -p :9090:9090 \\\n -v /Users/test/deploy/prometheus/prometheus.yaml:/etc/prometheus/prometheus.yml \\\n prom/prometheus:latest\n
After the container starts, you can view the running status of the prometheus service through http://localhost:9090/.
Click \"Status\" -> \"Configuration\" to check whether the configuration file used by the container is correct:
Click \"Status\" -> \"Targets\" to view the status of each monitored java-tron node:
In this example, the status of the first endpoint is UP, which means that Prometheus can fetch the data of this node normally. The second endpoint, whose status is DOWN, indicates an exception. For details, please refer to the description in \"Error\".
When the status of the monitored java-tron nodes is normal, you can monitor the indicator data through visualization tools such as Grafana or Promdash, etc. This article will use grafana to display the data:
"},{"location":"using_javatron/metrics/#deploy-grafana","title":"Deploy Grafana","text":"The deployment process of the Grafana visualization tool is as follows:
-
Install Grafana Please refer to the official documentation to install Grafana. This article will adopt the docker image deployment, and the pulled image version is the open source version:
$ docker pull grafana/grafana-oss\n
-
Start Grafana
You can use the below command to start Grafana:
$ docker run -d --name=grafana -p 3000:3000 grafana/grafana-oss\n
-
Log in to the Grafana web UI
After startup, you can login the Grafana web UI through http://localhost:3000/. The initial user name and password are both admin. After login, change the password according to the prompts, and then you can enter the main interface. Click the settings icon on the left side of the main page and select \"Data Sources\" to configure Grafana's data sources:
Enter the ip and port of the prometheus service in URL:
Then click the \"Save & test\" button at the bottom of the page to save the settings. After clicking save, Grafana will detect the connection with the data source, and if the connection is successful, you will find the words Data source is working.
-
Import Dashboard
Grafana's dashboard needs to be configured. For the convenience of java-tron node deployers, the TRON community provides a comprehensive dashboard configuration file java-tron-template_rev1.json, which you can download directly and then import into Grafana.
Click the Dashboards icon on the left, then select \"+Import\", then click \"Upload JSON file\" to import the downloaded dashboard configuration file:
Then you can see the following types of monitoring metrics on the dashboard, and monitor the running status of the nodes in real time:
"},{"location":"using_javatron/private_network/","title":"Private Network","text":"To build a private chain, it is necessary to deploy at least one fullnode running by SR to produces blocks, and any number of fullnodes to synchronize blocks and broadcast transactions. Only one SR node and one fullnode are set up in this example. Before the deployment, please install the Oracle JDK 1.8 first, and then you need to prepare at least two TRON network address and save the address and private key. You can use wallet-cli or Tronlink to create address.
"},{"location":"using_javatron/private_network/#deployment-guide","title":"Deployment Guide","text":"The process of building a node on private chain is the same as that on mainnet. The difference is the content of the node configuration file. The most important step to build a private chain is to modify the configuration items in the configuration file, so that the nodes can form a private network for node discovery, block synchronization and broadcast transactions.
-
Create deployment directory
Create deployment directory, it is recommended to put the two fullnodes in different directories.
$ mkdir SR\n$ mkdir FullNode\n
-
Obtain FullNode.jar
Obtain FullNode.jar, then put it into the SR and FullNode directories respectively.
$ cp FullNode.jar ./SR\n$ cp FullNode.jar ./FullNode\n
-
Obtain the node's config file private_net_config.conf
Obtain the node's config file private_net_config.conf, then put it into the SR and FullNode directories respectively, and modify the file names respectively to supernode.conf, fullnode.conf.
$ cp private_net_config.conf ./SR/supernode.conf\n$ cp private_net_config.conf ./FullNode/fullnode.conf\n
-
Modify the configuration file of each node
Please modify each configuration item of the node in turn according to the instructions in the following table:
Config Item SR Fullnode FullNode Description localwitness The private key of witness address Please do not fill in data Generating blocks requires signing with a private key genesis.block.witnesses Witness address The same as SR node's Genesis block related configuration genesis.block.Assets Preset TRX for specific accounts. Add the pre-prepared address to the end and specify its TRX balance as needed The same as SR node's Genesis block related configuration p2p.version any positive integer except for 11111 the same as SR node's Only nodes of the same p2p version can shake hands successfully seed.node Please do not fill in data Change the seed.node ip.list in the configuration file to the IP address and the port (listen.port) of the SR Enables fullnode to establish connection with SR node and synchronize data needSyncCheck false true Set the first SR\u2019s needSyncCheck to false, other SRs true node.discovery.enable true true If it is false, the current node will not be discovered by other nodes block.proposalExpireTime 600000 The same as SR node's The default proposal effective time is 3 days: 259200000 (ms), if you want to quickly pass the proposal, you can set this item to a smaller value, such as 10 minutes, that is, 600000ms block.maintenanceTimeInterval 300000 The same as SR node's The default maintenance time interval is 6 hours: 21600000 (ms), if you want to pass the proposal quickly, you can set this item to a smaller value, such as five minutes, that is, 300000ms. committee.allowSameTokenName 1 1 Allow same token name committee.allowTvmTransferTrc10 1 1 Allow tvm transfer TRC10 -
Modify the port in the configuration file, and configure the SR and FullNode with different port numbers. Note, this step is only required if SR and FullNode are running on the same machine, otherwise, this step can be skipped.
listen.port \uff1a p2p listen porthttp port\uff1a Http listen portrpc port\uff1a rpc listen port
-
Startup the node
The fullnode that produces blocks has the different startup command with the fullnodes that do not produce blocks:
- Fullnode that produces blocks
$ java -Xmx6g -XX:+HeapDumpOnOutOfMemoryError -jar FullNode.jar --witness -c supernode.conf\n
- Fullnode
$ java -Xmx6g -XX:+HeapDumpOnOutOfMemoryError -jar FullNode.jar -c fullnode.conf\n
-
Modify the dynamic parameters of the private chain
Dynamic parameters can be obtained by getchainparameters. The main network's current dynamic parameters and committee proposals related to them can be seen here, dynamic parameters are called network parameters here.
If you want all the dynamic parameters of your private network to be the same with the main network, maybe dbfork which could capture the latest status of Mainnet is what you are interested in.
If you want to modify part of dynamic parameters, there are two ways to choose from:
-
Configure File Some dynamic parameters can be directly set through configure file. These dynamic parameters can be seen here. Below is an example of modifying dynamic parameters through configure file.
committee = {\n allowCreationOfContracts = 1\n allowAdaptiveEnergy = 0\n allowMultiSign = 1\n allowDelegateResource = 1\n allowSameTokenName = 0\n allowTvmTransferTrc10 = 1\n}\n
-
Proposal Any witness(SR, SR partner, SR candidate) is entitled to create a proposal, SRs also have the right to vote for the proposal. A witness uses proposalcreate to create a proposal, and then SRs use proposalapprove to approve the proposal(Proposals only support voting for yes, super representatives do not vote means they do not agree with the proposal). Below is an code example of modifying two dynamic parameters through a committee proposal. In proposalcreate, dynamic parameters are represented by numbers, the mapping between number and string name of dynamic parameters can be seen here.
var TronWeb = require('tronweb');\nvar tronWeb = new TronWeb({\n fullHost: 'http://localhost:16887',\n privateKey: 'c741f5c0224020d7ccaf4617a33cc099ac13240f150cf35f496db5bfc7d220dc'\n})\n\nvar parametersForProposal1 = [{\"key\":9,\"value\":1},{\"key\":10,\"value\":1}];\n\nasync function modifyChainParameters(parameters,proposalID){\n\n parameters.sort((a, b) => {\n return a.key.toString() > b.key.toString() ? 1 : a.key.toString() === b.key.toString() ? 0 : -1;\n })\n var unsignedProposal1Txn = await tronWeb.transactionBuilder.createProposal(parameters,\"41D0B69631440F0A494BB51F7EEE68FF5C593C00F0\")\n var signedProposal1Txn = await tronWeb.trx.sign(unsignedProposal1Txn);\n var receipt1 = await tronWeb.trx.sendRawTransaction(signedProposal1Txn);\n\n setTimeout(async function() {\n console.log(receipt1)\n console.log(\"Vote proposal 1 !\")\n var unsignedVoteP1Txn = await tronWeb.transactionBuilder.voteProposal(proposalID, true, tronWeb.defaultAddress.hex)\n var signedVoteP1Txn = await tronWeb.trx.sign(unsignedVoteP1Txn);\n var rtn1 = await tronWeb.trx.sendRawTransaction(signedVoteP1Txn);\n }, 1000)\n\n}\n\nmodifyChainParameters(parametersForProposal1, 1)\n
After creating the proposal through the above code, you can check whether the proposal has been approved through listproposals interface. If the \"state\" in the return value of the interface is \"APPROVED\" When expiration time of the proposal has passed, it means that the proposal has been approved. It should be noted that dynamic parameters with interdependent relationships cannot be included in one proposal, the correct approach is to separate them into different proposals and pay attention to order of them.
"},{"location":"using_javatron/toolkit/","title":"java-tron Node Maintenance Tool - Toolkit","text":"The Toolkit integrates a series of tools of java-tron, and more functions will be added into it in the future for the convenience of developers. Currently Toolkit includes the following functions:
- Database Partition Tool
- Lite Fullnode Data Pruning
- Data Copy
- Data Conversion
- LevelDB Startup Optimization
The following describes the acquisition and use of the Toolkit toolbox in detail.
"},{"location":"using_javatron/toolkit/#obtain-toolkitjar","title":"Obtain Toolkit.jar","text":"Toolkit.jar can be obtained from the released version directly or by compiling the java-tron source code.
Compile the source code:
- Obtain java-tron source code
$ git clone https://github.com/tronprotocol/java-tron.git\n$ git checkout -t origin/master\n
- Compile
$ cd java-tron\n$ ./gradlew clean build -x test\n
You will find the Toolkit.jar under ./java-tron/build/libs/ folder if build is successful."},{"location":"using_javatron/toolkit/#database-partition-tool","title":"Database Partition Tool","text":"As the data on the chain continues to grow, the pressure on data storage will increase. At present, the FullNode data of the TRON public chain has reached 1T, and the daily data growth is about 1.2G. According to the current data growth rate, the annual growth rate is about 450G. A single disk capacity may be insufficient and need to be replaced by a larger disk. To this end the Toolkit toolbox introduces the database storage partitioning tool. The tool can migrate some databases to other storage disks. When the user encounters insufficient disk space, he only needs to add another disk according to the capacity requirement and does not need to replace the original disk.
"},{"location":"using_javatron/toolkit/#commands-and-parameters","title":"Commands and parameters","text":"To use the data partition function provided by Toolkit through the db mv command:
# full command\njava -jar Toolkit.jar db mv [-h] [-c=<config>] [-d=<database>]\n# examples\njava -jar Toolkit.jar db mv -c main_net_config.conf -d /data/tron/output-directory\n
Optional command parameters are as follows:
-c | --config: [ string ] This option is used to specify the FullNode configuration file. If not specified, the default value will be config.conf.-d | --database-directory: [ string ] This option is used to specify the FullNode database directory. If not specified, the default value will be output-directory.-h | --help: [ bool ] This option is used to view help description, default value: false.
"},{"location":"using_javatron/toolkit/#usage-instructions","title":"Usage Instructions","text":"Follow the following steps to use the database partition tool:
- Stop FullNode service
- Configure for database storage migration
- Perform database migration
- Restart FullNode service
"},{"location":"using_javatron/toolkit/#stop-fullnode-service","title":"Stop FullNode Service","text":"Use the command kill -15 pid to close FullNode.jar, below is the FullNode process pid lookup command:
$ ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}'`\n
"},{"location":"using_javatron/toolkit/#configure-for-database-storage-migration","title":"Configure For Database Storage Migration","text":"The configuration of database migration is in the storage.properties field in the java-tron node configuration file. The following is an example of migrating only the block and trans databases to illustrate how to migrate some databases to other storage disks:
storage {\n ......\n properties = [\n {\n name = \"block\",\n path = \"/data1/tron\",\n\n },\n {\n name = \"trans\",\n path = \"/data1/tron\",\n }\n ]\n ......\n}\n
name is the database name which you want to migrate, and path is the destination directory for database migration. The tool will migrate the database specified by name to the directory specified by path, and then create a soft link under the original path pointing to path directory. After FullNode starts, it will find the path directory according to the soft link."},{"location":"using_javatron/toolkit/#perform-database-migration","title":"Perform Database Migration","text":"When executed, the current migration progress will be shown.
$ java -jar Toolkit.jar db mv -c main_net_config.conf -d /data/tron/output-directory\n
"},{"location":"using_javatron/toolkit/#restart-fullnode-service","title":"Restart FullNode Service","text":"After the migration is complete, restart the java-tron node.
# FullNode\n$ nohup java -Xms9G -Xmx9G -XX:ReservedCodeCacheSize=256m \\\n -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m \\\n -XX:MaxDirectMemorySize=1G -XX:+PrintGCDetails \\\n -XX:+PrintGCDateStamps -Xloggc:gc.log \\\n -XX:+UseConcMarkSweepGC -XX:NewRatio=2 \\\n -XX:+CMSScavengeBeforeRemark -XX:+ParallelRefProcEnabled \\\n -XX:+HeapDumpOnOutOfMemoryError \\\n -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 \\\n -jar FullNode.jar -c main_net_config.conf >> start.log 2>&1 &\n\n# Super representative's FullNode\n$ nohup java -Xms9G -Xmx9G -XX:ReservedCodeCacheSize=256m \\\n -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m \\\n -XX:MaxDirectMemorySize=1G -XX:+PrintGCDetails \\\n -XX:+PrintGCDateStamps -Xloggc:gc.log \\\n -XX:+UseConcMarkSweepGC -XX:NewRatio=2 \\\n -XX:+CMSScavengeBeforeRemark -XX:+ParallelRefProcEnabled \\\n -XX:+HeapDumpOnOutOfMemoryError \\\n -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 \\\n -jar FullNode.jar --witness -c main_net_config.conf >> start.log 2>&1 &\n
"},{"location":"using_javatron/toolkit/#lite-fullnode-data-pruning","title":"Lite Fullnode Data Pruning","text":"Toolkit provides data pruning tool, which is mainly used for generating or pruning Lite Fullnode data.
The data pruning tool can divide the complete FullNode data into a snapshot dataset (Snapshot dataset) or a historical dataset (History dataset) according to the current latest_block_number, the snapshot dataset is used to start the Lite Fullnode (That is the Lite fullnode database), and the historical dataset is used for historical data query. Lite Fullnode started with a snapshot data set do not support querying historical data prior to the latest block height at the time of pruning. The data pruning tool also provides the function of merging historical data set with snapshot data set. The usage scenarios are as follows:
-
Convert FullNode data into Lite Fullnode data
The Lite Fullnode starts only based on the snapshot data set, use the data pruning tool to convert the full node data into the snapshot data set, and that will get the Lite Fullnode data
-
Prune Lite Fullnode data regularly
Since the Lite Fullnode saves the same data as the FullNode after startup, although the data volume of the Lite Fullnode is very small at startup, the data expansion rate in the later period is the same as that of the FullNode, so it may be necessary to periodically prune the data. Clipping the Lite Fullnode data is also to use this tool to cut the Lite Fullnode data into snapshot data set, that is, to obtain the Pruned Lite Fullnode data
-
Convert Lite Fullnode data back to FullNode data
Since Lite Fullnode does not support historical data query, if you want to support it, you need to change Lite Fullnode data into FullNode data, then the node will change from Lite Fullnode to FullNode. You can directly download the snapshot of the FullNode database, or you can use the data pruning tool: first, convert the FullNode data into historical data set, and then merge the historical data set and the snapshot data set of the Lite Fullnode to obtain the FullNode data.
Note: Before using this tool for any operation, you need to stop the currently running node first.
"},{"location":"using_javatron/toolkit/#command-and-parameters","title":"Command and parameters","text":"To use the data pruning tool provided by Toolkit through the db lite command:
# full command\n java -jar Toolkit.jar db lite [-h] -ds=<datasetPath> -fn=<fnDataPath> [-o=<operate>] [-t=<type>]\n# examples\n #split and get a snapshot dataset\n java -jar Toolkit.jar db lite -o split -t snapshot --fn-data-path output-directory/database --dataset-path /tmp\n #split and get a history dataset\n java -jar Toolkit.jar db lite -o split -t history --fn-data-path output-directory/database --dataset-path /tmp\n #merge history dataset and snapshot dataset\n java -jar Toolkit.jar db lite -o merge --fn-data-path /tmp/snapshot --dataset-path /tmp/history\n
Optional command parameters are as follows:
--operation | -o: [ split | merge ], this parameter specifies the operation as either to split or to merge, default is split.--type | -t: [ snapshot | history ], this parameter is used only when the operation is split. snapshot means clip to Snapshot Dataset and history means clip to History Dataset. Default is snapshot.--fn-data-path | -fn: The database path to be split or merged. When the operation type is split, fn-data-path is used to indicate the directory of the data to be pruned; when the operation type is merge, fn-data-path indicates the database directory of the Lite Fullnode or the directory of the snapshot dataset.--dataset-path | -ds: When operation is split, dataset-path is the path that store the snapshot or history, when operation is merge, dataset-path is the history data path.
"},{"location":"using_javatron/toolkit/#usage-instructions_1","title":"Usage Instructions","text":"The node database is stored in the output-directory/database directory by default. The examples in this chapter will be explained with the default database directory.
The following three examples illustrate how to use the data pruning tool:
-
Split and get a Snapshot Dataset
This function can split FullNode data into Lite Fullnode data, and can also be used to regularly trim Lite Fullnode data. The steps are as follows:
First, stop the FullNode and execute:
# just for simplify, save the snapshot into /tmp directory\njava -jar Toolkit.jar db lite -o split -t snapshot --fn-data-path output-directory/database --dataset-path /tmp\n
- --fn-data-path\uff1a The data directory to be trimmed, that is, the node data directory
- --dataset-path\uff1a The directory where the output snapshot dataset is stored
After the command is executed, a snapshot directory will be generated in /tmp, the data in this directory is the Lite Fullnode data, then rename the directory from snapshot to database (the default value of the storage.db.directory is database, make sure rename the snapshot directory to the specified value) and copy the database directory to the Lite Fullnode database directory to finish the splitting. Finally start the Lite Fullnode.
-
Split and get a History Dataset
The command to split the historical data set is as follows:
# just for simplify, save the history into `/tmp` directory,\njava -jar Toolkit.jar db lite -o split -t history --fn-data-path output-directory/database --dataset-path /tmp\n
- --fn-data-path\uff1a FullNode data directory
- --dataset-path\uff1a The directory where the output historical dataset is stored
After the command is executed, the history directory will be generated under the /tmp directory, and the data in it is the historical dataset.
-
Merge History Dataset and Snapshot Dataset
Both History Dataset and Snapshot Dataset have an info.properties file to identify the block height when they are split. Make sure that the split_block_num in History Dataset is not less than the corresponding value in the Snapshot Dataset. After the historical dataset is merged with the snapshot dataset through the merge operation, the Lite Fullnode will become a real FullNode.
The command to merge the historical dataset and the snapshot dataset is as follows:
# just for simplify, assume `History dataset` is locate in /tmp\njava -jar Toolkit.jar db lite -o merge --fn-data-path /tmp/snapshot --dataset-path /tmp/history\n
- --fn-data-path\uff1a snapshot dataset directory
- --dataset-path\uff1a history dataset directory
After the command is executed, the merged data will overwrite the directory where the snapshot data set is located, that is, the directory specified by --fn-data-path, copy the merged data to the node database directory, and the Lite Fullnode becomes a FullNode.
"},{"location":"using_javatron/toolkit/#data-copy","title":"Data Copy","text":"The node database is large, and the database copy operation is time-consuming. The Toolkit provides a fast database copy function, which can quickly copy the LevelDB or RocksDB database in the same file system by creating a hard link.
"},{"location":"using_javatron/toolkit/#command-and-parameters_1","title":"Command and parameters","text":"To use the data copy function provided by Toolkit through db copy :
# full command\n java -jar Toolkit.jar db cp [-h] <src> <dest>\n# examples\n java -jar Toolkit.jar db cp output-directory/database /tmp/database\n
Optional command parameters are as follows:
<src>: Source path for database. Default: output-directory/database<dest>: Output path for database. Default: output-directory-cp/database-h | --help\uff1a[ bool ] provide the help info. Default: false
Note: Before using this tool for any operation, you need to stop the currently running node first.
"},{"location":"using_javatron/toolkit/#data-conversion","title":"Data Conversion","text":"Toolkit supports database data conversion function, which can convert LevelDB data into RocksDB data.
"},{"location":"using_javatron/toolkit/#command-and-parameters_2","title":"Command and parameters","text":"To use the data conversion function provided by Toolkit through db convert command:
# full command\n java -jar Toolkit.jar db convert [-h] [--safe] <src> <dest>\n# examples\n java -jar Toolkit.jar db convert output-directory/database /tmp/database\n
Optional command parameters are as follows:
<src>: Input path for leveldb, default: output-directory/database.<dest>: Output path for rocksdb, default: output-directory-dst/database.--safe\uff1aIn safe mode, read data from leveldb then put into rocksdb, it's a very time-consuming procedure. If not, just change engine.properties from leveldb to rocksdb, rocksdb is compatible with leveldb for the current version. This may not be the case in the future, default: false.-h | --help\uff1a[ bool ] Provide the help info, default: false\u3002
Note: Before using this tool for any operation, you need to stop the currently running node first.
"},{"location":"using_javatron/toolkit/#leveldb-startup-optimization","title":"LevelDB Startup Optimization","text":"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, moreover, there may be an issue that the service is terminated abnormally due to the continuous growth of memory. To solve this issue, toolkit provides the leveldb startup optimization tool. The tool optimizes the file size of the manifest and the startup process of LevelDB, reduces memory usage, and improves node startup speed.
"},{"location":"using_javatron/toolkit/#command-and-parameters_3","title":"Command and parameters","text":"To use the LevelDB startup optimization function provided by Toolkit through db archive command:
# full command\n java -jar Toolkit.jar db archive [-h] [-b=<maxBatchSize>] [-d=<databaseDirectory>] [-m=<maxManifestSize>]\n# examples\n #1. use default settings\n java -jar Toolkit.jar db archive \n #2. specify the database directory as /tmp/db/database\n java -jar Toolkit.jar db archive -d /tmp/db/database \n #3. specify the batch size to 64000 when optimizing manifest\n java -jar Toolkit.jar db archive -b 64000\n #4. specify optimization only when Manifest exceeds 128M\n java -jar Toolkit.jar db archive -m 128 \n
Optional command parameters are as follows:
-b | --batch-size: Specify the batch manifest size, default: 80000.-d | --database-directory: Specify the database directory to be processed, default: output-directory/database.-m | --manifest-size: Specify the minimum required manifest file size, unit: M, default: 0.-h | --help\uff1a[ bool ] Provide the help info, default: false.
Note: Before using this tool for any operation, you need to stop the currently running node first. Usage instructions, please refer to Leveldb Startup Optimization Plugins.
"}]}
\ No newline at end of file
diff --git a/sitemap.xml b/sitemap.xml
index 3bd18aa0..964c28db 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,158 +2,158 @@
https://tronprotocol.github.io/documentation-en/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/glossary/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/api/http/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/api/json-rpc/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/api/rpc/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/architecture/database/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/architecture/event/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/clients/wallet-cli/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/contracts/contract/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/contracts/tools/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/developers/advanced-configuration/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/developers/archive-manifest/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/developers/code-structure/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/developers/demo/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/developers/deployment/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/developers/governance/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/developers/issue-workflow/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/developers/java-tron/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/developers/run-in-idea/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/developers/tips/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/getting_started/getting_started_with_javatron/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/mechanism-algorithm/account/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/mechanism-algorithm/dex/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/mechanism-algorithm/dpos/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/mechanism-algorithm/multi-signatures/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/mechanism-algorithm/resource/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/mechanism-algorithm/shielded-transaction/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/mechanism-algorithm/sr/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/mechanism-algorithm/system-contracts/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/releases/history/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/releases/signature_verification/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/releases/upgrade-instruction/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/using_javatron/backup_restore/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/using_javatron/connecting_to_tron/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/using_javatron/installing_javatron/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/using_javatron/litefullnode/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/using_javatron/metrics/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/using_javatron/private_network/
- 2025-04-30
+ 2025-05-09
https://tronprotocol.github.io/documentation-en/using_javatron/toolkit/
- 2025-04-30
+ 2025-05-09
\ No newline at end of file
diff --git a/sitemap.xml.gz b/sitemap.xml.gz
index 5a46cddb..344a1c8f 100644
Binary files a/sitemap.xml.gz and b/sitemap.xml.gz differ