TRON ホワイトペーパー

Introduction

1.1 Vision

TRON est un projet ambitieux dédié à la mise en place d'un Internet véritablement décentralisé et à ses infrastructures. Le protocole TRON, l'un des plus grands systèmes d'exploitation basés sur blockchain au monde. monde, offre une prise en charge publique blockchain d'un débit élevé, d'une évolutivité élevée et d'une haute disponibilité pour toutes les applications décentralisées (DApps) de l'écosystème TRON. L'acquisition en juillet 2018 de BitTorrent a encore consolidé le leadership de TRON dans la poursuite d'un écosystème décentralisé.
1.2 Contexte

L’introduction du Bitcoin en 2009 a révolutionné la perception qu’avait la société du secteur financier traditionnel. système à la suite de la Grande Récession (2007-2008). Comme les hedge funds centralisés et les banques effondré à cause de la spéculation sur des dérivés financiers opaques, la technologie blockchain a fourni un grand livre universel transparent à partir duquel chacun pourrait glaner des informations sur les transactions. Le les transactions ont été sécurisées cryptographiquement à l'aide d'un mécanisme de consensus Proof of Work (PoW), évitant ainsi les problèmes de double dépense.

Fin 2013, le livre blanc Ethereum proposait un réseau dans lequel des smart contract et un La machine virtuelle Turing-complete Ethereum (EVM) permettrait aux développeurs d'interagir avec le réseau via DApps. Cependant, alors que les volumes de transactions en Bitcoin et Ethereum ont culminé en 2017, il ressortait des faibles délais de traitement des transactions et des frais de transaction élevés que les crypto-monnaies comme Bitcoin et Ethereum dans leur état actuel n'étaient pas évolutives pour une utilisation généralisée. adoption. Ainsi, TRON a été fondée et envisagée comme une solution innovante à ces problèmes urgents. défis d’évolutivité.

1.3 Historique Le TRON DAO a été créé en juillet 2017 à Singapour. En décembre 2017, TRON avait a lancé son protocole open source. Le Testnet, Blockchain Explorer et Web Wallet étaient tous lancé en mars 2018. TRON Mainnet a été lancé peu de temps après en mai 2018, marquant le Sortie d'Odyssey 2.0 comme étape technique. En juin 2018, TRON a déclaré son indépendance avec la création du bloc Genesis, ainsi que l'acquisition de BitTorrent en juillet 2018. Dans En octobre 2018, TRON a lancé la machine virtuelle TRON (TVM), un ensemble complet d'outils pour les développeurs, et système de support 360. La feuille de route TRON consiste à combiner les 100 millions d’utilisateurs de BitTorrent avec le réseau TRON via Project Atlas, ainsi qu'en encourageant la communauté des développeurs à lancer de nouvelles DApp passionnantes sur le réseau TRON1. 1 V1.0 est disponible à https://tron.network/static/doc/white_paper_v_1_0.pdf

1.4 Terminologie

Adresse/portefeuille Une adresse ou un portefeuille composé d'identifiants de compte sur le réseau TRON est généré par un paire de clés, composée d'une clé privée et d'une clé publique, cette dernière étant dérivée de la première grâce à un algorithme. La clé publique est généralement utilisée pour le chiffrement de la clé de session, la signature vérification et cryptage des données qui pourraient être déchiffrées par une clé privée correspondante.

IBI Une interface binaire d'application (ABI) est une interface entre deux modules de programme binaires ; habituellement l'un de ces modules est une bibliothèque ou une fonctionnalité du système d'exploitation, et l'autre est un module exécuté par l'utilisateur. programme.

API Une interface de programmation d'application (API) est principalement utilisée pour le développement des clients utilisateurs. Avec API support, les plateformes d'émission token peuvent également être conçues par les développeurs eux-mêmes.

Actif Dans les documents de TRON, l'actif est le même que token, qui est également désigné par TRC-10 token.

Points de bande passante (BP) Pour assurer le bon fonctionnement du réseau, les transactions du réseau TRON utilisent BP comme carburant. Chaque compte obtient 5 000 BP quotidiens gratuits et davantage peut être obtenu en gelant TRX pour BP. TRX et TRC-10 Les transferts token sont des transactions normales coûtant à BP. Déploiement et exécution de contrats intelligents les transactions consomment à la fois du BP et de l’énergie.

Bloquer Les blocs contiennent les enregistrements numériques des transactions. Un bloc complet est constitué du nombre magique, taille de bloc, en-tête de bloc, compteur de transactions et données de transaction.

Bloquer la récompense Les récompenses de production de blocs sont envoyées sur un sous-compte (adresse/portefeuille). Les super représentants peuvent réclamez leurs récompenses sur Tronscan ou directement via l'API.

En-tête de bloc Un en-tête de bloc fait partie d'un bloc. Les en-têtes de bloc TRON contiennent le hash du bloc précédent, le Racine Merkle, horodatage, version et adresse du témoin.Portefeuille froid Le portefeuille froid, également appelé portefeuille hors ligne, maintient la clé privée complètement déconnectée de tout réseau. Les portefeuilles froids sont généralement installés sur des appareils « froids » (par exemple des ordinateurs ou des téléphones portables). rester hors ligne) pour assurer la sécurité de la clé privée TRX.

DApp Une application décentralisée est une application qui fonctionne sans partie de confiance centrale. Une candidature qui permet une interaction/des accords/une communication directe entre les utilisateurs finaux et/ou les ressources sans intermédiaire.

gRPC gRPC (gRPC Remote Procedure Calls) est un système d'appel de procédure à distance (RPC) open source 2 initialement développé chez Google. Il utilise HTTP/2 pour le transport, Protocol Buffers comme interface langage de description et fournit des fonctionnalités telles que l'authentification, le streaming bidirectionnel et le flux contrôle, liaisons bloquantes ou non bloquantes, annulation et délais d'attente. Il génère liaisons client et serveur multiplateformes pour de nombreuses langues. Scénarios d'utilisation les plus courants inclure des services de connexion dans une architecture de style microservices et la connexion d'appareils mobiles, et clients de navigateur vers les services backend.

Portefeuille chaud Le portefeuille chaud, également connu sous le nom de portefeuille en ligne, permet d'utiliser la clé privée de l'utilisateur en ligne. sensibles aux vulnérabilités potentielles ou à l’interception par des acteurs malveillants.

JDK Java Development Kit est le SDK Java utilisé pour les applications Java. C'est le cœur de Java développement, comprenant l'environnement d'application Java (bibliothèque de classes JVM+Java) et Java outils.

KhaosDB TRON a une KhaosDB dans la mémoire complète du nœud qui peut stocker toutes les chaînes nouvellement créées générées dans un certain laps de temps et aide les témoins à quitter rapidement leur propre chaîne active dans une nouvelle chaîne principale. Voir 2.2.2 Stockage d'état pour plus de détails.

