TRON Whitepaper v2.1

TRON DAO

Whitepaper de TRON

El whitepaper de TRON (v2.1) proporciona la base técnica para uno de los sistemas operativos descentralizados más grandes del mundo. Este documento detalla la arquitectura de 3 capas, el mecanismo de consenso DPoS y la TVM que impulsa las transacciones globales de alta capacidad.

TRON: Plataforma Blockchain Avanzada y Descentralizada

Versión del Whitepaper: 2.1
Versión del Protocolo TRON: 4.8.0

[!NOTE] Esta es una traducción proporcionada para la comodidad de los usuarios hispanohablantes. Para consultar la versión original, formal y más precisa, por favor visita el Whitepaper original en inglés.

1 Introducción

1.1 Visión

TRON es un proyecto ambicioso dedicado al establecimiento de un Internet verdaderamente descentralizado y su infraestructura. El Protocolo TRON, uno de los sistemas operativos basados en blockchain más grandes del mundo, ofrece soporte público de blockchain con alta capacidad de procesamiento, alta escalabilidad y alta disponibilidad para todas las Aplicaciones Descentralizadas (DApps) del ecosistema TRON. Desde sus inicios, TRON ha expandido constantemente sus capacidades, logrando una adopción significativa en áreas como las transferencias de stablecoins y cultivando una comunidad próspera, lo que consolida aún más su posición destacada dentro de la industria blockchain.

1.2 Antecedentes

La introducción de Bitcoin en 2009 revolucionó la percepción de la sociedad sobre el sistema financiero tradicional tras la Gran Recesión (2007-2008). Mientras los fondos de cobertura centralizados y los bancos colapsaban por la especulación en derivados financieros opacos, la tecnología blockchain proporcionó un libro de contabilidad universal y transparente del que cualquier persona podía obtener información sobre transacciones. Las transacciones estaban criptográficamente protegidas mediante un mecanismo de consenso de Prueba de Trabajo (PoW), lo que evitaba los problemas de doble gasto.

A finales de 2013, el whitepaper de Ethereum propuso una red en la que los contratos inteligentes y una Máquina Virtual de Ethereum (EVM) Turing-completa permitirían a los desarrolladores interactuar con la red a través de DApps. Sin embargo, cuando los volúmenes de transacciones de Bitcoin y Ethereum alcanzaron su punto máximo en 2017, resultó evidente por los bajos tiempos de procesamiento y las altas comisiones de transacción que criptomonedas como Bitcoin y Ethereum en su estado actual no eran escalables para una adopción masiva. Así, TRON fue fundado y concebido como una solución innovadora a estos apremiantes desafíos de escalabilidad.

1.3 Historia

1.3.1 El Génesis de un Internet Descentralizado (2017)

El camino de TRON comenzó en julio de 2017 con su fundación en Singapur, impulsado por una visión central: la creación de un Internet verdaderamente descentralizado. Esta ambiciosa empresa fue rápidamente respaldada por una exitosa Oferta Inicial de Monedas (ICO) en agosto de 2017, asegurando capital de desarrollo crucial. Un compromiso temprano con la transparencia y la colaboración abierta quedó demostrado con el lanzamiento de su protocolo de código abierto en diciembre de 2017, invitando a la participación de la comunidad desde su inicio.

1.3.2 Desarrollo del Núcleo (2018)

En 2018 tuvo lugar un rápido avance tecnológico. El lanzamiento de la Testnet Shasta en marzo allanó el camino para el lanzamiento pivotal del Mainnet, Odyssey 2.0, en mayo, estableciendo TRON como un blockchain de Capa 1 independiente y de alto rendimiento capaz de soportar una nueva generación de DApps. Priorizando la eficiencia de la red y la gobernanza descentralizada, TRON implementó el mecanismo de consenso de Prueba de Participación Delegada (DPoS) y eligió a sus Super Representantes (SR) en junio de 2018. Este año fundacional también vio una expansión estratégica con la adquisición de BitTorrent en julio, amplificando significativamente el alcance y el potencial de TRON en la distribución descentralizada de contenido. En la segunda mitad del año se lanzó la Máquina Virtual de TRON (TVM) compatible con Ethereum en octubre, un catalizador clave para atraer desarrolladores y fomentar el crecimiento del ecosistema. En apoyo a este desarrollo, la actualización Odyssey-v3.2 en noviembre introdujo la delegación de recursos, optimizando la utilidad de la red. Para diciembre de 2018, el floreciente ecosistema de TRON había atraído a más de 1 millón de cuentas de usuario. La introducción de los estándares de token TRC-10 y TRC-20 a lo largo de 2018 proporcionó la infraestructura fundamental para la tokenización de activos y la innovación en DApps en la plataforma.

1.3.3 Expansión de Funcionalidades y Adopción (2019 - 2021)

TRON continuó su evolución con actualizaciones clave del protocolo en 2019, incluyendo Odyssey-v3.5 en marzo, que mejoró la seguridad y flexibilidad de las cuentas, y Odyssey-v3.6.5 en octubre, que optimizó los mecanismos de staking y gobernanza. Este período también marcó el ascenso significativo de TRON como la red líder para transferencias de stablecoins, con la adopción masiva de USDT TRC-20 comenzando en 2019, aprovechando su velocidad y bajas comisiones de transacción. Esta utilidad se convirtió en un importante impulsor del crecimiento de usuarios. Para septiembre de 2020, la plataforma había incorporado a más de 10 millones de cuentas. La creciente prominencia de TRON en el ecosistema de stablecoins quedó subrayada aún más por el rápido crecimiento de la emisión de USDT TRC-20, que superó los 10 mil millones a principios de 2021 y alcanzó más de 30 mil millones en mayo de 2021.

1.3.4 Crecimiento Sostenido y Dominio del Ecosistema (2022 - Presente)

Este período demostró un crecimiento robusto y continuado tanto en la adopción de usuarios como en el dominio de las stablecoins. La base de usuarios de TRON experimentó una aceleración significativa, escalando a más de 100 millones de cuentas en junio de 2022 y superando los 300 millones en abril de 2025. Al mismo tiempo, la emisión de USDT TRC-20 continuó su trayectoria ascendente, alcanzando más de 70 mil millones en abril de 2025, consolidando la posición de TRON como infraestructura crítica dentro del panorama global de stablecoins. Esta expansión se complementa con el compromiso continuo de TRON de mejorar la estabilidad central de la plataforma, la escalabilidad, el rendimiento y la calibración del modelo económico en respuesta a la dinámica del mercado.

Los avances significativos del protocolo durante este período incluyen una serie de actualizaciones mayores obligatorias. El lanzamiento de GreatVoyage-v4.7.0.1 (Aristóteles) introdujo el mecanismo Stake 2.0 y un modelo dinámico de Energía para la TVM, mejorando la gestión de recursos y la eficiencia de ejecución. El lanzamiento de GreatVoyage-v4.7.2 (Periandro) actualizó el módulo de red de TRON a Libp2p v1.2.0, mejorando la comunicación entre pares y la sincronización de bloques. También introdujo actualizaciones críticas a Stake 2.0 y la instrucción EIP-3855 PUSH0 en la TVM. El lanzamiento de GreatVoyage-v4.8.0 (Kant) mejoró aún más la Máquina Virtual de TRON (TVM) adaptándose a las mejoras clave de las actualizaciones recientes de Ethereum, con el objetivo de mejorar la eficiencia de los contratos inteligentes y reducir los costos de transacción, manteniendo la competitividad de TRON como blockchain compatible con EVM.

1.3.5 De Cara al Futuro

Basándose en su infraestructura establecida, TRON sigue comprometido con mejorar la interoperabilidad, fomentar una adopción más amplia y consolidar aún más su posición como blockchain líder con un ecosistema próspero y una eficiencia incomparable en las transferencias de stablecoins dentro del panorama en evolución de las tecnologías descentralizadas.

1.4 Terminología

Para las definiciones de los términos clave y acrónimos utilizados a lo largo de este whitepaper, consulta el Apéndice A: Terminología.

Figura 1: *Cronología de Desarrollo e Hitos de TRON (2017-Presente)*

2 Arquitectura

TRON adopta una arquitectura de tres capas compuesta por una Capa Central, una Capa de Almacenamiento y una Capa de Aplicación. El protocolo TRON se adhiere a Protocol Buffers (Protobuf) de Google, que soporta intrínsecamente la extensión en múltiples lenguajes.

2.1 Capa Central

