Whitepaper de TRON

TRON Whitepaper v2.0

Автор Justin Sun · 2017

Introduction

Introduction

1.1 Vision

TRON is an ambitious project dedicated to the establishment of a truly decentralized Internet and its infrastructure. 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. The July 2018 acquisition of BitTorrent further cemented TRON’s leadership in pursuing a decentralized ecosystem.
1.2 Background

The introduction of Bitcoin in 2009 revolutionized society’s perception of the traditional financial system in the wake of the Great Recession (2007-2008). As centralized hedge funds and banks collapsed from speculation in opaque financial derivatives, blockchain technology provided a transparent universal ledger from which anybody could glean transaction information. The transactions were cryptographically secured using a Proof of Work (PoW) consensus mechanism, thus preventing double spend issues.

In late 2013, the Ethereum white paper proposed a network in which smart contracts and a Turing-complete Ethereum Virtual Machine (EVM) would allow developers to interact with the network through DApps. However, as transaction volumes in Bitcoin and Ethereum peaked in 2017, it was apparent from the low transaction throughput times and high transaction fees that cryptocurrencies like Bitcoin and Ethereum in their existing state were not scalable for widespread adoption. Thus, TRON was founded and envisioned as an innovative solution to these pressing scalability challenges.

TRON development roadmap phase 1 timeline from July 2017 to June 2018

1.3 History The TRON DAO 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 network1. 1 V1.0 is available at https://tron.network/static/doc/white_paper_v_1_0.pdf

TRON development roadmap phase 2 timeline from July 2018 to 2019

1.4 Terminology

Address/Wallet An address or wallet consisting of account credentials on the TRON network are generated by a key pair, which consists of a private key and a public key, the latter being derived from the former through an algorithm. The public key is usually used for session key encryption, signature verification, and encrypting data that could be decrypted by a corresponding private key.

ABI An application binary interface (ABI) is an interface between two binary program modules; usually one of these modules is a library or an operating system facility, and the other is a user run program.

API An application programming interface (API) is mainly used for user clients development. With API support, token issuance platforms can also be designed by developers themselves.

Asset In TRON's documents, asset is the same as token, which is also denoted as TRC-10 token.

Bandwidth Points (BP) To keep the network operating smoothly, TRON network transactions use BP as fuel. Each account gets 5000 free daily BP and more can be obtained by freezing TRX for BP. Both TRX and TRC-10 token transfers are normal transactions costing BP. Smart contract deployment and execution transactions consume both BP and Energy.

Block Blocks contain the digital records of transactions. A complete block consists of the magic number, block size, block header, transaction counter, and transaction data.

Block Reward Block production rewards are sent to a sub-account (address/wallet). Super Representatives can claim their rewards on Tronscan or through the API directly.

Block Header A block header is part of a block. TRON block headers contain the previous block’s hash, the Merkle root, timestamp, version, and witness address.

Cold Wallet Cold wallet, also known as offline wallet, keeps the private key completely disconnected from any network. Cold wallets are usually installed on "cold" devices (e.g. computers or mobile phones staying offline) to ensure the security of TRX private key.

DApp Decentralized Application is an App that operates without a centrally trusted party. An application that enables direct interaction/agreements/communication between end users and/or resources without a middleman.

gRPC gRPC (gRPC Remote Procedure Calls) is an open source remote procedure call (RPC) system 2 initially developed at Google. It uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as authentication, bidirectional streaming and flow control, blocking or nonblocking bindings, and cancellation and timeouts. It generates cross-platform client and server bindings for many languages. Most common usage scenarios include connecting services in microservices style architecture and connecting mobile devices, and browser clients to backend services.

Hot Wallet Hot wallet, also known as online wallet, allows user's private key to be used online, thus it could be susceptible to potential vulnerabilities or interception by malicious actors.

JDK Java Development Kit is the Java SDK used for Java applications. It is the core of Java development, comprising the Java application environment (JVM+Java class library) and Java tools.

KhaosDB 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. See 2.2.2 State Storage for more details.

LevelDB LevelDB was initially adopted with the primary goal to meet the requirements of fast R/W and rapid development. After launching the Mainnet, TRON upgraded its database to an entirely customized one catered to its very own needs. See 2.2.1 Blockchain Storage for more details.

Merkle Root A Merkle root is the hash of all hashes of all transactions included as part of a block in a blockchain network. See 3.1 Delegated Proof of Stake (DPoS) for more details. 2 https://en.wikipedia.org/wiki/GRPC

Public Testnet (Shasta) A version of the network running in a single-node configuration. Developers can connect and test features without worrying about the economic loss. Testnet tokens have no value and anyone can request more from the public faucet.

RPC
3 In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network), which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction.

Scalability Scalability is a feature of the TRON Protocol. It is the capability of a system, network, or process to handle a growing amount of work or its potential to be enlarged to accommodate that growth.

SUN SUN replaced drop as the smallest unit of TRX. 1 TRX = 1,000,000 SUN.

Throughput High throughput is a feature of TRON Mainnet. It is measured in Transactions Per Second (TPS), namely the maximum transaction capacity in one second.

Timestamp The approximate time of block production is recorded as Unix timestamp, which is the number of milliseconds that have elapsed since 00:00:00 01 Jan 1970 UTC.

TKC Token configuration.

TRC-10 A standard of crypto token on TRON platform. Certain rules and interfaces are required to follow when holding an initial coin offering on TRON blockchain.

TRX TRX stands for Tronix, which is the official cryptocurrency of TRON.

3 https://en.wikipedia.org/wiki/Remote_procedure_call

Introdução

1.1 Visão

TRON é um projeto ambicioso dedicado ao estabelecimento de uma Internet verdadeiramente descentralizada e sua infraestrutura. O protocolo TRON, um dos maiores sistemas operacionais baseados em blockchain do mundo, oferece suporte público blockchain de alto rendimento, alta escalabilidade e alta disponibilidade para todos os aplicativos descentralizados (DApps) no ecossistema TRON. A aquisição de julho de 2018 da O BitTorrent consolidou ainda mais a liderança de TRON na busca de um ecossistema descentralizado.
1.2 Antecedentes

A introdução de Bitcoin em 2009 revolucionou a percepção da sociedade sobre o mercado financeiro tradicional sistema na sequência da Grande Recessão (2007-2008). Como fundos de hedge e bancos centralizados entrou em colapso devido à especulação em derivativos financeiros opacos, a tecnologia blockchain forneceu um livro razão universal transparente do qual qualquer pessoa poderia obter informações sobre transações. O as transações foram protegidas criptograficamente usando um mecanismo de consenso de Prova de Trabalho (PoW), evitando assim problemas de gastos duplos.

No final de 2013, o white paper Ethereum propôs uma rede na qual smart contracts e um A Máquina Virtual Turing-complete Ethereum (EVM) permitiria aos desenvolvedores interagir com o rede através de DApps. No entanto, como os volumes de transações em Bitcoin e Ethereum atingiram o pico em 2017, ficou evidente pelos baixos tempos de processamento das transações e pelas altas taxas de transação que criptomoedas como Bitcoin e Ethereum em seu estado existente não eram escaláveis para uso generalizado adoção. Assim, TRON foi fundado e idealizado como uma solução inovadora para essas questões urgentes. desafios de escalabilidade.

TRON development roadmap phase 1 timeline from July 2017 to June 2018

1.3 História O TRON DAO foi estabelecido em julho de 2017 em Cingapura. Em dezembro de 2017, TRON tinha lançou seu protocolo de código aberto. O Testnet, Blockchain Explorer e Web Wallet foram todos lançada em março de 2018. TRON Mainnet foi lançada logo depois, em maio de 2018, marcando o Lançamento do Odyssey 2.0 como um marco técnico. Em junho de 2018, TRON declarou sua independência com a criação do bloco Genesis, juntamente com a aquisição do BitTorrent em julho de 2018. Em Outubro de 2018, TRON lançou a TRON Máquina Virtual (TVM), um conjunto completo de ferramentas para desenvolvedores, e sistema de suporte 360. O roteiro TRON envolve combinar os 100 milhões de usuários do BitTorrent com a rede TRON por meio do Project Atlas, além de incentivar a comunidade de desenvolvedores a lançar novos e emocionantes DApps na rede TRON1. 1 V1.0 está disponível em https://tron.network/static/doc/white_paper_v_1_0.pdf

1.4 Terminologia

Endereço/carteira Um endereço ou carteira que consiste em credenciais de conta na rede TRON é gerado por um par de chaves, que consiste em uma chave privada e uma chave pública, sendo esta última derivada da primeira através de um algoritmo. A chave pública é geralmente usada para criptografia de chave de sessão, assinatura verificação e criptografia de dados que poderiam ser descriptografados por uma chave privada correspondente.

ABI Uma interface binária de aplicativo (ABI) é uma interface entre dois módulos de programa binário; normalmente um desses módulos é uma biblioteca ou recurso do sistema operacional e o outro é uma execução do usuário programa.

API Uma interface de programação de aplicativos (API) é usada principalmente para desenvolvimento de clientes de usuários. Com API suporte, plataformas de emissão token também podem ser projetadas pelos próprios desenvolvedores.

Ativo Nos documentos de TRON, o ativo é igual a token, que também é indicado como TRC-10 token.

Pontos de largura de banda (BP) Para manter a rede operando sem problemas, as transações da rede TRON usam a BP como combustível. Cada conta recebe 5.000 BP diários gratuitos e mais podem ser obtidos congelando TRX para BP. TRX e TRC-10 token transferências são transações normais que custam BP. Implantação e execução de contratos inteligentes as transações consomem tanto BP quanto Energia.

Bloquear Os blocos contêm os registros digitais das transações. Um bloco completo consiste no número mágico, tamanho do bloco, cabeçalho do bloco, contador de transações e dados de transação.

Recompensa de bloco As recompensas de produção de blocos são enviadas para uma subconta (endereço/carteira). Superrepresentantes podem reivindicar suas recompensas no Tronscan ou diretamente através da API.

Cabeçalho do bloco Um cabeçalho de bloco faz parte de um bloco. Os cabeçalhos dos blocos TRON contêm o hash do bloco anterior, o Raiz Merkle, carimbo de data/hora, versão e endereço da testemunha.Carteira Fria A carteira fria, também conhecida como carteira offline, mantém a chave privada completamente desconectada de qualquer rede. As carteiras frias são geralmente instaladas em dispositivos "frios" (por exemplo, computadores ou telefones celulares). permanecer offline) para garantir a segurança da chave privada TRX.

DApp Aplicativo descentralizado é um aplicativo que opera sem uma parte centralmente confiável. Um aplicativo que permite interação/acordos/comunicação direta entre usuários finais e/ou recursos sem intermediário.

gRPC gRPC (gRPC Remote Procedure Calls) é um sistema de chamada de procedimento remoto (RPC) de código aberto 2 inicialmente desenvolvido no Google. Ele usa HTTP/2 para transporte, buffers de protocolo como interface linguagem de descrição e fornece recursos como autenticação, streaming bidirecional e fluxo controle, ligações bloqueadoras ou não bloqueadoras e cancelamento e tempos limite. Ele gera ligações de cliente e servidor de plataforma cruzada para vários idiomas. Cenários de uso mais comuns incluem a conexão de serviços em arquitetura estilo microsserviços e a conexão de dispositivos móveis, e clientes de navegador para serviços de back-end.

