TRON
The TRON Protocol, one of the largest blockchain-based operating systems in the
world, offers public blockchain support of high throughput, high scalability, and high availability for
all Decentralized Applications (DApps) in the TRON ecosystem
Progression from inception of project
- The TRON Foundation was established in July 2017 in Singapore.
- In December 2017, TRON had launched its open source protocol. The Testnet, Blockchain Explorer, and Web Wallet were all launched by March 2018.
- TRON Mainnet launched shortly afterward in May 2018, marking the Odyssey 2.0 release as a technical milestone.
- In June 2018, TRON declared its independence with the creation of the Genesis block, along with the July 2018 acquisition of BitTorrent.
- In October 2018, TRON launched the TRON Virtual Machine (TVM), a complete developers’ toolset, and 360 support system. The TRON roadmap involves combining BitTorrent’s 100 million users with the TRON network via Project Atlas, as well as fostering the developer community to launch exciting new DApps on the TRON network.
Architecture
💡 The Following article is by the founder of the TRON himself so have a look at it ,The TRON Blockchain's Technical Architecture | Gemini
💡 The below link is for the architecture of tron (official PDF)TRON adopts a 3-layer architecture divided into Storage Layer, Core Layer, and Application Layer.
The TRON protocol adheres to Google Protobuf, which intrinsically supports multi-language
extension
Diagram of 3 layer architecture of Tron
3-layers
Core Layer
There are several modules in the core layer, including smart contracts, account management, and
consensus. A stack-based virtual machine is implemented on TRON and an optimized instruction
set is used. In order to better support DApp developers, Solidity was chosen as the smart contract
language, followed by future support of other advanced languages. In addition, TRON's consensus
mechanism is based on Delegated Proof of Stake (DPoS) and many innovations were made in
order to meet its unique requirements.
Storage Layer
TRON designed a unique distributed storage protocol consisting of Block Storage and State
Storage. The notion of a graph database was introduced into the design of the storage layer to
better meet the need for diversified data storage in the real world
- Blockchain Storage :- TRON blockchain storage chooses to use LevelDB, which is developed by Google and proven successful with many companies and projects. It has high performance and supports arbitrary byte arrays as both keys and values, singular get, put and delete, batched put and delete, bi-directional iterators, and simple compression using the very fast Snappy algorithm.
- State Storage :- TRON has a KhaosDB in the full-node memory that can store all the newly forked chains generated within a certain period of time and supports witnesses to switch from their own active chain swiftly into a new main chain. It can also protect blockchain storage by making it more stable from being terminating abnormally in an intermediate state.
Application Layer
Developers can create a diverse range of DApps and customized wallets on TRON. Since TRON
enables smart contracts to be deployed and executed, the opportunities of utility applications are unlimited.
Protocol
TRON protocol adheres to Google Protocol Buffers, which is a language-neutral, platform-neutral,
and extensible way of serializing structured data for use in communications protocols, data storage,
and more.
What are protocol Buffers ?
Protocol Buffers (Protobuf) is a flexible, efficient, automated mechanism for serializing structured
data, similar to JSON or XML, but much smaller, faster and simpler.
Protobuf (.proto) definitions can be used to generate code for C++, Java, C#, Python, Ruby,
Golang, and Objective-C languages through the official code generators. Various third-party
implementations are also available for many other languages. Protobuf eases development for
clients by unifying the API definitions and also optimizing data transfers. Clients can take the API
.proto from TRON’s protocol repository and integrate through the automatically-generated code
libraries.
As a comparison, Protocol Buffers is 3 to 10 times smaller and 20 to 100 times faster than XML,
with less ambiguous syntax. Protobuf generates data access classes that are easier to use
programmatically.
Decentralized Exchange (DEX)
The TRON network natively supports decentralized exchange functions. A decentralized exchange
consists of multiple trading pairs. A trading pair (notation “Exchange”) is an Exchange Market
between TRC-10 tokens, or between a TRC-10 token and TRX. Any account can create a trading
pair between any tokens, even if the same pair already exists on the TRON network. Trading and price fluctuations of the trading pairs follow the Bancor Protocol. The TRON network stipulates that the weights of the two tokens in all trading pairs are equal, so the ratio of their balances is the price between them.
Consensus
The Tron Uses DPoS
Delegated Proof of Stake (DPoS)
In PoS networks, token holders lock their token balances to become block
validators. The validators take turns proposing and voting on the next block. However, the problem
with standard PoS is that validator influence correlates directly to the amount of tokens locked up.
This results in parties hoarding large amounts of the network’s base currency wielding undue
influence in the network ecosystem.
The TRON consensus mechanism uses an innovative Delegated Proof of Stake system in which 27
Super Representatives (SRs) produce blocks for the network. Every 6 hours, TRX account holders
who freeze their accounts can vote for a selection of SR candidates, with the top 27 candidates
deemed the SRs. Voters may choose SRs based on criteria such as projects sponsored by SRs to increase TRX adoption, and rewards distributed to voters. This allows for a more democratized and decentralized ecosystem. SRs’ accounts are normal accounts, but their accumulation of votes
allows them to produce blocks. With the low throughput rates of Bitcoin and Ethereum due to their PoW consensus mechanism and scalability issues, TRON’s DPoS system offers an innovative mechanism resulting in 2000 TPS compared to Bitcoin’s 3 TPS and Ethereum’s 15 TPS.
The TRON protocol network generates one block every three seconds, with each block awarding 32
TRX to Super Representatives. A total of 336,384,000 TRX will be awarded annually to the 27 SRs.
Each time an SR finishes block production, rewards are sent to a sub-account in the super-ledger.
SRs can check, but not directly make use of these TRX tokens. A withdrawal can be made by each
SR once every 24 hours, transferring the rewards from the sub-account to the specified SR account.
For more details refer to this :-
The Basics of TRON's DPoS Consensus Algorithm
The three types of nodes on the TRON network are Witness Node, Full Node, and Solidity Node.
- Witness nodes are set up by SRs and are mainly responsible for block production and proposal creation/voting.
- Full nodes provide APIs and broadcast transactions and blocks.
- Solidity nodes sync blocks from other Full Nodes and also provide indexable APIs.
Account
Types
The three types of accounts in the TRON network are regular accounts, token accounts, and
contract accounts.
1.Regular accounts are used for standard transactions.
2.Token accounts are used for storing TRC-10 tokens.
3.Contract accounts are smart contract accounts created by regular accounts and can be triggered by regular accounts as well.
Creation
There are three ways to create a TRON account:
- Create a new account through API
- Transfer TRX into a new account address
- Transfer any TRC-10 token into a new account address
Structure
- account_name: the name for this account – e.g. BillsAccount.
- type: what type of this account is – e.g. 0 (stands for type ‘Normal’).
- balance: balance of this account – e.g. 4213312. 16
- vote: received votes on this account – e.g. {(“0x1b7w...9xj3”,323), (“0x8djq...j12m”,88),...,(“0x82nd...mx6i”,10001)}.
- asset: other assets expected TRX in this account – e.g. {<“WishToken”, 66666>, <”Dogie”, 233>}.
- latest_operation_time: the latest operation time of this account.
message Account {
message Vote {
bytes vote_address = 1;
int64 vote_count = 2;
}
bytes accout_name = 1;
AccountType type = 2;
bytes address = 3;
int64 balance = 4;
repeated Vote votes = 5;
map<string, int64> asset = 6;
int64 latest_operation_time = 10;
}
enum AccountType {
Normal = 0;
AssetIssue = 1;
Contract = 2;
}
Block
A block typically contains a block header and several transactions.
message Block {
BlockHeader block_header = 1;
repeated Transaction transactions = 2;
}
Block Header
Raw data is denoted as raw_data in Protobuf. It contains the raw data of a message,containing 6 parameters:
- timestamp: timestamp of this message – e.g. 1543884429000.
- txTrieRoot: the Merkle Tree’s Root – e.g. 7dacsa...3ed.
- parentHash: the hash of the last block – e.g. 7dacsa...3ed.
- number: the block height – e.g. 4638708.
- version: reserved – e.g. 5.
- witness_address: the address of the witness packed in this block – e.g. 41928c...4d21.
message BlockHeader {
message raw {
int64 timestamp = 1;
bytes txTrieRoot = 2;
bytes parentHash = 3;
uint64 number = 4;
uint64 version = 5;
bytes witness_address = 6;
}
bytes witness_signature = 2
;
bytes blockID = 3;
}
💡 Witness signature is denoted as witness_signature in Protobuf, which is the signature for this block header from the witness node.
💡 Block ID is denoted as blockID in Protobuf. It contains the atomic identification of a block. A Block
ID contains 2 parameters:
hash: the hash of block.
number: the hash and height of the block.
Transactions
Signing :-
TRON’s transaction signing process follows a standard ECDSA cryptographic algorithm, with a SECP256K1 selection curve. A private key is a random number, and the public key is a point on the elliptic curve. The public key generation process consists of first generating a random number as a
private key, and then multiplying the base point of the elliptic curve by the private key to obtain the public key. When a transaction occurs, the transaction raw data is first converted into byte format.
The raw data then undergoes SHA-256 hashing. The private key corresponding to the contract
address then signs the result of the SHA256 hash. The signature result is then added to the transaction.
Bandwidth Model :-
Ordinary transactions only consume bandwidth points, but smart contract operations consume both
energy and bandwidth points. There are two types of bandwidth points available. Users can gain
bandwidth points from freezing TRX, while 5000 free bandwidth points are also available daily.
When a TRX transaction is broadcast, it is transmitted and stored in the form of a byte array over the network. Bandwidth Points consumed by one transaction = number of transaction bytes multiplied by bandwidth points rate. For example, if the byte array length of a transaction is 200,then the transaction consumes 200 bandwidth points. However, if a TRX or token transfer results in the target account being created, then only the bandwidth points consumed to create the account will be deducted, and additional bandwidth points will not be deducted. In an account creation scenario, the network will first consume the bandwidth points that the transaction initiator gained from freezing TRX. If this amount is insufficient, then the network consumes the transaction initiator’s TRX. In standard TRX transfer scenarios from one TRX account to another, the network first consumes the bandwidth points gained by the transaction initiator for freezing TRX. If that is insufficient, it then consumes from the free 5000 daily bandwidth points. If that is still not enough, then the network consumes the TRX of the transaction initiator. The amount is calculated by the number of bytes in the transaction multiplied by 10 SUN. Thus, for most TRX holders who may not necessarily freeze their TRX to participate in SR voting, the first step is automatically skipped (since TRX balance frozen = 0) and the 5000 daily free bandwidth powers the transaction.
For TRC-10 token transfers, the network first verifies whether the total free bandwidth points of the issued token asset are sufficient. If not, the bandwidth points obtained from freezing TRX are consumed. If there is still not enough bandwidth points, then it consumes the TRX of the transaction initiator.
TRON Virtual Machine (TVM)
The TVM is a lightweight, Turing complete virtual machine developed for TRON’s ecosystem. The
TVM connects seamlessly with the existing development ecosystem to provide millions of global
developers with a custom-built blockchain system that is efficient, convenient, stable, secure, and
scalable.
Cheers !!
Axat Bhardwaj
Blockchain Developer & Technologist
Top comments (1)
Honestly, I like how it works. This approach provides more opportunities not only for active crypto-businessmen, but also for those who participate in additional crypto-projects (for example, NFTs). I preferred to have a financial application in this system - nonbank.io/ As far as I understand from the updates, we will soon have the ability to synchronize with other networks.