Informe técnico de TRON

TRON Whitepaper v2.0

Por 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

Introducción

1.1 Visión

TRON es un ambicioso proyecto dedicado al establecimiento de una Internet verdaderamente descentralizada y su infraestructura. El protocolo TRON, uno de los sistemas operativos basados en blockchain más grandes del mundo. mundo, ofrece soporte público blockchain de alto rendimiento, alta escalabilidad y alta disponibilidad para todas las aplicaciones descentralizadas (DApps) en el ecosistema TRON. La adquisición en julio de 2018 de BitTorrent consolidó aún más el liderazgo de TRON en la búsqueda de un ecosistema descentralizado.
1.2 Antecedentes

La introducción de Bitcoin en 2009 revolucionó la percepción que tenía la sociedad sobre el sistema financiero tradicional. tras la Gran Recesión (2007-2008). Como fondos de cobertura y bancos centralizados colapsado por la especulación en derivados financieros opacos, la tecnología blockchain proporcionó una libro de contabilidad universal transparente del que cualquiera podría obtener información sobre transacciones. el las transacciones se aseguraron criptográficamente mediante un mecanismo de consenso de prueba de trabajo (PoW), evitando así problemas de doble gasto.

A finales de 2013, el documento técnico Ethereum propuso una red en la que smart contracts y un La máquina virtual Ethereum completa de Turing (EVM) permitiría a los desarrolladores interactuar con la red a través de DApps. Sin embargo, como los volúmenes de transacciones en Bitcoin y Ethereum alcanzaron su punto máximo en 2017, Era evidente por los bajos tiempos de procesamiento de las transacciones y las altas tarifas de transacción que Las criptomonedas como Bitcoin y Ethereum en su estado actual no eran escalables para uso generalizado. adopción. Por lo tanto, TRON fue fundada y concebida como una solución innovadora para estos apremiantes desafíos de escalabilidad.

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

1.3 Historia El TRON DAO se estableció en julio de 2017 en Singapur. En diciembre de 2017, TRON tuvo lanzó su protocolo de código abierto. Testnet, Blockchain Explorer y Web Wallet fueron todos lanzado en marzo de 2018. TRON Mainnet se lanzó poco después, en mayo de 2018, marcando el Lanzamiento de Odyssey 2.0 como un hito técnico. En junio de 2018, TRON declaró su independencia con la creación del bloque Génesis, junto con la adquisición de BitTorrent en julio de 2018. en En octubre de 2018, TRON lanzó la TRON Virtual Machine (TVM), un completo conjunto de herramientas para desarrolladores. y sistema de soporte 360. La hoja de ruta TRON implica combinar los 100 millones de usuarios de BitTorrent con la red TRON a través del Proyecto Atlas, además de fomentar que la comunidad de desarrolladores lance Nuevas y emocionantes DApps en la red TRON1. 1 V1.0 está disponible en https://tron.network/static/doc/white_paper_v_1_0.pdf

1.4 Terminología

Dirección/Monedero Una dirección o billetera que consta de credenciales de cuenta en la red TRON es generada por un par de claves, que consta de una clave privada y una clave pública, esta última derivada de la primera a través de un algoritmo. La clave pública se utiliza generalmente para el cifrado de la clave de sesión, la firma verificación y cifrado de datos que podrían descifrarse mediante la clave privada correspondiente.

ABI Una interfaz binaria de aplicación (ABI) es una interfaz entre dos módulos de programa binario; normalmente uno de estos módulos es una biblioteca o una instalación del sistema operativo, y el otro es una ejecución del usuario programa.

API Una interfaz de programación de aplicaciones (API) se utiliza principalmente para el desarrollo de clientes de usuarios. Con API soporte, token las plataformas de emisión también pueden ser diseñadas por los propios desarrolladores.

Activo En los documentos de TRON, el activo es el mismo que token, que también se indica como TRC-10 token.

Puntos de ancho de banda (BP) Para mantener la red funcionando sin problemas, las TRON transacciones de la red utilizan BP como combustible. cada cuenta obtiene 5000 BP diarios gratis y se puede obtener más congelando TRX para BP. Tanto TRX como TRC-10 Las transferencias token son transacciones normales que le cuestan a BP. Implementación y ejecución de contratos inteligentes Las transacciones consumen tanto BP como energía.

Bloquear Los bloques contienen los registros digitales de las transacciones. Un bloque completo consta del número mágico, tamaño de bloque, encabezado de bloque, contador de transacciones y datos de transacción.

Recompensa de bloque Las recompensas por producción de bloques se envían a una subcuenta (dirección/billetera). Los súper representantes pueden reclame sus recompensas en Tronscan o directamente a través de la API.

Encabezado de bloque Un encabezado de bloque es parte de un bloque. Los encabezados de bloque TRON contienen el hash del bloque anterior, el Raíz de Merkle, marca de tiempo, versión y dirección del testigo.Cartera fría La billetera fría, también conocida como billetera fuera de línea, mantiene la clave privada completamente desconectada de cualquier red. Las billeteras frías generalmente se instalan en dispositivos "fríos" (por ejemplo, computadoras o teléfonos móviles). permanecer fuera de línea) para garantizar la seguridad de la clave privada TRX.

DApp La aplicación descentralizada es una aplicación que funciona sin una parte de confianza central. una aplicacion que permite la interacción/acuerdos/comunicación directa entre usuarios finales y/o recursos sin intermediario.

gRPC gRPC (gRPC Remote Procedimiento Calls) es un sistema de llamada a procedimiento remoto (RPC) de código abierto 2 desarrollado inicialmente en Google. Utiliza HTTP/2 para el transporte, Protocol Buffers como interfaz lenguaje de descripción y proporciona funciones como autenticación, transmisión bidireccional y flujo control, vinculaciones bloqueantes o no bloqueantes, y cancelación y tiempos de espera. genera Enlaces de cliente y servidor multiplataforma para muchos idiomas. Escenarios de uso más comunes incluir servicios de conexión en arquitectura de estilo microservicios y conexión de dispositivos móviles, y clientes del navegador a servicios backend.

Cartera caliente La billetera activa, también conocida como billetera en línea, permite que la clave privada del usuario se use en línea, por lo que podría ser susceptible a posibles vulnerabilidades o interceptación por parte de actores maliciosos.

JDK Java Development Kit es el SDK de Java utilizado para aplicaciones Java. Es el núcleo de Java. desarrollo, que comprende el entorno de aplicaciones Java (biblioteca de clases JVM+Java) y Java herramientas.