La Capa Central está compuesta por varios módulos clave responsables de funciones como los contratos inteligentes, la gestión de cuentas y el consenso. TRON implementa una máquina virtual basada en pila, la Máquina Virtual de TRON (TVM), que utiliza un conjunto de instrucciones optimizado. Para apoyar mejor a los desarrolladores de DApps, se eligió Solidity como lenguaje de contratos inteligentes, con soporte futuro para otros lenguajes avanzados. Además, el mecanismo de consenso de TRON se basa en la Prueba de Participación Delegada (DPoS), incorporando numerosas innovaciones para satisfacer sus requisitos únicos.

2.2 Capa de Almacenamiento

El protocolo de almacenamiento distribuido único de TRON consiste en Almacenamiento de Bloques y Almacenamiento de Estado. El concepto de base de datos de grafos fue introducido 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 del Blockchain

El almacenamiento del blockchain de TRON utiliza LevelDB, desarrollado por Google y con éxito comprobado en numerosas empresas y proyectos. Ofrece alto rendimiento y soporta matrices de bytes arbitrarias tanto como claves como valores, operaciones sobre claves individuales (get, put, delete), operaciones por lotes (put, delete), iteradores bidireccionales y compresión simple utilizando el rápido algoritmo Snappy.

2.2.2 Almacenamiento de Estado

TRON dispone de una KhaosDB en la memoria del nodo completo que puede almacenar todas las cadenas bifurcadas recién generadas dentro de un período de tiempo determinado. Esto permite a los SRs cambiar rápidamente de su propia cadena activa a una nueva cadena principal. También protege el almacenamiento del blockchain haciéndolo más estable ante una terminación anormal en un estado intermedio.

Arquitectura de 3 capas de TRON — Figura 2: *Arquitectura de 3 Capas de TRON*

2.3 Capa de Aplicación

Los desarrolladores pueden crear una amplia variedad de DApps y billeteras personalizadas en TRON. Dado que TRON permite la implementación y ejecución de contratos inteligentes, soporta un amplio espectro de posibles casos de uso.

2.4 Protocolo

El protocolo TRON se adhiere a Google Protocol Buffers, que es una forma neutral en cuanto a lenguaje, neutral en cuanto a plataforma y extensible de serializar datos estructurados para su uso en protocolos de comunicación, almacenamiento de datos y más.

2.4.1 Protocol Buffers

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

Las definiciones de Protobuf (.proto) pueden usarse para generar código para los lenguajes C++, Java, C#, Python, Ruby, Golang y Objective-C mediante los generadores de código oficiales. También están disponibles diversas implementaciones de terceros para muchos otros lenguajes. Protobuf simplifica el desarrollo de clientes al unificar las definiciones de la API y también optimiza las transferencias de datos. Los clientes pueden usar el API.proto del repositorio del protocolo de TRON e integrarse mediante las bibliotecas de código generadas automáticamente.

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 de forma programática.

2.4.2 HTTP

El Protocolo TRON proporciona una API HTTP RESTful como alternativa a la API Protobuf. Comparten la misma interfaz, pero la API HTTP puede utilizarse fácilmente en clientes JavaScript.

2.5 Máquina Virtual de TRON (TVM)

La TVM es una máquina virtual ligera y Turing-completa desarrollada para el ecosistema de TRON. La TVM se conecta sin problemas con el ecosistema de desarrollo existente para proporcionar a millones de desarrolladores en todo el mundo un sistema blockchain a medida que es eficiente, conveniente, estable, seguro y escalable.

3 Consenso

3.1 Prueba de Participación Delegada (DPoS)

El mecanismo de consenso más antiguo es la Prueba de Trabajo (PoW). Este protocolo es implementado actualmente por Bitcoin y Ethereum. En los sistemas PoW, las transacciones transmitidas a través de la red se agrupan en bloques incipientes para su confirmación por parte de los mineros. Este proceso de confirmación implica el hash de las transacciones mediante algoritmos de hash criptográficos hasta alcanzar una raíz de Merkle, creando un árbol de Merkle:

Figura 3: 8 transacciones TRX son hasheadas hasta la raíz de Merkle. Esta raíz de Merkle se incluye luego en el encabezado del bloque, el cual se adjunta a los bloques confirmados anteriormente para formar un blockchain. Esto permite el seguimiento fácil y transparente de transacciones, marcas de tiempo y otra información relacionada.

Los algoritmos de hash criptográficos son útiles para la prevención de ataques a la red porque poseen varias propiedades:

Tamaño de entrada/salida: El algoritmo puede recibir una entrada de cualquier tamaño y produce un valor de hash de longitud fija.
Eficiencia: El algoritmo es relativamente fácil y rápido de calcular.
Resistencia a preimagen: Para una salida dada $z$ , es imposible encontrar cualquier entrada $x$ tal que $h(x) = z$ . En otras palabras, el algoritmo de hash $h(x)$ es una función unidireccional en la que solo se puede encontrar la salida dado un valor de entrada. El proceso inverso no es posible.
Resistencia a colisiones: Es computacionalmente inviable encontrar pares $x_1 \neq x_2$ tales que $h(x_1) = h(x_2)$ . En otras palabras, la probabilidad de encontrar dos entradas diferentes que produzcan la misma salida es extremadamente baja. Esta propiedad también implica resistencia a segunda preimagen.
Resistencia a segunda preimagen: Dado $x_1$ , y por tanto $h(x_1)$ , es computacionalmente inviable encontrar cualquier $x_2$ tal que $h(x_1) = h(x_2)$ . Aunque esta propiedad es similar a la resistencia a colisiones, difiere en que indica que un atacante con un $x_1$ dado encontrará computacionalmente inviable hallar cualquier $x_2$ que produzca la misma salida.
Determinismo: asigna cada entrada a una y solo una salida.
Efecto avalancha: un pequeño cambio en la entrada produce una salida completamente diferente.

Estas propiedades otorgan a la red de criptomonedas su valor intrínseco al garantizar que los ataques no comprometan la red. Cuando los mineros confirman un bloque, son recompensados con tokens como un incentivo integrado para la participación en la red. Sin embargo, a medida que la capitalización global del mercado de criptomonedas aumentó de manera constante, los mineros se centralizaron y enfocaron sus recursos informáticos en acumular tokens como activos, en lugar de hacerlo con propósitos de participación en la red. Los mineros de CPU cedieron paso a las GPU, que a su vez cedieron paso a los potentes ASICs.

Para resolver el problema del desperdicio de energía, el mecanismo de consenso de Prueba de Participación (PoS) fue propuesto por muchas nuevas redes. En las redes PoS, los tenedores de tokens bloquean sus saldos para convertirse en validadores de bloques. Los validadores se turnan para proponer y votar el siguiente bloque. Sin embargo, el problema del PoS estándar es que la influencia del validador se correlaciona directamente con la cantidad de tokens bloqueados. Esto resulta en que las partes que acumulan grandes cantidades de la moneda base de la red ejercen una influencia indebida en el ecosistema de la red.

El mecanismo de consenso de TRON utiliza un innovador sistema de Prueba de Participación Delegada en el que 27 SRs producen bloques para la red. Cada 6 horas, los titulares de cuentas TRX que congelen sus cuentas pueden votar por una selección de candidatos a SR, y los 27 candidatos con más votos son considerados los SRs. Los votantes pueden elegir SRs en función de criterios como los proyectos patrocinados por los SRs para aumentar la adopción de TRX y las recompensas distribuidas a los votantes. Esto permite un ecosistema más democratizado y descentralizado. Las cuentas de los SRs son cuentas normales, pero la acumulación de votos les permite producir bloques. Con las bajas tasas de procesamiento de Bitcoin y Ethereum debidas a su mecanismo de consenso PoW y sus problemas de escalabilidad, el sistema DPoS de TRON ofrece un mecanismo innovador que resulta en 2000 Transacciones Por Segundo (TPS) en comparación con las 3 TPS de Bitcoin y las 15 TPS de Ethereum.

La red del protocolo TRON genera un bloque cada tres segundos, otorgando 16 TRX a los SRs por cada bloque. Un total de 168,192,000 TRX serán otorgados anualmente a los 27 SRs. Cada vez que un SR finaliza la producción de un bloque, las recompensas se envían a una subcuenta en el super-libro de contabilidad. Los SRs pueden consultar, pero no utilizar directamente, estos tokens TRX. Cada SR puede realizar un retiro una vez cada 24 horas, transfiriendo las recompensas de la subcuenta a la cuenta SR especificada.

Los tres tipos de nodos en la red TRON son el Nodo Testigo, el Nodo Completo y el Nodo Completo Lite. Los nodos testigo son configurados por los SRs y son responsables principalmente de la producción de bloques y la creación/votación de propuestas. Los nodos completos proporcionan APIs y transmiten transacciones y bloques. Los nodos Solidity sincronizan bloques desde otros Nodos Completos y también proporcionan APIs indexables.