Carteira quente A carteira quente, também conhecida como carteira online, permite que a chave privada do usuário seja usada online, podendo assim ser suscetível a vulnerabilidades potenciais ou interceptação por atores mal-intencionados.

JDK Java Development Kit é o Java SDK usado para aplicativos Java. É o núcleo do Java desenvolvimento, compreendendo o ambiente de aplicação Java (biblioteca de classes JVM + Java) e Java ferramentas.

KhaosDB TRON possui um KhaosDB na memória do nó completo que pode armazenar todas as cadeias recém-bifurcadas geradas dentro de um determinado período de tempo e ajuda as testemunhas a mudar rapidamente de sua própria cadeia ativa em uma nova cadeia principal. Consulte 2.2.2 Armazenamento de estado para obter mais detalhes.

NívelDB O LevelDB foi inicialmente adotado com o objetivo principal de atender aos requisitos de R/W rápido e rápido desenvolvimento. Após lançar a Mainnet, TRON atualizou seu banco de dados para um totalmente customizado um atendia às suas próprias necessidades. Consulte 2.2.1 Armazenamento Blockchain para obter mais detalhes.

Raiz Merkel Uma raiz Merkle é o hash de todos os hashes de todas as transações incluídas como parte de um bloco em um blockchain rede. Consulte 3.1 Prova de participação delegada (DPoS) para obter mais detalhes. 2 https://en.wikipedia.org/wiki/GRPC

TRON development roadmap phase 2 timeline from July 2018 to 2019

Rede de teste pública (Shasta) Uma versão da rede executada em uma configuração de nó único. Os desenvolvedores podem se conectar e testar recursos sem se preocupar com a perda econômica. Testnet tokens não têm valor e qualquer um pode solicite mais da torneira pública.

RPC
3 Na computação distribuída, uma chamada de procedimento remoto (RPC) ocorre quando um programa de computador causa um procedimento (sub-rotina) para ser executado em um espaço de endereço diferente (geralmente em outro computador em uma rede compartilhada), que é codificada como se fosse uma chamada de procedimento normal (local), sem o programador codificando explicitamente os detalhes da interação remota.

Escalabilidade A escalabilidade é um recurso do protocolo TRON. É a capacidade de um sistema, rede ou processo de lidar com uma quantidade crescente de trabalho ou seu potencial será ampliado para acomodar esse crescimento.

SOL SUN substituiu drop como a menor unidade de TRX. 1 TRX = 1.000.000 SOL.

Taxa de transferência Alto rendimento é um recurso da TRON Mainnet. É medido em transações por segundo (TPS), ou seja, a capacidade máxima de transação em um segundo.

Carimbo de data e hora O tempo aproximado de produção do bloco é registrado como timestamp Unix, que é o número de milissegundos decorridos desde 00:00:00 de 01 de janeiro de 1970 UTC.

TKC Configuração de token.

TRC-10 Um padrão de criptografia token na plataforma TRON. Certas regras e interfaces devem ser seguidas ao realizar uma oferta inicial de moedas em TRON blockchain.

TRX TRX significa Tronix, que é a criptomoeda oficial de TRON.

3 https://en.wikipedia.org/wiki/Remote_procedure_call

Architecture

Architecture

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.

TRON three-layer architecture diagram showing Application Layer Core Layer and Storage Layer

Figure 1: TRON 3-layer Architecture

2.1 Core

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 4 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. 2.2 Storage

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. 2.2.1 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. 2.2.2 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. 2.3 Application

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. 4 Solidity official documentation: https://solidity.readthedocs.io/

2.4 Protocol

TRON protocol adheres to Google Protocol Buffers , which is a language-neutral, platform-neutral, 5 and extensible way of serializing structured data for use in communications protocols, data storage, and more. 2.4.1 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. 2.4.2 HTTP

TRON Protocol provides a RESTful HTTP API alternative to the Protobuf API. They share the same interface but the HTTP API can be readily used in javascript clients. 2.5 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.
2.6 Decentralized Exchange (DEX)

5 Google Protocol Buffers official documentation: https://developers.google.com/protocol-buffers/

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 6 the weights of the two tokens in all trading pairs are equal, so the ratio of their balances is the price between them. For example, consider a trading pair containing two tokens, ABC and DEF. ABC has a balance of 10 million and DEF has a balance of 1 million. Since their weights are equal, 10 ABC = 1 DEF. This means that the ratio of ABC to DEF is 10 ABC per DEF. 2.7 Implementation

The TRON blockchain code is implemented in Java and was originally a fork from EthereumJ.

6 Bancor Protocol official website: https://about.bancor.network/protocol/

Arquitetura

TRON adota uma arquitetura de 3 camadas dividida em camada de armazenamento, camada central e camada de aplicativo. O protocolo TRON segue o Google Protobuf, que oferece suporte intrínseco a vários idiomas extensão.

TRON three-layer architecture diagram showing Application Layer Core Layer and Storage Layer

Figura 1: TRON Arquitetura de 3 camadas

2.1 Núcleo

Existem vários módulos na camada principal, incluindo smart contracts, gerenciamento de contas e consenso. Uma máquina virtual baseada em pilha é implementada em TRON e uma instrução otimizada conjunto é usado. Para melhor oferecer suporte aos desenvolvedores de DApp, Solidity foi escolhido como smart contract 4 idioma, seguido de suporte futuro para outros idiomas avançados. Além disso, o consenso de TRON mecanismo é baseado em Prova de Participação Delegada (DPoS) e muitas inovações foram feitas em para atender aos seus requisitos exclusivos. 2.2 Armazenamento

TRON projetou um protocolo exclusivo de armazenamento distribuído que consiste em Block Storage e State Armazenamento. A noção de banco de dados gráfico foi introduzida no design da camada de armazenamento para atender melhor à necessidade de armazenamento diversificado de dados no mundo real. 2.2.1 Armazenamento Blockchain

TRON blockchain armazenamento opta por usar LevelDB, que é desenvolvido pelo Google e comprovado sucesso com muitas empresas e projetos. Possui alto desempenho e suporta bytes arbitrários matrizes como chaves e valores, obtenção, colocação e exclusão singular, colocação e exclusão em lote, bidirecional iteradores e compactação simples usando o algoritmo Snappy muito rápido. 2.2.2 Armazenamento de Estado

TRON possui um KhaosDB na memória do nó completo que pode armazenar todas as cadeias recém-bifurcadas geradas dentro de um determinado período de tempo e ajuda as testemunhas a mudar rapidamente de sua própria cadeia ativa em uma nova cadeia principal. Ele também pode proteger o armazenamento blockchain, tornando-o mais estável contra terminando anormalmente em um estado intermediário. 2.3 Aplicação

Os desenvolvedores podem criar uma grande variedade de DApps e carteiras personalizadas em TRON. Desde TRON permite que smart contracts sejam implantados e executados, as oportunidades de aplicativos utilitários são ilimitado. 4 Documentação oficial do Solidity: https://solidity.readthedocs.io/

2.4 Protocolo

O protocolo TRON adere aos Google Protocol Buffers , que é um protocolo neutro em termos de linguagem, plataforma e 5 e extensível de serializar dados estruturados para uso em protocolos de comunicação, armazenamento de dados, e muito mais. 2.4.1 Buffers de Protocolo

Protocol Buffers (Protobuf) é um mecanismo flexível, eficiente e automatizado para serializar dados estruturados. dados, semelhantes a JSON ou XML, mas muito menores, mais rápidos e mais simples.

As definições de protobuf (.proto) podem ser usadas para gerar código para C++, Java, C#, Python, Ruby, Linguagens Golang e Objective-C por meio dos geradores de código oficiais. Vários terceiros implementações também estão disponíveis para muitos outros idiomas. Protobuf facilita o desenvolvimento para clientes unificando as definições da API e também otimizando as transferências de dados. Os clientes podem usar a API .proto do repositório de protocolo de TRON e integrado por meio do código gerado automaticamente bibliotecas.

Como comparação, os buffers de protocolo são de 3 a 10 vezes menores e de 20 a 100 vezes mais rápidos que o XML, com sintaxe menos ambígua. Protobuf gera classes de acesso a dados mais fáceis de usar programaticamente. 2.4.2HTTP

TRON O protocolo fornece uma API RESTful HTTP alternativa à API Protobuf. Eles compartilham o mesmo interface, mas a API HTTP pode ser facilmente usada em clientes javascript. 2.5 TRON Máquina Virtual (TVM)

O TVM é uma máquina virtual Turing completa e leve desenvolvida para o ecossistema de TRON. O A TVM se conecta perfeitamente com o ecossistema de desenvolvimento existente para fornecer milhões de recursos globais desenvolvedores com um sistema blockchain personalizado que é eficiente, conveniente, estável, seguro e escalável.
2.6 Exchange Descentralizada (DEX)

5 Documentação oficial dos buffers de protocolo do Google: https://developers.google.com/protocol-buffers/A rede TRON oferece suporte nativo a funções de exchange descentralizadas. Uma exchange descentralizada consiste em vários pares de negociação. Um par de negociação (notação “Exchange”) é um mercado de câmbio entre TRC-10 tokens, ou entre um TRC-10 token e TRX. Qualquer conta pode criar uma negociação par entre quaisquer tokens, mesmo que o mesmo par já exista na rede TRON. Negociação e as flutuações de preços dos pares de negociação seguem o Protocolo Bancor. A rede TRON estipula que 6 os pesos dos dois tokens em todos os pares de negociação são iguais, então a proporção de seus saldos é o preço entre eles. Por exemplo, considere um par comercial contendo dois tokens, ABC e DEF. ABC tem um saldo de 10 milhões e o DEF tem um saldo de 1 milhão. Como seus pesos são iguais, 10 ABC = 1 DEF. Isso significa que a proporção de ABC para DEF é de 10 ABC por DEF. 2.7 Implementação

O código TRON blockchain é implementado em Java e era originalmente uma bifurcação de EthereumJ.

6 Site oficial do Protocolo Bancor: https://about.bancor.network/protocol/

Consensus

Consensus

3.1 Delegated Proof of Stake (DPoS)

The earliest consensus mechanism is the Proof of Work (PoW) consensus mechanism. This protocol is currently implemented in Bitcoin and Ethereum . In PoW systems, transactions 7 8 broadcast through the network are grouped together into nascent blocks for miner confirmation. The confirmation process involves hashing transactions using cryptographic hashing algorithms until a merkle root has been reached, creating a merkle tree:

Figure 2: 8 TRX transactions are hashed into the merkle root. This merkle root is then included in the block header, which is attached to the previously confirmed blocks to form a blockchain. This allows for easy and transparent tracking of transactions, timestamps, and other related information.

7 Bitcoin whitepaper: https://bitcoin.org/bitcoin.pdf 8 Ethereum whitepaper: https://github.com/ethereum/wiki/wiki/White-Paper

Cryptographic hashing algorithms are useful in network attack prevention because they possess several properties :
9

