From 934647c3ca4961b7b64ca9c81846e190a0d64411 Mon Sep 17 00:00:00 2001 From: Leem Date: Thu, 23 Jan 2025 11:45:25 +0800 Subject: [PATCH] 1: Normalize spelling of TRON when TRON appears separately in the document; 2: Normalize spelling of java-tron and treat java-tron as a proper noun that means j is not capitalized even if java-tron appears at the beginning of a sentence --- docs/architecture/database.md | 4 +- docs/architecture/event.md | 12 ++--- docs/clients/tron-grid.md | 2 +- docs/clients/wallet-cli-command.md | 6 +-- docs/clients/wallet-cli.md | 4 +- docs/contracts/contract.md | 4 +- docs/contracts/tvm.md | 16 +++--- docs/developers/code-structure.md | 34 ++++++------- docs/developers/demo.md | 16 +++--- docs/developers/deployment.md | 10 ++-- docs/developers/issue-workflow.md | 2 +- docs/developers/java-tron.md | 10 ++-- docs/developers/run-in-idea.md | 30 +++++------ docs/faq/index.md | 4 +- .../getting_started_with_javatron.md | 42 ++++++++-------- docs/index.md | 8 +-- docs/introduction/overview.md | 6 +-- docs/mechanism-algorithm/account.md | 2 +- docs/releases/history.md | 50 +++++++++---------- docs/releases/signature_verification.md | 14 +++--- docs/releases/upgrade-instruction.md | 22 ++++---- docs/using_javatron/backup_restore.md | 4 +- docs/using_javatron/connecting_to_tron.md | 20 ++++---- docs/using_javatron/installing_javatron.md | 18 +++---- docs/using_javatron/metrics.md | 8 +-- docs/using_javatron/toolkit.md | 4 +- docs_without_index/mpc/002/report.asc | 8 +-- docs_without_index/mpc/003/report.asc | 8 +-- docs_without_index/mpc/004/report.asc | 12 ++--- docs_without_index/mpc/005/report.asc | 2 +- docs_without_index/mpc/008/report.asc | 6 +-- docs_without_index/mpc/011/report.asc | 6 +-- docs_without_index/mpc/060/report.asc | 2 +- docs_without_index/mpc/071/report.asc | 2 +- docs_without_index/mpc/076/report.asc | 8 +-- docs_without_index/plugin/event-query-http.md | 2 +- .../tron-mpc-testnet/001/report.asc | 2 +- mkdocs.yml | 10 ++-- 38 files changed, 210 insertions(+), 210 deletions(-) diff --git a/docs/architecture/database.md b/docs/architecture/database.md index 0dfc4cc6..24fa00d7 100644 --- a/docs/architecture/database.md +++ b/docs/architecture/database.md @@ -1,7 +1,7 @@ # Database configuration -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. +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. +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. # RocksDB diff --git a/docs/architecture/event.md b/docs/architecture/event.md index b0182401..32c896e1 100644 --- a/docs/architecture/event.md +++ b/docs/architecture/event.md @@ -4,7 +4,7 @@ ### TIP -The TIP: [TIP-12:Tron event subscribes model](https://github.com/tronprotocol/tips/blob/master/tip-12.md) . +The TIP: [TIP-12:TRON event subscribes model](https://github.com/tronprotocol/tips/blob/master/tip-12.md) . ### Event Type @@ -98,21 +98,21 @@ contractTopics: contract topics list #### Event query -Tron Event Query Service +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](https://github.com/tronprotocol/TIPs/issues/12). +For more information of TRON event subscribe model, please refer to [TIP-12](https://github.com/tronprotocol/TIPs/issues/12). - [Event query deployment](https://tronprotocol.github.io/documentation-en/developers/deployment/#event-subscribe-plugin-deployment) - [Event query HTTP API](https://github.com/tronprotocol/documentation-en/tree/master/docs_without_index/plugin/event-query-http.md) -## Using Java-tron's Built-in Message Queue for Event Subscription +## Using java-tron's Built-in Message Queue for Event Subscription -TRON provides event subscription service. Developers can not only obtain on-chain events through event plugin, but also through [Java-tron’s built-in ZeroMQ message queue](https://github.com/tronprotocol/tips/blob/master/tip-28.md). 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. +TRON provides event subscription service. Developers can not only obtain on-chain events through event plugin, but also through [java-tron’s built-in ZeroMQ message queue](https://github.com/tronprotocol/tips/blob/master/tip-28.md). 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. +This article will introduce how to subscribe to events through java-tron's built-in message queue in detail. ### Configure node diff --git a/docs/clients/tron-grid.md b/docs/clients/tron-grid.md index bfcff8bc..cb5921bb 100644 --- a/docs/clients/tron-grid.md +++ b/docs/clients/tron-grid.md @@ -8,7 +8,7 @@ TronGrid provides TRON clients running in the cloud, so you don't have to run on TronGrid offers an easy to use hosted API, load balanced full nodes, secure and reliable developer tools with direct access to the TRON Network. -TronGrid uses a set of NodeJS apps to talk with Redis and PostgreSQL to provide a simple, fast and reliable query interface for the Tron API. +TronGrid uses a set of NodeJS apps to talk with Redis and PostgreSQL to provide a simple, fast and reliable query interface for the TRON API. TronGrid supports 2 types of api: diff --git a/docs/clients/wallet-cli-command.md b/docs/clients/wallet-cli-command.md index 1a5cd043..aa7a7e3f 100644 --- a/docs/clients/wallet-cli-command.md +++ b/docs/clients/wallet-cli-command.md @@ -1884,9 +1884,9 @@ wallet> getproposal 34 ### VoteWitness -Voting requires Tron Power, which can be obtained by freezing funds. +Voting requires TRON Power, which can be obtained by freezing funds. ``` -wallet> votewitness [SR(Super Representatives) address] [Tron Power Amount] +wallet> votewitness [SR(Super Representatives) address] [TRON Power Amount] ``` * The share calculation method is: 1 unit of share can be obtained for every 1TRX frozen. @@ -1896,7 +1896,7 @@ wallet> votewitness [SR(Super Representatives) address] [Tron Power Amount] For example: ```shell -wallet> freezeBalance 100000000 3 1 address # Freeze 10TRX and acquire 10 units of Tron Power +wallet> freezeBalance 100000000 3 1 address # Freeze 10TRX and acquire 10 units of TRON Power wallet> votewitness [SR1] 4 [SR2] 6 # Cast 4 votes for SR1 and 6 votes for SR2 at the same time diff --git a/docs/clients/wallet-cli.md b/docs/clients/wallet-cli.md index 7bf16bee..58215682 100644 --- a/docs/clients/wallet-cli.md +++ b/docs/clients/wallet-cli.md @@ -1,9 +1,9 @@ ## What is Wallet-CLI? -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: +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: ![](https://i.imgur.com/NRKmZmE.png) -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. +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](https://github.com/tronprotocol/wallet-cli) diff --git a/docs/contracts/contract.md b/docs/contracts/contract.md index bce2213d..9119fe9e 100644 --- a/docs/contracts/contract.md +++ b/docs/contracts/contract.md @@ -4,7 +4,7 @@ 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](https://github.com/tronprotocol/solidity/releases). 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. +TRON smart contract support Solidity language in (Ethereum). You can find the latest solidity version in the [TRON solidity repository](https://github.com/tronprotocol/solidity/releases). 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. ## Smart Contract Features TRON virtual machine is based on Ethereum solidity language, it also has TRON's own features. @@ -135,7 +135,7 @@ Ethereum VM address is 20 bytes, but TRON's VM address is 21 bytes. Need to convert TRON's address while using in solidity (recommended): ```text /** - * @dev convert uint256 (HexString add 0x at beginning) tron address to solidity address type + * @dev convert uint256 (HexString add 0x at beginning) TRON address to solidity address type * @param tronAddress uint256 tronAddress, begin with 0x, followed by HexString * @return Solidity address type */ diff --git a/docs/contracts/tvm.md b/docs/contracts/tvm.md index 0de9a975..b89233e8 100644 --- a/docs/contracts/tvm.md +++ b/docs/contracts/tvm.md @@ -22,7 +22,7 @@ Currently, TVM is compatible with EVM and will be with more mainstream VMs in th 4. Developer-friendly Thanks to TVM’s bandwidth setup, developments costs are reduced and developers can focus on the logic of their contract code. TVM also offers all-in-one interfaces for contract deployment, triggering and viewing, for the convenience of developers. -The following interfaces are available in Tron Wallet-CLI: +The following interfaces are available in TRON Wallet-CLI: + deploycontract(password, contractAddress, ABI, code, data, value) + triggercontract(password, contractAddress, selector, data, value) @@ -31,10 +31,10 @@ Developers can call these interfaces to deploy, trigger or check smart contracts ## How TVM Works -![Flowchart of Tron Virtual Machine](https://raw.githubusercontent.com/tronprotocol/documentation/master/images/Virtual_Machine/虚拟机.png) +![Flowchart of TRON Virtual Machine](https://raw.githubusercontent.com/tronprotocol/documentation/master/images/Virtual_Machine/虚拟机.png) The above flowchart shows how TVM works: -Compilation of Tron smart contract→execution and computing engines of VM→Interoperation service layer for external interfaces. +Compilation of TRON smart contract→execution and computing engines of VM→Interoperation service layer for external interfaces. Put simply, the flow is as follows: + Currently, TVM is compatible mainly with Solidity. The compiler translates Solidity smart contract into bytecode readable and executable on TVM. @@ -44,7 +44,7 @@ Put simply, the flow is as follows: ## Future Development of TVM 1. More developer-friendly debugging tools -Tron will be committed to the development of optimized debugging tools and the establishment of standardized symbol and data format, for improved developer efficiency. +TRON will be committed to the development of optimized debugging tools and the establishment of standardized symbol and data format, for improved developer efficiency. 2. Fulfillment of diversified processing demands @@ -52,7 +52,7 @@ Different from gas consumption mechanism for every transaction on EVM, there is 3. Improvement of Just-In-Time (JIT) compilation speed and integration of WebAssembly -Improving JIT compilation speed is conducive to faster interpretation and optimized compilation of local code. Meanwhile, Tron is planning to further optimize its TVM based on WebAssembly (WASM). WebAssembly, spearheaded by Apple, Google, Microsoft and Mozilla, is designed to break bottlenecks of current Web browsers and can be generated through compiling C/C++ and other programming languages. Integrating WASM, TVM will be able to provide high performance and high throughput for blockchain to cope with complex scenarios. +Improving JIT compilation speed is conducive to faster interpretation and optimized compilation of local code. Meanwhile, TRON is planning to further optimize its TVM based on WebAssembly (WASM). WebAssembly, spearheaded by Apple, Google, Microsoft and Mozilla, is designed to break bottlenecks of current Web browsers and can be generated through compiling C/C++ and other programming languages. Integrating WASM, TVM will be able to provide high performance and high throughput for blockchain to cope with complex scenarios. ## Usage Guide to TVM @@ -82,9 +82,9 @@ pragma solidity^0.4.11; 3. Deploy contract Wallet-cli-vm branch: [https://github.com/tronprotocol/wallet-cli/tree/wallet-cli-vm](https://github.com/tronprotocol/wallet-cli/tree/wallet-cli-vm) -Java-tron-vm branch: [https://github.com/tronprotocol/java-tron/tree/develop_vm](https://github.com/tronprotocol/java-tron/tree/develop_vm) +java-tron-vm branch: [https://github.com/tronprotocol/java-tron/tree/develop_vm](https://github.com/tronprotocol/java-tron/tree/develop_vm) Password: password of client-end wallet -ContractAddress: customized contract address (in Tron’s required format) +ContractAddress: customized contract address (in TRON’s required format) ABI: interface description Data: parameters of the initial function Value: reserved field @@ -101,4 +101,4 @@ triggercontract(Password, ContractAddress, Selector, Data, Value) getcontract(ContractAddress) ``` -The above is an introduction of Tron Virtual Machine and a guide to deployment. We welcome everyone to check out TVM and give us your thoughts and suggestions. We will continue to perfect and update TVM for optimal performance on TRON mainnet. +The above is an introduction of TRON Virtual Machine and a guide to deployment. We welcome everyone to check out TVM and give us your thoughts and suggestions. We will continue to perfect and update TVM for optimal performance on TRON mainnet. diff --git a/docs/developers/code-structure.md b/docs/developers/code-structure.md index 4a1aea9c..c42b2442 100644 --- a/docs/developers/code-structure.md +++ b/docs/developers/code-structure.md @@ -1,8 +1,8 @@ -# Java-tron Core Modules +# java-tron Core Modules ## Code Structure -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 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](#protocol), [common](#common), [chainbase](#chainbase), [consensus](#consensus), [actuator](#actuator), [crypto](#crypto), [framework](#framework), the following introduces the functions of each module and its code organization. +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](#protocol), [common](#common), [chainbase](#chainbase), [consensus](#consensus), [actuator](#actuator), [crypto](#crypto), [framework](#framework), the following introduces the functions of each module and its code organization. @@ -30,7 +30,7 @@ The above protocols adopt the [`Google Protobuf`](https://developers.google.com/ |-- contract ``` -* `protos/api/` - The gRPC interface and data structure provided by the Java-tron node externally +* `protos/api/` - The gRPC interface and data structure provided by the java-tron node externally * `protos/core/` - Data structure for communication between nodes and between modules within nodes * `Discover.proto` - Node discovers related data structures * `TronInventoryItems.proto` - Data structure related to block transferring between nodes @@ -125,7 +125,7 @@ In addition, the chainbase module features a well-designed abstract interface. A * `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: + 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 interface * `TronStoreWithRevoking.java` - It is the base class that supports rollbackable databases. All rollbackable databases are their implementations, such as `BlockStore`, `TransactionStore`, etc @@ -154,7 +154,7 @@ consensus module divides the consensus process into several important parts that 4. `validBlock` - define the consensus logic of validating blocks 5. `applyBlock` - 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. +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. ### actuator @@ -191,7 +191,7 @@ Actuator module defines the `Actuator` interface, which includes 4 different met Depending on their businesses, developers may set up Actuator accordingly and customize the processing of different types of transactions. ### crypto -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 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](https://github.com/tronprotocol/java-tron/tree/develop/crypto) module's source code is located at: `https://github.com/tronprotocol/java-tron/tree/develop/crypto`, its directory structure is as follows: ``` @@ -256,7 +256,7 @@ The framework is the core module of java-tron and the entrance of the node. The * `core/db/Manager.java` - Transaction and block verification and processing logic ### Summary -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. +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. @@ -266,12 +266,12 @@ As we all know, the blockchain is essentially a non-tamperable distributed ledge 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. +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. ### Prerequisites -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. +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. #### Account Models There are currently two mainstream account models, @@ -287,7 +287,7 @@ In the Account Model, user data is stored in the corresponding account, and smar 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 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](https://en.bitcoinwiki.org/wiki/DPoS). @@ -375,7 +375,7 @@ 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. +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. @@ -411,7 +411,7 @@ When rolling back, java-tron move the transactions in the pendingTransactionQueu 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, +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, ![image](https://raw.githubusercontent.com/tronprotocol/documentation-en/master/images/chainbase_6.png) @@ -436,9 +436,9 @@ In the process of producing the block, the transaction will be validated again, ### Block Solidity -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. +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, +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, ![image](https://raw.githubusercontent.com/tronprotocol/documentation-en/master/images/chainbase_8.png) @@ -456,13 +456,13 @@ This is obvious. If 'size' > 'maxSize', it means that the blocks corresponding t #### Atomicity -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 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. +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, diff --git a/docs/developers/demo.md b/docs/developers/demo.md index 8a66f4ab..6cc2e02d 100644 --- a/docs/developers/demo.md +++ b/docs/developers/demo.md @@ -1,9 +1,9 @@ # Development Example -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](../run-in-idea). +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](../run-in-idea). -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. +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. -## Fork Java-tron Repository +## Fork java-tron Repository Fork a new repository from the [https://github.com/tronprotocol/java-tron](https://github.com/tronprotocol/java-tron) project to your personal repository, and then use the following command Clone the code locally: @@ -30,7 +30,7 @@ $ git checkout -b feature/add-new-http-demo develop ``` ## Code Development -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. +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. ```java @Component @@ -137,7 +137,7 @@ public class FullNodeHttpApiService implements Service { } ``` -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: +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 $ curl --location --request POST 'http://127.0.0.1:16667/wallet/setpeer' \ @@ -156,11 +156,11 @@ At this point, the code development is complete, and then you need to write unit ## Write Unit Test -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](https://junit.org). The following is a brief introduction to the Java-tron unit test case specification and common annotations. +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](https://junit.org). The following is a brief introduction to the java-tron unit test case specification and common annotations. -### Java-tron Unit Test Cases Writing Specification -When writing Java-tron unit test cases, please follow the below guidelines: +### java-tron Unit Test Cases Writing Specification +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 diff --git a/docs/developers/deployment.md b/docs/developers/deployment.md index df73f7e9..a589e334 100644 --- a/docs/developers/deployment.md +++ b/docs/developers/deployment.md @@ -219,11 +219,11 @@ bash deploy_grpc_gateway.sh --rpchost 127.0.0.1 --rpcport 50052 --httpport 18891 ## Event Subscribe plugin Deployment -This is an implementation of Tron eventsubscribe model. +This is an implementation of TRON eventsubscribe model. -* **api** module defines IPluginEventListener, a protocol between Java-tron and event plugin. +* **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. +* **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