4 Cuenta

4.1 Tipos

La red TRON cuenta con dos tipos principales de cuentas:

Cuentas de Propiedad Externa (EOAs): Estas cuentas están controladas por una clave privada. Se utilizan para enviar TRX y tokens, votar por Super Representantes e implementar contratos inteligentes. Una cuenta EOA puede mantener saldos de TRX, tokens TRC-10 y tokens TRC-20/TRC-721 (mediante interacción con cuentas de contrato). Este es el tipo de cuenta más común, utilizado por todos los usuarios de billeteras.
Cuentas de Contrato: Son cuentas de contratos inteligentes controladas por la lógica de su código. Una cuenta de contrato no tiene clave privada y se activa al momento de su creación. Sus funciones pueden ser invocadas por cualquier EOA u otro contrato, según lo permita su código.

4.2 Creación

Existen tres formas de crear una cuenta TRON:

Crear una cuenta sin conexión usando la billetera de línea de comandos wallet-cli;
Crear una cuenta sin conexión usando un SDK, como el Trident SDK;
Crear una clave privada y su dirección correspondiente a través de una aplicación de billetera.

Las cuentas pueden activarse de las siguientes dos formas:

Enviar cualquier cantidad de TRX o tokens TRC-10 desde una cuenta existente a la nueva cuenta;
Llamar a la API wallet/createaccount de Java-tron para crear una transacción desde una cuenta existente, luego firmar la transacción y transmitirla a la red TRON.

También se puede generar un par de claves sin conexión compuesto por una dirección (clave pública) y una clave privada, que no es registrado por la red TRON. El algoritmo de generación de direcciones de usuario consiste en generar un par de claves y luego extraer la clave pública (matriz de bytes de 64 bytes que representa las coordenadas x, y). Se hace un hash de la clave pública usando la función SHA3-256 (el protocolo SHA3 adoptado es KECCAK-256) y se extraen los últimos 20 bytes del resultado. Se agrega 41 al inicio de la matriz de bytes y se asegura que la longitud inicial de la dirección sea de 21 bytes. Se hace un hash de la dirección dos veces usando la función SHA3-256 y se toman los primeros 4 bytes como código de verificación. Se agrega el código de verificación al final de la dirección inicial y se obtiene la dirección en formato base58check mediante codificación base58. Una dirección codificada del Mainnet comienza con T y tiene una longitud de 34 bytes.

4.3 Estructura

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

account_name: El nombre de la cuenta - por ejemplo, CuentaDeBill;
type: El tipo de cuenta - por ejemplo, 0 (representa el tipo ‘Normal’);
address: El identificador único para la cuenta en la red TRON - por ejemplo, T9yD… 9mGg;
balance: El saldo de TRX de la cuenta - por ejemplo, 4213312;
vote: Votos recibidos por la cuenta - por ejemplo, {("0x1b7w. . . 9xj3",323), ("0x8djq. . . j12m",88), . . . ,("0x82nd. . . mx6i",10001)};
asset: Otros activos, además de TRX, mantenidos en la cuenta - por ejemplo, {<"WishToken", 66666>, <"Dogie", 233>}.
latest_operation_time: La marca de tiempo de la operación más reciente de la cuenta.

Estructura de datos Protobuf:

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

5 Bloque

Un bloque generalmente contiene un encabezado de bloque y varias transacciones. Estructura de datos Protobuf:

message Block {
  BlockHeader block_header = 1;
  repeated Transaction transactions = 2;
}

5.1 Encabezado de Bloque

Un encabezado de bloque contiene datos sin procesar, la firma del testigo y el blockID. Estructura de datos Protobuf:

message BlockHeader {
  message raw {
    int64 timestamp = 1;
    bytes txTrieRoot = 2;
    bytes parentHash = 3;
    int64 number = 7;
    int64 witness_id = 8;
    bytes witness_address = 9;
    int32 version = 10;
    bytes accountStateRoot = 11;
  }
  raw raw_data = 1;
  bytes witness_signature = 2;
}

5.1.1 Datos Sin Procesar

Los datos sin procesar se denotan como raw_data en Protobuf. Contienen los datos sin procesar de un mensaje, con 8 parámetros:

timestamp: marca de tiempo de este mensaje - por ejemplo, 1543884429000.
txTrieRoot: la Raíz del Árbol de Merkle - por ejemplo, 7dacsa… 3ed.
parentHash: el hash del último bloque - por ejemplo, 7dacsa… 3ed.
number: la altura del bloque - por ejemplo, 4638708.
version: reservado - por ejemplo, 5.
witness_address: la dirección del testigo empaquetado en este bloque - por ejemplo, 41928c…4d21.
witness_id: el ID del testigo que empaquetó este bloque - por ejemplo, ” 0xu82h… 7237 ”.
accountStateRoot: la dirección del testigo que empaquetó este bloque - por ejemplo, ” 0xu82h… 7237 “.

5.1.2 Firma del Testigo

La firma del testigo se denota como witness_signature en Protobuf, que es la firma del encabezado de este bloque proveniente del nodo testigo.

5.1.3 ID de Bloque

El ID de bloque se denota como blockID en Protobuf. Contiene la identificación atómica de un bloque. Un ID de Bloque contiene 2 parámetros:

hash: el hash del bloque.
number: el hash y la altura del bloque.

5.2 Transacción

5.2.1 Firma

El proceso de firma de transacciones de TRON sigue el algoritmo criptográfico ECDSA estándar, con una 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 la clave pública consiste primero en generar 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 ocurre una transacción, los datos sin procesar de la transacción se convierten primero a formato byte. Los datos sin procesar se someten luego a un hash SHA-256. La clave privada correspondiente a la dirección del contrato firma el resultado del hash SHA256. El resultado de la firma se agrega luego a la transacción.

5.2.2 Modelo de Ancho de Banda

Las transacciones ordinarias solo consumen Puntos de Ancho de Banda, pero las operaciones de contratos inteligentes consumen tanto Energía como Puntos de Ancho de Banda. Hay dos tipos de Puntos de Ancho de Banda disponibles. Los usuarios pueden obtener Puntos de Ancho de Banda congelando TRX, mientras que también hay Puntos de Ancho de Banda gratuitos diarios disponibles diariamente.

Cuando se transmite una transacción TRX, se transmite y almacena en forma de una matriz de bytes a través de la red. Los Puntos de Ancho de Banda consumidos por una transacción = número de bytes de la 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 de TRX o token resulta en la creación de la cuenta de destino, entonces solo se deducirán los Puntos de Ancho de Banda consumidos para crear la cuenta, sin deducir Puntos de Ancho de Banda adicionales. Cuando una transferencia crea una cuenta con Ancho de Banda disponible insuficiente, se deducirá una comisión de creación de cuenta controlada por propuesta de 0.1 TRX. Las transacciones de creación de cuenta actualmente tienen un límite de tamaño de 1000 bytes, también gobernado por propuesta. En un escenario de creación de cuenta, la red consumirá primero los Puntos de Ancho de Banda que el iniciador de la transacción obtuvo por congelar TRX. Si esta cantidad es insuficiente, la red consume el TRX del iniciador de la transacción.

En los escenarios de transferencia estándar de TRX de una cuenta a otra, la red consume primero los Puntos de Ancho de Banda obtenidos por el iniciador de la transacción al congelar TRX. Si eso es insuficiente, consume de los Puntos de Ancho de Banda gratuitos diarios. Si todavía no es suficiente, la red consume el TRX del iniciador de la transacción. La cantidad se calcula por el número de bytes de la transacción multiplicado por el costo de TRX por byte. Por tanto, para la mayoría de los titulares de TRX que pueden no necesariamente congelar su TRX para participar en la votación de SRs, el primer paso se omite automáticamente (ya que el saldo TRX congelado = 0) y el Ancho de Banda gratuito diario impulsa la transacción.

Para las transferencias de tokens TRC-10, la red primero verifica si los Puntos de Ancho de Banda gratuitos totales del activo de token emitido son suficientes. Si no, se consumen los Puntos de Ancho de Banda obtenidos al congelar TRX. Si aún no hay suficientes Puntos de Ancho de Banda, se consume el TRX del iniciador de la transacción.

5.2.3 Comisión

La red TRON generalmente no cobra comisiones por la mayoría de las transacciones; sin embargo, debido a restricciones del sistema y equidad, el uso de Ancho de Banda y las transacciones sí incurren en ciertas comisiones.

Los cargos por comisiones se dividen en las siguientes categorías:

Las transacciones normales cuestan Puntos de Ancho de Banda. Los usuarios pueden usar los Puntos de Ancho de Banda gratuitos diarios o congelar TRX para obtener más. Cuando los Puntos de Ancho de Banda no son suficientes, el TRX se usará directamente desde la cuenta remitente. El TRX necesario es el número de bytes * costo de TRX por byte.
Los contratos inteligentes cuestan Energía (Sección 6) pero también necesitarán Puntos de Ancho de Banda para que la transacción sea transmitida y confirmada. El costo de Ancho de Banda es el mismo que el anterior.
Todas las transacciones de consulta son gratuitas. No cuestan Energía ni Ancho de Banda.

La red TRON también define un conjunto de comisiones fijas para las siguientes transacciones (para los valores más recientes, consulta la API de Parámetros de la Cadena TRON):

Emitir un token TRC-10: 1,024 TRX (ver getAssetIssueFee)
Solicitar ser candidato a SR: 9,999 TRX (ver getAccountUpgradeCost)
Crear una transacción Bancor: 1,024 TRX (ver getExchangeCreateFee)
Actualizar el permiso de la cuenta: 100 TRX (ver getUpdateAccountPermissionFee)
Activar la cuenta: 1 TRX (ver getCreateNewAccountFeeInSystemContract); el Ancho de Banda insuficiente obtenido mediante staking en la cuenta del creador incurre en una comisión adicional de 0.1 TRX para pagar el Ancho de Banda (ver getCreateAccountFee)
Transacción multifirma: 1 TRX (ver getMultiSignFee)
Nota de transacción: 1 TRX (ver getMemoFee)

5.2.4 Transacción como Prueba de Participación (TaPoS)

TRON utiliza TaPoS para garantizar que todas las transacciones confirmen el blockchain principal, dificultando al mismo tiempo la falsificación de cadenas. En TaPoS, las redes requieren que cada transacción incluya parte del hash de un encabezado de bloque reciente. Este requisito evita que las transacciones sean reproducidas en bifurcaciones que no incluyan el bloque referenciado, y también señala a la red que un usuario particular y su participación están en una bifurcación específica. Este mecanismo de consenso protege la red contra ataques de Denegación de Servicio, del 51%, de minería egoísta y de doble gasto.

5.2.5 Confirmación de Transacción

Una transacción se incluye en un bloque tras ser transmitida a la red. La transacción se considera confirmada después de que su bloque haya sido seguido por 19 bloques subsiguientes, cada uno producido por un Super Representante diferente.

Cada bloque tarda $\sim3$ segundos en ser minado en el blockchain. El tiempo puede variar ligeramente para cada SR debido a las condiciones de la red y las configuraciones de la máquina. En general, una transacción se considera completamente confirmada después de $\sim1$ minuto.

5.2.6 Estructura

Las APIs de transacción consisten en las siguientes funciones:

message Transaction {
  message Contract {
    enum ContractType {
      AccountCreateContract = 0; // Crear cuenta/billetera
      TransferContract = 1; // Transferir TRX
      TransferAssetContract = 2; // Transferir token TRC-10
      VoteWitnessContract = 4; // Votar por SR
      WitnessCreateContract = 5; // Crear una nueva cuenta SR
      AssetIssueContract = 6; // Crear un nuevo token TRC-10
      WitnessUpdateContract = 8; // Actualizar información del SR
      ParticipateAssetIssueContract = 9; // Comprar token TRC-10
      AccountUpdateContract = 10; // Actualizar información de cuenta/billetera
      FreezeBalanceContract = 11; // Congelar TRX para Ancho de Banda o Energía
      UnfreezeBalanceContract = 12; // Descongelar TRX
      WithdrawBalanceContract = 13; // Retirar recompensas de SR, una vez por día
      UnfreezeAssetContract = 14; // Descongelar token TRC-10
      UpdateAssetContract = 15; // Actualizar información de un token TRC-10
      ProposalCreateContract = 16; // Crear una nueva propuesta de red por cualquier SR
      ProposalApproveContract = 17; // El SR vota sí en una propuesta de red
      ProposalDeleteContract = 18; // Eliminar una propuesta de red por su creador
      CreateSmartContract = 30; // Implementar un nuevo contrato inteligente
      TriggerSmartContract = 31; // Llamar a una función de un contrato inteligente
      GetContract = 32; // Obtener un contrato inteligente existente
      UpdateSettingContract = 33; // Actualizar los parámetros de un contrato inteligente
      ExchangeCreateContract = 41; // Crear un par de trading de tokens en DEX
      ExchangeInjectContract = 42; // Inyectar fondos en un par de trading
      ExchangeWithdrawContract = 43; // Retirar fondos de un par de trading
      ExchangeTransactionContract = 44; // Realizar trading de tokens
      UpdateEnergyLimitContract = 45; // Actualizar origin_energy_limit en un contrato inteligente
      AccountPermissionUpdateContract = 46; // Actualizar permisos de cuenta
      ClearABIContract = 48; // Limpiar el ABI de un contrato inteligente
      UpdateBrokerageContract = 49; // Actualizar tasa de comisión de brokerage del SR
      MarketSellAssetContract = 52; // Colocar una orden de venta en el mercado
      MarketCancelOrderContract = 53; // Cancelar una orden de mercado existente
      FreezeBalanceV2Contract = 54; // Congelar TRX para obtener recursos
      UnfreezeBalanceV2Contract = 55; // Cancelar TRX congelado
      WithdrawExpireUnfreezeContract = 56; // Retirar TRX tras el vencimiento del período de espera de descongelamiento
      DelegateResourceContract = 57; // Delegar Ancho de Banda o Energía a otra cuenta
      UnDelegateResourceContract = 58; // Cancelar recurso delegado
      CancelAllUnfreezeV2Contract = 59; // Cancelar todas las operaciones de descongelamiento pendientes
    }
    ContractType type = 1;
    google.protobuf.Any parameter = 2;
    bytes provider = 3;
    bytes ContractName = 4;
    int32 Permission_id = 5;
  }
}

6 Máquina Virtual de TRON (TVM)

6.1 Introducción

La Máquina Virtual de TRON (TVM) es una máquina virtual ligera y Turing-completa desarrollada para el ecosistema de TRON. Su objetivo es proporcionar un sistema blockchain a medida que sea eficiente, conveniente, estable, seguro y escalable.

La TVM fue inicialmente una bifurcación de la EVM y puede conectarse sin problemas con el ecosistema de desarrollo de contratos inteligentes de Solidity existente. Basándose en eso, la TVM adicionalmente soporta el consenso DPoS.

La TVM introduce el concepto de Energía para gestionar los recursos computacionales, lo que difiere del mecanismo de Gas de la EVM. En la TVM, la ejecución de contratos inteligentes consume Energía. Los usuarios pueden obtener Energía haciendo staking de TRX. Cuando una cuenta tiene suficiente Energía, la ejecución de operaciones de contratos inteligentes no requiere la quema directa de TRX. Cuando la Energía disponible es insuficiente, el sistema quemará TRX de la cuenta para cubrir los costos computacionales.

6.2 Flujo de Trabajo

El compilador primero traduce el contrato inteligente de Solidity en bytecode legible y ejecutable en la TVM. La TVM luego procesa los datos a través del código de operación (opcode), que equivale a operar la lógica de una máquina de estado finito basada en pila. Finalmente, la TVM accede a los datos del blockchain e invoca la Interfaz de Datos Externa a través de la capa de Interoperación.

6.3 Rendimiento

6.3.1 Arquitectura Ligera

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

6.3.2 Robustez

TRON emplea un modelo de doble recurso (que comprende Ancho de banda y Energía) para el procesamiento de transacciones y la ejecución de contratos inteligentes. Los usuarios pueden adquirir principalmente estos recursos sin costo transaccional directo congelando TRX. Cuando se superan los límites de recursos, el TRX se consume (se quema) de manera proporcional al exceso de uso. Este sistema de gestión de recursos mejora la seguridad de la red al aumentar significativamente el costo económico de las actividades maliciosas y garantiza un consumo de recursos predecible gracias a los costos unitarios fijos para cada operación.

6.3.3 Alta Compatibilidad

La TVM es compatible con la EVM y será compatible con más máquinas virtuales convencionales en el futuro. De este modo, todos los contratos inteligentes de la EVM son ejecutables en la TVM.

6.3.4 Bajo Costo

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

7 Contrato Inteligente

7.1 Introducción

Un contrato inteligente es un protocolo que verifica digitalmente la negociación de un contrato. Definen las reglas y penalizaciones relacionadas con un acuerdo y también imponen automáticamente esas obligaciones. El código del contrato inteligente facilita, verifica y hace cumplir la negociación o el cumplimiento de un acuerdo o transacción. Desde la perspectiva de la tokenización, los contratos inteligentes también facilitan las transferencias automáticas de fondos entre las partes participantes en caso de que se cumplan ciertos criterios.