● Input/Output length size​ - The algorithm can pass in an input of any length in size, and outputs a fixed length hash value.
● Efficiency​ - The algorithm is relatively easy and fast to compute.
● Preimage resistance​ - For a given output ​z​, it is impossible to find any input ​x​ such that h(x) =​ ​z​. In other words, the hashing algorithm ​h(x)​ is a one-way function in which only the output can be found, given an input. The reverse is not possible.
● Collision resistance​ - It is computationally infeasible to find any pairs \(x_1 \neq x_2\) such that \(h(x_1) = h(x_2)\). In other words, the probability of finding two different inputs hashing to the same output is extremely low. This property also implies ​second preimage resistance​.
● Second preimage resistance​ - Given ​x​1​, and thus ​h(x​1​)​, it is computationally infeasible to find any ​x​2​ such that ​h(x​1​) = h(x​2​)​. While this property is similar to ​collision resistance​, the property differs in that it is saying an attacker with a given ​x​1​ will find it computationally infeasible to find any ​x​2​ hashing to the same output.
● Deterministic​ - maps each input to one and only one output. ● Avalanche effect​ - a small change in the input results in an entirely different output.

These properties give the cryptocurrency network its intrinsic value by ensuring attacks do not compromise the network. When miners confirm a block, they are rewarded tokens as a built-in incentive for network participation. However, as the global cryptocurrency market capitalization steadily increased, the miners became centralized and focused their computing resources on hoarding tokens as assets, rather than for network participation purposes. CPU miners gave way to GPUs, which in turn gave way to powerful ASICs. In one notable study, the total power consumption of Bitcoin mining has been estimated to be as high as 3 GW , comparable to Ireland’s 10 power consumption. This same study projected total power consumption to reach 8 GW in the near future.

To solve the energy waste issue, the Proof of Stake (PoS) consensus mechanism was proposed by many new networks. 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 9 PAAR, C., PELZL, J., ​Understanding Cryptography: A Textbook for Students and Practitioners​, 2010 ed. Springer-Verlag Berlin Heidelberg, 2010.
10 https://www.sciencedirect.com/science/article/pii/S2542435118301776

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.

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.

Consenso

3.1 Prova de Participação Delegada (DPoS)

O mecanismo de consenso mais antigo é o mecanismo de consenso Prova de Trabalho (PoW). Isto o protocolo está atualmente implementado em Bitcoin e Ethereum . Em sistemas PoW, as transações 7 8 transmitidos pela rede são agrupados em blocos nascentes para confirmação do minerador. O O processo de confirmação envolve hashing transações usando algoritmos criptográficos hashing até que um A raiz merkle foi alcançada, criando uma árvore merkle:

Figura 2: 8 transações TRX são hash inseridas na raiz merkle. Essa raiz merkle é então incluída no cabeçalho do bloco, que é anexado aos blocos previamente confirmados para formar um blockchain. Isso permite um rastreamento fácil e transparente de transações, carimbos de data/hora e outras informações relacionadas.

7 Bitcoin documento técnico: https://bitcoin.org/bitcoin.pdf 8 Ethereum documento técnico: https://github.com/ethereum/wiki/wiki/White-Paper

Algoritmos criptográficos hashing são úteis na prevenção de ataques à rede porque possuem várias propriedades:
9

● Tamanho do comprimento de entrada/saída - O algoritmo pode passar uma entrada de qualquer tamanho e gera um valor hash de comprimento fixo.
● Eficiência​ - O algoritmo é relativamente fácil e rápido de calcular.
● Resistência de pré-imagem​ - Para uma determinada saída z, é impossível encontrar qualquer entrada x tal que h(x) =​ z​. Em outras palavras, o algoritmo hashing h(x)​ é uma função unidirecional em que apenas o a saída pode ser encontrada, dada uma entrada. O inverso não é possível.
● Resistência à colisão​ - É computacionalmente inviável encontrar quaisquer pares ​x​1 ​≠ x​2​ ​tais que ​h(x​1​) =h(x​2​)​. Em outras palavras, a probabilidade de encontrar duas entradas diferentes hash na mesma a saída é extremamente baixa. Esta propriedade também implica segunda resistência de pré-imagem.
● Segunda resistência de pré-imagem​ - Dado ​x​1​, e portanto h(x​1​)​, é computacionalmente inviável encontre qualquer x2 tal que h(x​1​) = h(x​2​)​. Embora esta propriedade seja semelhante à resistência à colisão, o propriedade difere porque diz que um invasor com um determinado x1 irá encontrá-lo computacionalmente inviável encontrar qualquer ​x​2​ hashing para a mesma saída.
● Determinístico - mapeia cada entrada para uma e apenas uma saída. ● Efeito Avalanche​ - uma pequena alteração na entrada resulta em uma saída totalmente diferente.

Estas propriedades conferem à rede de criptomoedas o seu valor intrínseco, garantindo que os ataques não comprometer a rede. Quando os mineradores confirmam um bloqueio, eles são recompensados com tokens como um recurso integrado incentivo à participação na rede. No entanto, à medida que a capitalização do mercado global de criptomoedas aumentou constantemente, os mineiros tornaram-se centralizados e concentraram seus recursos de computação em acumular tokens como ativos, e não para fins de participação na rede. Os mineradores de CPU deram lugar a GPUs, que por sua vez deram lugar a poderosos ASICs. Em um estudo notável, o poder total o consumo de mineração Bitcoin foi estimado em até 3 GW, comparável ao da Irlanda 10 consumo de energia. Este mesmo estudo projetou que o consumo total de energia atingirá 8 GW no próximo futuro.

Para resolver a questão do desperdício de energia, o mecanismo de consenso Proof of Stake (PoS) foi proposto por muitas novas redes. Em redes PoS, os titulares de token bloqueiam seus saldos token para se tornarem bloqueados validators. Os validators se revezam propondo e votando no próximo bloco. No entanto, o problema com PoS padrão é que a influência de validator se correlaciona diretamente com a quantidade de tokens bloqueados. Isto resulta em partes que acumulam grandes quantidades da moeda base da rede e exercem indevidamente influência no ecossistema da rede.

O mecanismo de consenso TRON usa um sistema inovador de Prova de Participação Delegada no qual 27 Super Representantes (SRs) produzem blocos para a rede. A cada 6 horas, titulares de contas TRX que congelam suas contas podem votar em uma seleção de candidatos SR, com os 27 principais candidatos considerados os SRs. Os eleitores podem escolher RS com base em critérios como projetos patrocinados por RS para 9 PAAR, C., PELZL, J., Compreendendo a criptografia: um livro didático para estudantes e profissionais, 2010 ed. Springer-Verlag Berlim Heidelberg, 2010.
10 https://www.sciencedirect.com/science/article/pii/S2542435118301776aumentar a adoção do TRX e recompensas distribuídas aos eleitores. Isto permite um ambiente mais democratizado e ecossistema descentralizado. As contas dos SRs são contas normais, mas a sua acumulação de votos lhes permite produzir blocos. Com as baixas taxas de transferência de Bitcoin e Ethereum devido à sua Mecanismo de consenso PoW e problemas de escalabilidade, o sistema TRON de DPoS oferece um inovador mecanismo resultando em 2000 TPS em comparação com Bitcoin 3 TPS e Ethereum 15 TPS.

A rede do protocolo TRON gera um bloco a cada três segundos, com cada bloco concedendo 32 TRX para Super Representantes. Um total de 336.384.000 TRX serão concedidos anualmente aos 27 SRs. Cada vez que um SR termina a produção do bloco, as recompensas são enviadas para uma subconta no super-razão. Os SRs podem verificar, mas não fazer uso direto desses TRX tokens. Um saque pode ser feito por cada SR uma vez a cada 24 horas, transferindo as recompensas da subconta para o SR especificado conta.

Os três tipos de nós na rede TRON são Witness Node, Full Node e Solidity Node. Os nós testemunhas são configurados pelos SRs e são os principais responsáveis pela produção e proposta de blocos criação/votação. Nós completos fornecem APIs e transações e blocos de transmissão. Sincronização de nós de solidez blocos de outros Full Nodes e também fornecem APIs indexáveis.

Account

Account

4.1 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. 4.2 Creation

There are three ways to create a TRON account:

1. Create a new account through API 2. Transfer TRX into a new account address 3. Transfer any TRC-10 token into a new account address

An offline key-pair consisting of an address (public key) and a private key, and not recorded by the TRON network, can also be generated. The user address generation algorithm consists of generating a key-pair and then extracting the public key (64-byte byte array representing x, y coordinates). Hash the public key using the SHA3-256 function (the SHA3 protocol adopted is KECCAK-256) and extract the last 20 bytes of the result. Add 41 to the beginning of the byte array and ensure the initial address length is 21 bytes. Hash the address twice using SHA3-256 function and take the first 4 bytes as verification code. Add the verification code to the end of the initial address and obtain the address in base58check format through base58 encoding. An encoded Mainnet address begins with T and is 34 bytes in length. 4.3 Structure

The three different account types are Normal, AssetIssue, and Contract. An Account contains 7 parameters:

1. account_name​: the name for this account – e.g. BillsAccount.
2. type​: what type of this account is – e.g. 0 (stands for type ‘Normal’).
3. balance​: balance of this account – e.g. 4213312.

4. vote​: received votes on this account – e.g. {(“0x1b7w…9xj3”,323), (“0x8djq…j12m”,88),…,(“0x82nd…mx6i”,10001)}.
5. asset​: other assets expected TRX in this account – e.g. {<“WishToken”, 66666>, <”Dogie”, 233>}. 6. latest_operation_time​: the latest operation time of this account.

Protobuf data structure: 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​; }

Conta

4.1 Tipos

Os três tipos de contas na rede TRON são contas normais, contas token e contas contratuais.

1. Contas regulares são usadas para transações padrão.
2. Contas de token são usadas para armazenar TRC-10 tokens.
3. As contas de contrato são contas smart contract criadas por contas normais e podem ser acionado por contas regulares também. 4.2 Criação

Existem três maneiras de criar uma conta TRON:

1. Crie uma nova conta através da API 2. Transfira TRX para um novo endereço de conta 3. Transfira qualquer TRC-10 token para um novo endereço de conta

Um par de chaves off-line composto por um endereço (chave pública) e uma chave privada, e não registrado pelo TRON rede, também pode ser gerada. O algoritmo de geração de endereço de usuário consiste em gerando um par de chaves e depois extraindo a chave pública (matriz de bytes de 64 bytes representando x, y coordenadas). Faça hash da chave pública usando a função SHA3-256 (o protocolo SHA3 adotado é KECCAK-256) e extraia os últimos 20 bytes do resultado. Adicione 41 ao início da matriz de bytes e certifique-se de que o comprimento do endereço inicial seja de 21 bytes. Hash o endereço duas vezes usando a função SHA3-256 e pegue os primeiros 4 bytes como código de verificação. Adicione o código de verificação ao final do inicial endereço e obtenha o endereço no formato base58check por meio da codificação base58. Um codificado O endereço da rede principal começa com T e tem 34 bytes de comprimento. 4.3 Estrutura

Os três tipos de conta diferentes são Normal, AssetIssue e Contrato. Uma conta contém 7 parâmetros:

1. nome_da_conta​: o nome desta conta – por exemplo. Conta de contas.
2. tipo​: que tipo é esta conta – por ex. 0 (significa tipo ‘Normal’).
3. saldo​: saldo desta conta – por ex. 4213312.

Protobuf data structure: 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

Block

A block typically contains a block header and several transactions.

Protobuf data structure: message​ ​Block​ {
BlockHeader block_header = ​1​; ​repeated​ Transaction transactions = ​2​; } 5.1 Block Header