CaosDB TRON tiene un KhaosDB en la memoria del nodo completo que puede almacenar todas las cadenas recién bifurcadas generadas dentro de un cierto período de tiempo y ayuda a los testigos a cambiar rápidamente de su propia cadena activa en una nueva cadena principal. Consulte 2.2.2 Almacenamiento estatal para obtener más detalles.

NivelDB LevelDB se adoptó inicialmente con el objetivo principal de cumplir con los requisitos de R/W rápido y rápido desarrollo. Después de lanzar Mainnet, TRON actualizó su base de datos a una totalmente personalizada uno atendía sus propias necesidades. Consulte 2.2.1 Almacenamiento Blockchain para obtener más detalles.

Raíz de Merkle Una raíz de Merkle es el hash de todos los hashes de todas las transacciones incluidas como parte de un bloque en un blockchain red. Consulte 3.1 Prueba de participación delegada (DPoS) para obtener más detalles. 2 https://en.wikipedia.org/wiki/GRPC

TRON development roadmap phase 2 timeline from July 2018 to 2019

Red de prueba pública (Shasta) Una versión de la red que se ejecuta en una configuración de un solo nodo. Los desarrolladores pueden conectarse y probar características sin preocuparse por la pérdida económica. Testnet tokens no tienen valor y cualquiera puede Solicite más al grifo público.

RPC
3 En la informática distribuida, una llamada a procedimiento remoto (RPC) es cuando un programa de computadora provoca una procedimiento (subrutina) para ejecutar en un espacio de direcciones diferente (comúnmente en otra computadora en una red compartida), que se codifica como si fuera una llamada a procedimiento normal (local), sin la programador que codifica explícitamente los detalles para la interacción remota.

Escalabilidad La escalabilidad es una característica del protocolo TRON. Es la capacidad de un sistema, red o proceso para manejar una cantidad creciente de trabajo o su potencial de ampliarse para dar cabida a ese crecimiento.

SOL SUN reemplazó a la gota como la unidad más pequeña de TRX. 1 TRX = 1.000.000 DOM.

Rendimiento El alto rendimiento es una característica de TRON Mainnet. Se mide en Transacciones Por Segundo (TPS), es decir, la capacidad máxima de transacción en un segundo.

Marca de tiempo El tiempo aproximado de producción del bloque se registra como marca de tiempo Unix, que es el número de milisegundos que han transcurrido desde las 00:00:00 01 de enero de 1970 UTC.

TKC Configuración de tokens.

CVR-10 Un estándar de criptografía token en la plataforma TRON. Es necesario seguir ciertas reglas e interfaces. al realizar una oferta inicial de monedas el TRON blockchain.

TRX TRX significa Tronix, que es la criptomoneda 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/

Arquitectura

TRON adopta una arquitectura de 3 capas dividida en capa de almacenamiento, capa central y capa de aplicación. El protocolo TRON se adhiere a Google Protobuf, que intrínsecamente admite varios idiomas. extensión.

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

Figura 1: TRON Arquitectura de 3 capas

2.1 Núcleo

Hay varios módulos en la capa central, incluidos smart contracts, administración de cuentas y consenso. Se implementa una máquina virtual basada en pila en TRON y una instrucción optimizada Se utiliza el conjunto. Para brindar un mejor soporte a los desarrolladores de DApp, se eligió Solidity como smart contract 4 idioma, seguido por el soporte futuro de otros idiomas avanzados. Además, el consenso de TRON El mecanismo se basa en la prueba de participación delegada (DPoS) y se realizaron muchas innovaciones en para cumplir con sus requisitos únicos. 2.2 Almacenamiento

TRON diseñó un protocolo de almacenamiento distribuido único que consta de almacenamiento en bloque y estado Almacenamiento. La noción de una base de datos gráfica se introdujo en el diseño de la capa de almacenamiento para satisfacer mejor la necesidad de almacenamiento de datos diversificado en el mundo real. 2.2.1 Almacenamiento de cadena de bloques

TRON blockchain el almacenamiento elige utilizar LevelDB, desarrollado por Google y probado éxito en muchas empresas y proyectos. Tiene un alto rendimiento y admite bytes arbitrarios. matrices como claves y valores, obtención, colocación y eliminación singulares, colocación y eliminación por lotes, bidireccional iteradores y compresión simple utilizando el algoritmo Snappy muy rápido. 2.2.2 Almacenamiento estatal

TRON tiene un KhaosDB en la memoria del nodo completo que puede almacenar todas las cadenas recién bifurcadas generadas dentro de un cierto período de tiempo y ayuda a los testigos a cambiar rápidamente de su propia cadena activa en una nueva cadena principal. También puede proteger el almacenamiento blockchain haciéndolo más estable frente a terminando anormalmente en un estado intermedio. 2.3 Aplicación

Los desarrolladores pueden crear una amplia gama de DApps y billeteras personalizadas en TRON. Desde TRON permite implementar y ejecutar smart contracts, las oportunidades de las aplicaciones de servicios públicos son ilimitado. 4 Documentación oficial de Solidez: https://solidity.readthedocs.io/

2.4 Protocolo

El protocolo TRON se adhiere a Google Protocol Buffers , que es un protocolo neutral en cuanto al idioma y a la plataforma. 5 y extensible de serializar datos estructurados para su uso en protocolos de comunicaciones, almacenamiento de datos, y más. 2.4.1 Búfers de protocolo

Protocol Buffers (Protobuf) es un mecanismo flexible, eficiente y automatizado para serializar archivos estructurados. datos, similar a JSON o XML, pero mucho más pequeño, más rápido y más simple.

Las definiciones de Protobuf (.proto) se pueden utilizar para generar código para C++, Java, C#, Python, Ruby, Lenguajes Golang y Objective-C a través de los generadores de código oficiales. Varios terceros Las implementaciones también están disponibles para muchos otros idiomas. Protobuf facilita el desarrollo de clientes unificando las definiciones de API y también optimizando las transferencias de datos. Los clientes pueden tomar la API .proto del repositorio de protocolos de TRON e integrarlo a través del código generado automáticamente bibliotecas.

En comparación, Protocol Buffers es de 3 a 10 veces más pequeño y de 20 a 100 veces más rápido que XML. con una sintaxis menos ambigua. Protobuf genera clases de acceso a datos que son más fáciles de usar programáticamente. 2.4.2HTTP

El protocolo TRON proporciona una API HTTP RESTful alternativa a la API de Protobuf. ellos comparten lo mismo interfaz, pero la API HTTP se puede utilizar fácilmente en clientes javascript. 2.5 TRON Máquina virtual (TVM)

TVM es una máquina virtual ligera y completa de Turing desarrollada para el ecosistema de TRON. el TVM se conecta perfectamente con el ecosistema de desarrollo existente para proporcionar millones de soluciones globales. desarrolladores con un sistema blockchain personalizado que es eficiente, conveniente, estable, seguro y escalable.
2.6 Intercambio descentralizado (DEX)