Los contratos inteligentes de TRON están escritos en el lenguaje Solidity. Una vez escritos y probados, pueden ser compilados en bytecode y luego implementados en la red TRON para la Máquina Virtual de TRON. Una vez implementados, los contratos inteligentes pueden ser consultados a través de sus direcciones de contrato. La Interfaz Binaria de Aplicación (ABI) del contrato muestra las funciones de llamada del contrato y se utiliza para interactuar con la red.

7.2 Modelo de Energía

El límite máximo de Energía para la implementación y la ejecución de un contrato inteligente es función de varias variables:

Energía Dinámica por congelar 1 TRX es 180,000,000,000 (Límite Total de Energía) / (Peso Total de Energía)
Límite de Energía es el límite diario de Energía de la cuenta obtenido al congelar TRX
Energía diaria restante de la cuenta proveniente de congelar TRX se calcula como Límite de Energía - Energía Usada
Límite de comisiones en TRX se establece en la llamada de implementación/ejecución del contrato inteligente
TRX utilizable restante en la cuenta
Energía por TRX si se compra directamente (210 SUN = 1 Energía) = 100,000, los SRs pueden votar sobre los ajustes

Hay dos escenarios de consumo para calcular el límite máximo de Energía para la implementación y la ejecución. La lógica se puede expresar de la siguiente manera:

const R = Límite Dinámico de Energía
const F = Energía diaria de la cuenta por congelar TRX
const E = Energía diaria restante de la cuenta por congelar TRX
const L = Límite de comisiones en TRX establecido en la llamada de implementación/ejecución
const T = TRX utilizable restante en la cuenta
const C = Energía por TRX si se compra directamente
// Calcular M, definido como el límite máximo de Energía para la implementación/ejecución de un contrato inteligente
if F > L*R
    let M = min(E+T*C, L*R)
else
    let M = E+T*C

Desde el 5 de febrero de 2023, la red TRON ha implementado un nuevo modelo dinámico de Energía, habilitado por la propuesta del comité No. 83 iniciada por la comunidad de desarrolladores de TRON. Este modelo ajusta dinámicamente el consumo de Energía de cada contrato de acuerdo con la ocupación de recursos del contrato. Esto tiene como objetivo hacer que la asignación de recursos de Energía en la cadena sea más razonable y evitar la concentración excesiva de recursos de red en unos pocos contratos populares.

7.3 Implementación

Cuando un contrato inteligente de Solidity de TRON se compila, la Máquina Virtual de TRON lee el bytecode compilado. El bytecode consta de una sección para la implementación del código, el código del contrato y el Auxdata. El Auxdata es la huella criptográfica del código fuente, utilizada para la verificación. El bytecode de implementación ejecuta la función constructora y establece las variables de almacenamiento iniciales. El código de implementación también calcula el código del contrato y se lo devuelve a la TVM. La ABI es un archivo JSON que describe las funciones de un contrato inteligente de TRON. Este archivo define los nombres de las funciones, su capacidad de pago (payability), los valores de retorno de la función y la mutabilidad de su estado.

7.4 Función de Ejecución (Trigger)

Una vez que los contratos inteligentes de TRON se han implementado, sus funciones pueden ejecutarse individualmente ya sea a través de Tronide o mediante llamadas a la API. Las funciones que cambian el estado requieren Energía, mientras que las funciones de solo lectura se ejecutan sin Energía.

7.5 TRON Solidity

TRON Solidity es una bifurcación del lenguaje Solidity de Ethereum. TRON modifica el proyecto original para soportar las unidades TRX y SUN (1 TRX = 1,000,000 SUN). El resto de la sintaxis del lenguaje es compatible con Solidity 0.8.23. Por lo tanto, la Máquina Virtual de TRON (TVM) es casi 100% compatible con las instrucciones de la EVM.

8 Token

8.1 Token TRC-10

En la red TRON, cada cuenta puede emitir tokens a expensas de 1024 TRX. Para emitir tokens, el emisor debe especificar el nombre del token, la capitalización total, el tipo de cambio con TRX, la duración de la circulación, la descripción, el sitio web, el consumo máximo de Ancho de banda por cuenta, el consumo total de Ancho de banda y la cantidad de tokens congelados. Cada emisión de tokens también puede configurar los Puntos de Ancho de banda diarios máximos de la transferencia de tokens de cada cuenta, los Puntos de Ancho de banda diarios máximos de la transferencia de tokens de toda la red, el suministro total de tokens, la duración del bloqueo en días y la cantidad total de tokens bloqueados.

8.2 Token TRC-20

TRC-20 es un estándar técnico utilizado para los contratos inteligentes que implementan tokens compatibles con la Máquina Virtual de TRON. Es totalmente compatible con ERC-20.

La interfaz es la siguiente:

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

Las transferencias de tokens TRC-10 consumen principalmente Ancho de banda, mientras que las transferencias de tokens TRC-20 consumen tanto Ancho de banda como Energía. Esta diferencia en el consumo de recursos a menudo resulta en comisiones de transacción significativamente más bajas para los tokens TRC-10 en comparación con los TRC-20. Aunque las transferencias por API y los depósitos de tokens TRC-10 incurren en costos de Ancho de banda, el costo generalmente se mantiene más bajo que la combinación de Ancho de banda y Energía de las transacciones TRC-20. Las transferencias y los depósitos en contratos inteligentes para tokens TRC-10 cuestan tanto Ancho de banda como Energía. Por el contrario, los TRC-20 consumen consistentemente tanto Ancho de banda como Energía para transferencias y depósitos, ya sea a través de llamadas a la API o contratos inteligentes.

8.3 Más allá

Dado que TRON utiliza la misma versión de Solidity que Ethereum, se podrían portar fácilmente más estándares de tokens a TRON.

9 Gobernanza

9.1 Super Representante

9.1.1 General

Cada cuenta en la red TRON puede postularse y tener la oportunidad de convertirse en un Super Representante (SR). Todos pueden votar por los candidatos a SR. Los 27 candidatos con la mayor cantidad de votos se convertirán en SRs con el derecho y la obligación de generar bloques. Los votos se cuentan cada 6 horas y los SRs cambiarán en consecuencia.

Para evitar ataques maliciosos, existe un costo para convertirse en candidato a SR. Al momento de la solicitud, se quemarán 9999 TRX de la cuenta del solicitante. Una vez exitosa, dicha cuenta puede participar en la elección de SR.

9.1.2 Elección

El TRON Power (denotado como TP) es necesario para votar y la cantidad de TP depende de los activos congelados del votante (TRX).

El TP se calcula de la siguiente manera:

$1 \text{ TP} = 1 \text{ TRX congelado para obtener Energía/Ancho de banda}$

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

Después de la liberación (descongelamiento, disponible tras 14 días), los usuarios no tendrán ningún activo congelado y perderán todo el TP en consecuencia. Como resultado, todos los votos quedan invalidados para la ronda de votación actual y futura, a menos que se vuelva a congelar TRX para votar.

Ten en cuenta que la red TRON solo registra el voto más reciente, lo que significa que cada nuevo voto negará todos los votos anteriores.

9.1.3 Recompensa

a. Recompensa por Voto

También conocida como Recompensa por Candidato, en la que los 127 mejores candidatos, actualizados una vez cada ronda (6 horas), compartirán 921,600 TRX a medida que se minen. La recompensa se dividirá de acuerdo con el peso de los votos que reciba cada candidato. Cada año, la recompensa total para los candidatos será de 1,345,536,000 TRX.

Recompensa total por voto por ronda

¿Por qué 921,600 TRX en cada ronda?

$921,600 \text{ TRX} = \text{recompensa total por voto por ronda } (VR/\text{ronda})$

$VR/\text{ronda} = 128 \text{ TRX/bloque} \times 20 \text{ bloques/min} \times 60 \text{ mins/h} \times 6 \text{ hs/ronda}$

Nota: esto lo establece WITNESS_127_PAY_PER_BLOCK = 128 TRX. Consulta los parámetros dinámicos de red.

Recompensa total por voto por año

¿Por qué 1,345,536,000 TRX cada año?

$1,345,536,000 \text{ TRX} = \text{recompensa total por voto por año } (VR/\text{año})$

$VR/\text{año} = 921,600 \text{ TRX/ronda} \times 4 \text{ rondas/día} \times 365 \text{ días/año}$

b. Recompensa por Bloque