NiveauDB LevelDB a été initialement adopté dans le but principal de répondre aux exigences de R/W rapide et de développement. Après avoir lancé le Mainnet, TRON a mis à niveau sa base de données vers une base de données entièrement personnalisée on répondait à ses propres besoins. Voir 2.2.1 Stockage Blockchain pour plus de détails.

Racine de Merkle Une racine Merkle est le hash de tous les hash de toutes les transactions incluses dans le cadre d'un bloc dans un blockchain. réseau. Voir 3.1 Preuve de participation déléguée (DPoS) pour plus de détails. 2 https://en.wikipedia.org/wiki/GRPC

Réseau de test public (Shasta) Une version du réseau fonctionnant dans une configuration à nœud unique. Les développeurs peuvent se connecter et tester fonctionnalités sans se soucier de la perte économique. Les token Testnet n'ont aucune valeur et tout le monde peut demandez plus au robinet public.

RPC
3 En informatique distribuée, un appel de procédure à distance (RPC) se produit lorsqu'un programme informatique provoque un procédure (sous-programme) à exécuter dans un espace d’adressage différent (généralement sur un autre ordinateur sur un réseau partagé), qui est codé comme s'il s'agissait d'un appel de procédure normal (local), sans le programmeur codant explicitement les détails de l’interaction à distance.

Évolutivité L'évolutivité est une fonctionnalité du protocole TRON. C'est la capacité d'un système, d'un réseau ou d'un processus à gérer une quantité croissante de travail ou son potentiel d’être élargi pour s’adapter à cette croissance.

SOLEIL SUN a remplacé drop en tant que plus petite unité de TRX. 1 TRX = 1 000 000 SOLEIL.

Débit Le débit élevé est une fonctionnalité du réseau principal TRON. Il est mesuré en transactions par seconde (TPS), à savoir la capacité maximale de transaction en une seconde.

Horodatage L'heure approximative de production du bloc est enregistrée sous forme d'horodatage Unix, qui correspond au nombre de millisecondes écoulées depuis 00:00:00 le 1er janvier 1970 UTC.

CTK Configuration du jeton.

TRC-10 Un standard de crypto token sur la plateforme TRON. Certaines règles et interfaces doivent être respectées lors de la détention d'une offre initiale de pièces le TRON blockchain.

TRX TRX signifie Tronix, qui est la crypto-monnaie officielle de TRON.

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

Architecture

TRON adopte une architecture à 3 couches divisée en couche de stockage, couche principale et couche d'application. Le protocole TRON adhère à Google Protobuf, qui prend intrinsèquement en charge le multilingue prolongation.

Figure 1 : TRON Architecture à 3 couches

2.1 Noyau

Il existe plusieurs modules dans la couche principale, notamment smart contracts, la gestion des comptes et consensus. Une machine virtuelle basée sur une pile est implémentée sur TRON et une instruction optimisée l’ensemble est utilisé. Afin de mieux accompagner les développeurs DApp, Solidity a été choisi comme smart contract 4 langue, suivie par la prise en charge future d'autres langues avancées. De plus, le consensus de TRON Le mécanisme est basé sur la preuve de participation déléguée (DPoS) et de nombreuses innovations ont été apportées en afin de répondre à ses exigences uniques. 2.2 Stockage

TRON a conçu un protocole de stockage distribué unique composé de stockage par blocs et d'état Stockage. La notion de base de données graphes a été introduite dans la conception de la couche de stockage pour mieux répondre au besoin de stockage de données diversifié dans le monde réel. 2.2.1 Stockage blockchain

TRON blockchain Storage choisit d'utiliser LevelDB, développé par Google et éprouvé avec succès auprès de nombreuses entreprises et projets. Il a des performances élevées et prend en charge les octets arbitraires tableaux comme clés et valeurs, obtention, mise et suppression singulières, mise et suppression par lots, bidirectionnel itérateurs et compression simple utilisant l'algorithme Snappy très rapide. 2.2.2 Stockage d'état

TRON a une KhaosDB dans la mémoire complète du nœud qui peut stocker toutes les chaînes nouvellement fourchues générées dans un certain laps de temps et aide les témoins à quitter rapidement leur propre chaîne active dans une nouvelle chaîne principale. Il peut également protéger le stockage blockchain en le rendant plus stable contre les se terminant anormalement dans un état intermédiaire. 2.3 Demande

Les développeurs peuvent créer une gamme diversifiée de DApps et de portefeuilles personnalisés sur TRON. Depuis TRON permet aux smart contract d'être déployés et exécutés, les opportunités des applications utilitaires sont illimité. 4 Documentation officielle Solidité : https://solidity.readthedocs.io/

2.4 Protocole

Le protocole TRON adhère à Google Protocol Buffers , qui est neutre en termes de langage, de plate-forme, 5 et extensible de sérialiser des données structurées pour une utilisation dans les protocoles de communication, le stockage de données, et plus encore. 2.4.1 Tampons de protocole

Protocol Buffers (Protobuf) est un mécanisme flexible, efficace et automatisé pour la sérialisation structurée données, similaires à JSON ou XML, mais beaucoup plus petites, plus rapides et plus simples.

Les définitions Protobuf (.proto) peuvent être utilisées pour générer du code pour C++, Java, C#, Python, Ruby, Golang et Objective-C via les générateurs de code officiels. Divers tiers des implémentations sont également disponibles pour de nombreux autres langages. Protobuf facilite le développement de clients en unifiant les définitions des API et en optimisant également les transferts de données. Les clients peuvent utiliser l'API .proto du référentiel de protocoles de TRON et intégré via le code généré automatiquement bibliothèques.

À titre de comparaison, les tampons de protocole sont 3 à 10 fois plus petits et 20 à 100 fois plus rapides que XML, avec une syntaxe moins ambiguë. Protobuf génère des classes d'accès aux données plus faciles à utiliser par programmation. 2.4.2 HTTP

Le protocole TRON fournit une alternative à l'API HTTP RESTful à l'API Protobuf. Ils partagent la même chose interface mais l'API HTTP peut être facilement utilisée dans les clients javascript. 2.5 TRON Machine virtuelle (TVM)

Le TVM est une machine virtuelle complète et légère de Turing développée pour l'écosystème de TRON. Le TVM se connecte de manière transparente à l'écosystème de développement existant pour fournir des millions de développeurs avec un système blockchain personnalisé qui est efficace, pratique, stable, sécurisé et évolutif.
2.6 Échange décentralisé (DEX)