5 Documentación oficial de Google Protocol Buffers: https://developers.google.com/protocol-buffers/La red TRON admite de forma nativa funciones de intercambio descentralizadas. Un intercambio descentralizado consta de múltiples pares comerciales. Un par comercial (notación "Exchange") es un mercado cambiario entre TRC-10 tokens, o entre un TRC-10 token y TRX. Cualquier cuenta puede crear una cuenta comercial. par entre cualquier tokens, incluso si el mismo par ya existe en la red TRON. Comercio y Las fluctuaciones de precios de los pares comerciales siguen el Protocolo Bancor. La red TRON estipula que 6 los pesos de los dos tokens en todos los pares comerciales son iguales, por lo que la relación de sus saldos es el precio entre ellos. Por ejemplo, considere un par comercial que contiene dos token, ABC y DEF. ABC tiene un saldo de 10 millones y DEF tiene un saldo de 1 millón. Como sus pesos son iguales, 10 ABC = 1 DEF. Esto significa que la relación entre ABC y DEF es 10 ABC por DEF. 2.7 Implementación

El código TRON blockchain está implementado en Java y originalmente era una bifurcación de EthereumJ.

6 Sitio web oficial del Protocolo de 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 Prueba de participación delegada (DPoS)

El primer mecanismo de consenso es el mecanismo de consenso de prueba de trabajo (PoW). esto El protocolo está implementado actualmente en Bitcoin y Ethereum. En los sistemas PoW, las transacciones 7 8 transmitidos a través de la red se agrupan en bloques incipientes para la confirmación del minero. el El proceso de confirmación implica hashing transacciones utilizando algoritmos criptográficos hashing hasta que Se ha alcanzado la raíz de Merkle, creando un árbol de Merkle:

Figura 2: 8 transacciones TRX se hash__ en la raíz de merkle. Esta raíz merkle se incluye luego en el encabezado del bloque, que se adjunta a los bloques previamente confirmados para formar un blockchain. Esto permite un seguimiento fácil y transparente de transacciones, marcas de tiempo y otra información relacionada.

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

Los algoritmos criptográficos hashing son útiles en la prevención de ataques de red porque poseen varias propiedades:
9

● Tamaño de longitud de entrada/salida: el algoritmo puede pasar una entrada de cualquier longitud y tamaño, y genera un valor de longitud fija hash.
● Eficiencia: el algoritmo es relativamente fácil y rápido de calcular.
● Resistencia de preimagen: para una salida dada z, es imposible encontrar una entrada x tal que h(x) =​ ​z​. En otras palabras, el algoritmo hashing ​h(x)​ es una función unidireccional en la que solo La salida se puede encontrar, dada una entrada. Lo contrario no es posible.
● Resistencia a la colisión: es computacionalmente inviable encontrar pares ​x​1 ​≠ x​2​ ​tal que ​h(x​1​) = h(x​2​)​. En otras palabras, la probabilidad de encontrar dos entradas diferentes hashing al mismo la producción es extremadamente baja. Esta propiedad también implica una segunda resistencia a la preimagen.
● Segunda resistencia de preimagen: dada ​x​1​, y por lo tanto ​h(x​1​)​, es computacionalmente inviable encuentre cualquier ​x​2​ tal que ​h(x​1​) = h(x​2​)​. Si bien esta propiedad es similar a la ​resistencia a la colisión​, la La propiedad difiere en que dice que un atacante con un ​x​1​ dado lo encontrará computacionalmente No es factible encontrar ​x​2​ hashing a la misma salida.
● Determinista: asigna cada entrada a una y solo una salida. ● Efecto Avalanche: un pequeño cambio en la entrada da como resultado una salida completamente diferente.

Estas propiedades le dan a la red de criptomonedas su valor intrínseco al garantizar que los ataques no comprometer la red. Cuando los mineros confirman un bloque, reciben tokens como recompensa incorporada incentivo para la participación en la red. Sin embargo, a medida que la capitalización del mercado global de criptomonedas aumentó constantemente, los mineros se centralizaron y centraron sus recursos informáticos en acaparar tokens como activos, en lugar de con fines de participación en la red. Los mineros de CPU dieron paso a GPU, que a su vez dieron paso a potentes ASIC. En un estudio notable, la potencia total Se ha estimado que el consumo de la minería Bitcoin alcanza los 3 GW, comparable al de Irlanda. 10 consumo de energía. Este mismo estudio proyectó que el consumo total de energía alcanzaría los 8 GW en los próximos años. futuro.

Para resolver el problema del desperdicio de energía, el mecanismo de consenso de Prueba de Participación (PoS) fue propuesto por muchas redes nuevas. En las redes PoS, los titulares de token bloquean sus saldos token para bloquearlos. validators. Los validator se turnan para proponer y votar el siguiente bloque. Sin embargo, el problema con PoS estándar es que la influencia validator se correlaciona directamente con la cantidad de tokens bloqueados. Esto da como resultado que las partes acaparen grandes cantidades de la moneda base de la red y ejerzan influencia en el ecosistema de la red.

El mecanismo de consenso TRON utiliza un innovador sistema de prueba de participación delegada en el que 27 Los SuperRepresentantes (SR) producen bloques para la red. Cada 6 horas, los titulares de cuentas TRX quienes congelan sus cuentas pueden votar por una selección de candidatos SR, siendo los 27 mejores candidatos consideraron los SR. Los votantes pueden elegir a los SR basándose en criterios tales como proyectos patrocinados por los SR para 9 PAAR, C., PELZL, J., ​Comprensión de la criptografía: un libro de texto para estudiantes y profesionales​, 2010 ed. Springer-Verlag Berlín Heidelberg, 2010.
10 https://www.sciencedirect.com/science/article/pii/S2542435118301776aumentar la adopción de TRX y las recompensas distribuidas a los votantes. Esto permite una sociedad más democratizada y ecosistema descentralizado. Las cuentas de los SR son cuentas normales, pero su acumulación de votos les permite producir bloques. Con las bajas tasas de rendimiento de Bitcoin y Ethereum debido a su Mecanismo de consenso de PoW y problemas de escalabilidad, el sistema DPoS de TRON ofrece una solución innovadora. mecanismo que resultó en 2000 TPS en comparación con los 3 TPS de Bitcoin y los 15 TPS de Ethereum.