@@ -235,7 +235,7 @@ This is an implementation of Tron eventsubscribe model. * 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， add the following fields:

+

Edit **config.conf** of java-tron， add the following fields:

``` event.subscribe = { @@ -365,7 +365,7 @@ kafka-console-consumer.sh --zookeeper localhost:2181 --topic contractlog kafka-console-consumer.sh --zookeeper localhost:2181 --topic contractevent ``` -

Load plugin in Java-tron

+

Load plugin in java-tron

* add --es to command line, for example: ``` diff --git a/docs/developers/issue-workflow.md b/docs/developers/issue-workflow.md index 63b9aced..2edd970a 100644 --- a/docs/developers/issue-workflow.md +++ b/docs/developers/issue-workflow.md @@ -1,5 +1,5 @@ # Issue Work Flow -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. +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. ## Submit an Issue diff --git a/docs/developers/java-tron.md b/docs/developers/java-tron.md index 475f48a1..986cf3c6 100644 --- a/docs/developers/java-tron.md +++ b/docs/developers/java-tron.md @@ -2,9 +2,9 @@ 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: +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 +* Fork java-tron repository * Fix the code * Commit the code * Send a pull request @@ -12,14 +12,14 @@ GitHub is used to track issues and contribute code, suggestions, feature request 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](https://github.com/tronprotocol/tips) detailing your motivations, implementation plans, etc. For how to submit a TIP issue, please refer to [TIP Specification](../tips/). -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`. +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](#code-review-guidelines). ## Key Branches -Java-tron only has `master`, `develop`, `release-*`, `feature-*`, and `hotfix-*` branches, which are described below: +java-tron only has `master`, `develop`, `release-*`, `feature-*`, and `hotfix-*` branches, which are described below: * ``develop`` branch @@ -46,7 +46,7 @@ Java-tron only has `master`, `develop`, `release-*`, `feature-*`, and `hotfix-*` If you want to contribute codes to java-tron, please follow the following steps: -* Fork Java-tron repository +* Fork java-tron repository Fork a new repository from [tronprotocol/java-tron](https://github.com/tronprotocol/java-tron) to your personal code repository diff --git a/docs/developers/run-in-idea.md b/docs/developers/run-in-idea.md index 641353bd..d7d75349 100644 --- a/docs/developers/run-in-idea.md +++ b/docs/developers/run-in-idea.md @@ -1,8 +1,8 @@ # Configure the IntelliJ IDEA IDE -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. +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: +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](https://www.jetbrains.com/idea/download/#section=mac) are installed @@ -13,16 +13,16 @@ 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. + 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 ![image](https://raw.githubusercontent.com/tronprotocol/documentation-en/master/images/IDE_annotation.png) * Check the JDK version and make sure that `Oracle JDK 1.8` is used in IntelliJ IDEA ![image](https://raw.githubusercontent.com/tronprotocol/documentation-en/master/images/IDE_JDK.png) -* Download Java-tron source code +* Download java-tron source code - Clone the Java-tron source code locally and switch to the `develop` branch. + Clone the java-tron source code locally and switch to the `develop` branch. ``` $ git clone https://github.com/tronprotocol/java-tron.git $ git checkout -t origin/develop @@ -30,23 +30,23 @@ The IntelliJ IDEA configuration steps are as follows: ## Configure the code style check plugin -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: +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 ![image](https://raw.githubusercontent.com/tronprotocol/documentation-en/master/images/IDE_checkstyle.png) * Code style configuration - First, download the [Java-tron code style check configuration file](https://github.com/tronprotocol/java-tron/blob/develop/config/checkstyle/checkStyleAll.xml), 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. + First, download the [java-tron code style check configuration file](https://github.com/tronprotocol/java-tron/blob/develop/config/checkstyle/checkStyleAll.xml), 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. ![image](https://raw.githubusercontent.com/tronprotocol/documentation-en/master/images/IDE_checkStyleAll.png) 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. ![image](https://raw.githubusercontent.com/tronprotocol/documentation-en/master/images/IDE_stylecheck.png) -## Compile Java-tron +## Compile java-tron -You can use the terminal to compile Java-tron with the following command in the Java-tron project directory: +You can use the terminal to compile java-tron with the following command in the java-tron project directory: ``` $ ./gradlew clean build @@ -56,24 +56,24 @@ The above compile command will execute all test cases, you can use `-x test` to $ ./gradlew clean build -x test ``` -You can also compile Java-tron in IDEA: Open the Java-tron project in IDEA and click "Build" -> "Build Project" to compile the project. +You can also compile java-tron in IDEA: Open the java-tron project in IDEA and click "Build" -> "Build Project" to compile the project. ## Run and Debug -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. +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 ``` -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`. +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. +"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. ![image](https://raw.githubusercontent.com/tronprotocol/documentation-en/master/images/IDE_RunDebug.png) -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. +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. ![image](https://raw.githubusercontent.com/tronprotocol/documentation-en/master/images/IDE_runjavatron.png) -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. +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. ![image](https://raw.githubusercontent.com/tronprotocol/documentation-en/master/images/IDE_debug.png) diff --git a/docs/faq/index.md b/docs/faq/index.md index 258e3fb2..bf5a3056 100644 --- a/docs/faq/index.md +++ b/docs/faq/index.md @@ -178,7 +178,7 @@ Please use './gradlew build -x test' to skip the test cases. ### How to test if the deployment works normally, if there is a test api or command like redis: get ping return pong? -Java-tron does not provide a default api to test. Once the service start, grpc commands can be sent. Based on that, there are several ways to test if the deployment is successful. You can also use the following command to test: +java-tron does not provide a default api to test. Once the service start, grpc commands can be sent. Based on that, there are several ways to test if the deployment is successful. You can also use the following command to test: ```text > tail -f logs/tron.log |grep "MyheadBlockNumber" @@ -228,7 +228,7 @@ No, but the node provides wallet rpc api. ### Why does the block process time take so long? -Java-tron need more RAM to process transactions. +java-tron need more RAM to process transactions. ## Test Net diff --git a/docs/getting_started/getting_started_with_javatron.md b/docs/getting_started/getting_started_with_javatron.md index 2e558785..d10c9fda 100644 --- a/docs/getting_started/getting_started_with_javatron.md +++ b/docs/getting_started/getting_started_with_javatron.md @@ -1,10 +1,10 @@ -# Getting Started with Java-tron +# Getting Started with java-tron -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](../using_javatron/installing_javatron.md) page. This tutorial on this page assumes Java-tron and associated developer tools have been successfully installed. +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](../using_javatron/installing_javatron.md) 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. +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. +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. # Generating accounts 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). @@ -13,7 +13,7 @@ Enter the command `java -jar wallet-cli.jar` in the terminal to start a wallet-c ``` $ java -jar wallet-cli.jar -Welcome to Tron Wallet-Cli +Welcome to TRON Wallet-Cli Please type one of the following commands to proceed. Login, RegisterWallet or ImportWallet @@ -61,12 +61,12 @@ wallet> 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. -# Run a Java-tron node -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](../using_javatron/installing_javatron.md) chapter, and then run the following command to start Java-tron. +# Run a java-tron node +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](../using_javatron/installing_javatron.md) chapter, and then run the following command to start java-tron. ``` $ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c nile_net_config.conf ``` -After Java-tron starts, the logs will include the following: +After java-tron starts, the logs will include the following: ``` 11:07:58.758 INFO [main] [app](Args.java:1143) ************************ Net config ************************ 11:07:58.758 INFO [main] [app](Args.java:1144) P2P version: 201910292 @@ -77,7 +77,7 @@ After Java-tron starts, the logs will include the following: ``` -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: +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. 11:08:42.547 INFO [TronJClientWorker-1] [net](ChannelManager.java:161) Add active peer /123.56.3.74:18888 | fea80a0298b465a54fd332ff36819545d850115e77b327858b5306c9a58c6b8c2e7c08df76ab508a7594ed3577a8f4157727108442877077ab499b102b488467, total active peers: 1 @@ -106,13 +106,13 @@ Num:23113870,ID:000000000160b08e37cb9951d31a4233f106c7e77e0535c597dbb6a16f163699 ``` -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: +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 ``` -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 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`. +If you want to shut down java-tron node, please use this command: `kill -15 process id`. # Get TRX on Nile testnet 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: @@ -123,12 +123,12 @@ In order to make some transactions, the user must fund their account with TRX. O In the TRON testnet, TRX has no real value and can be obtained for free through [faucet](https://nileex.io/join/getJoinPage). -# Interact with Java-tron +# Interact with java-tron -## Interacting with Java-tron nodes using wallet-cli -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. +## Interacting with java-tron nodes using wallet-cli +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. ### Get account information -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. +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 ``` @@ -189,7 +189,7 @@ before sign transaction hex string is 0a85010a02cbc322088581ae7e29258a5240a89aef Please confirm and input your permission id, if input y or Y means default 0, other non-numeric characters will cancel transaction. ``` -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. +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. y @@ -262,8 +262,8 @@ wallet> gettransactioninfobyid 21851bcf1faf22c99a7a49c4f246d709cf9f54db2f264ca14 } wallet> ``` -## Interacting with Java-tron nodes using Curl -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. +## Interacting with java-tron nodes using Curl +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. ### Get account balance @@ -286,7 +286,7 @@ Sending a transaction through the http interface requires a total of three steps 2. Sign the transaction 3. Broadcast transaction -The following takes the transferring TRX as an example to illustrate how to send a transaction to Java-tron node. +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`](https://developers.tron.network/reference/createtransaction): @@ -328,7 +328,7 @@ Returns an unsigned TRX transferring transaction: ``` Then sign the transaction offline. -Finally, Broadcast the signed transaction to the Java-tron node through the [`wallet/broadcasttransaction`](https://developers.tron.network/reference/broadcasttransaction) interface to complete the sending of the TRX transferring transaction. +Finally, Broadcast the signed transaction to the java-tron node through the [`wallet/broadcasttransaction`](https://developers.tron.network/reference/broadcasttransaction) interface to complete the sending of the TRX transferring transaction. ``` diff --git a/docs/index.md b/docs/index.md index 3b42d3ee..32ce70ed 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,12 +1,12 @@ -# Welcome to the Java-tron user manual! +# Welcome to the java-tron user manual! -Java-tron is a TRON client implemented in Java, it provides completely open source code, you can download the [Java-tron source code](https://github.com/tronprotocol/java-tron) 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: +java-tron is a TRON client implemented in Java, it provides completely open source code, you can download the [java-tron source code](https://github.com/tronprotocol/java-tron) 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 Guide](/documentation-en/getting_started/getting_started_with_javatron/) -* [Using Java-tron](/documentation-en/using_javatron/installing_javatron/) +* [Using java-tron](/documentation-en/using_javatron/installing_javatron/) * [Protocol Guide](/documentation-en/introduction/dpos/) -* [Java-tron Development](/documentation-en/developers/java-tron/) +* [java-tron Development](/documentation-en/developers/java-tron/) * [DAPP Development](/documentation-en/contracts/compiler/) * [APIs](/documentation-en/api/http/) * [Wallet-CLI](/documentation-en/clients/wallet-cli/) diff --git a/docs/introduction/overview.md b/docs/introduction/overview.md index 8ffa79a5..870a9cee 100644 --- a/docs/introduction/overview.md +++ b/docs/introduction/overview.md @@ -113,7 +113,7 @@ id: proposal id - Query all the proposals list by pagination (GetPaginatedProposalList) - Query a proposal by proposal id (GetProposalById) -For more api detail, please refer to [Tron HTTP API](../api/http.md) +For more api detail, please refer to [TRON HTTP API](../api/http.md) # 3. Account Model @@ -128,7 +128,7 @@ TRON uses account model. An account's identity is address, it needs private key 2. Use an account already existed in TRON network to create an account ## 3.3 Key-pair Generation Algorithm -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. +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. ## 3.4 Address Format 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 comes out. Do basecheck to address, here is the final address. All addresses start with 'T'. @@ -486,7 +486,7 @@ Ethereum VM address is 20 bytes, but TRON's VM address is 21 bytes. Need to convert TRON's address while using in solidity (recommended): ```text /** - * @dev convert uint256 (HexString add 0x at beginning) tron address to solidity address type + * @dev convert uint256 (HexString add 0x at beginning) TRON address to solidity address type * @param tronAddress uint256 tronAddress, begin with 0x, followed by HexString * @return Solidity address type */ diff --git a/docs/mechanism-algorithm/account.md b/docs/mechanism-algorithm/account.md index 4a629413..b478df6d 100644 --- a/docs/mechanism-algorithm/account.md +++ b/docs/mechanism-algorithm/account.md @@ -13,7 +13,7 @@ If you have enough staked BandWidth Points, creating an account only consume you ## Key-pair Generation -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. +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. ## Address Format diff --git a/docs/releases/history.md b/docs/releases/history.md index 766c103e..3c881bb4 100644 --- a/docs/releases/history.md +++ b/docs/releases/history.md @@ -86,7 +86,7 @@ GreatVoyage-4.7.7(Epicurus) introduces multiple important optimizations and upda ### Core #### 1. Migrate `pow` operation from java.lang.Math to java.lang.StrictMath for cross-platform computational consistency -In order to enable Java-tron to support multiple platforms and be compatible with new JDK versions, the Epicurus version switches the floating-point power operation library from `java.lang.Math` to `java.lang.StrictMath` to ensure consistency in cross-platform calculations. +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. @@ -98,7 +98,7 @@ Source Code: [https://github.com/tronprotocol/java-tron/pull/6098](https://githu ### Other Changes #### 1. Optimize event subscription processing logic -Java-tron provides event subscription service, and developers can subscribe to specific events from node through event plugin. For block events, when a node receives a new block, if it successfully verifies and processes the block, it will save the block data in the memory database. At the same time, if there is a new solidified block, the solidified block data will be written to the disk database. If the node deployer subscribes to block events, after the node completing the above block processing steps, the event sending related logic will be performed, that is, the latest block event and the latest solidified block event will be sent to the event plugin. However, in previous versions of Epicurus, block processing and event sending used the same exception capture logic: the newly received block data was removed from the memory database and an exception was thrown. This would result in the new block data being deleted when the block processing was normal but an exception occurred during event sending, which might temporarily affect block synchronization. +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. @@ -134,7 +134,7 @@ The GreatVoyage-4.7.6(Anaximander) introduces several important optimizations an ### Other Changes #### 1. Optimize the statistical logic of node HTTP request monitoring metric -Java-tron supports node monitoring and provides various metrics data. Anaximander optimizes the statistical logic of node HTTP request monitoring metric to ensure data consistency during concurrent access by multiple threads when counting request data from each mapping address. +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](https://github.com/tronprotocol/java-tron/pull/5920) @@ -321,7 +321,7 @@ The Bias version bumps the jetty dependency library to v9.4.53.v20231009. Source Code: [https://github.com/tronprotocol/java-tron/pull/5571](https://github.com/tronprotocol/java-tron/pull/5571) #### 4. Refactor Gradle dependencies -The Java-tron code is divided into multiple modules, each module has its own dependencies, but currently there are situations where dependencies are declared multiple times in multiple modules. The Bias version reconstructs the Gradle dependencies of each module and deletes duplicate dependency statements, making the code dependencies clearer and enabling unified management of dependencies to reduce maintenance costs. +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](https://github.com/tronprotocol/java-tron/pull/5625) @@ -379,7 +379,7 @@ Source Code: [https://github.com/tronprotocol/java-tron/pull/5624](https://githu #### 11. Add synchronization control when writing to ZeroMQ -Java-tron supports subscribing to events through the built-in ZeroMQ message queue. However, when multiple threads concurrently send events to the ZeroMQ, write exception errors may occur. The Bias version adds synchronization control when writing to ZeroMQ, ensuring the order of concurrent access between threads. +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](https://github.com/tronprotocol/java-tron/pull/5536) @@ -512,7 +512,7 @@ Source Code: [https://github.com/tronprotocol/java-tron/pull/5332](https://githu #### 2. Provide uniform rate limitation configuration for all HTTP and gRPC APIs -Java-tron supports interface rate limiting. The default qps (queries per second) of each interface is 1000. Node deployers can also limit the traffic of a particular interface. However, in previous versions of Chilon, it was not supported to modify the default qps of each interface, that way, If you want to configure the default qps of each interface to 2000, you need to configure the current limit for each interface respectively. The Chilon version adds a new default interface rate limit configuration `rate.limiter.global.api.qps`. With this configuration, users can change the rate limit of all interfaces, simplifying the configuration complexity. +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 @@ -577,7 +577,7 @@ Source Code: [https://github.com/tronprotocol/java-tron/pull/5441](https://githu #### 4. Obtain external IP through Libp2p -In previous versions of Chilon, when a node starts, the external IP address would be obtained repeatedly, and Java-tron and lib2p2 each perform the IP acquisition once. To improve the node startup speed, Chilon optimizes the external IP acquisition logic. When a node starts, it directly calls the libp2p module to obtain the external IP, and it can directly assign the external IP to libp2p and repeated obtaining is avoided. +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](https://github.com/tronprotocol/java-tron/pull/5407) @@ -629,7 +629,7 @@ Please see the details below. ### Core #### 1. Upgrade Libp2p to v1.2.0 -Libp2p is a Java version open-source P2P protocol framework developed by the Java-tron core developers and anyone can develop distributed applications with Libp2p, as the underlying P2P network of Java-tron is implemented based on Libp2p. In order to further improve the underlying network performance of Java-tron, Periander upgrades the Libp2p v0.1.4 with the v1.2.0 version. +Libp2p 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： @@ -870,7 +870,7 @@ In versions previous to Periander, for contracts created by the `create2` instru ### Other Changes #### 1. Optimize event forwarding logic in event subscription -Java-tron supports event subscription. In the previous version of Periander, if the solidified transaction event is subscribed, then when the node receives a new block, it would send the transaction information in the latest solidified block to the subscriber. If the network of most SR nodes is unstable, making them unable to synchronize and produce blocks in time, in this case, according to the calculation logic of the latest solidified block of the node, the height of the latest solidified block will not be guaranteed to increase by one each time. So that the latest obtained solidified block forwarded to the subscriber during event forwarding may not be the block next to the one that was forwarded the last time, resulting in data missing. +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. @@ -879,7 +879,7 @@ Since the conditions for this problem are very strict, it will basically not app #### 2. Support dynamic loading according to node.active and node.passive -Java-tron supports configuring trusted nodes for the local node with `node.active` and `node.passive`. The local node will actively connect to the nodes in `node.active` and accept the connection request of the nodes in `node.passive`. By configuring trusted nodes, you can solve the problem that the node has no valid connections or the number of connections is rather small. However, in the previous version of Periander, you need to stop the node first to change the configuration file, and then restart the node after the update is completed. Restarting the node has a certain impact on some applications. Therefore, starting from the Periander version, the dynamic loading of `node.active` and `node.passive` configuration items are supported, so that the change of the trusted node can be completed without restarting the local node, which improves the online stability of the node. +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. @@ -1101,7 +1101,7 @@ Source code: [https://github.com/tronprotocol/java-tron/pull/4977](https://githu ## GreatVoyage-v4.7.0.1(Aristotle) -GreatVoyage-v4.7.0.1 (Aristotle) introduces several important optimizations and updates. The new stake mechanism, Stake 2.0, improves the flexibility of the resource model and the stability of the stake system; the dynamic energy model helps to promote ecologically balanced development; the secondary cache mechanism optimizes the database reading performance, improves transaction execution performance, and expands the network throughput; uses the libp2p library as the Java-tron P2P network module to make the code structure clearer and reduce code coupling; optimizes the log output, redirect the logs of LevelDB and RocksDB to Java-tron log files; integrate more tools and functions into the ‘Toolkit.jar’ toolbox to bring users a more convenient development experience. +GreatVoyage-v4.7.0.1 (Aristotle) introduces several important optimizations and updates. The new stake mechanism, Stake 2.0, improves the flexibility of the resource model and the stability of the stake system; the dynamic energy model helps to promote ecologically balanced development; the secondary cache mechanism optimizes the database reading performance, improves transaction execution performance, and expands the network throughput; uses the libp2p library as the java-tron P2P network module to make the code structure clearer and reduce code coupling; optimizes the log output, redirect the logs of LevelDB and RocksDB to java-tron log files; integrate more tools and functions into the ‘Toolkit.jar’ toolbox to bring users a more convenient development experience. Please see the details below. @@ -1134,7 +1134,7 @@ The new stake mechanism is a dynamic parameter in the TRON network. After GreatV * Source code: [https://github.com/tronprotocol/java-tron/pull/4838](https://github.com/tronprotocol/java-tron/pull/4838) #### 2.Enhance database query performance -Java-tron uses memory and disk databases for data storage. The solidified block data will be stored in multiple disk databases, and the unsolidified data will be stored in memory. When a block is solidified, the corresponding in-memory data is written to the disk databases. When querying data, first query the data in memory, if not found, then query the disk database. The disk database query is time-consuming. Therefore, the GreatVoyage-v4.7.0.1 (Aristotle) version optimizes the database query performance and adds a secondary cache before performing the underlying disk database operation. When data is written to the disk, the data is also written to the second-level cache. When the disk database needs to be queried, if the data to be queried exists in the second-level cache, it will be returned directly without querying the disk database. The second-level cache reduces the number of queries to the disk database, improves transaction execution speed, and improves network throughput. +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. @@ -1152,8 +1152,8 @@ When a node processes a block, it will use the transaction hash value multiple t * Source code: [https://github.com/tronprotocol/java-tron/pull/4792](https://github.com/tronprotocol/java-tron/pull/4792) -#### 5. Add `libp2p` module as Java-tron p2p network protocol implementation -Starting from GreatVoyage-v4.7.0.1 (Aristotle), the libp2p library will be directly used as the P2P network module of Java-tron, instead of using the original p2p network stack, so that the code structure is clearer, the code coupling is lower, and is easy to maintain. +#### 5. Add `libp2p` module as java-tron p2p network protocol implementation +Starting from GreatVoyage-v4.7.0.1 (Aristotle), the libp2p library will be directly used as the P2P network module of java-tron, instead of using the original p2p network stack, so that the code structure is clearer, the code coupling is lower, and is easy to maintain. * Source code: [https://github.com/tronprotocol/java-tron/pull/4791](https://github.com/tronprotocol/java-tron/pull/4791) @@ -1207,7 +1207,7 @@ The dynamic energy model is a dynamic parameter in the TRON network. After Great #### 3. Optimize the return value of the `chainId` opcode -Starting from the GreatVoyage-v4.7.0.1 (Aristotle) version, the return value of the `chainid` opcode is changed from the block hash of the genesis block to the last four bytes of the block hash of the genesis block, keeping the return value of the chainid opcode consistent with the return value of the Java-tron JSON-RPC `eth_chainId` API. +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. @@ -1269,7 +1269,7 @@ curl --location --request POST 'https://api.nileex.io/wallet/estimateenergy' \ ### Other Changes #### 1. Optimize Gradle compilation parameters -GreatVoyage-v4.7.0.1(Aristotle) optimizes the compiling parameters of Gradle, configuring JVM minimum heap size to 1GB, which improves the compilation speed of Java-tron. +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](https://github.com/tronprotocol/java-tron/pull/4837) @@ -1298,7 +1298,7 @@ Therefore, starting from the GreatVoyage-v4.7.0.1 (Aristotle) version, the numbe * Source code: [https://github.com/tronprotocol/java-tron/pull/4834](https://github.com/tronprotocol/java-tron/pull/4834) #### 6. Toolkit.jar Integration -`DBConvert.jar` is a database conversion tool, which can convert LevelDB into RocksDB; `LiteFullNodeTool.jar` is a light FullNode tool, which can convert FullNode data into LiteFullNode data. Starting from GreatVoyage-v4.7.0.1 (Aristotle), `DBConvert.jar` and `LiteFullNodeTool.jar` have been integrated into the `Toolkit.jar` toolbox, and a database copy function is added which can realize fast Node database copy. In the future, the tools around Java-tron will be gradually integrated into the `Toolkit.jar` toolbox in order to facilitate tool maintenance and developer use. The commands for using the new functions of the `Toolkit.jar` toolbox are as follows: +`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: @@ -1366,7 +1366,7 @@ The optimized reward algorithm is a TRON network parameter and is disabled by de #### 4. Upgrade checkpoint mechanism to v2 in database module -The Checkpoint is a recovery mechanism established to prevent database damage caused by the exceptional shutdown. Java-tron uses memory and multi-disk databases for data storage. The data of the solidified block will be stored in multiple business databases. Unsolidified data is stored in the memory. When a block is solidified, the corresponding memory data will be written to relevant databases. However, since the writing to multiple business databases is not an atomic operation, if there is an unexpected downtime due to some reason, then all the data in the block may not be able to be written to the disk, and the node will not be able to restart due to database corruption. +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. @@ -1389,7 +1389,7 @@ The GreatVoyage-v4.6.0 (Socrates) optimizes the priority of block production log #### 6.Optimize the Kademlia algorithm for the network module -The Java-tron node ID is a random number, which will be regenerated every time the node is started. In the implementation of the Kademlia algorithm of Java-tron, the distance of the node will be calculated according to the node ID, and then the node information will be put into the corresponding K bucket according to the distance. If the node in the K bucket is restarted for some reason, the node ID will change. When it is detected that the node is offline again, the distance calculated according to the latest node ID has been unable to locate the original K bucket, therefore it is not able to delete the node from the bucket. Too many such nodes restarted will cause too much invalid data to be stored in the K bucket of the node. +The java-tron node ID is a random number, which will be regenerated every time the node is started. In the implementation of the Kademlia algorithm of java-tron, the distance of the node will be calculated according to the node ID, and then the node information will be put into the corresponding K bucket according to the distance. If the node in the K bucket is restarted for some reason, the node ID will change. When it is detected that the node is offline again, the distance calculated according to the latest node ID has been unable to locate the original K bucket, therefore it is not able to delete the node from the bucket. Too many such nodes restarted will cause too much invalid data to be stored in the K bucket of the node. Therefore, the GreatVoyage-v4.6.0 (Socrates) optimizes the Kademlia algorithm, and uses a hash table to record the discovered nodes. The distance of a node is only calculated once when it is written into the K bucket for the first time and is assigned to the ‘distance’ field of the node, and then the node is added to the hash table. In the future, the node distance will be obtained directly through this field. Even if the node ID changes after the node is restarted, the distance of the node in the Hash table will not be updated. When the node is detected to be offline, the corresponding node can be found from the hash table according to the node IP, and then the distance to the node can be obtained through the node distance field, at last the node information can be deleted from the K bucket. @@ -1398,7 +1398,7 @@ Therefore, the GreatVoyage-v4.6.0 (Socrates) optimizes the Kademlia algorithm, a ### Other Changes #### 1. Merge ArchiveManifest.jar into Toolkit.jar -ArchiveManifest.jar is an independent LevelDB startup optimization tool, which can optimize the file size of LevelDB manifest, thereby reducing memory usage and greatly improving node startup speed. Starting from the GreatVoyage-v4.6.0 (Socrates), the ArchiveManifest.jar tool has been integrated into the Toolkit.jar. In the future, all the tools around Java-tron will be gradually integrated into the Toolkit.jar toolbox to facilitate tool maintenance and developer use. +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](https://github.com/tronprotocol/java-tron/pull/4603) @@ -1720,8 +1720,8 @@ The GreatVoyage-v4.4.4(Plotinus) version optimizes the network service shutdown Source Code：https://github.com/tronprotocol/java-tron/pull/4220 -#### 3. improve the Java-tron upgrade mechenism -For upgrade mechanism of java-tron,Before the GreatVoyage-v4.4.4 (Plotinus) version,all 27 super representative nodes need to complete the code upgrade, TRON network can be upgraded to the new version,TRON is a completely decentralized governance network,Sometimes the 27 super representative nodes cannot complete the code upgrade within a certain period of time, making the version upgrade process slow.In order to achieve more efficient decentralized governance, in GreatVoyage-v4.4.4 (Plotinus), the upgrade mechanism of Java-tron has been improved, only 22 super representative nodes are needed to complete the code upgrade, and the TRON network can complete the upgrade. +#### 3. improve the java-tron upgrade mechenism +For upgrade mechanism of java-tron,Before the GreatVoyage-v4.4.4 (Plotinus) version,all 27 super representative nodes need to complete the code upgrade, TRON network can be upgraded to the new version,TRON is a completely decentralized governance network,Sometimes the 27 super representative nodes cannot complete the code upgrade within a certain period of time, making the version upgrade process slow.In order to achieve more efficient decentralized governance, in GreatVoyage-v4.4.4 (Plotinus), the upgrade mechanism of java-tron has been improved, only 22 super representative nodes are needed to complete the code upgrade, and the TRON network can complete the upgrade. Source Code：https://github.com/tronprotocol/java-tron/pull/4218 @@ -2273,7 +2273,7 @@ Odyssey-v3.7 has modularized the code organization structure, making it much eas As the core module, Framework performs as both a gateway to the blockchain and an adhesive that effectively connects all other modules. In other words, the framework module initializes each module and facilitates communication between modules. #### Protocol -The decentralized Tron protocol can be implemented by any teams without limitation of programming languages. Any clients in accordance with the Tron protocol can communicate with each other. +The decentralized TRON protocol can be implemented by any teams without limitation of programming languages. Any clients in accordance with the TRON protocol can communicate with each other. A concise and efficient data transfer protocol is essential to a distributed network, even more for the blockchain. So, the implementation of the protocol is based on the Protocol Buffers, an open-source and excellent software protocol maintained by Google. The specific business logic of the blockchain defined by the protocol includes: - the data format of message，including block, transaction, proposal, witness, vote, account, exchange and so on. @@ -2281,14 +2281,14 @@ The specific business logic of the blockchain defined by the protocol includes: - the interface protocols that the blockchain provides to the external system or clients #### Consensus -The consensus mechanism is an essential part of the blockchain. The Tron blockchain chooses the DPoS as the core consensus mechanism and it has been running steadily for a long time. But replaceable consensus module is essential if we want to redefine the java-tron as the powerful infrastructure for building application-specific blockchains. The developers of blockchain should determine to choose the consensus mechanism that considered to be most suitable to the specific application scenario. The ultimate goal of the replaceable consensus module is that the consensus mechanism can be determined by configuring some necessary parameters. In addition, the developers can implement a customized consensus module as long as several essential interfaces implemented. +The consensus mechanism is an essential part of the blockchain. The TRON blockchain chooses the DPoS as the core consensus mechanism and it has been running steadily for a long time. But replaceable consensus module is essential if we want to redefine the java-tron as the powerful infrastructure for building application-specific blockchains. The developers of blockchain should determine to choose the consensus mechanism that considered to be most suitable to the specific application scenario. The ultimate goal of the replaceable consensus module is that the consensus mechanism can be determined by configuring some necessary parameters. In addition, the developers can implement a customized consensus module as long as several essential interfaces implemented. #### Crypto Encryption is also one of the core modules of the blockchain. It is the foundation of the blockchain data security. such as public and private key deduction, transaction verification, zero-knowledge proof, etc. The java-tron abstracts the encryption module and supports the replacement of encryption algorithms. A suitable encryption algorithm can be chosen according to different business needs. #### Actuator -Actuator is the core module used for handling various kinds of transactions. As you know, every transaction in the Tron blockchain contains a contract. On a high level, there are two types of contracts in the Tron blockchain, the system contract and the smart contract. A large number of applications are implemented by the smart contracts and ran in an internal virtual machine of the blockchain. Unfortunately, smart contracts are constrained in terms of their functions and not flexible enough to accommodate the needs of complex applications. Customized actuators offer application developers a brand new way of development. They can choose to implant their application codes into the chain instead of running them on virtual machines. +Actuator is the core module used for handling various kinds of transactions. As you know, every transaction in the TRON blockchain contains a contract. On a high level, there are two types of contracts in the TRON blockchain, the system contract and the smart contract. A large number of applications are implemented by the smart contracts and ran in an internal virtual machine of the blockchain. Unfortunately, smart contracts are constrained in terms of their functions and not flexible enough to accommodate the needs of complex applications. Customized actuators offer application developers a brand new way of development. They can choose to implant their application codes into the chain instead of running them on virtual machines. #### Chainbase Chainbase is specially designed for data storage in the blockchain. Nodes always consider the longest chain to be the correct one and will keep working on extending it. So switching to the longest chain is a common scenario for the blockchain unless it uses a deterministic consensus algorithm like PBFT. For this reason, supporting data rollback is the most distinctive feature of the chainbase module. Several well-designed abstract interfaces are defined in this module. So, the developers can choose the storage engine freely and then implement corresponding interfaces. The LevelDB and RocksDB are two existing implementation. diff --git a/docs/releases/signature_verification.md b/docs/releases/signature_verification.md index 297e0647..ab0fc7fb 100644 --- a/docs/releases/signature_verification.md +++ b/docs/releases/signature_verification.md @@ -1,14 +1,14 @@ -# Signature Verification of Java-tron Release Package +# Signature Verification of java-tron Release Package -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. +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. +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](#gpg-signature-verification-process) * Versions released before January 3, 2023: [TRON Address Signature Verification Process](#tron-address-signature-verification-process) ## GPG signature verification process -The java-tron executable file and its signature file are released together, you can get it at [here](https://github.com/tronprotocol/java-tron/releases), please follow the below process to verify the signature of the Java-tron which released after January 3, 2023. +The java-tron executable file and its signature file are released together, you can get it at [here](https://github.com/tronprotocol/java-tron/releases), please follow the below process to verify the signature of the java-tron which released after January 3, 2023. ### Install GPG If you have already installed GPG, please skip this step. If not, please refer to the following command to install it on MacOS: @@ -22,7 +22,7 @@ $ sudo apt install gpg ### Import public key 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](https://github.com/tronprotocol/java-tron). +Please first obtain the public key Hash and uid of the GPG signature of the java-tron release package from [here](https://github.com/tronprotocol/java-tron). ``` pub: 1254 F859 D2B1 BD9F 66E7 107D F859 BCB4 4A28 290B @@ -58,7 +58,7 @@ Subkey fingerprint: 1254 F859 D2B1 BD9F 66E7 107D F859 BCB4 4A28 290B If the verification fails, it will display the words `gpg: BAD signature from “build_tron ”`. ## TRON address signature verification process -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](#signatures-of-historical-versions) chapter, or in the [https://github.com/tronprotocol/java-tron/releases](https://github.com/tronprotocol/java-tron/releases) page; the signature result please check in the [Signatures of historical versions](#signatures-of-historical-versions) chapter. +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](#signatures-of-historical-versions) chapter, or in the [https://github.com/tronprotocol/java-tron/releases](https://github.com/tronprotocol/java-tron/releases) page; the signature result please check in the [Signatures of historical versions](#signatures-of-historical-versions) chapter. [tronweb](https://developers.tron.network/docs/tronweb-1) 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. @@ -335,4 +335,4 @@ SolidityNode sha256sum: ee37a425a84677063b6ea44ed073b8260e336586a61debc10ce0b1544bf7db6a SolidityNode signature: 332c273ef1cdae8dc39c76a83b38750a74b3dd1b915e49698e4ae6870cfed49a1449e8d8db995c7a6be2295e2603efedb0f3e8e906ac7681583c5023b28a521d1b -``` \ No newline at end of file +``` diff --git a/docs/releases/upgrade-instruction.md b/docs/releases/upgrade-instruction.md index 6425ac84..3f3f9b05 100644 --- a/docs/releases/upgrade-instruction.md +++ b/docs/releases/upgrade-instruction.md @@ -1,7 +1,7 @@ -# New Version Deployment Manual of Java-tron +# New Version Deployment Manual of java-tron 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](#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](#active-and-backup-nodes-upgrade-guide). +Please directly refer to [java-tron New version deployment Process](#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](#active-and-backup-nodes-upgrade-guide). ## New version deployment Process @@ -9,13 +9,13 @@ Please follow the below steps to upgrade your FullNode, FullNode that produces b ### 1. Prepare the executable file of the new version -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: +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](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](https://tronprotocol.github.io/documentation-en/releases/signature_verification/). + 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](https://tronprotocol.github.io/documentation-en/releases/signature_verification/). * Way 2: Compile the source code @@ -32,10 +32,10 @@ You can directly download the Java-tron executable file, or download the code of ``` -### 2. Shut down the Java-tron process -Shut down the node process. Note: If a Java-tron node has not been deployed on this machine before, please skip to step 5. +### 2. Shut down the java-tron process +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 +* First, get the process ID of the java-tron node through the following command ``` $ ps -ef | grep java ``` @@ -66,10 +66,10 @@ Please back up the executable file, database, and configuration file before the ### 4. Replace old version files 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: -1. Copy the newest jar package obtained in the previous step to the Java-tron working directory to replace the old executable file. +1. Copy the newest jar package obtained in the previous step to the java-tron working directory to replace the old executable file. 2. 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](https://tronprotocol.github.io/documentation-en/using_javatron/backup_restore/#public-backup-data). +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](https://tronprotocol.github.io/documentation-en/using_javatron/backup_restore/#public-backup-data). ### 5. Start the nodes @@ -99,7 +99,7 @@ To upgrade the active and backup nodes, please follow the steps below: 1. Upgrade the backup node - Upgrade the backup node according to the [Java-tron new version deployment Process](#new-version-deployment-process). + Upgrade the backup node according to the [java-tron new version deployment Process](#new-version-deployment-process). 2. Shut down the master node @@ -107,7 +107,7 @@ To upgrade the active and backup nodes, please follow the steps below: 3. Upgrade the master node - If the backup node works normally, follow [Java-tron New Version Deployment Process](#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’s log for root cause analysis. + If the backup node works normally, follow [java-tron New Version Deployment Process](#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’s log for root cause analysis. 4. Shut down the backup node diff --git a/docs/using_javatron/backup_restore.md b/docs/using_javatron/backup_restore.md index 4b4e9bbd..b0a9d700 100644 --- a/docs/using_javatron/backup_restore.md +++ b/docs/using_javatron/backup_restore.md @@ -1,6 +1,6 @@ # Data Backup & Restore -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. +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 @@ -65,7 +65,7 @@ The following table shows the download address of Fullnode data snapshots. Pleas ### Lite FullNode Data Snapshot -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. +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 | diff --git a/docs/using_javatron/connecting_to_tron.md b/docs/using_javatron/connecting_to_tron.md index a20bb2bd..872e330a 100644 --- a/docs/using_javatron/connecting_to_tron.md +++ b/docs/using_javatron/connecting_to_tron.md @@ -1,8 +1,8 @@ # Connecting to the TRON network -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. +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: +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` @@ -14,9 +14,9 @@ You need to set the following configuration items to connect Java-tron to one of # Finding peers -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. +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: +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 = { @@ -71,7 +71,7 @@ There are scenarios where disabling the discovery process is useful, for example # Connectivity problems -There are occasions when Java-tron simply fails to connect to peers. The common reasons for this are: +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`](#active-and-passive-connections) in the case of node discovery invalid. @@ -79,13 +79,13 @@ There are occasions when Java-tron simply fails to connect to peers. The common * 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. # Log and network connection verification -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: +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/ ``` -You will see the below block synchronization logs if Java-tron is running as expected. +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 @@ -134,7 +134,7 @@ Returns： "totalFlow": 8735314 } ``` -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. +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. # Private network @@ -145,9 +145,9 @@ The private chain network needs to configure the configuration item `node.p2p.ve # Active and passive connections -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. +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`. +When java-tron starts, it will actively establish a connection with the peer node in `node.active`. ``` node { diff --git a/docs/using_javatron/installing_javatron.md b/docs/using_javatron/installing_javatron.md index ac27cf77..732ff107 100644 --- a/docs/using_javatron/installing_javatron.md +++ b/docs/using_javatron/installing_javatron.md @@ -1,27 +1,27 @@ -# Deploy a Java-tron Node +# Deploy a java-tron Node -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. +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`, `2T SDD`, the recommended configuration is: `16-core CPU`, `32G memory`, `2.5T+ SDD`. The fullnode running by super representative to produce block recommends `32-core CPU` and `64G memory`. +The minimum hardware configuration required to run a java-tron node is `8-core CPU`, `16G memory`, `2T SDD`, the recommended configuration is: `16-core CPU`, `32G memory`, `2.5T+ SDD`. The fullnode running by super representative to produce block recommends `32-core CPU` and `64G memory`. # Compile the Source Code -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. +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 $ git checkout -t origin/master ``` -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. +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 $ ./gradlew clean build -x test ``` -## Run a Java-tron Node -You can choose different configuration files to connect Java-tron nodes to different networks. The mainnet configuration file is: [main_net_config.conf](https://github.com/tronprotocol/tron-deployment/blob/master/main_net_config.conf), other network configuration files can be found [here](https://github.com/tronprotocol/tron-deployment). +## Run a java-tron Node +You can choose different configuration files to connect java-tron nodes to different networks. The mainnet configuration file is: [main_net_config.conf](https://github.com/tronprotocol/tron-deployment/blob/master/main_net_config.conf), other network configuration files can be found [here](https://github.com/tronprotocol/tron-deployment). ### Startup a fullnode @@ -53,7 +53,7 @@ then run the following command to start the node: $ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar --witness -c main_net_config.conf ``` -**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](../backup_restore/#public-backup-data) 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. +**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](../backup_restore/#public-backup-data) 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. # Others @@ -124,4 +124,4 @@ Instructions for each Linux distributions are as belows: ``` export LD_PRELOAD="/usr/lib64/libtcmalloc.so.4" export TCMALLOC_RELEASE_RATE=10 - ``` \ No newline at end of file + ``` diff --git a/docs/using_javatron/metrics.md b/docs/using_javatron/metrics.md index ce333232..982b9843 100644 --- a/docs/using_javatron/metrics.md +++ b/docs/using_javatron/metrics.md @@ -1,7 +1,7 @@ -# Java-tron Node Metrics Monitoring +# java-tron Node Metrics Monitoring 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. -## Configure Java-tron +## Configure java-tron 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: ``` @@ -21,9 +21,9 @@ node { } ``` -## Start Java-tron node +## Start java-tron node -Start Java-tron node using below command： +Start java-tron node using below command： ```shell $ java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c main_net_config.conf diff --git a/docs/using_javatron/toolkit.md b/docs/using_javatron/toolkit.md index 4e885ab2..3ae28219 100644 --- a/docs/using_javatron/toolkit.md +++ b/docs/using_javatron/toolkit.md @@ -1,4 +1,4 @@ -# Java-tron Node Maintenance Tool - Toolkit +# java-tron Node Maintenance Tool - Toolkit 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: @@ -67,7 +67,7 @@ $ ps -ef |grep FullNode.jar |grep -v grep |awk '{print $2}'` #### Configure For Database Storage Migration -The configuration of database migration is in the [storage.properties](https://github.com/tronprotocol/tron-deployment/blob/master/main_net_config.conf#L36) 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: +The configuration of database migration is in the [storage.properties](https://github.com/tronprotocol/tron-deployment/blob/master/main_net_config.conf#L36) 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: ```conf diff --git a/docs_without_index/mpc/002/report.asc b/docs_without_index/mpc/002/report.asc index 6c07b731..263c6163 100644 --- a/docs_without_index/mpc/002/report.asc +++ b/docs_without_index/mpc/002/report.asc @@ -1,5 +1,5 @@ From: tronz_mpc -Subject: RE: Tron - MPC Test +Subject: RE: TRON - MPC Test Date: 2020/01/07 at 12:05:03 GMT+8 To: Crypto Guy In ZA @@ -17,7 +17,7 @@ Tronz Team From: Crypto Guy In ZA Sent: Tuesday, January 7 2020, 1:05 am To: tronz_mpc -Subject: Re: Tron - MPC Test +Subject: Re: TRON - MPC Test Hi   @@ -51,11 +51,11 @@ Tronz Team From: Crypto Guy In ZA Sent: Monday, January 6 2020, 7:48 pm To: tronz_mpc -Subject: Tron - MPC Test +Subject: TRON - MPC Test   Hi   -I am Tron SR CryptoGuyInZA and will participate in TRON-mpc test. +I am TRON SR CryptoGuyInZA and will participate in TRON-mpc test.   Please advise way forward.   diff --git a/docs_without_index/mpc/003/report.asc b/docs_without_index/mpc/003/report.asc index 3cc65e0b..3ac3ca62 100644 --- a/docs_without_index/mpc/003/report.asc +++ b/docs_without_index/mpc/003/report.asc @@ -1,5 +1,5 @@ From: tronz_mpc -Subject: RE: invite to participate in Tron MainNet MPC +Subject: RE: invite to participate in TRON MainNet MPC Date: 2020/01/07 at 15:30:52 GMT+8 To: Jason Neely @@ -15,7 +15,7 @@ Tronz Team From: Jason Neely Sent: Tuesday, January 7 2020, 12:25 pm To: tronz_mpc -Subject: Re: invite to participate in Tron MainNet MPC +Subject: Re: invite to participate in TRON MainNet MPC  353044e1 540ec813 c0acdb2c b7f927b7 bb6ae4de 5c248008 b8a5e35f 580f0216 @@ -65,10 +65,10 @@ Tronz Team From: tronz_mpc Sent: Tuesday, December 31 2019, 5:32 pm To: bondibox@gmail.com -Subject: invite to participate in Tron MainNet MPC +Subject: invite to participate in TRON MainNet MPC   Dear Jason， -   Do you still want to participate Tron MainNet MPC ? If you want to join in, please tell us your free time between 2020-01-01 and 2020-01-14, it takes about 2~3 hours. +   Do you still want to participate TRON MainNet MPC ? If you want to join in, please tell us your free time between 2020-01-01 and 2020-01-14, it takes about 2~3 hours.    See more detail on https://github.com/tronprotocol/mpc.     Thank you for your attention.   diff --git a/docs_without_index/mpc/004/report.asc b/docs_without_index/mpc/004/report.asc index 6fe9864e..e71bd8e6 100644 --- a/docs_without_index/mpc/004/report.asc +++ b/docs_without_index/mpc/004/report.asc @@ -1,5 +1,5 @@ ```text -From: Tron Europe +From: TRON Europe Subject: Re: MPC Participation Date: 2020/01/07 at 18:36:45 GMT+8 @@ -9,7 +9,7 @@ OS used Ubuntu 18.10 https://raw.githubusercontent.com/tronprotocol/documentation-en/master/docs_without_index/mpc/004/hash.PNG -Tron Europe +TRON Europe Dirk Frank CEO @@ -29,14 +29,14 @@ Tronz Team   -----Original message----- -From: Tron Europe +From: TRON Europe Sent: Saturday, January 4 2020, 12:29 am To: tronz_mpc Subject: Re: MPC Participation ok thank you   -Tron Europe +TRON Europe Dirk Frank CEO @@ -49,7 +49,7 @@ Your sincerely， Tronz Team   -----Original message----- -From: Tron Europe +From: TRON Europe Sent: Friday, January 3 2020, 5:06 pm To: tronz_mpc Subject: MPC Participation @@ -62,7 +62,7 @@ the rest i think you know what we are already doing. -- -Tron Europe +TRON Europe Dirk Frank CEO diff --git a/docs_without_index/mpc/005/report.asc b/docs_without_index/mpc/005/report.asc index f58fe7d2..d83cca97 100644 --- a/docs_without_index/mpc/005/report.asc +++ b/docs_without_index/mpc/005/report.asc @@ -34,7 +34,7 @@ Tronz Team On 2020/1/8, at 14:59, tronz_mpc wrote: Hi, Dimitris Apostolou,    Welcome to participate in mpc ! We start mpc this week and need more participants. we may send you a mail when it's you turn. -   you can also contact with telegram more conveniently, https://t.me/joinchat/HF9ZSxTgHaW_0V1o_CCu8Q, username is @TronZTron . +   you can also contact with telegram more conveniently, https://t.me/joinchat/HF9ZSxTgHaW_0V1o_CCu8Q, username is @TronZTron.    Thanks for your support. Your sincerely， Tronz Team diff --git a/docs_without_index/mpc/008/report.asc b/docs_without_index/mpc/008/report.asc index d21d3579..7dc693ed 100644 --- a/docs_without_index/mpc/008/report.asc +++ b/docs_without_index/mpc/008/report.asc @@ -1,5 +1,5 @@ From: jiangyuanshu -Subject: Re: invite to participate in Tron MainNet MPC +Subject: Re: invite to participate in TRON MainNet MPC Date: 2020/01/12 at 11:52:13 GMT+8 To: Bruno Campos @@ -70,7 +70,7 @@ Tronz Team From: Bruno Campos Sent: Thursday, January 2 2020, 10:17 pm To: tronz_mpc -Subject: Re: invite to participate in Tron MainNet MPC +Subject: Re: invite to participate in TRON MainNet MPC Yep! I want to participate. Thanks for the invite.   @@ -87,7 +87,7 @@ This e-mail message may contain confidential or legally privileged information a   On Tue, Dec 31, 2019 at 6:34 AM tronz_mpc wrote: Dear Bruno Campos， -   Do you still want to participate in Tron MainNet MPC ? If you want to join in, please tell us your free time between 2020-01-01 and 2020-01-14, it takes about 2~3 hours. +   Do you still want to participate in TRON MainNet MPC ? If you want to join in, please tell us your free time between 2020-01-01 and 2020-01-14, it takes about 2~3 hours.    See more detail on https://github.com/tronprotocol/mpc.     Thank you for your attention.   diff --git a/docs_without_index/mpc/011/report.asc b/docs_without_index/mpc/011/report.asc index 3ee1ffe2..c0d670a4 100644 --- a/docs_without_index/mpc/011/report.asc +++ b/docs_without_index/mpc/011/report.asc @@ -1,4 +1,4 @@ -From: tron +From: TRON Subject: Re: apply for the MPC of TRONZ Date: January 22, 2020 at 5:21:54 PM GMT+8 To: sun @@ -39,7 +39,7 @@ Tronz Team -----Original message----- -On Jan 22, 2020, at 3:04 PM, tron wrote: +On Jan 22, 2020, at 3:04 PM, TRON wrote: Hi, sun, @@ -54,7 +54,7 @@ TRONZ TEAM On Jan 22, 2020, at 2:50 PM, sun wrote: Hi, dev team: -    I am a cryptocurrency lover and I am interested in the anonymous transactions. The Tron has achieved great success and I want to be a member that can witness the historic moment TRONZ is implemented as an anonymous coin in the Tron public chain. +    I am a cryptocurrency lover and I am interested in the anonymous transactions. The TRON has achieved great success and I want to be a member that can witness the historic moment TRONZ is implemented as an anonymous coin in the TRON public chain.     I am a programmer and have written many codes about distributed systems. It is my honor that I can participate in the MPC.      Best regards! diff --git a/docs_without_index/mpc/060/report.asc b/docs_without_index/mpc/060/report.asc index 100fb145..73a1035d 100644 --- a/docs_without_index/mpc/060/report.asc +++ b/docs_without_index/mpc/060/report.asc @@ -52,7 +52,7 @@ On Feb 7, 2020, at 2:51 PM, Xuguo Wang wrote: Hi Tronz, - I'm Slogen , applying to participate in the MPC project. My available time is 2020-02-07 ~ 2020-02-22, 08:00~10:00, UTC+8. As a android developer, Blockchain Developer of Tron community, I'm living in Beijing China now, focusing on Blockchain technology. + I'm Slogen , applying to participate in the MPC project. My available time is 2020-02-07 ~ 2020-02-22, 08:00~10:00, UTC+8. As a android developer, Blockchain Developer of TRON community, I'm living in Beijing China now, focusing on Blockchain technology. Yours Faithfully, Slogan.Wang diff --git a/docs_without_index/mpc/071/report.asc b/docs_without_index/mpc/071/report.asc index 59bac085..4d2df945 100644 --- a/docs_without_index/mpc/071/report.asc +++ b/docs_without_index/mpc/071/report.asc @@ -45,7 +45,7 @@ Tronz Team On 2020/2/6, at 05:16, Krazy Kewl wrote: -Good day my name is Bruce and currently run a tron project named KrazyKewlGamezToken and would like to participate in the MPC! +Good day my name is Bruce and currently run a TRON project named KrazyKewlGamezToken and would like to participate in the MPC! Thank you  KrazyKewl Bruce  diff --git a/docs_without_index/mpc/076/report.asc b/docs_without_index/mpc/076/report.asc index a5dd11ac..b57124fa 100644 --- a/docs_without_index/mpc/076/report.asc +++ b/docs_without_index/mpc/076/report.asc @@ -1,5 +1,5 @@ From: tronz_mpc -Subject: Re: Joining Tron MPC project +Subject: Re: Joining TRON MPC project Date: 2020/02/22 at 10:03:23 GMT+8 To: Denis Pitcher @@ -33,7 +33,7 @@ Sent from my mobile From: tronz_mpc Sent: February 21, 2020 11:02 AM To: Denis Pitcher -Subject: Re: Joining Tron MPC project +Subject: Re: Joining TRON MPC project   Hi, Denis，      Welcome to be the 76th participant in the MPC project, and your params file is https://mpcfilepub.s3.amazonaws.com/mpc/076/params with md5sum a10ffbe359a755a3aa447141792e126a. This link will be invalid after 24 hours from now on.  @@ -56,7 +56,7 @@ Sent from my mobile From: tronz_mpc Sent: Friday, February 21, 2020 2:45:59 AM To: Denis Pitcher -Subject: Re: Joining Tron MPC project +Subject: Re: Joining TRON MPC project   Hi，Denis Petcher,          @@ -85,7 +85,7 @@ Sent from my mobile From: tronz_mpc Sent: February 19, 2020 3:25 AM To: Denis Pitcher -Subject: Re: Joining Tron MPC project +Subject: Re: Joining TRON MPC project   Hi, Denis Pitcher,    diff --git a/docs_without_index/plugin/event-query-http.md b/docs_without_index/plugin/event-query-http.md index d97c54e7..b4cab54c 100644 --- a/docs_without_index/plugin/event-query-http.md +++ b/docs_without_index/plugin/event-query-http.md @@ -1,4 +1,4 @@ -# Tron Event Query Service +# TRON Event Query Service ## What is the main HTTP service? baseUrl: https://api.tronex.io diff --git a/docs_without_index/tron-mpc-testnet/001/report.asc b/docs_without_index/tron-mpc-testnet/001/report.asc index 9b087663..b352304b 100644 --- a/docs_without_index/tron-mpc-testnet/001/report.asc +++ b/docs_without_index/tron-mpc-testnet/001/report.asc @@ -35,7 +35,7 @@ tron foundation Hi -I am Tron SR CryptoGuyInZA and will participate in TRON-mpc test. +I am TRON SR CryptoGuyInZA and will participate in TRON-mpc test. Please advise way forward. diff --git a/mkdocs.yml b/mkdocs.yml index 7a882bbe..ff79eac2 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,12 +1,12 @@ -site_name: Java Tron +site_name: java-tron site_url: https://tronprotocol.github.io/documentation-en/ repo_url: https://github.com/tronprotocol/documentation-en nav: - Getting Started: - - Getting Started with Java-tron: getting_started/getting_started_with_javatron.md - - Using Java-tron: - - Deploying Java-tron: using_javatron/installing_javatron.md + - Getting Started with java-tron: getting_started/getting_started_with_javatron.md + - Using java-tron: + - Deploying java-tron: using_javatron/installing_javatron.md - Backup & Restore: using_javatron/backup_restore.md - Lite FullNode: developers/litefullnode.md - Private Network: using_javatron/private_network.md @@ -27,7 +27,7 @@ nav: - System Contract: mechanism-algorithm/system-contracts.md - Decentralized Exchange: mechanism-algorithm/dex.md - Multi-Signature: mechanism-algorithm/multi-signatures.md - - For Java-tron Developers: + - For java-tron Developers: - Developer Guide: developers/java-tron.md - TIPs Workflow: developers/tips.md - Issue Workflow: developers/issue-workflow.md