5 Documentation officielle des tampons de protocole Google : https://developers.google.com/protocol-buffers/Le réseau TRON supporte nativement les fonctions d'échange décentralisées. Un échange décentralisé se compose de plusieurs paires de trading. Une paire de trading (notation « Exchange ») est un marché d'échange entre des TRC-10 token, ou entre un TRC-10 token et un TRX. N'importe quel compte peut créer un trading paire entre n’importe quel token, même si la même paire existe déjà sur le réseau TRON. Commerce et les fluctuations de prix des paires de trading suivent le protocole Bancor. Le réseau TRON stipule que 6 les poids des deux token dans toutes les paires de trading sont égaux, donc le rapport de leurs soldes est le prix entre eux. Par exemple, considérons une paire de trading contenant deux token, ABC et DEF. ABC a un solde de 10 millions et DEF a un solde de 1 million. Puisque leurs poids sont égaux, 10 ABC = 1 DÉF. Cela signifie que le rapport ABC/DEF est de 10 ABC par DEF. 2.7 Mise en œuvre

Le code TRON blockchain est implémenté en Java et était à l'origine un fork de EthereumJ.

6 Site officiel du Protocole Bancor : https://about.bancor.network/protocol/

Consensus

3.1 Preuve de participation déléguée (DPoS)

Le mécanisme de consensus le plus ancien est le mécanisme de consensus Proof of Work (PoW). Ceci Le protocole est actuellement implémenté dans Bitcoin et Ethereum . Dans les systèmes PoW, les transactions 7 8 diffusés à travers le réseau sont regroupés en blocs naissants pour confirmation par le mineur. Le Le processus de confirmation implique de hashing transactions à l'aide d'algorithmes cryptographiques hashing jusqu'à ce qu'un La racine Merkle a été atteinte, créant un arbre Merkle :

Figure 2 : 8 transactions TRX sont hashed dans la racine merkle. Cette racine merkle est ensuite incluse dans l'en-tête du bloc, qui est attaché aux blocs précédemment confirmés pour former un blockchain. Cela permet un suivi facile et transparent de transactions, horodatages et autres informations connexes.

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

Les algorithmes cryptographiques hashing sont utiles dans la prévention des attaques réseau car ils possèdent plusieurs propriétés :
9

● Taille de la longueur d'entrée/sortie - L'algorithme peut transmettre une entrée de n'importe quelle longueur, et génère une valeur hash de longueur fixe.
● Efficacité​ - L'algorithme est relativement simple et rapide à calculer.
● Résistance de préimage​ - Pour une sortie ​z​ donnée, il est impossible de trouver une entrée ​x​ telle que h(x) =​ ​z​. En d’autres termes, l’algorithme hashing ​h(x)​ est une fonction unidirectionnelle dans laquelle seul le la sortie peut être trouvée, étant donné une entrée. L’inverse n’est pas possible.
● Résistance aux collisions​ - Il est informatiquement impossible de trouver des paires ​x​1 ​≠ x​2​ ​telles que ​h(x​1​) = h(x​2​)​. En d’autres termes, la probabilité de trouver deux entrées différentes hash au même le rendement est extrêmement faible. Cette propriété implique également une ​résistance à la seconde préimage​.
● Résistance de la deuxième pré-image - Étant donné ​x​1​, et donc ​h(x​1​)​, il est informatiquement impossible de trouver n'importe quel ​x​2​ tel que ​h(x​1​) = h(x​2​)​. Bien que cette propriété soit similaire à la ​résistance aux collisions​, la la propriété diffère en ce sens qu'elle signifie qu'un attaquant avec un ​x​1​ donné le trouvera par calcul impossible de trouver un ​x​2​ hash sur la même sortie.
● Déterministe​ - mappe chaque entrée sur une et une seule sortie. ● Effet Avalanche​ - un petit changement dans l'entrée entraîne une sortie entièrement différente.

Ces propriétés confèrent au réseau de crypto-monnaie sa valeur intrinsèque en garantissant que les attaques ne compromettre le réseau. Lorsque les mineurs confirment un blocage, ils sont récompensés par des token sous forme de récompense intégrée. incitation à la participation au réseau. Cependant, comme la capitalisation boursière mondiale des cryptomonnaies En constante augmentation, les mineurs se sont centralisés et ont concentré leurs ressources informatiques sur thésauriser les token en tant qu'actifs, plutôt qu'à des fins de participation au réseau. Les mineurs de CPU ont cédé la place à Les GPU, qui à leur tour ont cédé la place aux puissants ASIC. Dans une étude notable, la puissance totale la consommation de l’exploitation minière Bitcoin a été estimée à 3 GW, comparable à celle de l’Irlande. 10 consommation d'énergie. Cette même étude prévoyait que la consommation totale d'énergie atteindrait 8 GW à court terme. futur.

Pour résoudre le problème du gaspillage énergétique, le mécanisme de consensus Proof of Stake (PoS) a été proposé par de nombreux nouveaux réseaux. Dans les réseaux PoS, les détenteurs de token verrouillent leurs soldes token pour devenir des blocs validators. Les validator proposent et votent à tour de rôle sur le bloc suivant. Cependant, le problème avec le PoS standard, l'influence de validator est directement corrélée au nombre de token bloqués. Cela conduit les parties à thésauriser de grandes quantités de la monnaie de base du réseau et à les utiliser de manière injustifiée. influence dans l’écosystème du réseau.

Le mécanisme de consensus TRON utilise un système innovant de Delegated Proof of Stake dans lequel 27 Les super représentants (SR) produisent des blocs pour le réseau. Toutes les 6 heures, les titulaires de comptes TRX qui gèlent leurs comptes peuvent voter pour une sélection de candidats SR, les 27 premiers candidats considérés comme les SR. Les électeurs peuvent choisir les SR en fonction de critères tels que les projets parrainés par les SR pour 9 PAAR, C., PELZL, J., ​Comprendre la cryptographie : un manuel pour les étudiants et les praticiens​, 2010 éd. Springer-Verlag Berlin Heidelberg, 2010.
10 https://www.sciencedirect.com/science/article/pii/S2542435118301776augmenter l’adoption du TRX et les récompenses distribuées aux électeurs. Cela permet une société plus démocratisée et écosystème décentralisé. Les comptes des SR sont des comptes normaux, mais leur accumulation de voix leur permet de produire des blocs. Avec les faibles débits de Bitcoin et Ethereum en raison de leur Mécanisme de consensus PoW et problèmes d'évolutivité, le système DPoS de TRON offre une solution innovante mécanisme résultant en 2000 TPS par rapport aux 3 TPS de Bitcoin et aux 15 TPS de Ethereum.

Le réseau de protocole TRON génère un bloc toutes les trois secondes, chaque bloc attribuant 32 TRX aux super représentants. Un total de 336 384 000 TRX seront attribués chaque année aux 27 SR. Chaque fois qu'un SR termine la production de blocs, les récompenses sont envoyées sur un sous-compte du super-grand livre. Les SR peuvent vérifier, mais ne peuvent pas utiliser directement ces TRX token. Un retrait peut être effectué par chacun SR une fois toutes les 24 heures, transférant les récompenses du sous-compte vers le SR spécifié compte.