La red de protocolo TRON genera un bloque cada tres segundos, y cada bloque otorga 32 TRX a Súper Representantes. Se otorgará un total de 336.384.000 TRX anualmente a los 27 SR. Cada vez que un SR termina la producción de bloques, las recompensas se envían a una subcuenta en el superlibro mayor. Los SR pueden verificar, pero no utilizar directamente, estos TRX tokens. Cada uno puede realizar un retiro. SR una vez cada 24 horas, transfiriendo las recompensas de la subcuenta al SR especificado cuenta.

Los tres tipos de nodos en la red TRON son el nodo testigo, el nodo completo y el nodo de solidez. Los nodos testigo son creados por SR y son los principales responsables de la producción y propuesta de bloques. creación/votación. Los nodos completos proporcionan API y transmiten transacciones y bloques. Sincronización de nodos de solidez bloques de otros nodos completos y también proporcionan API indexables.

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​; }

Cuenta

4.1 Tipos

Los tres tipos de cuentas en la red TRON son cuentas regulares, cuentas token y cuentas de contrato.

1. Las cuentas regulares se utilizan para transacciones estándar.
2. Las cuentas de token se utilizan para almacenar TRC-10 tokens.
3. Las cuentas de contrato son smart contract cuentas creadas por cuentas regulares y pueden activado también por cuentas regulares. 4.2 Creación

Hay tres formas de crear una cuenta TRON:

1. Crear una nueva cuenta a través de API 2. Transfiera TRX a una nueva dirección de cuenta 3. Transfiera cualquier TRC-10 token a una nueva dirección de cuenta

Un par de claves fuera de línea que consta de una dirección (clave pública) y una clave privada, y no registrada por el También se puede generar la red TRON. El algoritmo de generación de direcciones de usuario consta de generar un par de claves y luego extraer la clave pública (matriz de bytes de 64 bytes que representa x, y coordenadas). Hash la clave pública usando la función SHA3-256 (el protocolo SHA3 adoptado es KECCAK-256) y extrae los últimos 20 bytes del resultado. Agregue 41 al comienzo de la matriz de bytes y asegúrese de que la longitud de la dirección inicial sea de 21 bytes. Hash la dirección dos veces usando la función SHA3-256 y tome los primeros 4 bytes como código de verificación. Añade el código de verificación al final de la inicial. dirección y obtenga la dirección en formato base58check a través de la codificación base58. un codificado La dirección de Mainnet comienza con T y tiene 34 bytes de longitud. 4.3 Estructura

Los tres tipos de cuentas diferentes son Normal, AssetIssue y Contrato. Una cuenta contiene 7 parámetros:

1. nombre_cuenta​: el nombre de esta cuenta – p.e. Cuenta de facturas.
2. tipo​: qué tipo de cuenta es, p.e. 0 (significa tipo "Normal").
3. saldo​: saldo de esta cuenta – p.e. 4213312.

4. voto​: votos recibidos en esta cuenta – p.e. {(“0x1b7w…9xj3”,323), (“0x8djq…j12m”,88),…,(“0x82nd…mx6i”,10001)}.
5. activo​: otros activos esperados TRX en esta cuenta – p.e. {<“WishToken”, 66666>, <”Perrito”, 233>}. 6. last_operation_time​: la última hora de operación de esta cuenta.

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 } } }

Bloque

Un bloque normalmente contiene un encabezado de bloque y varias transacciones.

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

Un encabezado de bloque contiene ​raw_data​, ​witness_signature​ y ​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 Datos sin procesar

Los datos sin procesar se indican como ​raw_data​ en Protobuf. Contiene los datos sin procesar de un mensaje, que contiene 6 parámetros:

1. marca de tiempo​: marca de tiempo de este mensaje – p.e. 1543884429000. 2. txTrieRoot​: la raíz del árbol Merkle – p.e. 7dacsa…3ed. 3. parentHash​: el hash del último bloque – p.e. 7dacsa…3ed. 4. número​: la altura del bloque – p.e. 4638708. 5. versión​: reservada – p.ej. 5.

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

6. dirección_testigo​: la dirección del testigo incluida en este bloque – p.e. 41928c...4d21. 5.1.2 Firma del testigo

La firma del testigo se indica como ​witness_signature​ en Protobuf, que es la firma de este bloquear el encabezado del nodo testigo. 5.1.3 ID de bloque

El ID de bloque se indica como ​blockID​ en Protobuf. Contiene la identificación atómica de un bloque. un bloque La identificación contiene 2 parámetros: 1. hash​: el hash del bloque. 2. número​: el hash y altura del bloque. 5.2 Transacción 5.2.1 Firma

El proceso de firma de transacciones de TRON sigue un algoritmo criptográfico estándar ECDSA, con un Curva de selección SECP256K1. Una clave privada es un número aleatorio y la clave pública es un punto en la curva elíptica. El proceso de generación de clave pública consiste en generar primero un número aleatorio como clave privada y luego multiplicar el punto base de la curva elíptica por la clave privada para obtener la clave pública. Cuando se produce una transacción, los datos sin procesar de la transacción se convierten primero al formato de bytes. Los datos sin procesar luego se someten a SHA-256 hashing. La clave privada correspondiente al contrato. La dirección luego firma el resultado del SHA256 hash. El resultado de la firma luego se agrega al transacción.
5.2.2 Modelo de ancho de banda

Las transacciones ordinarias solo consumen puntos de ancho de banda, pero las operaciones smart contract consumen ambos puntos de energía y ancho de banda. Hay dos tipos de puntos de ancho de banda disponibles. Los usuarios pueden ganar puntos de ancho de banda de congelar TRX, mientras que 5000 puntos de ancho de banda gratuitos también están disponibles diariamente.

Cuando se transmite una transacción TRX, se transmite y almacena en forma de una matriz de bytes sobre la red. Puntos de ancho de banda consumidos por una transacción = número de bytes de transacción multiplicado por la tasa de puntos de ancho de banda. Por ejemplo, si la longitud de la matriz de bytes de una transacción es 200, entonces la transacción consume 200 puntos de ancho de banda. Sin embargo, si una transferencia TRX o token resulta en la cuenta de destino que se está creando, entonces solo los puntos de ancho de banda consumidos para crear la cuenta se deducirán y no se deducirán puntos de ancho de banda adicionales. En la creación de una cuenta En este escenario, la red consumirá primero los puntos de ancho de banda que obtuvo el iniciador de la transacción.por congelar TRX. Si esta cantidad es insuficiente, entonces la red consume la transacción. TRX del iniciador.