A block header contains ​raw_data​, ​witness_signature​, and ​blockID​.

Protobuf data structure: 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​;
} 5.1.1 Raw Data

Raw data is denoted as ​raw_data​ in Protobuf. It contains the raw data of a message, containing 6 parameters:

1. timestamp​: timestamp of this message – e.g. 1543884429000. 2. txTrieRoot​: the Merkle Tree’s Root – e.g. 7dacsa…3ed. 3. parentHash​: the hash of the last block – e.g. 7dacsa…3ed. 4. number​: the block height – e.g. 4638708. 5. version​: reserved – e​.g. 5.

Block header and Merkle tree structure showing how TRX transactions are hashed into the Merkle root

6. witness_address​: the address of the witness packed in this block – e.g. 41928c...4d21. 5.1.2 Witness Signature

Witness signature is denoted as ​witness_signature​ in Protobuf, which is the signature for this block header from the witness node. 5.1.3 Block ID

Block ID is denoted as ​blockID​ in Protobuf. It contains the atomic identification of a block. A Block ID contains 2 parameters: 1. hash​: the hash of block. 2. number​: the hash and height of the block. 5.2 Transaction 5.2.1 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.
5.2.2 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.

5.2.3 Fee

TRON network generally does not charge fees for most transactions, however, due to system restrictions and fairness, bandwidth usage and transactions do take in certain fees.

Fee charges are broken down into the following categories: 1. Normal transactions cost bandwidth points. Users can use the free daily bandwidth points (5000) or freeze TRX to obtain more. When bandwidth points are not enough, TRX will be used directly from the sending account. The TRX needed is the number of bytes * 10 SUN. 2. Smart contracts cost energy (Section 6) but will also need bandwidth points for the transaction to be broadcasted and confirmed. The bandwidth cost is the same as above. 3. All query transactions are free. It doesn’t cost energy or bandwidth.

TRON network also defines a set of fixed fees for the following transactions: 1. Creating a witness node: 9999 TRX 2. Issuing a TRC-10 token: 1024 TRX 3. Creating a new account: 0.1 TRX 4. Creating an exchange pair: 1024 TRX 5.2.4 Transaction as Proof of Stake (TaPoS)

TRON uses TaPoS to ensure the transactions all confirm the main blockchain, while making it difficult to forge counterfeit chains. In TaPoS, the networks require each transaction include part of the hash of a recent block header. This requirement prevents transactions from being replayed on forks not including the referenced block, and also signals the network that a particular user and their

stake are on a specific fork. This consensus mechanism protects the network against Denial of Service, 51%, selfish mining, and double spend attacks.
5.2.5 Transaction Confirmation

A transaction is included in a future block after being broadcast to the network. After 19 blocks are mined on TRON (including its own block), the transaction is confirmed. Each block is produced by one of the top 27 Super Representatives in a round robin fashion. Each block takes ~3 seconds to be mined on the blockchain. Time may slightly vary for each Super Representative due to network conditions and machine configurations. In general, a transaction is considered fully confirmed after ~1 minute. 5.2.6 Structure