Les trois types de nœuds sur le réseau TRON sont Witness Node, Full Node et Solidity Node. Les nœuds témoins sont mis en place par les SR et sont principalement responsables de la production et de la proposition des blocs. création/vote. Les nœuds complets fournissent des API et diffusent des transactions et des blocs. Synchronisation des nœuds Solidity blocs à partir d’autres nœuds complets et fournissent également des API indexables.

Compte

4.1 Types

Les trois types de comptes du réseau TRON sont les comptes réguliers, les comptes token et comptes de contrats.

1. Les comptes réguliers sont utilisés pour les transactions standard.
2. Les comptes de jetons sont utilisés pour stocker les TRC-10 token.
3. Les comptes de contrats sont des comptes smart contract créés par des comptes réguliers et peuvent être déclenchés également par les comptes réguliers. 4.2 Création

Il existe trois façons de créer un compte TRON :

1. Créer un nouveau compte via l'API 2. Transférer TRX vers une nouvelle adresse de compte 3. Transférez n'importe quel TRC-10 token vers une nouvelle adresse de compte

Une paire de clés hors ligne composée d'une adresse (clé publique) et d'une clé privée, et non enregistrée par le Le réseau TRON, peut également être généré. L'algorithme de génération d'adresse utilisateur consiste en générer une paire de clés puis extraire la clé publique (tableau d'octets de 64 octets représentant x, y coordonnées). Hachez la clé publique grâce à la fonction SHA3-256 (le protocole SHA3 adopté est KECCAK-256) et extrayez les 20 derniers octets du résultat. Ajoutez 41 au début du tableau d'octets et assurez-vous que la longueur de l’adresse initiale est de 21 octets. Hachez l'adresse deux fois à l'aide de la fonction SHA3-256 et prenez les 4 premiers octets comme code de vérification. Ajoutez le code de vérification à la fin du mot initial et obtenez l'adresse au format base58check via l'encodage base58. Un codé L'adresse du réseau principal commence par T et mesure 34 octets. 4.3 Structure

Les trois types de comptes différents sont Normal, AssetIssue et Contract. Un compte contient 7 paramètres :

1. account_name​ : le nom de ce compte – par ex. Compte de factures.
2. type​ : quel est le type de ce compte – par ex. 0 (signifie type « Normal »).
3. solde​ : solde de ce compte – par ex. 4213312.

4. vote​ : votes reçus sur ce compte – par ex. {("0x1b7w…9xj3",323), (« 0x8djq…j12m »,88),…,(« 0x82nd…mx6i »,10001)}.
5. actif​ : autres actifs TRX attendus dans ce compte – par ex. {<"WishToken", 66666>, <"Dogie", 233>}. 6. last_operation_time​ : la dernière heure de fonctionnement de ce compte.

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

Bloc

Un bloc contient généralement un en-tête de bloc et plusieurs transactions.

Protobuf data structure: message​ ​Block​ {
BlockHeader block_header = ​1​; ​repeated​ Transaction transactions = ​2​; } 5.1 En-tête de bloc

Un en-tête de bloc contient ​raw_data​, ​witness_signature​ et ​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 Données brutes

Les données brutes sont désignées par ​raw_data​ dans Protobuf. Il contient les données brutes d'un message, contenant 6 paramètres :

1. timestamp​ : horodatage de ce message – par ex. 1543884429000. 2. txTrieRoot​ : la racine de l'arbre Merkle – par ex. 7dacsa…3éd. 3. parentHash​ : le hash du dernier bloc – par ex. 7dacsa…3éd. 4. nombre​ : la hauteur du bloc – par ex. 4638708. 5. version​: réservé – par ex. 5.

6. Witness_address​ : l'adresse du témoin contenue dans ce bloc – par ex. 41928c...4d21. 5.1.2 Signature du témoin

La signature du témoin est désignée par ​witness_signature​ dans Protobuf, qui est la signature de ce en-tête de bloc du nœud témoin. 5.1.3 ID de bloc

L'ID de bloc est noté ​blockID​ dans Protobuf. Il contient l'identification atomique d'un bloc. Un bloc L'ID contient 2 paramètres : 1. hash​ : le hash du bloc. 2. numéro​ : le hash et la hauteur du bloc. 5.2 Opérations 5.2.1 Signature

Le processus de signature de transaction de TRON suit un algorithme cryptographique ECDSA standard, avec un Courbe de sélection SECP256K1. Une clé privée est un nombre aléatoire et la clé publique est un point sur le courbe elliptique. Le processus de génération de clé publique consiste à générer d'abord un nombre aléatoire clé privée, puis en multipliant le point de base de la courbe elliptique par la clé privée pour obtenir le clé publique. Lorsqu'une transaction se produit, les données brutes de la transaction sont d'abord converties au format octet. Les données brutes subissent ensuite un SHA-256 hashing. La clé privée correspondant au contrat adresse signe ensuite le résultat du SHA256 hash. Le résultat de la signature est ensuite ajouté au transaction.
5.2.2 Modèle de bande passante

Les transactions ordinaires ne consomment que des points de bande passante, mais les opérations smart contract consomment les deux. points d’énergie et de bande passante. Il existe deux types de points de bande passante disponibles. Les utilisateurs peuvent gagner points de bande passante contre le gel de TRX, tandis que 5 000 points de bande passante gratuits sont également disponibles quotidiennement.

Lorsqu'une transaction TRX est diffusée, elle est transmise et stockée sous la forme d'un tableau d'octets sur le réseau. Points de bande passante consommés par une transaction = nombre d'octets de transaction multiplié par le taux de points de bande passante. Par exemple, si la longueur du tableau d'octets d'une transaction est de 200, alors la transaction consomme 200 points de bande passante. Cependant, si un transfert TRX ou token entraîne le compte cible en cours de création, puis uniquement les points de bande passante consommés pour créer le compte seront déduits et les points de bande passante supplémentaires ne seront pas déduits. Dans une création de compte Dans ce scénario, le réseau consommera d'abord les points de bande passante gagnés par l'initiateur de la transaction.du gel de TRX. Si ce montant est insuffisant, alors le réseau consomme la transaction TRX de l’initiateur.

Dans les scénarios de transfert TRX standard d'un compte TRX à un autre, le réseau consomme d'abord les points de bande passante gagnés par l'initiateur de la transaction pour geler TRX. Si cela est insuffisant, alors consomme à partir des 5 000 points de bande passante quotidiens gratuits. Si cela ne suffit toujours pas, alors le réseau consomme le TRX de l'initiateur de la transaction. Le montant est calculé par le nombre d'octets dans la transaction multipliée par 10 SUN. Ainsi, pour la plupart des détenteurs de TRX qui ne gèlent pas nécessairement leur TRX pour participer au vote SR, la première étape est automatiquement ignorée (puisque le solde TRX gelé = 0) et les 5 000 bandes passantes gratuites quotidiennes alimentent la transaction.

Pour les transferts TRC-10 token, le réseau vérifie d'abord si le total des points de bande passante libre du l'actif token émis est suffisant. Sinon, les points de bande passante obtenus en gelant TRX sont consommé. S’il n’y a toujours pas assez de points de bande passante, alors cela consomme le TRX de la transaction initiateur.

5.2.3 Frais

Le réseau TRON ne facture généralement pas de frais pour la plupart des transactions, cependant, en raison du système les restrictions et l'équité, l'utilisation de la bande passante et les transactions entraînent certains frais.

Les frais facturés sont répartis dans les catégories suivantes : 1. Les transactions normales coûtent des points de bande passante. Les utilisateurs peuvent utiliser les points de bande passante quotidiens gratuits (5000) ou geler TRX pour en obtenir plus. Lorsque les points de bande passante ne suffisent pas, TRX sera utilisé directement à partir du compte d’envoi. Le TRX nécessaire est le nombre d'octets * 10 SUN. 2. Les contrats intelligents coûtent de l'énergie (Section 6) mais nécessiteront également des points de bande passante pour le transaction à diffuser et à confirmer. Le coût de la bande passante est le même que ci-dessus. 3. Toutes les transactions de requête sont gratuites. Cela ne coûte ni énergie ni bande passante.

Le réseau TRON définit également un ensemble de frais fixes pour les transactions suivantes : 1. Création d'un nœud témoin : 9999 TRX 2. Émission d'un TRC-10 token : 1024 TRX 3. Création d'un nouveau compte : 0.1 TRX 4. Création d'une paire d'échange : 1024 TRX 5.2.4 Transaction comme preuve de participation (TaPoS)

TRON utilise TaPoS pour garantir que les transactions confirment toutes le blockchain principal, tout en le réalisant difficile de forger des chaînes contrefaites. Dans TaPoS, les réseaux exigent que chaque transaction comprenne une partie de le hash d’un en-tête de bloc récent. Cette exigence empêche la relecture des transactions sur forks n'incluant pas le bloc référencé, et signale également au réseau qu'un utilisateur particulier et sonles enjeux sont sur une fourchette spécifique. Ce mécanisme de consensus protège le réseau contre le déni de Service, 51 %, exploitation minière égoïste et attaques à double dépense.
5.2.5 Confirmation de transaction

Une transaction est incluse dans un futur bloc après avoir été diffusée sur le réseau. Après 19 blocs sont extrait le TRON (y compris son propre bloc), la transaction est confirmée. Chaque bloc est produit par l'un des 27 meilleurs super-représentants dans un tournoi à la ronde. Chaque bloc prend environ 3 secondes pour être extrait sur le blockchain. Le temps peut légèrement varier pour chaque super représentant en raison du réseau conditions et configurations des machines. En général, une transaction est considérée comme entièrement confirmée après ~1 minute. 5.2.6 Structure

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

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

TRON Machine virtuelle

6.1 Présentation

TRON Virtual Machine (TVM) est une machine virtuelle légère et complète de Turing développée pour le L'écosystème de TRON. Son objectif est de fournir un système blockchain sur mesure qui soit efficace, pratique, stable, sécurisé et évolutif.

TVM est initialement dérivé de EVM et peut se connecter de manière transparente à la solidité existante smart contract 11 écosystème de développement. Sur cette base, TVM prend également en charge le consensus DPoS.

TVM utilise le concept d'énergie. Différent du mécanisme à gaz sur EVM, les opérations de les transactions et les smart contract sur TVM sont gratuits, sans TRX consommé. Techniquement, exécutable la capacité de calcul sur TVM n'est pas limitée par le montant total de détention de tokens. 6.2 Flux de travail

Le compilateur traduit d'abord le Solidity smart contract en bytecode lisible et exécutable sur le TVM. Le TVM traite ensuite les données via l'opcode, ce qui équivaut à faire fonctionner la logique d'une machine à états finis basée sur une pile. Enfin, le TVM accède aux données blockchain et invoque Interface de données externe via la couche d'interopération. 11 EVM : Ethereum Machine virtuelle (https://github.com/ethereum/ethereumj)

Figure 3 : Flux de travail TVM

6.3 Performances 6.3.1 Architecture légère

TVM adopte une architecture légère dans le but de réduire la consommation de ressources pour garantir performances du système. 6.3.2 Robuste

Les transferts TRX et l'exécution smart contract coûtent uniquement des points de bande passante, au lieu de TRX, qui exempte TRON d'être attaqué. La consommation de bande passante est prévisible et statique puisque chaque le coût de l’étape de calcul est fixe. 6.3.3 Haute compatibilité

TVM est compatible avec EVM et sera compatible avec davantage de machines virtuelles grand public à l'avenir. Ainsi, tous les smart contract sur EVM sont exécutables sur TVM. 6.3.4 Faible coût

Grâce à la configuration de la bande passante de TVM, les coûts de développement sont réduits et les développeurs peuvent se concentrer sur le développement logique de leur code de contrat. TVM propose également des interfaces tout-en-un pour les contrats déploiement, déclenchement et visualisation pour offrir la commodité aux développeurs.

Contrat intelligent

7.1 Introduction

Un smart contract est un protocole qui vérifie numériquement la négociation d'un contrat. Ils définissent les règles et pénalités liées à un accord et faire respecter automatiquement ces obligations. L'intelligent le code du contrat facilite, vérifie et impose la négociation ou l’exécution d’un accord ou transaction. Du point de vue de la tokenisation, les smart contract facilitent également les fonds automatiques les transferts entre les parties participantes si certains critères sont remplis.

TRON smart contracts sont écrits dans le langage Solidity. Une fois rédigés et testés, ils peuvent être compilé en bytecode, puis déployé sur le réseau TRON pour la machine virtuelle TRON. Une fois déployés, les smart contract peuvent être interrogés via leurs adresses contractuelles. La demande de contrat L'interface binaire (ABI) affiche les fonctions d'appel du contrat et est utilisée pour interagir avec le réseau. 7.2 Modèle énergétique

La limite d'énergie maximale pour le déploiement et le déclenchement d'un smart contract est fonction de plusieurs variables :

● L'énergie dynamique issue du gel 1 TRX est de 50 000 000 000 (limite d'énergie totale) / (énergie totale Poids) ● La limite d'énergie est la limite d'énergie quotidienne du compte suite au gel du TRX. ● L'énergie quotidienne restante due au gel du TRX est calculée comme Limite d'énergie - Énergie Utilisé ● La limite de frais dans TRX est définie dans l'appel de déploiement/déclenchement smart contract ● TRX restant utilisable dans le compte ● Énergie par TRX si achetée directement (10 SUN = 1 Énergie) = 100 000, les SR peuvent voter réglage

Il existe deux scénarios de consommation pour calculer la limite énergétique maximale pour le déploiement et déclencheur. La logique peut s’exprimer ainsi :
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 Déploiement

Lorsqu'une solidité TRON smart contract est compilée, la machine virtuelle TRON lit le contenu compilé. bytecode. Le bytecode se compose d'une section pour le déploiement du code, le code du contrat et les Auxdata. L’Auxdata est l’empreinte cryptographique du code source, utilisée pour la vérification. Le déploiement le bytecode exécute la fonction constructeur et configure les variables de stockage initiales. Le déploiement code calcule également le code du contrat et le renvoie au TVM. L'ABI est un fichier JSON qui décrit les fonctions d'un TRON smart contract. Ce fichier définit les noms des fonctions, leur payabilité, les valeurs de retour de la fonction et leur mutabilité d'état. 7.4 Fonction de déclenchement

Une fois les TRON smart contract déployés, leurs fonctions peuvent être déclenchées individuellement soit via TronStudio ou via des appels API. Les fonctions de changement d'état nécessitent de l'énergie tandis que les fonctions en lecture seule exécuter sans énergie. 7.5 TRON Solidité

TRON Solidity est un fork du langage Solidity de Ethereum. TRON modifie le projet d'origine pour prend en charge les unités TRX et SUN (1 TRX = 1 000 000 SUN). Le reste de la syntaxe du langage est compatible avec Solidité ^0.4.24. Ainsi la Machine Virtuelle Tron (TVM) est quasiment 100% compatible avec les instructions EVM.

Token

8.1 Jeton TRC-10

Dans le réseau TRON, chaque compte peut émettre des token au prix de 1024 TRX. ​Pour émettre des tokens, l'émetteur doit préciser un nom token, la capitalisation totale, le taux de change par rapport au TRX, durée de diffusion, description, site Internet, consommation maximale de bande passante par compte, total la consommation de bande passante et la quantité de token gelée. Chaque édition token peut également configurer le maximum quotidien de chaque compte token transférer des points de bande passante, le maximum quotidien de l'ensemble du réseau token transférer des points de bande passante, l'offre totale de token, la durée de verrouillage en jours et le montant total de token verrouillés. 8.2 Jeton TRC-20

TRC-20 est une norme technique utilisée pour les smart contract mettant en œuvre les token pris en charge par le TRON Machine virtuelle. Il est entièrement compatible avec ERC-20.

L'interface est la suivante :
contrat​ TRC20Interface { ​fonction​ ​totalSupply​() ​public​ ​retours​ ​constants​ (uint); ​fonction​ ​balanceOf​(adresse tokenOwner) ​public​ ​rendements​ ​constants​ (uint solde); ​fonction​ ​allocation​(adresse tokenPropriétaire, adresse du dépensier) ​publique​ ​constante renvoie​ (uint restant) ; ​fonction​ ​transfer​(adresse à, uint tokens) ​public​ ​retours​ (bool success) ; ​fonction​ ​approuve​(adresse dépensier, uint tokens) ​public​ ​retourne​ (bool succès); ​fonction​ ​transferFrom​(adresse de, adresse à, uint tokens) ​public renvoie​ (succès booléen) ;

​événement​ ​Transfer​(adresse indexée de, adresse indexée vers, uint tokens) ; 
​événement​ ​Approbation​(adresse indexée tokenPropriétaire, adresse dépensière indexée, uint

tokens); }

Du point de vue du développeur, il existe plusieurs différences entre TRC-10 et TRC-20. Certains L'une des principales différences réside dans le fait que les token TRC-10 sont accessibles par les API et les smart contract tandis que Les token TRC-20 permettent la personnalisation de l'interface mais ne sont accessibles que dans les smart contract.

Du point de vue des coûts, les TRC-10 token ont des frais de transaction 1 000 fois inférieurs à ceux des TRC-20, mais entraîne des coûts de bande passante pour les transferts et les dépôts d'API. Virements et dépôts en smart les contrats pour les TRC-10 token coûtent à la fois de la bande passante et de l'énergie.
8.3 Au-delà

Étant donné que TRON utilise la même version Solidity que Ethereum, davantage de normes token pourraient être facilement porté sur TRON.

Gouvernance

9.1 Super Représentant 9.1.1 Général

Chaque compte du réseau TRON peut postuler et avoir l'opportunité de devenir un Super Représentant (noté SR). Tout le monde peut voter pour les candidats SR. Les 27 meilleurs candidats avec le plus grand nombre de votes deviendront des SR avec le droit et l'obligation de générer des blocs. Les votes sont compté toutes les 6 heures et les SR changeront en conséquence.

Pour prévenir les attaques malveillantes, devenir candidat SR a un coût. Lors de votre candidature, 9999 TRX sera brûlé depuis le compte du demandeur. Une fois réussi, ce compte peut rejoindre le SR élection. 9.1.2 Élection

TRON La puissance (notée TP) est nécessaire pour voter et le montant de TP dépend de la puissance de l'électeur. avoirs gelés (TRX).

TP est calculé de la manière suivante :
TP 1 TRX gelé pour obtenir de la bande passante 1 =

Chaque compte du réseau TRON a le droit de voter pour ses propres SR.

Après la sortie (dégel, disponible après 3 jours), les utilisateurs n'auront plus aucun actif gelé et perdront tout TP en conséquence. En conséquence, tous les votes deviennent invalides pour le tour de scrutin en cours et à venir, à moins que TRX est à nouveau gelé pour voter.

Notez que le réseau TRON n'enregistre que le vote le plus récent, ce qui signifie que chaque nouveau vote annulera tous les votes précédents. 9.1.3 Récompense une. Récompense de vote

Également connu sous le nom de Récompense du candidat, que les 127 meilleurs candidats ont mis à jour une fois à chaque tour (6 heures) partagera 115 200 TRX tels qu’ils sont extraits. La récompense sera répartie en fonction du poids du vote chaque candidat reçoit. Chaque année, la récompense totale des candidats s'élèvera à 168 192 000 TRX. Récompense totale des votes par tour Pourquoi 115 200 TRX à chaque tour ? 15h00 TRX récompense totale des votes par tour (V R/tour) 1 2 =
V R/tour = 16 T RX/bloc × 20 blocs/min × 60 min/h × 6 heures/tour Remarque : ceci est défini par WITNESS_STANDBY_ALLOWANCE = 115 200 TRX. Voir les paramètres de réseau dynamiques. Récompense totale des votes par an Pourquoi 168 192 000 TRX chaque année ? 168 192 000 T RX = récompense totale des votes par an (V R/an) V R/an = 115, 200 T RX/tour × 4 tours/jour × 365 jours/an b. Bloquer la récompense Également connue sous le nom de Super Representative Reward, qui récompense les 27 meilleurs candidats (SR) élus chaque tour (6 heures) partagera environ 230 400 TRX extraits. La récompense sera répartie équitablement entre les 27 SR (moins le total des blocs de récompense manqués en raison d'une erreur réseau). Un total de 336 384 000 TRX seront attribués chaque année aux 27 SR. Récompense totale de bloc par tour Pourquoi 230 400 TRX à chaque tour ? 230 400 T RX = récompense de bloc totale par tour (BR/tour) BR/tour = 32 T RX/bloc × 20 blocs/min × 60 min/h × 6 h/tour Remarque : la récompense du bloc unitaire est définie par WITNESS_PAY_PER_BLOCK = 32 TRX. Voir le réseau dynamique paramètres. Récompense de bloc totale par an Pourquoi 336 384 000 TRX chaque année ? 336 384 000 T RX = récompense de bloc totale par an (BR/an) BR/an = 230, 400 T RX/tour × 4 tours/jour × 365 jours/an 1 janvier 2021 Il n'y aura pas d'inflation sur le réseau TRON avant le 1er janvier 2021, et le TRON DAO sera attribuer toutes les récompenses de bloc et les récompenses de candidat avant cette date. c. Calcul des récompenses

Calcul de la récompense SR récompense totale récompense de vote (V R) récompense de bloc (BR) t =
+

R. V R totale V =
×
total des voix votes reçus par le candidat SR
R.

bloc manqué 2 B =
27 BR total − × 3
Remarque : la récompense est calculée par SR et par tour (6 heures)

Calcul de la récompense du candidat SR du rang 28 au rang 127 récompense totale récompense de vote (V R) t =

R. V R totale V =
×
total des voix votes reçus par le candidat SR
Remarque : la récompense est calculée par candidat SR et par tour (6 heures) 9.2 Comité 9.2.1 Général

Le comité est utilisé pour modifier les paramètres dynamiques du réseau TRON, tels que la génération de blocs récompenses, frais de transaction, etc. Le comité est composé des 27 SR du tour en cours. Chaque SR a le droit de proposer et de voter sur les propositions. Lorsqu'une proposition reçoit 19 voix ou plus, elle est approuvé et les nouveaux paramètres réseau seront appliqués au cours de la prochaine période de maintenance (3 jours). 9.2.2 Paramètres de réseau dynamiques 0. MAINTENANCE_TIME_INTERVAL une. Descriptif
Modifier le temps d'intervalle de maintenance en ms. Connu sous le nom de temps d'intervalle de vote SR par rond.
b. Exemple [6 * 3600 * 1000] ms - soit 6 heures. c. Gamme [3271000, 2436001000] ms 1. ACCOUNT_UPGRADE_COST une. Descriptif Modifier le coût de demande de compte SR. b. Exemple [9 999 000 000] SOLEIL - soit 9 999 TRX. c. Gamme [0,100 000 000 000 000 000] DIM 2. CREATE_ACCOUNT_FEE une. Descriptif Modifier les frais de création de compte.b. Exemple [100 000] SOLEIL - soit 1 TRX. c. Gamme [0,100 000 000 000 000 000] DIM 3. TRANSACTION_FEE une. Descriptif Modifiez le montant des frais utilisés pour obtenir une bande passante supplémentaire. b. Exemple [10] SUN/octet. c. Gamme [0,100 000 000 000 000 000] SUN/octet 4. ASSET_ISSUE_FEE une. Descriptif Modifier les frais d'émission d'actifs. b. Exemple [1024 000 000] SOLEIL - soit 1024 TRX. c. Gamme [0,100 000 000 000 000 000] DIM 5. WITNESS_PAY_PER_BLOCK une. Descriptif Modifier la récompense de génération de bloc SR. Connu sous le nom de récompense de bloc unitaire. b. Exemple [32 000 000] SOLEIL - soit 32 TRX. c. Gamme [0,100 000 000 000 000 000] DIM 6. WITNESS_STANDBY_ALLOWANCE une. Descriptif Modifier les récompenses accordées aux 127 meilleurs candidats SR. Connu sous le nom de récompense totale du vote par tour. b. Exemple [115 200 000 000] SOLEIL - soit 115 200 TRX. c. Gamme [0,100 000 000 000 000 000] DIM 7. CREATE_NEW_ACCOUNT_FEE_IN_SYSTEM_CONTRACT une. Descriptif Modifier le coût de création de compte. Combinez les paramètres de réseau dynamiques #8 pour obtenir coût total de création de compte :
REATE_NEW_ACCOUNT_FEE_IN_SY STEM_CONTRACT REATE_NEW_ACCOUNT_BANDWIDTH_RATE
C ×C

b. Exemple [0] DIM. c. Gamme [0,100 000 000 000 000 000] DIM 8. CREATE_NEW_ACCOUNT_BANDWIDTH_RATE

une. Descriptif Modifier le coût de création de compte. Combinez les paramètres de réseau dynamiques n°7 pour obtenir coût total de création de compte :
REATE_NEW_ACCOUNT_FEE_IN_SY STEM_CONTRACT REATE_NEW_ACCOUNT_BANDWIDTH_RATE
C ×C

b. Exemple [1]. c. Gamme [0,100,000,000,000,000,000] 9. ALLOW_CREATION_OF_CONTRACTS une. Descriptif Pour activer la machine virtuelle Tron (TVM). b. Exemple True - défini pour être activé et pris en compte depuis le 10/10/2018 à 23h47 UTC. c. Gamme Vrai/Faux 10. REMOVE_THE_POWER_OF_THE_GR une. Descriptif Supprimer les votes initiaux de la genèse GR b. Exemple Vrai - effectué le 11/4/2018 08:46 UTC. c. Gamme Vrai/Faux - Remarque : impossible de revenir à Faux à partir de Vrai. 11. ÉNERGIE_FEE une. Descriptif Modifier les frais de 1 énergie. b. Exemple 20 DIM. c. Gamme [0,100 000 000 000 000 000] DIM 12. EXCHANGE_CREATE_FEE une. Descriptif Modifier le coût de création d'une paire de trading. Connu comme le coût de création d’un ordre commercial. b. Exemple [1 024 000 000] SOLEIL - soit 1 024 TRX. c. Gamme [0,100 000 000 000 000 000] DIM 13. MAX_CPU_TIME_OF_ONE_TX une. Descriptif Modifier le temps d'exécution maximum d'une transaction. Connu sous le nom de délai d'attente de une transaction. b. Exemple 50 ms. c. Gamme

[0, 1000] ms 14. ALLOW_UPDATE_ACCOUNT_NAME une. Descriptif Modifiez l'option pour permettre à un compte de mettre à jour son nom de compte.
b. Exemple False - qui peut être proposé à partir de Java-tron Odyssey v3.2. c. Gamme Vrai/Faux - Remarque : impossible de revenir à Faux à partir de Vrai. 15. ALLOW_SAME_TOKEN_NAME une. Descriptif Modifiez la validation en autorisant différents token à avoir un nom en double.
b. Exemple False - qui peut être proposé à partir de Java-tron Odyssey v3.2. c. Gamme Vrai/Faux - Remarque : impossible de revenir à Faux à partir de Vrai. 16. ALLOW_DELEGATE_RESOURCE une. Descriptif Modifier la validation de l'autorisation d'émettre token avec un nom en double, afin que le tokenID​ du token, en type de données entier long, serait le seul atome identification d’un token.
b. Exemple False - qui peut être proposé à partir de Java-tron Odyssey v3.2. c. Gamme Vrai/Faux - Remarque : impossible de revenir à Faux à partir de Vrai. 17. TOTAL_ENERGY_LIMIT une. Descriptif Modifier la limite énergétique totale de l'ensemble du réseau. b. Exemple [50 000 000 000 000 000] SOLEIL - soit 50 000 000 000 TRX. c. Gamme [0,100,000,000,000,000,000] SOLEIL 18. ALLOW_TVM_TRANSFER_TRC10 une. Descriptif Autoriser le transfert TRC-10 token dans les smart contracts. ALLOW_UPDATE_ACCOUNT_NAME, ALLOW_SAME_TOKEN_NAME, Les propositions ALLOW_DELEGATE_RESOURCE doivent toutes être approuvées avant d'être proposées. ce changement de paramètre.
b. Exemple False - qui peut être proposé à partir de Java-tron Odyssey v3.2. c. Gamme Vrai/Faux - Remarque : impossible de revenir à Faux à partir de Vrai.9.2.3 Créer une proposition

Seuls les comptes SR ont le droit de proposer une modification des paramètres dynamiques du réseau. 9.2.4 Proposition de vote

Seuls les membres du comité (SR) peuvent voter pour une proposition et le membre qui ne vote pas à temps sera considéré comme un désaccord. La proposition est active pendant 3 jours après sa création. Le vote peut être modifié ou récupéré pendant la fenêtre de vote de 3 jours. Une fois la période terminée, la proposition sera soit réussir (19+ votes), soit échouer (et terminer). 9.2.5 Annuler la proposition

Le proposant peut annuler la proposition avant qu'elle ne devienne effective. 9.3 Structure

Les SR sont les témoins des blocs nouvellement générés. Un témoin contient 8 paramètres :
1. adresse​ : l'adresse de ce témoin – par ex. 0xu82h…7237.
2. voteCount​ : nombre de votes reçus sur ce témoin – par ex. 234234.
3. pubKey​ : la clé publique de ce témoin – par ex. 0xu82h…7237.
4. url​ : l'url de ce témoin – par ex. https://www.noonetrust.com.
5. totalProduced​ : le nombre de blocs produits par ce témoin – par ex. 2434.
6. totalMissed​ : le nombre de blocs manqués par ce témoin – par ex. 7.
7. lastBlockNum​ : la dernière hauteur du bloc – par ex. 4522. 8. isjobs​ : un indicateur booléen.

Structure des données Protobuf : message​ ​Témoin​{
adresse ​octets​ = ​1​ ;
​int64​ voteCount = ​2​;
​octets​ pubKey = ​3​;
URL de chaîne = ​4​;
​int64​ totalProduced = ​5​;
​int64​ totalManqué = ​6​;
​int64​ lastBlockNum = ​7​; ​bool​ isJobs = ​8​; }

1. Développement DApp 10.1 API

Le réseau TRON offre une large sélection de plus de 60 passerelles API HTTP pour interagir avec le réseau via des nœuds complets et solides. De plus, TronWeb est une bibliothèque JavaScript complète contenant des fonctions API qui permettent aux développeurs de déployer des smart contract, modifiez le blockchain état, interrogez blockchain et informations sur le contrat, négociez sur le DEX et bien plus encore. Ces API les passerelles peuvent être dirigées vers un réseau privé local, le réseau de test Shasta ou le réseau principal TRON.

10.2 Réseaux

TRON possède à la fois un réseau de test Shasta et un réseau principal. Les développeurs peuvent se connecter aux réseaux en déployer des nœuds, interagir via TronStudio ou utiliser des API via le service TronGrid. La grille Tron Le service se compose de clusters de nœuds à charge équilibrée hébergés sur des serveurs AWS dans le monde entier. En tant que DApp le développement s'intensifie et les volumes d'appels API augmentent, TronGrid répond avec succès à l'augmentation du Trafic API.
10.3 Outils

TRON propose une suite d'outils de développement permettant aux développeurs de créer des DApp innovantes.
TronBox est un framework qui permet aux développeurs de tester et de déployer des smart contract via TronWeb API. TronGrid est un service API hébergé et à charge équilibrée qui permet aux développeurs d'accéder au TRON réseau sans avoir à exécuter leur propre nœud. TronGrid offre un accès à la fois au Shasta testnet ainsi que le réseau principal TRON. TronStudio est un développement intégré complet Environnement (IDE) qui permet aux développeurs de compiler, déployer et déboguer leur solution intelligente Solidity contrats. TronStudio contient un nœud complet interne qui crée un environnement local privé pour smart contract tests avant le déploiement. La bibliothèque API TronWeb connecte les développeurs au réseau via une large sélection d'appels d'API HTTP enveloppés dans JavaScript.
10.4 Ressources

Le TRON Developer Hub est un site de documentation API complet conçu pour 12 développeurs souhaitant s’appuyer sur le réseau TRON. Le Developer Hub fournit un haut niveau compréhension conceptuelle de TRON et guide les utilisateurs à travers les détails de l'interaction avec le 12 Hub des développeurs : https://developers.tron.network/

réseau. Les guides guident les développeurs dans la configuration, le déploiement et l'interaction des nœuds avec Smart. contrats, interaction et mise en œuvre de l'API, création d'exemples de DApp et utilisation de chacun des outils de développement. De plus, les chaînes de la communauté des développeurs sont disponibles via Discord.
13

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

1. Conclusion

TRON est une solution blockchain évolutive qui a utilisé des méthodes innovantes pour lutter contre défis rencontrés par les anciens réseaux blockchain. Ayant atteint plus de 2 millions de transactions par jour, avec plus de 700 000 comptes TRX et dépassant les 2 000 TPS, TRON a permis à la communauté de créer un réseau décentralisé et démocratisé.