En escenarios de transferencia TRX estándar de una cuenta TRX a otra, la red primero consume los puntos de ancho de banda obtenidos por el iniciador de la transacción para congelar TRX. Si eso es insuficiente, entonces consume de los 5000 puntos de ancho de banda diarios gratuitos. Si esto todavía no es suficiente, entonces la red Consume el TRX del iniciador de la transacción. La cantidad se calcula por el número de bytes en la transacción multiplicada por 10 DOM. Por lo tanto, para la mayoría de los poseedores de TRX, que no necesariamente pueden congelar su TRX para participar en la votación SR, el primer paso se omite automáticamente (ya que el saldo TRX frozen = 0) y los 5000 anchos de banda gratuitos diarios impulsan la transacción.

Para transferencias TRC-10 token, la red primero verifica si el total de puntos de ancho de banda libres del activo emitido token son suficientes. De lo contrario, los puntos de ancho de banda obtenidos al congelar TRX son consumido. Si todavía no hay suficientes puntos de ancho de banda, entonces consume el TRX de la transacción. iniciador.

5.2.3 Tarifa

La red TRON generalmente no cobra tarifas por la mayoría de las transacciones; sin embargo, debido al sistema Las restricciones y la equidad, el uso del ancho de banda y las transacciones conllevan ciertas tarifas.

Los cargos por tarifas se dividen en las siguientes categorías: 1. Las transacciones normales cuestan puntos de ancho de banda. Los usuarios pueden utilizar los puntos de ancho de banda diarios gratuitos. (5000) o congelar TRX para obtener más. Cuando los puntos de ancho de banda no sean suficientes, TRX será utilizado directamente desde la cuenta emisora. El TRX necesario es la cantidad de bytes * 10 SUN. 2. Los contratos inteligentes cuestan energía (Sección 6), pero también necesitarán puntos de ancho de banda para el transacción que será transmitida y confirmada. El costo del ancho de banda es el mismo que el anterior. 3. Todas las transacciones de consulta son gratuitas. No cuesta energía ni ancho de banda.

La red TRON también define un conjunto de tarifas fijas para las siguientes transacciones: 1. Creando un nodo testigo: 9999 TRX 2. Emitiendo un TRC-10 token: 1024 TRX 3. Creando una nueva cuenta: 0.1 TRX 4. Creando un par de intercambio: 1024 TRX 5.2.4 Transacción como prueba de participación (TaPoS)

TRON usa TaPoS para garantizar que todas las transacciones confirmen el blockchain principal, mientras lo hace Es difícil falsificar cadenas. En TaPoS, las redes requieren que cada transacción incluya parte de el hash de un encabezado de bloque reciente. Este requisito evita que las transacciones se repitan en se bifurca sin incluir el bloque al que se hace referencia, y también indica a la red que un usuario en particular y sulo que está en juego está en una bifurcación específica. Este mecanismo de consenso protege la red contra la Denegación de Servicio, 51%, minería egoísta y ataques de doble gasto.
5.2.5 Confirmación de transacción

Una transacción se incluye en un bloque futuro después de ser transmitida a la red. Después de 19 cuadras son minado el TRON (incluido su propio bloque), se confirma la transacción. Cada bloque es producido por uno de los 27 mejores Súper Representantes en un sistema de todos contra todos. Cada bloque tarda ~3 segundos en ser extraído en el blockchain. El tiempo puede variar ligeramente para cada Súper Representante debido a la red. condiciones y configuraciones de la máquina. En general, una transacción se considera totalmente confirmada después ~1 minuto. 5.2.6 Estructura

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 Introducción

TRON Virtual Machine (TVM) es una máquina virtual ligera y completa de Turing desarrollada para El ecosistema de TRON. Su objetivo es proporcionar un sistema blockchain personalizado que sea eficiente, conveniente, estable, seguro y escalable.

TVM inicialmente se bifurcó de EVM y puede conectarse sin problemas con la solidez existente smart contract 11 ecosistema de desarrollo. En base a eso, TVM también admite el consenso DPoS.

TVM emplea el concepto de Energía. A diferencia del mecanismo de gas en EVM, las operaciones de las transacciones y smart contracts en TVM son gratuitas y no se consume TRX. Técnicamente, ejecutable La capacidad de cálculo en TVM no está restringida por la cantidad total de tenencias de tokens. 6.2 Flujo de trabajo

El compilador primero traduce Solidity smart contract a código de bytes legible y ejecutable en la TVM. Luego, TVM procesa datos a través de código de operación, lo que equivale a operar la lógica. de una máquina de estados finitos basada en pila. Finalmente, TVM accede a blockchain datos e invoca Interfaz de Datos Externos a través de la capa de Interoperación. 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: Flujo de trabajo TVM

6.3 Rendimiento 6.3.1 Arquitectura ligera

TVM adopta una arquitectura ligera con el objetivo de reducir el consumo de recursos para garantizar rendimiento del sistema. 6.3.2 Robusto

Las transferencias TRX y la ejecución smart contract cuestan solo puntos de ancho de banda, en lugar de TRX, que exime a TRON de ser atacado. El consumo de ancho de banda es predecible y estático ya que cada El costo del paso computacional es fijo. 6.3.3 Alta compatibilidad

TVM es compatible con EVM y será compatible con más máquinas virtuales convencionales en el futuro. Por lo tanto, todos los smart contracts en EVM son ejecutables en TVM. 6.3.4 Bajo Costo

Gracias a la configuración del ancho de banda de TVM, los costos de desarrollo se reducen y los desarrolladores pueden concentrarse en desarrollo lógico de su código de contrato. TVM también ofrece interfaces todo en uno para contrato implementación, activación y visualización para ofrecer comodidad a los desarrolladores.

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 Introducción

Un smart contract es un protocolo que verifica digitalmente la negociación del contrato. Definen las reglas y sanciones relacionadas con un acuerdo y también hacer cumplir automáticamente esas obligaciones. el inteligente El código de contrato facilita, verifica y hace cumplir la negociación o ejecución de un acuerdo o transacción. Desde una perspectiva de tokenización, los smart contracts también facilitan los fondos automáticos transferencias entre partes participantes si se cumplen ciertos criterios.

TRON smart contracts están escritos en el lenguaje Solidity. Una vez escritos y probados, pueden ser compilado en código de bytes y luego implementado en la red TRON para la máquina virtual TRON. una vez implementado, smart contracts se pueden consultar a través de sus direcciones de contrato. La solicitud del contrato La interfaz binaria (ABI) muestra las funciones de llamada del contrato y se utiliza para interactuar con el red. 7.2 Modelo Energético

El límite máximo de energía para desplegar y activar un smart contract es función de varios variables:

● La energía dinámica procedente de la congelación de 1 TRX es 50 000 000 000 (límite de energía total) / (energía total Peso) ● El límite de energía es el límite de energía diario de la cuenta por congelar TRX ● La energía restante diaria de la cuenta por congelar TRX se calcula como Límite de energía - Energía Usado ● El límite de tarifa en TRX se establece en smart contract llamada de implementación/activación ● TRX utilizable restante en la cuenta ● Energía por TRX si se compra directamente (10 SUN = 1 Energía) = 100,000, los SR pueden votar ajuste