También conocida como Recompensa de Super Representante, en la que los 27 mejores candidatos (SRs) elegidos en cada ronda (6 horas) compartirán aproximadamente 57,600 TRX a medida que se minen. La recompensa se dividirá equitativamente entre los 27 SRs (menos el total de bloques de recompensa perdidos debido a un error de red). Un total de 84,096,000 TRX se otorgarán anualmente a los 27 SRs.

Recompensa total por bloque por ronda

¿Por qué 57,600 TRX en cada ronda?

$57,600 \text{ TRX} = \text{recompensa total por bloque por ronda } (BR/\text{ronda})$

$BR/\text{ronda} = 8 \text{ TRX/bloque} \times 20 \text{ bloques/min} \times 60 \text{ mins/h} \times 6 \text{ hs/ronda}$

Nota: la recompensa unitaria por bloque la establece WITNESS_PAY_PER_BLOCK = 8 TRX. Consulta los parámetros dinámicos de red.

Recompensa total por bloque por año

¿Por qué 84,096,000 TRX cada año?

$84,096,000 \text{ TRX} = \text{recompensa total por bloque por año } (BR/\text{año})$

$BR/\text{año} = 57,600 \text{ TRX/ronda} \times 4 \text{ rondas/día} \times 365 \text{ días/año}$

c. Cálculo de la Recompensa

Cálculo de la recompensa del SR

$\text{recompensa total} = \text{recompensa por voto}(VR) + \text{recompensa por bloque}(BR)$

$VR = \text{total } VR \times \frac{\text{votos recibidos por el candidato a SR}}{\text{total de votos}}$

$BR = \frac{\text{total } BR}{27} - \text{bloques perdidos} \times 32$

Nota: la recompensa se calcula por SR por ronda (6 horas)

Cálculo de la recompensa del candidato a SR del rango 28 al 127

$\text{recompensa total} = \text{recompensa por voto}(VR)$

$VR = \text{total } VR \times \frac{\text{votos recibidos por el candidato a SR}}{\text{total de votos}}$

Nota: la recompensa se calcula por candidato a SR por ronda (6 horas)

9.2 Comité

9.2.1 General

El comité se utiliza para modificar los parámetros dinámicos de la red TRON, como las recompensas por generación de bloques, las comisiones de transacción, etc. El comité consta de los 27 SRs en la ronda actual. Cada SR tiene el derecho de proponer y votar sobre propuestas. Cuando una propuesta recibe 19 votos o más, es aprobada y los nuevos parámetros de red se aplicarán en el próximo período de mantenimiento (3 días).

9.2.2 Parámetros Dinámicos de Red

Consulta el Apéndice B para obtener más detalles.

9.2.3 Crear Propuesta

Solo las cuentas SR tienen derecho a proponer un cambio en los parámetros dinámicos de red.

9.2.4 Votar Propuesta

Solo los miembros del comité (SRs) pueden votar por una propuesta y el miembro que no vote a tiempo se considerará en desacuerdo. La propuesta permanece activa durante 3 días después de su creación. El voto puede cambiarse o recuperarse durante el período de votación de 3 días. Una vez que finaliza el período, la propuesta tendrá éxito (19+ votos) o fracasará (y finalizará).

9.2.5 Cancelar Propuesta

El proponente puede cancelar la propuesta antes de que se vuelva efectiva.

9.3 Estructura

Los SRs son los testigos de los bloques recién generados. Un testigo contiene 8 parámetros:

address: la dirección de este testigo - por ejemplo, 0xu82h… 7237.
voteCount: número de votos recibidos en este testigo - por ejemplo, 234234.
pubKey: la clave pública de este testigo - por ejemplo, 0xu82h… 7237.
url: la url de este testigo - por ejemplo, https://www.noonetrust.com.
totalProduced: el número de bloques que ha producido este testigo - por ejemplo, 2434.
totalMissed: el número de bloques perdidos por este testigo - por ejemplo, 7.
latestBlockNum: la altura del bloque más reciente - por ejemplo, 4522.
isjobs: una bandera booleana.

Estructura de datos Protobuf:

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

10 Desarrollo de DApps

10.1 APIs

La red TRON ofrece una amplia selección de más de 60 puertas de enlace de la API HTTP para interactuar con la red a través de Nodos Completos. Además, TronWeb es una biblioteca completa de JavaScript que contiene funciones de API que permiten a los desarrolladores implementar contratos inteligentes, cambiar el estado del blockchain, consultar información de contratos y del blockchain, operar en el DEX, y mucho más. Estas puertas de enlace de API se pueden dirigir hacia una red privada local, la testnet Shasta, la testnet Nile o el Mainnet de TRON.

10.2 Redes

TRON tiene una testnet Shasta, una testnet Nile, además del Mainnet. Los desarrolladores pueden conectarse a las redes implementando nodos, o interactuando mediante las APIs de Nodo Completo en el servicio TronGrid. El servicio TronGrid consiste en grupos de nodos equilibrados en carga, alojados en servidores de AWS en todo el mundo. A medida que el desarrollo de DApps aumenta a escala y los volúmenes de llamadas a la API se incrementan, TronGrid asume con éxito el aumento en el tráfico de la API.

10.3 Recursos

El Hub para Desarrolladores de TRON es un sitio completo de documentación de API adaptado para desarrolladores que deseen construir en la red TRON. El Hub para Desarrolladores ofrece una comprensión conceptual de alto nivel de TRON y guía a los usuarios por los detalles de interacción con la red. Las guías explican paso a paso a los desarrolladores la configuración de nodos, la implementación e interacción con contratos inteligentes, la interacción e implementación de APIs, el desarrollo de DApps de muestra y el uso de cada una de las herramientas de desarrollo.

11 Conclusión

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

Apéndice A: Terminología

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

Interfaz Binaria de Aplicación (ABI) La ABI es una interfaz entre dos módulos de programa binario; generalmente uno de estos módulos es una biblioteca o una facilidad del sistema operativo, y el otro es un programa ejecutado por el usuario.

Interfaz de Programación de Aplicaciones (API) Una API se utiliza principalmente para el desarrollo de clientes de usuario. Con el soporte de API, los propios desarrolladores también pueden diseñar plataformas de emisión de tokens.

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

Puntos de Ancho de Banda (BP) Para mantener el buen funcionamiento de la red, las transacciones de la red TRON utilizan los BP como combustible. Cada cuenta obtiene una cantidad diaria gratuita de BP, definida por el parámetro freeNetLimit en la API de Parámetros de la Cadena TRON, y se pueden obtener más congelando TRX para BP. Tanto las transferencias de TRX como las de tokens TRC-10 son transacciones normales que cuestan BP. Las transacciones de implementación y ejecución de contratos inteligentes consumen tanto BP como Energía.

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

Recompensa por Bloque Las recompensas por la producción de bloques se envían a una subcuenta (dirección/billetera). Los SRs pueden reclamar 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 de TRON contienen el hash del bloque anterior, la raíz de Merkle, la marca de tiempo, la versión y la dirección del testigo.

Billetera 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 que permanecen fuera de línea) para garantizar la seguridad de la clave privada de TRX.

Aplicación Descentralizada (DApp) Una DApp es una aplicación que opera sin una parte central de confianza. Una aplicación que permite la interacción/acuerdos/comunicación directa entre los usuarios finales y/o los recursos sin un intermediario.

Llamadas a Procedimientos Remotos gRPC (gRPC) gRPC es un sistema de llamadas a procedimientos remotos (RPC) de código abierto desarrollado inicialmente por Google. Utiliza HTTP/2 para el transporte, Protocol Buffers como lenguaje de descripción de interfaz y proporciona características como autenticación, transmisión bidireccional y control de flujo, enlaces bloqueantes o no bloqueantes, y cancelación y tiempos de espera. Genera enlaces multiplataforma de cliente y servidor para muchos lenguajes. Los escenarios de uso más comunes incluyen la conexión de servicios en la arquitectura de estilo microservicios y la conexión de dispositivos móviles y clientes de navegador a servicios backend.

Billetera Caliente La billetera caliente, también conocida como billetera en línea, permite que las claves privadas de los usuarios se utilicen en línea, por lo que podría ser susceptible a posibles vulnerabilidades o a la intercepción por actores maliciosos.

Kit de Desarrollo de Java (JDK) El JDK es el SDK de Java utilizado para aplicaciones Java. Es el núcleo del desarrollo en Java, que comprende el entorno de la aplicación Java (JVM + biblioteca de clases de Java) y las herramientas de Java.

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

LevelDB LevelDB se adoptó inicialmente con el objetivo principal de cumplir con los requisitos de lectura/escritura rápida y desarrollo rápido. Después del lanzamiento del Mainnet, TRON actualizó su base de datos a una completamente personalizada que atendía sus propias necesidades. Ver 2.2.1 Almacenamiento del Blockchain para 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 una red blockchain. Ver 3.1 Prueba de Participación Delegada (DPoS) para más detalles.

