Whitepaper de TRON

Por Justin Sun · 2017

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

Introdução

1.1 Visão

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

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

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

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

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

1.4 Terminologia

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TRON development roadmap phase 2 timeline from July 2018 to 2019

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

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

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

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

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

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

TKC Configuração de token.

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

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

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

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/

Arquitetura

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

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

Figura 1: TRON Arquitetura de 3 camadas

2.1 Núcleo

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

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

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

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

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

2.4 Protocolo

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

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

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

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

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

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

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

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

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

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.

Consenso

3.1 Prova de Participação Delegada (DPoS)

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

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

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

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

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

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

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

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

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

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

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

Conta

4.1 Tipos

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

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

Existem três maneiras de criar uma conta TRON:

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

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

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

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

Protobuf data structure: message​ ​Account​ {
​message​ ​Vote​ {

​bytes​ vote_address = ​1​;

​int64​ vote_count = ​2​;

} ​bytes​ accout_name = ​1​;
AccountType type = ​2​;
​bytes​ address = ​3​;
​int64​ balance = ​4​;
​repeated​ Vote votes = ​5​;
map<​string​, ​int64​> asset = ​6​; ​int64​ latest_operation_time = ​10​; }

enum​ ​AccountType​ {
Normal = ​0​;
AssetIssue = ​1​;
Contract = ​2​; }

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

Bloco

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

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

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

Protobuf data structure: message​ ​BlockHeader​ {
​message​ ​raw​ {

​int64​ timestamp = ​1​;

​bytes​ txTrieRoot = ​2​; 
​bytes​ parentHash = ​3​;

​uint64​ number = ​4​;  
​uint64​ version = ​5​;

​bytes​ witness_address = ​6​;

} ​bytes​ witness_signature = ​2​; ​bytes​ blockID = ​3​;
} 5.1.1 Dados Brutos

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

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

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

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

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

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

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

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

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

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

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

5.2.3 Taxa

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

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

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

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

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

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

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

TRON 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.

TRON Máquina Virtual

6.1 Introdução

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

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

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

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

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

Figura 3: Fluxo de trabalho TVM

6.3 Desempenho 6.3.1 Arquitetura Leve

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

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

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

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

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.

Contrato Inteligente

7.1 Introdução

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

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

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

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

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

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

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

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

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

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

Token

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.

Token

8.1 Token TRC-10

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

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

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

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

tokens); }

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

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

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

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.

Governança

9.1 Superrepresentante 9.1.1 Geral

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Desenvolvimento de DApps 10.1 APIs

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

10.2 Redes

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

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

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

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

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

  1. Conclusão

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