Hay dos escenarios de consumo para calcular el límite máximo de energía para la implementación y disparador. La lógica se puede expresar de la siguiente manera:
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 Implementación

Cuando se compila una TRON solidez smart contract, la Máquina Virtual TRON lee el compilado código de bytes. El código de bytes consta de una sección para la implementación del código, el código de contrato y los datos auxiliares. Los datos auxiliares son la huella digital criptográfica del código fuente, que se utiliza para la verificación. El despliegue bytecode ejecuta la función constructora y configura las variables de almacenamiento iniciales. El despliegue El código también calcula el código del contrato y lo devuelve al TVM. El ABI es un archivo JSON que describe las funciones de TRON smart contract. Este archivo define los nombres de las funciones, su pagabilidad, los valores de retorno de la función y su mutabilidad de estado. 7.4 Función de disparo

Una vez que se implementan los TRON smart contracts, sus funciones se pueden activar individualmente a través de TronStudio o mediante llamadas API. Las funciones de cambio de estado requieren energía, mientras que las funciones de solo lectura ejecutar sin energía. 7.5 TRON Solidez

TRON Solidity es una bifurcación del lenguaje Solidity de Ethereum. TRON modifica el proyecto original para Admite unidades TRX y SUN (1 TRX = 1.000.000 SUN). El resto de la sintaxis del lenguaje es compatible con Solidez ^0.4.24. Así la Máquina Virtual Tron (TVM) es casi 100% compatible con EVM instrucciones.

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 Ficha TRC-10

En la red TRON, cada cuenta puede emitir tokens a expensas de 1024 TRX. ​Para emitir tokens, el emisor debe especificar un nombre token, la capitalización total, el tipo de cambio a TRX, duración de la circulación, descripción, sitio web, consumo máximo de ancho de banda por cuenta, total consumo de ancho de banda y la cantidad de token congelada. Cada emisión token también puede configurar el máximo diario de transferencia de token puntos de ancho de banda de cada cuenta, el máximo diario de toda la red token transfiere puntos de ancho de banda, suministro total de token, duración del bloqueo en días y monto total de tokens bloqueados. 8.2 Ficha TRC-20

TRC-20 es un estándar técnico utilizado para smart contracts que implementan tokens respaldados por TRON Máquina virtual. Es totalmente compatible con ERC-20.

La interfaz es la siguiente:
contrato​ TRC20Interfaz { ​función​ ​suministrototal​() ​pública​ ​constante​ ​retorna​ (uint); ​función​ ​balanceOf​(dirección tokenPropietario) ​retornos​ ​públicos​ ​constantes​ (uint saldo); ​función​ ​asignación​(dirección tokenPropietario, dirección del gastador) ​pública​ ​constante devoluciones (uint restante); transferencia de función (dirección a, uint tokens) devoluciones públicas (éxito bool); ​función​ ​aprobar​(gastador de direcciones, uint tokens) ​devoluciones​ ​públicas​ (bool éxito); ​función​ ​transferFrom​(dirección de, dirección a, uint tokens) ​público devoluciones​ (éxito bool);

​evento​ ​Transferencia​(dirección indexada desde, dirección indexada hacia, uint tokens); 
​evento​ ​Aprobación​(dirección indexada tokenPropietario, dirección gastadora indexada, uint

tokens); }

Desde la perspectiva del desarrollador, existen varias diferencias entre TRC-10 y TRC-20. Algunos Una de las diferencias clave es que los tokens TRC-10 son accesibles mediante API y smart contracts, mientras que TRC-20 tokens permiten la personalización de la interfaz, pero solo se puede acceder a ellos dentro de smart contracts.

Desde una perspectiva de costos, los TRC-10 tokens tienen tarifas de transacción que son 1000 veces más bajas que TRC-20, pero conlleva costos de ancho de banda para transferencias y depósitos de API. Transferencias y depósitos en smart Los contratos para TRC-10 tokens cuestan ancho de banda y energía.
8.3 Más allá

Dado que TRON usa la misma versión de Solidity que Ethereum, se podrían implementar más estándares token. transferido a 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.

Gobernancia

9.1 Súper Representante 9.1.1 Generalidades

Todas las cuentas de la red TRON pueden postularse y tener la oportunidad de convertirse en Super Representante (denotado como SR). Todos pueden votar por los candidatos SR. Los 27 mejores candidatos con los más votos pasarán a ser SR con derecho y obligación de generar bloques. los votos son se cuenta cada 6 horas y los SR cambiarán en consecuencia.

Para evitar ataques maliciosos, convertirse en candidato a SR tiene un coste. Al aplicar, 9999 TRX se eliminará de la cuenta del solicitante. Una vez exitosa, dicha cuenta puede unirse al SR elección. 9.1.2 Elección

TRON Se necesita poder (denotado como TP) para votar y la cantidad de TP depende del voto del votante. activos congelados (TRX).

El TP se calcula de la siguiente manera:
TP 1 TRX congelado para obtener ancho de banda 1 =

Cada cuenta en la red TRON tiene derecho a votar por sus propios SR.

Después del lanzamiento (descongelado, disponible después de 3 días), los usuarios no tendrán ningún activo congelado y perderán todo. TP en consecuencia. Como resultado, todos los votos dejan de ser válidos para la ronda de votación actual y futura a menos que TRX vuelve a estar congelado para votar.

Tenga en cuenta que la red TRON solo registra el voto más reciente, lo que significa que cada nuevo voto anulará todos los votos anteriores. 9.1.3 Recompensa un. Recompensa por voto