Testnet Pública (Shasta, Nile) 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. Los tokens de Testnet no tienen valor y cualquiera puede solicitar más desde la faucet pública.

Llamada a procedimiento remoto (RPC) En computación distribuida, un RPC es cuando un programa de computadora hace que un procedimiento (subrutina) se ejecute en un espacio de direcciones diferente (comúnmente en otra computadora en una red compartida), que está codificado como si fuera una llamada a procedimiento normal (local), sin que el programador codifique 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 para ampliarse para acomodar ese crecimiento.

SUN SUN reemplazó al drop como la unidad más pequeña de TRX. 1 TRX = 1,000,000 SUN.

Capacidad de Procesamiento (Throughput) El alto rendimiento es una característica del Mainnet de TRON. Se mide en Transacciones Por Segundo (TPS), es decir, la capacidad máxima de transacciones en un segundo.

Marca de tiempo (Timestamp) El tiempo aproximado de producción del bloque se registra como una marca de tiempo de Unix, que es la cantidad de milisegundos transcurridos desde las 00:00:00 del 01 de enero de 1970 UTC.

TRC-10 Un estándar de token criptográfico en la plataforma TRON. Se requiere seguir ciertas reglas e interfaces cuando se lleva a cabo una oferta inicial de monedas en el blockchain de TRON.

TRX TRX es la abreviatura de Tronix, que es la criptomoneda oficial de TRON.

Apéndice B: Parámetros Dinámicos de Red

0. MAINTENANCE_TIME_INTERVAL

Descripción: Modifica el intervalo de tiempo de mantenimiento, que también es el intervalo para que los SRs calculen y distribuyan las recompensas por votación.
Ejemplo: [6 * 3600 * 1000] ms - lo que equivale a 6 horas.
Rango: [3 * 27 * 1000, 24 * 3600 * 1000] ms

1. ACCOUNT_UPGRADE_COST

Descripción: Modifica el costo para que una cuenta solicite convertirse en candidato a Super Representante.
Ejemplo: [9 999 000 000] SUN - lo que equivale a 9999 TRX.
Rango: [0, 100 000 000 000 000 000] SUN

2. CREATE_ACCOUNT_FEE

Descripción: Modifica la comisión por crear una nueva cuenta enviando TRX a una nueva dirección.
Ejemplo: [100 000] SUN - lo que equivale a 0.1 TRX.
Rango: [0, 100 000 000 000 000 000] SUN

3. TRANSACTION_FEE

Descripción: Modifica la tasa de comisión por consumir Puntos de Ancho de Banda cuando el Ancho de Banda gratuito o apostado de una cuenta es insuficiente.
Ejemplo: [10] SUN/byte.
Rango: [0, 100 000 000 000] SUN/byte

4. ASSET_ISSUE_FEE

Descripción: Modifica la comisión única por emitir un nuevo token TRC-10.
Ejemplo: [1 024 000 000] SUN - lo que equivale a 1024 TRX.
Rango: [0, 100 000 000 000 000 000] SUN

5. WITNESS_PAY_PER_BLOCK

Descripción: Modifica la recompensa pagada a un Super Representante por producir un bloque con éxito.
Ejemplo: [16 000 000] SUN - lo que equivale a 16 TRX.
Rango: [0, 100 000 000 000 000 000] SUN

6. WITNESS_STANDBY_ALLOWANCE

Descripción: Modifica la recompensa total distribuida entre los 127 principales Super Representantes y Socios por ronda.
Ejemplo: [115 200 000 000] SUN - lo que equivale a 115,200 TRX.
Rango: [0, 100 000 000 000 000 000] SUN

7. CREATE_NEW_ACCOUNT_FEE_IN_SYSTEM_CONTRACT

Descripción: Modifica la comisión por crear una nueva cuenta mediante una llamada a contrato de sistema.
Ejemplo: [0] SUN.
Rango: [0, 100 000 000 000 000 000] SUN

8. CREATE_NEW_ACCOUNT_BANDWIDTH_RATE

Descripción: Modifica el multiplicador de consumo de Ancho de Banda para crear una nueva cuenta.
Ejemplo: [1].
Rango: [0, 100 000 000 000 000 000]

9. ALLOW_CREATION_OF_CONTRACTS

Descripción: Habilita o deshabilita la creación de nuevos contratos inteligentes.
Ejemplo: True
Tipo: True/False

10. REMOVE_THE_POWER_OF_THE_GR

Descripción: Elimina el poder de votación inicial en manos de los Representantes del Génesis (GRs).
Ejemplo: True
Tipo: True/False - Nota: no se puede revertir a False desde True.

11. ENERGY_FEE

Descripción: Modifica la tasa de comisión por consumir Energía cuando la Energía de una cuenta es insuficiente.
Ejemplo: [10] SUN.
Rango: [0, 100 000 000 000 000 000] SUN

12. EXCHANGE_CREATE_FEE

Descripción: Modifica la comisión por crear un nuevo par de comercio TRC-10 en el intercambio descentralizado.
Ejemplo: [1 024 000 000] SUN - lo que equivale a 1024 TRX.
Rango: [0, 100 000 000 000 000 000] SUN

13. MAX_CPU_TIME_OF_ONE_TX

Descripción: Modifica el tiempo máximo de ejecución de la CPU permitido para una sola transacción.
Ejemplo: [50] ms.
Rango: [0, 1000] ms

14. ALLOW_UPDATE_ACCOUNT_NAME

Descripción: Habilita o deshabilita la capacidad de las cuentas para actualizar su nombre.
Ejemplo: False
Tipo: True/False

15. ALLOW_SAME_TOKEN_NAME

Descripción: Permite que se creen diferentes tokens TRC-10 con el mismo nombre.
Ejemplo: True
Tipo: True/False

16. ALLOW_DELEGATE_RESOURCE

Descripción: Habilita o deshabilita la funcionalidad de delegación de recursos (staking v1.0).
Ejemplo: True
Tipo: True/False

18. ALLOW_TVM_TRANSFER_TRC10

Descripción: Permite que los contratos inteligentes transfieran de forma nativa tokens TRC-10 mediante la llamada transferToken.
Ejemplo: True
Tipo: True/False

19. TOTAL_CURRENT_ENERGY_LIMIT

Descripción: Modifica la cantidad total actual de Energía disponible en la red.
Ejemplo: [50 000 000 000].
Rango: [0, 100 000 000 000 000 000]

20. ALLOW_MULTI_SIGN

Descripción: Habilita o deshabilita la función multifirma para las cuentas.
Ejemplo: True
Tipo: True/False

21. ALLOW_ADAPTIVE_ENERGY

Descripción: Habilita o deshabilita el modelo adaptativo de Energía.
Ejemplo: True
Tipo: True/False

22. UPDATE_ACCOUNT_PERMISSION_FEE

Descripción: Modifica la comisión por actualizar la estructura de permisos de una cuenta.
Ejemplo: [100 000 000] SUN - lo que equivale a 100 TRX.
Rango: [0, 100 000 000 000] SUN

23. MULTI_SIGN_FEE

Descripción: Modifica la comisión adicional cobrada por procesar una transacción multifirma.
Ejemplo: [1 000 000] SUN - lo que equivale a 1 TRX.
Rango: [0, 100 000 000 000] SUN

24. ALLOW_PROTO_FILTER_NUM

Descripción: Habilita o deshabilita el filtrado de mensajes de protocolo.
Ejemplo: False
Tipo: True/False

26. ALLOW_TVM_CONSTANTINOPLE

Descripción: Habilita las funciones de la actualización de Ethereum Constantinople en la TVM.
Ejemplo: True
Tipo: True/False

29. ADAPTIVE_RESOURCE_LIMIT_MULTIPLIER

Descripción: Modifica el multiplicador utilizado en el modelo de recursos adaptativo.
Ejemplo: [1000].
Rango: [1, 10000]

30. ALLOW_CHANGE_DELEGATION

Descripción: Permite a los usuarios cambiar el receptor de sus recursos delegados sin quitar el staking.
Ejemplo: True
Tipo: True/False

31. WITNESS_127_PAY_PER_BLOCK

Descripción: Modifica la recompensa por producción de bloques para los Socios clasificados del puesto 28 al 127.
Ejemplo: [160 000 000] SUN - lo que equivale a 160 TRX.
Rango: [0, 100 000 000 000 000 000] SUN

32. ALLOW_TVM_SOLIDITY_059

Descripción: Habilita la compatibilidad de TVM para contratos compilados con Solidity v0.5.9 y superiores.
Ejemplo: True
Tipo: True/False