Transaction APIs consist of the following functions: message​ ​Transaction​ { ​message​ ​Contract​ { ​enum​ ​ContractType​ { AccountCreateContract = ​0​; // Create account/wallet TransferContract = ​1​; // Transfer TRX TransferAssetContract = ​2​; // Transfer TRC10 token VoteWitnessContract = ​4​; // Vote for Super Representative (SR) WitnessCreateContract = ​5​; // Create a new SR account AssetIssueContract = ​6​; // Create a new TRC10 token WitnessUpdateContract = ​8​; // Update SR information ParticipateAssetIssueContract = ​9​; // Purchase TRC10 token AccountUpdateContract = ​10​; // Update account/wallet information FreezeBalanceContract = ​11​; // Freeze TRX for bandwidth or energy UnfreezeBalanceContract = ​12​; // Unfreeze TRX WithdrawBalanceContract = ​13​; // Withdraw SR rewards, once per day UnfreezeAssetContract = ​14​; // Unfreeze TRC10 token UpdateAssetContract = ​15​; // Update a TRC10 token’s information ProposalCreateContract = ​16​; // Create a new network proposal by any SR ProposalApproveContract = ​17​; // SR votes yes for a network proposal ProposalDeleteContract = ​18​; // Delete a network proposal by owner CreateSmartContract = ​30​; // Deploy a new smart contract TriggerSmartContract = ​31​; // Call a function on a smart contract GetContract = ​32​; // Get an existing smart contract UpdateSettingContract = ​33​; // Update a smart contract’s parameters ExchangeCreateContract = ​41​; // Create a token trading pair on DEX ExchangeInjectContract = ​42​; // Inject funding into a trading pair

ExchangeWithdrawContract = ​43​; // Withdraw funding from a trading pair ExchangeTransactionContract = ​44​; // Perform token trading UpdateEnergyLimitContract = ​45​; // Update origin_energy_limit on a smart contract } } }

Bloco

Um bloco normalmente contém um cabeçalho de bloco e diversas transações.

Protobuf data structure: message​ ​Block​ {
BlockHeader block_header = ​1​; ​repeated​ Transaction transactions = ​2​; } 5.1 Cabeçalho do bloco

Um cabeçalho de bloco contém ​raw_data​, ​witness_signature​ e ​blockID​.

Protobuf data structure: 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​;
} 5.1.1 Dados Brutos

Os dados brutos são denotados como raw_data no Protobuf. Ele contém os dados brutos de uma mensagem, contendo 6 parâmetros:

1. timestamp​: timestamp desta mensagem – por ex. 1543884429000. 2. txTrieRoot​: a raiz da árvore Merkle – por exemplo. 7dacsa…3ed. 3. parentHash​: o hash do último bloco – por exemplo. 7dacsa…3ed. 4. número​: a altura do bloco – por ex. 4638708. 5. versão​: reservada – por exemplo. 5.

Block header and Merkle tree structure showing how TRX transactions are hashed into the Merkle root

6. testemunha_address​: o endereço da testemunha compactada neste bloco – por exemplo. 41928c...4d21. 5.1.2 Assinatura da Testemunha

A assinatura da testemunha é denotada como ​witness_signature​ no Protobuf, que é a assinatura para este cabeçalho do bloco do nó testemunha. 5.1.3 ID do bloco

Block ID é denotado como ​blockID​ no Protobuf. Ele contém a identificação atômica de um bloco. Um bloco O ID contém 2 parâmetros: 1. hash​: o hash do bloco. 2. número​: o hash e a altura do bloco. 5.2 Transação 5.2.1 Assinatura

O processo de assinatura da transação de TRON segue um algoritmo criptográfico ECDSA padrão, com um Curva de seleção SECP256K1. Uma chave privada é um número aleatório e a chave pública é um ponto na curva elíptica. O processo de geração de chave pública consiste em primeiro gerar um número aleatório como um chave privada e, em seguida, multiplicando o ponto base da curva elíptica pela chave privada para obter o chave pública. Quando ocorre uma transação, os dados brutos da transação são primeiro convertidos em formato de byte. Os dados brutos são então submetidos a SHA-256 hashing. A chave privada correspondente ao contrato address então assina o resultado do SHA256 hash. O resultado da assinatura é então adicionado ao transação.
5.2.2 Modelo de largura de banda

As transações comuns consomem apenas pontos de largura de banda, mas as operações smart contract consomem ambos pontos de energia e largura de banda. Existem dois tipos de pontos de largura de banda disponíveis. Os usuários podem ganhar pontos de largura de banda do congelamento do TRX, enquanto 5.000 pontos de largura de banda gratuitos também estão disponíveis diariamente.

Quando uma transação TRX é transmitida, ela é transmitida e armazenada na forma de uma matriz de bytes sobre a rede. Pontos de largura de banda consumidos por uma transação = número de bytes da transação multiplicado pela taxa de pontos de largura de banda. Por exemplo, se o comprimento da matriz de bytes de uma transação for 200, então a transação consome 200 pontos de largura de banda. No entanto, se uma transferência TRX ou token resultar em a conta de destino sendo criada, apenas os pontos de largura de banda consumidos para criar a conta serão deduzidos e pontos de largura de banda adicionais não serão deduzidos. Na criação de uma conta cenário, a rede consumirá primeiro os pontos de largura de banda que o iniciador da transação ganhoudo congelamento do TRX. Se esse valor for insuficiente, a rede consome a transação TRX do iniciador.

Em cenários padrão de transferência TRX de uma conta TRX para outra, a rede primeiro consome os pontos de largura de banda obtidos pelo iniciador da transação para congelar o TRX. Se isso for insuficiente, então consome dos 5.000 pontos de largura de banda diários gratuitos. Se isso ainda não for suficiente, então a rede consome o TRX do iniciador da transação. O valor é calculado pelo número de bytes em a transação multiplicada por 10 SUN. Assim, para a maioria dos detentores de TRX que podem não necessariamente congelar seu TRX para participar da votação SR, a primeira etapa é automaticamente ignorada (já que o saldo TRX frozen = 0) e a largura de banda gratuita diária de 5.000 alimenta a transação.

Para transferências TRC-10 token, a rede primeiro verifica se o total de pontos de largura de banda livre do ativo token emitido são suficientes. Caso contrário, os pontos de largura de banda obtidos com o congelamento do TRX são consumido. Se ainda não houver pontos de largura de banda suficientes, então consome o TRX da transação iniciador.

5.2.3 Taxa

A rede TRON geralmente não cobra taxas para a maioria das transações, entretanto, devido ao sistema restrições e justiça, uso de largura de banda e transações cobram certas taxas.

As taxas cobradas são divididas nas seguintes categorias: 1. As transações normais custam pontos de largura de banda. Os usuários podem usar os pontos de largura de banda diários gratuitos (5000) ou congele TRX para obter mais. Quando os pontos de largura de banda não forem suficientes, o TRX será usado diretamente da conta remetente. O TRX necessário é o número de bytes * 10 SUN. 2. Os contratos inteligentes custam energia (Seção 6), mas também precisarão de pontos de largura de banda para o transação a ser transmitida e confirmada. O custo da largura de banda é o mesmo acima. 3. Todas as transações de consulta são gratuitas. Não custa energia ou largura de banda.

A rede TRON também define um conjunto de taxas fixas para as seguintes transações: 1. Criando um nó testemunha: 9999 TRX 2. Emitindo um TRC-10 token: 1024 TRX 3. Criando uma nova conta: 0,1 TRX 4. Criando um par de troca: 1024 TRX 5.2.4 Transação como Prova de Participação (TaPoS)

TRON usa TaPoS para garantir que todas as transações confirmem o blockchain principal, ao mesmo tempo que o faz difícil forjar correntes falsificadas. No TaPoS, as redes exigem que cada transação inclua parte de o hash de um cabeçalho de bloco recente. Este requisito impede que as transações sejam reproduzidas em bifurcações não incluindo o bloco referenciado, e também sinaliza à rede que um determinado usuário e seusa aposta está em um fork específico. Este mecanismo de consenso protege a rede contra negação de Serviço, 51%, mineração egoísta e ataques de gasto duplo.
5.2.5 Confirmação de Transação

Uma transação é incluída em um bloco futuro após ser transmitida para a rede. Após 19 blocos serem minerado em TRON (incluindo seu próprio bloco), a transação é confirmada. Cada bloco é produzido por um dos 27 principais superrepresentantes em um estilo round robin. Cada bloco leva cerca de 3 segundos para ser extraído em blockchain. O tempo pode variar ligeiramente para cada Super Representante devido à rede condições e configurações da máquina. Em geral, uma transação é considerada totalmente confirmada após ~1 minuto. 5.2.6 Estrutura

Transaction APIs consist of the following functions: message​ ​Transaction​ { ​message​ ​Contract​ { ​enum​ ​ContractType​ { AccountCreateContract = ​0​; // Create account/wallet TransferContract = ​1​; // Transfer TRX TransferAssetContract = ​2​; // Transfer TRC10 token VoteWitnessContract = ​4​; // Vote for Super Representative (SR) WitnessCreateContract = ​5​; // Create a new SR account AssetIssueContract = ​6​; // Create a new TRC10 token WitnessUpdateContract = ​8​; // Update SR information ParticipateAssetIssueContract = ​9​; // Purchase TRC10 token AccountUpdateContract = ​10​; // Update account/wallet information FreezeBalanceContract = ​11​; // Freeze TRX for bandwidth or energy UnfreezeBalanceContract = ​12​; // Unfreeze TRX WithdrawBalanceContract = ​13​; // Withdraw SR rewards, once per day UnfreezeAssetContract = ​14​; // Unfreeze TRC10 token UpdateAssetContract = ​15​; // Update a TRC10 token’s information ProposalCreateContract = ​16​; // Create a new network proposal by any SR ProposalApproveContract = ​17​; // SR votes yes for a network proposal ProposalDeleteContract = ​18​; // Delete a network proposal by owner CreateSmartContract = ​30​; // Deploy a new smart contract TriggerSmartContract = ​31​; // Call a function on a smart contract GetContract = ​32​; // Get an existing smart contract UpdateSettingContract = ​33​; // Update a smart contract’s parameters ExchangeCreateContract = ​41​; // Create a token trading pair on DEX ExchangeInjectContract = ​42​; // Inject funding into a trading pair

ExchangeWithdrawContract = ​43​; // Withdraw funding from a trading pair ExchangeTransactionContract = ​44​; // Perform token trading UpdateEnergyLimitContract = ​45​; // Update origin_energy_limit on a smart contract } } }

TRON Virtual Machine

TRON Virtual Machine

6.1 Introduction

TRON Virtual Machine (TVM) is a lightweight, Turing complete virtual machine developed for the TRON's ecosystem. Its goal is to provide a custom-built blockchain system that is efficient, convenient, stable, secure and scalable.

TVM initially forked from EVM and can connect seamlessly with the existing solidity smart contract 11 development ecosystem. Based on that, TVM additionally supports DPoS consensus.

TVM employs the concept of Energy. Different from the Gas mechanism on EVM, operations of transactions and smart contracts on TVM are free, with no TRX consumed. Technically, executable computation capacity on TVM is not restricted by total holding amount of tokens. 6.2 Workflow

The compiler first translates the Solidity smart contract into bytecode readable and executable on the TVM. The TVM then processes data through opcode, which is equivalent to operating the logic of a stack-based finite state machine. Finally, the TVM accesses blockchain data and invokes External Data Interface through the Interoperation layer. 11 EVM: Ethereum Virtual Machine (https://github.com/ethereum/ethereumj)

TVM workflow showing compiler translating Solidity smart contracts into bytecode for execution on the TRON Virtual Machine

Figure 3: TVM Workflow

6.3 Performance 6.3.1 Lightweight Architecture

TVM adopts a lightweight architecture with the aim of reducing resource consumption to guarantee system performance. 6.3.2 Robust

TRX transfers and smart contract execution cost bandwidth points only, instead of TRX, which exempts TRON from being attacked. Bandwidth consumption is predictable and static since each computational step cost is fixed. 6.3.3 High Compatibility

TVM is compatible with EVM and will be compatible with more mainstream VMs in the future. Thereby, all smart contracts on EVM are executable on TVM. 6.3.4 Low Cost

Due to TVM’s bandwidth setup, development costs are reduced and developers can focus on the logic development of their contract code. TVM also offers all-in-one interfaces for contract deployment, triggering and viewing to offer the convenience for developers.

TRON Máquina Virtual

6.1 Introdução

TRON Máquina Virtual (TVM) é uma máquina virtual Turing completa e leve desenvolvida para o Ecossistema de TRON. Seu objetivo é fornecer um sistema blockchain personalizado que seja eficiente, conveniente, estável, seguro e escalável.

TVM inicialmente bifurcado de EVM e pode se conectar perfeitamente com a solidez existente smart contract 11 ecossistema de desenvolvimento. Com base nisso, o TVM também oferece suporte ao consenso DPoS.

A TVM emprega o conceito de Energia. Diferente do mecanismo de gás em EVM, as operações de transações e smart contracts no TVM são gratuitas, sem consumo de TRX. Tecnicamente, executável a capacidade de computação no TVM não é restrita pela quantidade total de tokens. 6.2 Fluxo de trabalho

O compilador primeiro traduz o Solidity smart contract em bytecode legível e executável em a TVM. O TVM então processa os dados através do opcode, o que equivale a operar a lógica de uma máquina de estados finitos baseada em pilha. Finalmente, o TVM acessa dados blockchain e invoca Interface de dados externos através da camada de interoperação. 11 EVM: Ethereum Máquina Virtual (https://github.com/ethereum/ethereumj)

TVM workflow showing compiler translating Solidity smart contracts into bytecode for execution on the TRON Virtual Machine

Figura 3: Fluxo de trabalho TVM

6.3 Desempenho 6.3.1 Arquitetura Leve

A TVM adota uma arquitetura leve com o objetivo de reduzir o consumo de recursos para garantir desempenho do sistema. 6.3.2 Robusto

As transferências de TRX e a execução de smart contract custam apenas pontos de largura de banda, em vez de TRX, que isenta TRON de ser atacado. O consumo de largura de banda é previsível e estático, pois cada o custo da etapa computacional é fixo. 6.3.3 Alta Compatibilidade

TVM é compatível com EVM e será compatível com VMs mais convencionais no futuro. Assim, todos os smart contracts em EVM são executáveis ​​no TVM. 6.3.4 Baixo Custo

Devido à configuração da largura de banda do TVM, os custos de desenvolvimento são reduzidos e os desenvolvedores podem se concentrar no desenvolvimento lógico de seu código de contrato. A TVM também oferece interfaces completas para contratos implantação, acionamento e visualização para oferecer conveniência aos desenvolvedores.

Smart Contract

Smart Contract

7.1 Introduction

A smart contract is a protocol that digitally verifies contract negotiation. They define the rules and penalties related to an agreement and also automatically enforce those obligations. The smart contract code facilitates, verifies, and enforces the negotiation or performance of an agreement or transaction. From a tokenization perspective, smart contracts also facilitate automatic funds transfers between participating parties should certain criteria be met.

TRON smart contracts are written in the Solidity language. Once written and tested, they can be compiled into bytecode, then deployed onto the TRON network for the TRON Virtual Machine. Once deployed, smart contracts can be queried via their contract addresses. The contract Application Binary Interface (ABI) shows the contract’s call functions and is used for interacting with the network. 7.2 Energy Model

The maximum energy limit for deploying and triggering a smart contract is a function of several variables:

● Dynamic energy from freezing 1 TRX is 50,000,000,000 (Total Energy Limit) / (Total Energy Weight) ● Energy limit is the daily account energy limit from freezing TRX ● Remaining daily account energy from freezing TRX is calculated as Energy Limit - Energy Used ● Fee limit in TRX is set in smart contract deploy/trigger call ● Remaining usable TRX in the account ● Energy per TRX if purchased directly (10 SUN = 1 Energy) = 100,000, SRs can vote on adjustment

There are two consumption scenarios to calculate for maximum energy limit for deployment and trigger. The logic can be expressed as follows:
const​ R = Dynamic Energy Limit const​ F = Daily account energy ​from​ freezing TRX const​ E = Remaining daily account energy ​from​ freezing TRX const​ L = Fee limit ​in​ TRX set ​in​ deploy/trigger call const​ T = Remaining usable TRX ​in​ account

const​ C = Energy per TRX ​if​ purchased directly

// Calculate M, defined as maximum energy limit for deployment/trigger of smart contract if​ F > LR let​ M = min(E+TC, LR) else let​ M = E+TC 7.3 Deployment

When a TRON solidity smart contract is compiled, the TRON Virtual Machine reads the compiled bytecode. The bytecode consists of a section for code deployment, contract code, and the Auxdata. The Auxdata is the source code’s cryptographic fingerprint, used for verification. The deployment bytecode runs the constructor function and sets up the initial storage variables. The deployment code also calculates the contract code and returns it to the TVM. The ABI is a JSON file that describes a TRON smart contract’s functions. This file defines the function names, their payability, the function return values, and their state mutability. 7.4 Trigger Function

Once the TRON smart contracts are deployed, their functions can be triggered individually either via TronStudio or through API calls. State-changing functions require Energy while read-only functions execute without Energy. 7.5 TRON Solidity

TRON Solidity is a fork from Ethereum’s Solidity language. TRON modifies the original project to support TRX and SUN units (1 TRX = 1,000,000 SUN). The rest of the language syntax is compatible with Solidity ^0.4.24. Thus the Tron Virtual Machine (TVM) is almost 100% compatible with EVM instructions.

Contrato Inteligente

7.1 Introdução

Um smart contract é um protocolo que verifica digitalmente a negociação de contratos. Eles definem as regras e penalidades relacionadas a um acordo e também aplicar automaticamente essas obrigações. O inteligente O código do contrato facilita, verifica e reforça a negociação ou execução de um acordo ou transação. De uma perspectiva de tokenização, smart contracts também facilitam fundos automáticos transferências entre as partes participantes caso determinados critérios sejam atendidos.

TRON smart contracts são escritos na linguagem Solidity. Uma vez escritos e testados, eles podem ser compilado em bytecode e então implantado na rede TRON para a máquina virtual TRON. Uma vez implantados, smart contracts podem ser consultados por meio de seus endereços de contrato. A aplicação do contrato Interface Binária (ABI) mostra as funções de chamada do contrato e é usada para interagir com o rede. 7.2 Modelo Energético

O limite máximo de energia para implantar e acionar um smart contract é uma função de vários variáveis:

● A energia dinâmica do congelamento de 1 TRX é 50.000.000.000 (Limite de Energia Total) / (Energia Total Peso) ● O limite de energia é o limite diário de energia da conta após o congelamento do TRX ● A energia restante da conta diária do congelamento do TRX é calculada como Limite de Energia - Energia Usado ● O limite de taxa no TRX é definido em smart contract implantar/acionar chamada ● TRX utilizável restante na conta ● Energia por TRX se comprada diretamente (10 SUN = 1 Energia) = 100.000, os SRs podem votar ajuste

Existem dois cenários de consumo para calcular o limite máximo de energia para implantação e gatilho. A lógica pode ser expressa da seguinte forma:
const​ R = Dynamic Energy Limit const​ F = Daily account energy ​from​ freezing TRX const​ E = Remaining daily account energy ​from​ freezing TRX const​ L = Fee limit ​in​ TRX set ​in​ deploy/trigger call const​ T = Remaining usable TRX ​in​ account

const​ C = Energy per TRX ​if​ purchased directly

// Calculate M, defined as maximum energy limit for deployment/trigger of smart contract if​ F > LR let​ M = min(E+TC, LR) else let​ M = E+TC 7.3 Implantação

Quando uma solidez TRON smart contract é compilada, a máquina virtual TRON lê o compilado bytecódigo. O bytecode consiste em uma seção para implantação de código, código de contrato e Auxdata. O Auxdata é a impressão digital criptográfica do código-fonte, usada para verificação. A implantação bytecode executa a função construtora e configura as variáveis de armazenamento iniciais. A implantação code também calcula o código do contrato e o retorna ao TVM. A ABI é um arquivo JSON que descreve as funções de TRON smart contract. Este arquivo define os nomes das funções, sua remuneração, os valores de retorno da função e sua mutabilidade de estado. 7.4 Função de disparo

Depois que os TRON smart contracts forem implantados, suas funções poderão ser acionadas individualmente por meio de TronStudio ou através de chamadas de API. Funções de mudança de estado requerem energia enquanto funções somente leitura executar sem energia. 7.5 TRON Solidez

TRON Solidity é um fork da linguagem Solidity de Ethereum. TRON modifica o projeto original para suporta unidades TRX e SUN (1 TRX = 1.000.000 SUN). O resto da sintaxe da linguagem é compatível com Solidity ^0.4.24. Assim, a Máquina Virtual Tron (TVM) é quase 100% compatível com instruções EVM.

Token

Token

8.1 TRC-10 Token

In the TRON network, each account can issue tokens at the expense of 1024 TRX. ​To issue tokens, the issuer needs to specify a token name, the total capitalization, the exchange rate to TRX, circulation duration, description, website, maximum bandwidth consumption per account, total bandwidth consumption, and the amount of token frozen. Each token issuance can also configure each account’s maximum daily token transfer Bandwidth Points, the entire network’s maximum daily token transfer Bandwidth Points, total token supply, locking duration in days, and the total amount of tokens locked. 8.2 TRC-20 Token

TRC-20 is a technical standard used for smart contracts implementing tokens supported by the TRON Virtual Machine. It is fully compatible with ERC-20.

The interface is as follows:
contract​ TRC20Interface { ​function​ ​totalSupply​() ​public​ ​constant​ ​returns​ (uint); ​function​ ​balanceOf​(address tokenOwner) ​public​ ​constant​ ​returns​ (uint balance); ​function​ ​allowance​(address tokenOwner, address spender) ​public​ ​constant returns​ (uint remaining); ​function​ ​transfer​(address to, uint tokens) ​public​ ​returns​ (bool success); ​function​ ​approve​(address spender, uint tokens) ​public​ ​returns​ (bool success); ​function​ ​transferFrom​(address from, address to, uint tokens) ​public returns​ (bool success);

​event​ ​Transfer​(address indexed from, address indexed to, uint tokens); 
​event​ ​Approval​(address indexed tokenOwner, address indexed spender, uint

tokens); }

From a developer’s perspective, there are several differences between TRC-10 and TRC-20. Some of the key differences are that TRC-10 tokens are accessible by APIs and smart contracts while TRC-20 tokens allow for interface customization but are only accessible within smart contracts.

From a cost perspective, TRC-10 tokens have transaction fees that are 1000 times lower than TRC-20, but carry bandwidth costs for API transfers and deposits. Transfers and deposits in smart contracts for TRC-10 tokens cost both bandwidth and energy.
8.3 Beyond

Since TRON uses the same Solidity version as Ethereum, more token standards could be readily ported to TRON.

Token

8.1 Token TRC-10

Na rede TRON, cada conta pode emitir tokens às custas de 1024 TRX. ​Para emitir tokens, o emissor precisa especificar um nome token, a capitalização total, a taxa de câmbio para TRX, duração da circulação, descrição, site, consumo máximo de largura de banda por conta, total consumo de largura de banda e a quantidade de token congelados. Cada emissão token também pode configurar o máximo diário de token pontos de largura de banda de transferência de cada conta, o máximo diário de toda a rede token pontos de largura de banda de transferência, fornecimento total de token, duração do bloqueio em dias e valor total de tokens bloqueados. 8.2 Token TRC-20

TRC-20 é um padrão técnico usado para smart contracts implementando tokens suportado pelo TRON Máquina Virtual. É totalmente compatível com ERC-20.

A interface é a seguinte:
contrato​ TRC20Interface { ​função​ ​totalSupply​() ​retornos constantes​ públicos​ (uint); ​função​ ​balanceOf​(endereço tokenOwner) ​public​ ​constantes​ ​retornos​ (uint equilíbrio); ​função​ ​subsídio​(endereço tokenProprietário, endereço gastador) ​public​ ​constante retorna​ (uint restante); transferência de função (endereço para, uint tokens) retornos públicos (bool sucesso); função aprovar (endereço gastador, uint tokens) retornos públicos (bool sucesso); ​função​ ​transferFrom​(endereço de, endereço para, uint tokens) ​public retorna​ (bool sucesso);

​event​ ​Transfer​(endereço indexado de, endereço indexado para, uint tokens); 
Aprovação do evento (endereço indexado tokenProprietário, endereço gastador indexado, uint

tokens); }

Do ponto de vista do desenvolvedor, existem várias diferenças entre o TRC-10 e o TRC-20. Alguns das principais diferenças é que TRC-10 tokens são acessíveis por APIs e smart contracts enquanto TRC-20 tokens permitem a personalização da interface, mas só são acessíveis dentro de smart contracts.

Do ponto de vista de custo, os TRC-10 tokens têm taxas de transação 1.000 vezes mais baixas do que TRC-20, mas acarreta custos de largura de banda para transferências e depósitos de API. Transferências e depósitos em smart os contratos para TRC-10 tokens custam largura de banda e energia.
8.3 Além

Como TRON usa a mesma versão do Solidity que Ethereum, mais padrões token poderiam ser prontamente portado para TRON.

Governance

Governance

9.1 Super Representative 9.1.1 General

Every account in the TRON network can apply and have the opportunity to become a Super Representative (denoted as SR). Everyone can vote for SR candidates. The top 27 candidates with the most votes will become SRs with the right and obligation to generate blocks. The votes are counted every 6 hours and the SRs will change accordingly.

To prevent malicious attacks, there is a cost to becoming an SR candidate. When applying, 9999 TRX will be burned from the applicant’s account. Once successful, such account can join the SR election. 9.1.2 Election

TRON Power (denoted as TP) is needed to vote and the amount of TP depends on the voter’s frozen assets (TRX).

TP is calculated in the following way:
TP 1 TRX frozen to get bandwidth 1 =

Every account in the TRON network has the right to vote for their own SRs.

After the release (unfreeze, available after 3 days), users won't have any frozen assets and lose all TP accordingly. As a result, all votes become invalid for the ongoing and future voting round unless TRX is frozen again to vote.

Note that the TRON network only records the most recent vote, which means that every new vote will negate all previous votes. 9.1.3 Reward a. Vote Reward

Also known as Candidate Reward, which the top 127 candidates updated once every round (6 hours) will share 115,200 TRX as mined. The reward will be split in accordance with the vote weight each candidate receives. Each year, the total reward for candidates will be 168,192,000 TRX. Total vote reward per round Why 115,200 TRX every round? 15, 00 TRX total vote reward per round (V R/round) 1 2 =
V R/round = 16 T RX/block × 20 blocks/min × 60 mins/hr × 6 hrs/round Notice: this is set by WITNESS_STANDBY_ALLOWANCE = 115,200 TRX. See dynamic network parameters. Total vote reward per year Why 168,192,000 TRX every year? 168, 192, 000 T RX = total vote reward per year (V R/year) V R/year = 115, 200 T RX/round × 4 rounds/day × 365 days/year b. Block Reward Also known as Super Representative Reward, which the top 27 candidates (SRs) who are elected every round (6 hours) will share roughly 230,400 TRX as mined. The reward will be split evenly between the 27 SRs (minus the total reward blocks missed due to network error). A total of 336,384,000 TRX will be awarded annually to the 27 SRs. Total block reward per round Why 230,400 TRX every round? 230, 400 T RX = total block reward per round (BR/round) BR/round = 32 T RX/bloc × 20 blocks/min × 60 mins/hr × 6 hrs/round Notice: the unit block reward is set by WITNESS_PAY_PER_BLOCK = 32 TRX. See dynamic network parameters. Total block reward per year Why 336,384,000 TRX every year? 336, 384, 000 T RX = total block reward per year (BR/year) BR/year = 230, 400 T RX/round × 4 rounds/day × 365 days/year January 1, 2021 There will be no inflation on the TRON network before January 1, 2021, and the TRON DAO will award all block rewards and candidate rewards prior to that date. c. Reward Calculation

SR reward calculation otal reward vote reward (V R) block reward (BR) t =
+

R total V R V =
×
total votes votes SR candidate received
R

block missed 2 B =
27 total BR − × 3
Note: the reward is calculated per SR per round (6 hours)

Rank 28 to rank 127 SR candidate reward calculation otal reward vote reward (V R) t =

R total V R V =
×
total votes votes SR candidate received
Note: the reward is calculated per SR candidate per round (6 hours) 9.2 Committee 9.2.1 General

The committee is used to modify TRON dynamic network parameters, such as block generation rewards, transaction fees, etc. The committee consists of the 27 SRs in the current round. Each SR has the right to propose and vote on proposals. When a proposal receives 19 votes or more, it is approved and the new network parameters will be applied in the next maintenance period (3 days). 9.2.2 Dynamic Network Parameters 0. MAINTENANCE_TIME_INTERVAL a. Description
Modify the maintenance interval time in ms. Known as the SR vote interval time per round.
b. Example [6 * 3600 * 1000] ms - which is 6 hours. c. Range [3 * 27* 1000, 24 * 3600 * 1000] ms 1. ACCOUNT_UPGRADE_COST a. Description Modify the cost of applying for SR account. b. Example [9,999,000,000] SUN - which is 9,999 TRX. c. Range [0,100 000 000 000 000 000] SUN 2. CREATE_ACCOUNT_FEE a. Description Modify the account creation fee.

b. Example [100,000] SUN - which is 1 TRX. c. Range [0,100 000 000 000 000 000] SUN 3. TRANSACTION_FEE a. Description Modify the amount of fee used to gain extra bandwidth. b. Example [10] SUN/byte. c. Range [0,100 000 000 000 000 000] SUN/byte 4. ASSET_ISSUE_FEE a. Description Modify asset issuance fee. b. Example [1024,000,000] SUN - which is 1024 TRX. c. Range [0,100 000 000 000 000 000] SUN 5. WITNESS_PAY_PER_BLOCK a. Description Modify SR block generation reward. Known as unit block reward. b. Example [32,000,000] SUN - which is 32 TRX. c. Range [0,100 000 000 000 000 000] SUN 6. WITNESS_STANDBY_ALLOWANCE a. Description Modify the rewards given to the top 127 SR candidates. Known as total vote reward per round. b. Example [115,200,000,000] SUN - which is 115,200 TRX. c. Range [0,100 000 000 000 000 000] SUN 7. CREATE_NEW_ACCOUNT_FEE_IN_SYSTEM_CONTRACT a. Description Modify the cost of account creation. Combine dynamic network parameters #8 to get total account creation cost:
REATE_NEW_ACCOUNT_FEE_IN_SY STEM_CONTRACT REATE_NEW_ACCOUNT_BANDWIDTH_RATE
C × C

b. Example [0] SUN. c. Range [0,100 000 000 000 000 000] SUN 8. CREATE_NEW_ACCOUNT_BANDWIDTH_RATE

a. Description Modify the cost of account creation. Combine dynamic network parameters #7 to get total account creation cost:
REATE_NEW_ACCOUNT_FEE_IN_SY STEM_CONTRACT REATE_NEW_ACCOUNT_BANDWIDTH_RATE
C × C

b. Example [1]. c. Range [0,100,000,000,000,000,000] 9. ALLOW_CREATION_OF_CONTRACTS a. Description To turn on Tron Virtual Machine (TVM). b. Example True - set to activate and effect since 10/10/2018 23:47 UTC. c. Range True/False 10. REMOVE_THE_POWER_OF_THE_GR a. Description Remove the initial GR genesis votes b. Example True - effected at 11/4/2018 08:46 UTC. c. Range True/False - Notice: cannot set back to False from True. 11. ENERGY_FEE a. Description Modify the fee of 1 energy. b. Example 20 SUN. c. Range [0,100 000 000 000 000 000] SUN 12. EXCHANGE_CREATE_FEE a. Description Modify the cost of trading pair creation. Known as the cost of creating a trade order. b. Example [1,024,000,000] SUN - which is 1024 TRX. c. Range [0,100 000 000 000 000 000] SUN 13. MAX_CPU_TIME_OF_ONE_TX a. Description Modify the maximum execution time of one transaction. Known as the timeout limit of one transaction. b. Example 50 ms. c. Range

[0, 1000] ms 14. ALLOW_UPDATE_ACCOUNT_NAME a. Description Modify the option to let an account update their account name.
b. Example False - which is available to propose from java-tron Odyssey v3.2. c. Range True/False - Notice: cannot set back to False from True. 15. ALLOW_SAME_TOKEN_NAME a. Description Modify the validation of allowing different token have a duplicate name.
b. Example False - which is available to propose from java-tron Odyssey v3.2. c. Range True/False - Notice: cannot set back to False from True. 16. ALLOW_DELEGATE_RESOURCE a. Description Modify the validation of allowing to issue token with a duplicate name, so the tokenID​ of the token, in long integer data type, would be the only atomic identification of a token.
b. Example False - which is available to propose from java-tron Odyssey v3.2. c. Range True/False - Notice: cannot set back to False from True. 17. TOTAL_ENERGY_LIMIT a. Description Modify the whole network total energy limit. b. Example [50,000,000,000,000,000] SUN - which is 50,000,000,000 TRX. c. Range [0,100,000,000,000,000,000] SUN 18. ALLOW_TVM_TRANSFER_TRC10 a. Description Allow TRC-10 token transfer within smart contracts. ALLOW_UPDATE_ACCOUNT_NAME, ALLOW_SAME_TOKEN_NAME, ALLOW_DELEGATE_RESOURCE proposals must all be approved before proposing this parameter change.
b. Example False - which is available to propose from java-tron Odyssey v3.2. c. Range True/False - Notice: cannot set back to False from True.

9.2.3 Create Proposal

Only the SR accounts have the rights to propose a change in dynamic network parameters. 9.2.4 Vote Proposal

Only committee members (SRs) can vote for a proposal and the member who does not vote in time will be considered as a disagree. The proposal is active for 3 days after it is created. The vote can be changed or retrieved during the 3-days voting window. Once the period ends, the proposal will either succeed (19+ votes) or fail (and end). 9.2.5 Cancel Proposal

The proposer can cancel the proposal before it becomes effective. 9.3 Structure

SRs are the witnesses of newly generated blocks. A witness contains 8 parameters:
1. address​: the address of this witness – e.g. 0xu82h…7237.
2. voteCount​: number of received votes on this witness – e.g. 234234.
3. pubKey​: the public key for this witness – e.g. 0xu82h…7237.
4. url​: the url for this witness – e.g. https://www.noonetrust.com.
5. totalProduced​: the number of blocks this witness produced – e.g. 2434.
6. totalMissed​: the number of blocks this witness missed – e.g. 7.
7. latestBlockNum​: the latest height of block – e.g. 4522. 8. isjobs​: a boolean flag.

Protobuf data structure: message​ ​Witness​{
​bytes​ address = ​1​;
​int64​ voteCount = ​2​;
​bytes​ pubKey = ​3​;
​string​ url = ​4​;
​int64​ totalProduced = ​5​;
​int64​ totalMissed = ​6​;
​int64​ latestBlockNum = ​7​; ​bool​ isJobs = ​8​; }

  1. DApp Development 10.1 APIs

The TRON network offers a wide selection of over 60+ HTTP API gateways for interacting with the network via Full and Solidity Nodes. Additionally, TronWeb is a comprehensive JavaScript library containing API functions that enable developers to deploy smart contracts, change the blockchain state, query blockchain and contract information, trade on the DEX, and much more. These API gateways can be directed towards a local privatenet, the Shasta testnet, or the TRON Mainnet.

10.2 Networks

TRON has both a Shasta testnet as well as a Mainnet. Developers may connect to the networks by deploying nodes, interacting via TronStudio, or using APIs via the TronGrid service. The TronGrid service consists of load balanced node clusters hosted on AWS servers worldwide. As DApp development scales up and API call volumes increase, TronGrid successfully fields the increase in API traffic.
10.3 Tools

TRON offers a suite of development tools for enabling developers to create innovative DApps.
TronBox is a framework that allows developers to test and deploy smart contracts via the TronWeb API. TronGrid is a load balanced and hosted API service that allows developers to access the TRON network without having to run their own node. TronGrid offers access to both the Shasta testnet as well as the TRON Mainnet. TronStudio is a comprehensive Integrated Development Environment (IDE) that enables developers to compile, deploy, and debug their Solidity smart contracts. TronStudio contains an internal full node that creates a private local environment for smart contract testing prior to deployment. The TronWeb API library connects developers to the network via a wide selection of HTTP API calls wrapped in JavaScript.
10.4 Resources

The TRON Developer Hub is a comprehensive API documentation site tailored towards 12 developers wishing to build on the TRON network. The Developer Hub provides a high-level conceptual understanding of TRON and walks users through the details of interacting with the 12 Developer Hub: https://developers.tron.network/

network. The guides walk developers through node setup, deployment and interaction with smart contracts, API interaction and implementation, building sample DApps, and using each of the developer tools. Additionally, developer community channels are available through Discord .
13

13 Discord: https://discordapp.com/invite/GsRgsTD

  1. Conclusion

TRON is a scalable blockchain solution that has employed innovative methods for tackling challenges faced by legacy blockchain networks. Having reached over 2M transactions per day, with over 700K TRX accounts, and surpassing 2000 TPS, TRON has enabled the community in creating a decentralized and democratized network.

Governança

9.1 Superrepresentante 9.1.1 Geral

Todas as contas da rede TRON podem se inscrever e ter a oportunidade de se tornar um Super Representante (denotado como SR). Todos podem votar em candidatos SR. Os 27 principais candidatos com os mais votados se tornarão SRs com direito e obrigação de gerar blocos. Os votos são contado a cada 6 horas e os SRs mudarão de acordo.

Para evitar ataques maliciosos, há um custo para se tornar um candidato à RS. Ao se inscrever, 9999 O TRX será eliminado da conta do requerente. Uma vez bem-sucedida, essa conta pode ingressar no SR eleição. 9.1.2 Eleição

TRON O poder (denotado como TP) é necessário para votar e a quantidade de TP depende do eleitor ativos congelados (TRX).

O TP é calculado da seguinte forma:
PT 1 TRX congelado para obter largura de banda 1 =

Cada conta na rede TRON tem o direito de votar em seus próprios SRs.

Após o lançamento (descongelamento, disponível após 3 dias), os usuários não terão nenhum ativo congelado e perderão todos TP em conformidade. Como resultado, todos os votos tornam-se inválidos para a ronda de votação em curso e futura, a menos que TRX está congelado novamente para votar.

Observe que a rede TRON registra apenas o voto mais recente, o que significa que cada novo voto anulará todos os votos anteriores. 9.1.3 Recompensa uma. Recompensa de voto

Também conhecido como Recompensa do Candidato, que os 127 melhores candidatos atualizam uma vez a cada rodada (6 horas) compartilhará 115.200 TRX extraídos. A recompensa será dividida de acordo com o peso dos votos cada candidato recebe. A cada ano, a recompensa total para os candidatos será de 168.192.000 TRX. Recompensa total de votos por rodada Por que 115.200 TRX a cada rodada? 15,00 TRX recompensa total de votos por rodada (V R/rodada) 1 2 =
V R/rodada = 16 T RX/bloco × 20 blocos/min × 60 minutos/h × 6 horas/rodada Aviso: isso é definido por WITNESS_STANDBY_ALLOWANCE = 115.200 TRX. Consulte parâmetros de rede dinâmica. Recompensa total de votos por ano Por que 168.192.000 TRX todos os anos? 168.192.000 T RX = recompensa total de votos por ano (V R/ano) V R/ano = 115.200 T RX/rodada × 4 rodadas/dia × 365 dias/ano b. Recompensa de bloco Também conhecida como Recompensa do Super Representante, que os 27 principais candidatos (SRs) eleitos cada rodada (6 horas) compartilhará cerca de 230.400 TRX extraídos. A recompensa será dividida igualmente entre os 27 SRs (menos o total de blocos de recompensa perdidos devido a erro de rede). Um total de 336.384.000 TRX serão concedidos anualmente aos 27 SRs. Recompensa total do bloco por rodada Por que 230.400 TRX a cada rodada? 230, 400 T RX = recompensa total do bloco por rodada (BR/rodada) BR/rodada = 32 T RX/bloco × 20 blocos/min × 60 minutos/h × 6 horas/rodada Aviso: a recompensa do bloco unitário é definida por WITNESS_PAY_PER_BLOCK = 32 TRX. Veja rede dinâmica parâmetros. Recompensa total do bloco por ano Por que 336.384.000 TRX todos os anos? 336.384.000 T RX = recompensa total do bloco por ano (BR/ano) BR/ano = 230.400 T RX/rodada × 4 rodadas/dia × 365 dias/ano 1º de janeiro de 2021 Não haverá inflação na rede TRON antes de 1º de janeiro de 2021, e TRON DAO conceder todas as recompensas em bloco e recompensas de candidatos antes dessa data. c. Cálculo de recompensa

Cálculo de recompensa SR recompensa total recompensa de voto (V R) recompensa de bloco (BR) t =
+

R VR total V =
×
total de votos votos que o candidato SR recebeu
R

bloco perdido 2 B =
27 BR total - × 3
Nota: a recompensa é calculada por SR por rodada (6 horas)

Cálculo de recompensa de candidato de classificação 28 a 127 SR recompensa total recompensa de voto (V R) t =

R VR total V =
×
total de votos votos que o candidato SR recebeu
Nota: a recompensa é calculada por candidato SR por rodada (6 horas) 9.2 Comitê 9.2.1 Geral

O comitê é usado para modificar parâmetros de rede dinâmicos TRON, como geração de blocos recompensas, taxas de transação, etc. O comitê é composto pelos 27 SRs da rodada atual. Cada RS tem o direito de propor e votar propostas. Quando uma proposta recebe 19 votos ou mais, é aprovado e os novos parâmetros de rede serão aplicados no próximo período de manutenção (3 dias). 9.2.2 Parâmetros de Rede Dinâmicos 0. MAINTENANCE_TIME_INTERVAL uma. Descrição
Modifique o tempo do intervalo de manutenção em ms. Conhecido como tempo de intervalo de votação SR por redondo.
b. Exemplo [6 * 3600 * 1000] ms - que é 6 horas. c. Alcance [3271000, 2436001000]ms 1. ACCOUNT_UPGRADE_COST uma. Descrição Modifique o custo de inscrição para uma conta SR. b. Exemplo [9.999.000.000] SUN – que é 9.999 TRX. c. Alcance [0,100 000 000 000 000 000] SOL 2. CREATE_ACCOUNT_FEE uma. Descrição Modifique a taxa de criação de conta.b. Exemplo [100.000] SOL - que é 1 TRX. c. Alcance [0,100 000 000 000 000 000] SOL 3. TRANSACTION_FEE uma. Descrição Modifique o valor da taxa usada para obter largura de banda extra. b. Exemplo [10] SOL/byte. c. Alcance [0,100 000 000 000 000 000] SOL/byte 4. ASSET_ISSUE_FEE uma. Descrição Modifique a taxa de emissão de ativos. b. Exemplo [1024.000.000] SOL - que é 1024 TRX. c. Alcance [0,100 000 000 000 000 000] SOL 5. WITNESS_PAY_PER_BLOCK uma. Descrição Modifique a recompensa de geração de bloco SR. Conhecida como recompensa de bloco unitário. b. Exemplo [32.000.000] SUN - que é 32 TRX. c. Alcance [0,100 000 000 000 000 000] SOL 6. WITNESS_STANDBY_ALLOWANCE uma. Descrição Modifique as recompensas dadas aos 127 principais candidatos SR. Conhecida como recompensa total de votos por rodada. b. Exemplo [115.200.000.000] SUN – que é 115.200 TRX. c. Alcance [0,100 000 000 000 000 000] SOL 7. CREATE_NEW_ACCOUNT_FEE_IN_SYSTEM_CONTRACT uma. Descrição Modifique o custo de criação de conta. Combine os parâmetros de rede dinâmica nº 8 para obter custo total de criação de conta:
REATE_NEW_ACCOUNT_FEE_IN_SY STEM_CONTRACT REATE_NEW_ACCOUNT_BANDWIDTH_RATE
C ×C

b. Exemplo [0] SOL. c. Alcance [0,100 000 000 000 000 000] SOL 8. CREATE_NEW_ACCOUNT_BANDWIDTH_RATE

uma. Descrição Modifique o custo de criação de conta. Combine os parâmetros de rede dinâmica nº 7 para obter custo total de criação de conta:
REATE_NEW_ACCOUNT_FEE_IN_SY STEM_CONTRACT REATE_NEW_ACCOUNT_BANDWIDTH_RATE
C ×C

b. Exemplo [1]. c. Alcance [0.100.000.000.000.000.000] 9. ALLOW_CREATION_OF_CONTRACTS uma. Descrição Para ativar a Máquina Virtual Tron (TVM). b. Exemplo Verdadeiro - definido para ativação e efeito desde 10/10/2018 23:47 UTC. c. Alcance Verdadeiro/Falso 10. REMOVE_THE_POWER_OF_THE_GR uma. Descrição Remova os votos iniciais do GR genesis b. Exemplo Verdadeiro - efetuado em 04/11/2018 08:46 UTC. c. Alcance Verdadeiro/Falso - Aviso: não é possível retornar de Verdadeiro para Falso. 11. ENERGY_FEE uma. Descrição Modifique a taxa de 1 energia. b. Exemplo 20 SOL. c. Alcance [0,100 000 000 000 000 000] SOL 12. EXCHANGE_CREATE_FEE uma. Descrição Modifique o custo de criação de pares de negociação. Conhecido como o custo de criação de uma ordem comercial. b. Exemplo [1.024.000.000] SOL - que é 1024 TRX. c. Alcance [0,100 000 000 000 000 000] SOL 13. MAX_CPU_TIME_OF_ONE_TX uma. Descrição Modifique o tempo máximo de execução de uma transação. Conhecido como limite de tempo limite de uma transação. b. Exemplo 50 ms. c. Alcance

[0, 1000] ms 14. ALLOW_UPDATE_ACCOUNT_NAME uma. Descrição Modifique a opção para permitir que uma conta atualize seu nome de conta.
b. Exemplo Falso - que está disponível para proposta no java-tron Odyssey v3.2. c. Alcance Verdadeiro/Falso - Aviso: não é possível retornar de Verdadeiro para Falso. 15.ALLOW_SAME_TOKEN_NAME uma. Descrição Modifique a validação para permitir que diferentes token tenham um nome duplicado.
b. Exemplo Falso - que está disponível para proposta no java-tron Odyssey v3.2. c. Alcance Verdadeiro/Falso - Aviso: não é possível retornar de Verdadeiro para Falso. 16. ALLOW_DELEGATE_RESOURCE uma. Descrição Modifique a validação para permitir a emissão de token com nome duplicado, para que o tokenID​ do token, no tipo de dados inteiro longo, seria o único atômico identificação de um token.
b. Exemplo Falso - que está disponível para proposta no java-tron Odyssey v3.2. c. Alcance Verdadeiro/Falso - Aviso: não é possível retornar de Verdadeiro para Falso. 17. TOTAL_ENERGY_LIMIT uma. Descrição Modifique todo o limite de energia total da rede. b. Exemplo [50.000.000.000.000.000] SOL - que é 50.000.000.000 TRX. c. Alcance [0.100.000.000.000.000.000] SOL 18. ALLOW_TVM_TRANSFER_TRC10 uma. Descrição Permitir transferência TRC-10 token dentro de smart contracts. ALLOW_UPDATE_ACCOUNT_NAME, ALLOW_SAME_TOKEN_NAME, Todas as propostas ALLOW_DELEGATE_RESOURCE devem ser aprovadas antes de serem propostas esta mudança de parâmetro.
b. Exemplo Falso - que está disponível para proposta no java-tron Odyssey v3.2. c. Alcance Verdadeiro/Falso - Aviso: não é possível retornar de Verdadeiro para Falso.9.2.3 Criar Proposta

Somente as contas SR têm o direito de propor uma alteração nos parâmetros dinâmicos da rede. 9.2.4 Proposta de Votação

Somente os membros do comitê (SRs) podem votar em uma proposta e o membro que não votar a tempo será considerado como discordo. A proposta fica ativa por 3 dias após ser criada. A votação pode ser alterado ou recuperado durante o período de votação de 3 dias. Terminado o período, a proposta será sucesso (mais de 19 votos) ou fracasso (e fim). 9.2.5 Cancelar Proposta

O proponente pode cancelar a proposta antes que ela entre em vigor. 9.3 Estrutura

SRs são as testemunhas dos blocos recém-gerados. Uma testemunha contém 8 parâmetros:
1. endereço​: o endereço desta testemunha – por ex. 0xu82h…7237.
2. voteCount​: número de votos recebidos nesta testemunha – por ex. 234234.
3. pubKey​: a chave pública desta testemunha – por exemplo. 0xu82h…7237.
4. url​: o URL desta testemunha – por ex. https://www.noonetrust.com.
5. totalProduzido​: o número de blocos que esta testemunha produziu – por exemplo. 2434.
6. totalMissed​: o número de blocos que esta testemunha perdeu – por exemplo. 7.
7. lastBlockNum​: a última altura do bloco – por exemplo. 4522. 8. isjobs​: um sinalizador booleano.

Estrutura de dados do protobuf: mensagem​ ​Testemunha​{
endereço de bytes = 1;
​int64​ contagem de votos = ​2​;
​bytes​ pubKey = ​3​;
string url=4;
​int64​ totalProduzido = ​5​;
​int64​ totalPerdidos = ​6​;
​int64​ últimoBlockNum = ​7​; bool isJobs = 8; }

  1. Desenvolvimento de DApps 10.1 APIs

A rede TRON oferece uma ampla seleção de mais de 60 gateways de API HTTP para interagir com o rede via Full e Solidity Nodes. Além disso, TronWeb é uma biblioteca JavaScript abrangente contendo funções de API que permitem aos desenvolvedores implantar smart contracts, altere o blockchain estado, consulta blockchain e informações de contrato, negociação no DEX e muito mais. Estas APIs os gateways podem ser direcionados para uma rede privada local, a rede de teste Shasta ou a rede principal TRON.

10.2 Redes

TRON possui uma rede de teste Shasta e também uma rede principal. Os desenvolvedores podem se conectar às redes por implantando nós, interagindo via TronStudio ou usando APIs por meio do serviço TronGrid. O TronGrid O serviço consiste em clusters de nós com balanceamento de carga hospedados em servidores AWS em todo o mundo. Como DApp o desenvolvimento aumenta e os volumes de chamadas de API aumentam, o TronGrid responde com sucesso ao aumento em Tráfego de API.
10.3 Ferramentas

TRON oferece um conjunto de ferramentas de desenvolvimento para permitir que os desenvolvedores criem DApps inovadores.
TronBox é uma estrutura que permite aos desenvolvedores testar e implantar smart contracts através do TronWeb API. TronGrid é um serviço de API hospedado e com balanceamento de carga que permite aos desenvolvedores acessar o TRON rede sem precisar executar seu próprio nó. TronGrid oferece acesso tanto ao Shasta testnet, bem como a rede principal TRON. TronStudio é um desenvolvimento integrado abrangente Ambiente (IDE) que permite aos desenvolvedores compilar, implantar e depurar seu Solidity smart contratos. TronStudio contém um nó completo interno que cria um ambiente local privado para smart contract testes antes da implantação. A biblioteca API TronWeb conecta desenvolvedores ao rede por meio de uma ampla seleção de chamadas de API HTTP agrupadas em JavaScript.
10.4 Recursos

O TRON Developer Hub é um site abrangente de documentação de API adaptado para 12 desenvolvedores que desejam desenvolver na rede TRON. O Developer Hub fornece um alto nível compreensão conceitual de TRON e orienta os usuários nos detalhes da interação com o 12 Centro do desenvolvedor: https://developers.tron.network/

rede. Os guias orientam os desenvolvedores na configuração, implantação e interação do nó com aplicativos inteligentes contratos, interação e implementação de API, construção de DApps de amostra e uso de cada um dos ferramentas para desenvolvedores. Além disso, os canais da comunidade de desenvolvedores estão disponíveis através do Discord.
13

13Discordância: https://discordapp.com/invite/GsRgsTD

  1. Conclusão

TRON é uma solução blockchain escalável que empregou métodos inovadores para lidar com desafios enfrentados pelas redes blockchain legadas. Tendo alcançado mais de 2 milhões de transações por dia, com mais de 700 mil contas TRX e ultrapassando 2.000 TPS, TRON permitiu à comunidade em criando uma rede descentralizada e democratizada.