También conocida como Candidate Reward, que los 127 mejores candidatos actualizaron una vez por ronda (6 horas) compartirá 115,200 TRX extraídos. La recompensa se dividirá de acuerdo con el peso de los votos. cada candidato recibe. Cada año, la recompensa total para los candidatos será de 168.192.000 TRX. Recompensa total de votos por ronda ¿Por qué 115.200 TRX en cada ronda? 15, 00 TRX recompensa total de votos por ronda (V R/ronda) 1 2 =
V R/ronda = 16 T RX/bloque × 20 bloques/min × 60 min/h × 6 h/ronda Aviso: esto lo establece WITNESS_STANDBY_ALLOWANCE = 115,200 TRX. Ver parámetros de red dinámica. Recompensa total de votos por año ¿Por qué 168.192.000 TRX cada año? 168, 192, 000 T RX = recompensa total de votos por año (V R/año) V R/año = 115, 200 T RX/ronda × 4 rondas/día × 365 días/año B. Recompensa de bloque También conocida como Recompensa Súper Representante, que se entrega a los 27 mejores candidatos (SR) elegidos. cada ronda (6 horas) compartirá aproximadamente 230,400 TRX extraídos. La recompensa se dividirá en partes iguales. entre los 27 SR (menos el total de bloques de recompensa perdidos debido a un error de red). un total de Se otorgarán 336.384.000 TRX anualmente a los 27 SR. Recompensa total en bloque por ronda ¿Por qué 230.400 TRX en cada ronda? 230, 400 T RX = recompensa total en bloque por ronda (BR/ronda) BR/ronda = 32 T RX/bloque × 20 bloques/min × 60 min/h × 6 h/ronda Aviso: la recompensa del bloque de unidades se establece en WITNESS_PAY_PER_BLOCK = 32 TRX. Ver red dinámica parámetros. Recompensa total en bloque por año ¿Por qué 336.384.000 TRX cada año? 336, 384, 000 T RX = recompensa total en bloque por año (BR/año) BR/año = 230, 400 T RX/ronda × 4 rondas/día × 365 días/año 1 de enero de 2021 No habrá inflación en la red TRON antes del 1 de enero de 2021, y la TRON DAO otorgar todas las recompensas en bloque y recompensas de candidatos antes de esa fecha. do. Cálculo de recompensa

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

R V R total V =
×
votos totales votos recibidos por el candidato SR
R

bloque perdido 2 b =
27 BR total − × 3
Nota: la recompensa se calcula por SR por ronda (6 horas)

Cálculo de recompensa del candidato SR del rango 28 al rango 127 recompensa total recompensa de voto (V R) t =

R V R total V =
×
votos totales votos recibidos por el candidato SR
Nota: la recompensa se calcula por candidato SR por ronda (6 horas) 9.2 Comité 9.2.1 Generalidades

El comité se utiliza para modificar TRON parámetros dinámicos de la red, como la generación de bloques. recompensas, tarifas de transacción, etc. El comité está formado por los 27 SR de la ronda actual. Cada SR tiene derecho a proponer y votar propuestas. Cuando una propuesta recibe 19 votos o más, se aprobado y los nuevos parámetros de la red se aplicarán en el próximo período de mantenimiento (3 días). 9.2.2 Parámetros de red dinámica 0. MAINTENANCE_TIME_INTERVAL un. Descripción
Modifique el tiempo del intervalo de mantenimiento en ms. Conocido como el intervalo de tiempo de votación SR por redondo.
b. Ejemplo [6 * 3600 * 1000] ms, que son 6 horas. do. Rango [3 * 27 * 1000, 24 * 3600 * 1000] ms 1. ACCOUNT_UPGRADE_COST un. Descripción Modificar el costo de solicitar la cuenta SR. b. Ejemplo [9,999,000,000] SUN, que es 9,999 TRX. do. Rango [0,100 000 000 000 000 000] DOM 2. CREATE_ACCOUNT_FEE un. Descripción Modificar la tarifa de creación de cuenta.b. Ejemplo [100,000] SUN, que es 1 TRX. do. Rango [0,100 000 000 000 000 000] DOM 3. TRANSACTION_FEE un. Descripción Modifique el monto de la tarifa utilizada para obtener ancho de banda adicional. b. Ejemplo [10] DOM/byte. do. Rango [0,100 000 000 000 000 000] DOM/byte 4. ASSET_ISSUE_FEE un. Descripción Modificar tarifa de emisión de activos. b. Ejemplo [1024,000,000] SUN, que es 1024 TRX. do. Rango [0,100 000 000 000 000 000] DOM 5. TESTIGO_PAY_PER_BLOCK un. Descripción Modificar la recompensa de generación de bloques SR. Conocido como recompensa por bloque unitario. b. Ejemplo [32,000,000] SUN, que es 32 TRX. do. Rango [0,100 000 000 000 000 000] DOM 6. WITNESS_STANDBY_ALLOWANCE un. Descripción Modifique las recompensas otorgadas a los 127 mejores candidatos SR. Conocido como recompensa de voto total por ronda. b. Ejemplo [115,200,000,000] SUN, que son 115,200 TRX. do. Rango [0,100 000 000 000 000 000] DOM 7. CREATE_NEW_ACCOUNT_FEE_IN_SYSTEM_CONTRACT un. Descripción Modificar el costo de creación de cuenta. Combine los parámetros de red dinámica n.° 8 para obtener Costo total de creación de cuenta:
REATE_NEW_ACCOUNT_FEE_IN_SY STEM_CONTRACT REATE_NEW_ACCOUNT_BANDWIDTH_RATE
c ×C

B. Ejemplo [0] DOM. do. Rango [0,100 000 000 000 000 000] DOM 8. CREATE_NEW_ACCOUNT_BANDWIDTH_RATE

un. Descripción Modificar el costo de creación de cuenta. Combine los parámetros de red dinámica n.° 7 para obtener Costo total de creación de cuenta:
REATE_NEW_ACCOUNT_FEE_IN_SY STEM_CONTRACT REATE_NEW_ACCOUNT_BANDWIDTH_RATE
c ×C

B. Ejemplo [1]. do. Rango [0,100,000,000,000,000,000] 9. ALLOW_CREATION_OF_CONTRACTS un. Descripción Para encender la máquina virtual Tron (TVM). b. Ejemplo Verdadero: configurado para activarse y entrar en vigor desde el 10/10/2018 a las 23:47 UTC. do. Rango Verdadero/Falso 10. QUITAR_EL_PODER_DE_EL_GR un. Descripción Eliminar los votos iniciales de GR génesis B. Ejemplo Verdadero: realizado el 4/11/2018 a las 08:46 UTC. do. Rango Verdadero/Falso: Aviso: no se puede volver a establecer Falso desde Verdadero. 11. TARIFA_ENERGÍA un. Descripción Modifica la tarifa de 1 energía. b. Ejemplo 20 DOM. do. Rango [0,100 000 000 000 000 000] DOM 12. EXCHANGE_CREATE_FEE un. Descripción Modifique el costo de creación de pares comerciales. Conocido como el costo de crear una orden comercial. b. Ejemplo [1,024,000,000] SUN, que es 1024 TRX. do. Rango [0,100 000 000 000 000 000] DOM 13. MAX_CPU_TIME_OF_ONE_TX un. Descripción Modificar el tiempo máximo de ejecución de una transacción. Conocido como el límite de tiempo de espera de una transacción. b. Ejemplo 50 ms. do. Rango