33. ADAPTIVE_RESOURCE_LIMIT_TARGET_RATIO

Descripción: Modifica el ratio objetivo utilizado en el algoritmo del modelo de recursos adaptativo.
Ejemplo: [10].
Rango: [1, 1000]

35. FORBID_TRANSFER_TO_CONTRACT

Descripción: Prohíbe las transferencias directas de TRX a un contrato sin una función de respaldo (fallback function) pagable.
Ejemplo: True
Tipo: True/False

39. ALLOW_SHIELDED_TRC20_TRANSACTION

Descripción: Habilita o deshabilita las transacciones blindadas que preservan la privacidad para los tokens TRC-20.
Ejemplo: True
Tipo: True/False

40. ALLOW_PBFT

Descripción: Habilita o deshabilita el mecanismo de consenso PBFT para una finalización más rápida de las transacciones.
Ejemplo: True
Tipo: True/False

41. ALLOW_TVM_ISTANBUL

Descripción: Habilita las funciones de la actualización de Ethereum Istanbul en la TVM.
Ejemplo: True
Tipo: True/False

44. ALLOW_MARKET_TRANSACTION

Descripción: Habilita o deshabilita las transacciones de órdenes de mercado en el intercambio descentralizado.
Ejemplo: True
Tipo: True/False

45. MARKET_SELL_FEE

Descripción: Modifica la comisión cobrada por ejecutar una orden de venta en el intercambio descentralizado.
Ejemplo: [0] SUN.
Rango: [0, 10 000 000 000] SUN

46. MARKET_CANCEL_FEE

Descripción: Modifica la comisión por cancelar una orden abierta en el intercambio descentralizado.
Ejemplo: [0] SUN.
Rango: [0, 10 000 000 000] SUN

47. MAX_FEE_LIMIT

Descripción: Modifica el fee_limit máximo que un usuario puede establecer para una sola transacción.
Ejemplo: [15 000 000 000] SUN - lo que equivale a 15,000 TRX.
Rango: [0, 100 000 000 000 000 000] SUN

48. ALLOW_TRANSACTION_FEE_POOL

Descripción: Habilita o deshabilita el mecanismo del fondo de comisiones de transacción (transaction fee pool).
Ejemplo: False
Tipo: True/False

49. ALLOW_BLACKHOLE_OPTIMIZATION

Descripción: Habilita o deshabilita una optimización en la que la quema de tokens consume una cantidad mínima de Energía.
Ejemplo: True
Tipo: True/False

51. ALLOW_NEW_RESOURCE_MODEL

Descripción: Habilita o deshabilita el nuevo modelo de recursos (Staking 2.0).
Ejemplo: True
Tipo: True/False

52. ALLOW_TVM_FREEZE

Descripción: Habilita o deshabilita las instrucciones TVM relacionadas con el nuevo modelo de staking/recursos (Staking 2.0).
Ejemplo: True
Tipo: True/False

53. ALLOW_ACCOUNT_ASSET_OPTIMIZATION

Descripción: Habilita una optimización para la forma en que se almacenan los saldos de los activos (TRC-10) de la cuenta.
Ejemplo: True
Tipo: True/False

59. ALLOW_TVM_VOTE

Descripción: Habilita o deshabilita la capacidad de los contratos inteligentes para ejecutar operaciones de votación.
Ejemplo: True
Tipo: True/False

60. ALLOW_TVM_COMPATIBLE_EVM

Descripción: Habilita o deshabilita las funciones de compatibilidad de la TVM con la EVM.
Ejemplo: True
Tipo: True/False

61. FREE_NET_LIMIT

Descripción: Modifica la cantidad de Puntos de Ancho de Banda gratuitos que cada cuenta recibe diariamente.
Ejemplo: [5000].
Rango: [0, 100000]

62. TOTAL_NET_LIMIT

Descripción: Modifica el Ancho de Banda total suministrado por la red a partir del TRX apostado.
Ejemplo: [43 200 000 000].
Rango: [0, 1 000 000 000 000]

63. ALLOW_TVM_LONDON

Descripción: Habilita las funciones de la actualización de Ethereum London en la TVM.
Ejemplo: True
Tipo: True/False

65. ALLOW_HIGHER_LIMIT_FOR_MAX_CPU_TIME_OF_ONE_TX

Descripción: Permite proponer un valor máximo mayor para el parámetro MAX_CPU_TIME_OF_ONE_TX.
Ejemplo: True
Tipo: True/False

66. ALLOW_ASSET_OPTIMIZATION

Descripción: Habilita o deshabilita la optimización del almacenamiento de activos en la cuenta.
Ejemplo: True
Tipo: True/False

67. ALLOW_NEW_REWARD

Descripción: Habilita o deshabilita el nuevo algoritmo de recompensa para SRs y votantes.
Ejemplo: True
Tipo: True/False

68. MEMO_FEE

Descripción: Modifica la comisión cobrada por byte por incluir una nota (memo) en una transacción.
Ejemplo: [1 000 000] SUN - lo que equivale a 1 TRX.
Rango: [0, 1 000 000 000] SUN

69. ALLOW_DELEGATE_OPTIMIZATION

Descripción: Habilita o deshabilita las optimizaciones para el almacenamiento de la delegación de recursos.
Ejemplo: True
Tipo: True/False

70. UNFREEZE_DELAY_DAYS

Descripción: Modifica el número de días que un activo está bloqueado cuando se utiliza el nuevo mecanismo de staking.
Ejemplo: [14] Días.
Rango: [1, 365] Días

71. ALLOW_OPTIMIZED_RETURN_VALUE_OF_CHAIN_ID

Descripción: Habilita una optimización para el valor de retorno del código de operación (opcode) CHAINID.
Ejemplo: True
Tipo: True/False

72. ALLOW_DYNAMIC_ENERGY

Descripción: Habilita o deshabilita el modelo de Energía dinámico.
Ejemplo: True
Tipo: True/False

73. DYNAMIC_ENERGY_THRESHOLD

Descripción: Modifica el umbral de consumo de Energía del contrato antes de que se aplique la penalización dinámica.
Ejemplo: [5 000 000 000].
Rango: [0, 9223372036854775807]

74. DYNAMIC_ENERGY_INCREASE_FACTOR

Descripción: Modifica el factor porcentual por el que aumenta el costo de Energía para un contrato que excede el umbral.
Ejemplo: [2000].
Rango: [0, 10000]

75. DYNAMIC_ENERGY_MAX_FACTOR

Descripción: Modifica el multiplicador máximo para el costo de Energía bajo el modelo de Energía dinámico.
Ejemplo: [34000].
Rango: [0, 100000]

76. ALLOW_TVM_SHANGHAI

Descripción: Habilita las funciones de la actualización de Ethereum Shanghai en la TVM.
Ejemplo: True
Tipo: True/False

77. ALLOW_CANCEL_ALL_UNFREEZE_V2

Descripción: Habilita la capacidad de cancelar todas las solicitudes de descongelamiento pendientes en Staking 2.0.
Ejemplo: True
Tipo: True/False

78. MAX_DELEGATE_LOCK_PERIOD

Descripción: Modifica el período máximo de bloqueo para la delegación de recursos.
Ejemplo: [864000].
Rango: (86400, 10512000]

79. ALLOW_OLD_REWARD_OPT

Descripción: Habilita una optimización para el algoritmo de retiro de recompensas para el antiguo sistema de recompensas.
Ejemplo: True
Tipo: True/False

81. ALLOW_ENERGY_ADJUSTMENT

Descripción: Habilita o deshabilita las funcionalidades de ajuste de Energía.
Ejemplo: True
Tipo: True/False

82. MAX_CREATE_ACCOUNT_TX_SIZE

Descripción: Modifica el tamaño máximo de la transacción para crear una nueva cuenta.
Ejemplo: [1000].
Rango: [500, 10000]

83. ALLOW_TVM_CANCUN

Descripción: Habilita las funciones de la actualización de Ethereum Cancun en la TVM.
Ejemplo: True
Tipo: True/False

87. ALLOW_STRICT_MATH

Descripción: Migra las operaciones matemáticas de la TVM a java.lang.StrictMath para una coherencia entre plataformas.
Ejemplo: True
Tipo: True/False

88. CONSENSUS_LOGIC_OPTIMIZATION

Descripción: Habilita o deshabilita las optimizaciones en la lógica de consenso.
Ejemplo: True
Tipo: True/False

89. ALLOW_TVM_BLOB

Descripción: Habilita o deshabilita la compatibilidad de TVM con transacciones de blob (EIP-4844).
Ejemplo: True
Tipo: True/False