[0, 1000] ms 14. ALLOW_UPDATE_ACCOUNT_NAME un. Descripción Modifique la opción para permitir que una cuenta actualice su nombre de cuenta.
b. Ejemplo Falso: que está disponible para proponer desde java-tron Odyssey v3.2. do. Rango Verdadero/Falso: Aviso: no se puede volver a establecer Falso desde Verdadero. 15. ALLOW_SAME_TOKEN_NAME un. Descripción Modifique la validación para permitir que diferentes token tengan un nombre duplicado.
b. Ejemplo Falso: está disponible para proponer desde java-tron Odyssey v3.2. do. Rango Verdadero/Falso: Aviso: no se puede volver a establecer Falso desde Verdadero. 16. ALLOW_DELEGATE_RESOURCE un. Descripción Modificar la validación de permitir emitir token con un nombre duplicado, para que el tokenID​ del token, en tipo de datos entero largo, sería el único atómico identificación de un token.
b. Ejemplo Falso: está disponible para proponer desde java-tron Odyssey v3.2. do. Rango Verdadero/Falso: Aviso: no se puede volver a establecer Falso desde Verdadero. 17. LÍMITE_ENERGÍA_TOTAL un. Descripción Modificar el límite de energía total de toda la red. b. Ejemplo [50 000 000 000 000 000] SUN, que son 50 000 000 000 TRX. do. Rango [0,100,000,000,000,000,000] SOL 18. ALLOW_TVM_TRANSFER_TRC10 un. Descripción Permitir la transferencia TRC-10 token dentro de smart contracts. ALLOW_UPDATE_ACCOUNT_NAME, ALLOW_SAME_TOKEN_NAME, Todas las propuestas ALLOW_DELEGATE_RESOURCE deben aprobarse antes de proponer este parámetro cambia.
b. Ejemplo Falso: está disponible para proponer desde java-tron Odyssey v3.2. do. Rango Verdadero/Falso: Aviso: no se puede volver a establecer Falso desde Verdadero.9.2.3 Crear propuesta

Sólo las cuentas SR tienen derecho a proponer un cambio en los parámetros dinámicos de la red. 9.2.4 Propuesta de votación

Sólo los miembros del comité (SR) pueden votar por una propuesta y el miembro que no vota a tiempo se considerará en desacuerdo. La propuesta está activa durante 3 días después de su creación. el voto puede modificarse o recuperarse durante el período de votación de 3 días. Una vez finalizado el plazo, la propuesta será O tiene éxito (más de 19 votos) o fracasa (y finaliza). 9.2.5 Cancelar propuesta

El proponente puede cancelar la propuesta antes de que entre en vigor. 9.3 Estructura

Los SR son testigos de los bloques recién generados. Un testigo contiene 8 parámetros:
1. dirección​: la dirección de este testigo – p.ej. 0xu82h…7237.
2. voteCount​: número de votos recibidos sobre este testigo – p.e. 234234.
3. pubKey​: la clave pública para este testigo – p.e. 0xu82h…7237.
4. url​: la URL de este testigo – p.e. https://www.noonetrust.com.
5. totalProduced​: la cantidad de bloques que produjo este testigo, p. 2434.
6. totalMissed​: el número de bloques que este testigo omitió, p.e. 7.
7. lastBlockNum​: la última altura del bloque – p.e. 4522. 8. isjobs​: una bandera booleana.

Estructura de datos de Protobuf: mensaje​ ​Testigo​{
Dirección de bytes = ​1​;
​int64​ voteCount = ​2​;
​bytes​ pubKey = ​3​;
​cadena​ URL = ​4​;
​int64​ totalProducido = ​5​;
​int64​ totalPerdidos = ​6​;
​int64​ últimoBlockNum = ​7​; ​bool​ esTrabajos = ​8​; }

  1. Desarrollo de aplicaciones digitales 10.1 API

La red TRON ofrece una amplia selección de más de 60 puertas de enlace API HTTP para interactuar con el red a través de Nodos Full y Solidity. Además, TronWeb es una biblioteca JavaScript completa. que contiene funciones API que permiten a los desarrolladores implementar smart contracts, cambie el blockchain estado, consulta blockchain e información del contrato, comercio en DEX y mucho más. Estas API Las puertas de enlace se pueden dirigir hacia una red privada local, la red de prueba Shasta o la red principal TRON.

10.2 Redes

TRON tiene tanto una red de prueba Shasta como una red principal. Los desarrolladores pueden conectarse a las redes mediante implementar nodos, interactuar a través de TronStudio o usar API a través del servicio TronGrid. El TronGrid El servicio consta de clústeres de nodos con carga equilibrada alojados en servidores AWS en todo el mundo. Como aplicación digital El desarrollo se amplía y los volúmenes de llamadas API aumentan, TronGrid aborda con éxito el aumento en Tráfico API.
10.3 Herramientas

TRON ofrece un conjunto de herramientas de desarrollo para permitir a los desarrolladores crear DApps innovadoras.
TronBox es un marco que permite a los desarrolladores probar e implementar smart contracts a través de TronWeb API. TronGrid es un servicio API alojado y con carga equilibrada que permite a los desarrolladores acceder a TRON red sin tener que ejecutar su propio nodo. TronGrid ofrece acceso tanto a Shasta testnet así como la TRON Mainnet. TronStudio es un desarrollo integrado integral Entorno (IDE) que permite a los desarrolladores compilar, implementar y depurar Solidity de forma inteligente. contratos. TronStudio contiene un nodo completo interno que crea un entorno local privado para smart contract pruebas antes de la implementación. La biblioteca API de TronWeb conecta a los desarrolladores con la red a través de una amplia selección de llamadas API HTTP envueltas en JavaScript.
10.4 Recursos

El TRON Developer Hub es un sitio de documentación API integral diseñado para 12 desarrolladores que deseen construir en la red TRON. El Developer Hub proporciona un alto nivel comprensión conceptual de TRON y guía a los usuarios a través de los detalles de la interacción con el 12 Centro de desarrolladores: https://developers.tron.network/

red. Las guías guían a los desarrolladores a través de la configuración, implementación e interacción de nodos con dispositivos inteligentes. contratos, interacción e implementación de API, creación de DApps de muestra y uso de cada uno de los herramientas de desarrollo. Además, los canales de la comunidad de desarrolladores están disponibles a través de Discord.
13

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

  1. Conclusión

TRON es una solución blockchain escalable que ha empleado métodos innovadores para abordar desafíos que enfrentan las redes heredadas blockchain. Habiendo alcanzado más de 2 millones de transacciones por día, con más de 700.000 cuentas TRX y superando las 2000 TPS, TRON ha permitido a la comunidad en creando una red descentralizada y democratizada.