TRON-Whitepaper

TRON Whitepaper v2.0

بقلم Justin Sun · 2017

Introduction

Introduction

1.1 Vision

TRON is an ambitious project dedicated to the establishment of a truly decentralized Internet and its infrastructure. The TRON Protocol, one of the largest blockchain-based operating systems in the world, offers public blockchain support of high throughput, high scalability, and high availability for all Decentralized Applications (DApps) in the TRON ecosystem. The July 2018 acquisition of BitTorrent further cemented TRON’s leadership in pursuing a decentralized ecosystem.
1.2 Background

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

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

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

1.3 History The TRON DAO was established in July 2017 in Singapore. In December 2017, TRON had launched its open source protocol. The Testnet, Blockchain Explorer, and Web Wallet were all launched by March 2018. TRON Mainnet launched shortly afterward in May 2018, marking the Odyssey 2.0 release as a technical milestone. In June 2018, TRON declared its independence with the creation of the Genesis block, along with the July 2018 acquisition of BitTorrent. In October 2018, TRON launched the TRON Virtual Machine (TVM), a complete developers’ toolset, and 360 support system. The TRON roadmap involves combining BitTorrent’s 100 million users with the TRON network via Project Atlas, as well as fostering the developer community to launch exciting new DApps on the TRON network1. 1 V1.0 is available at https://tron.network/static/doc/white_paper_v_1_0.pdf

TRON development roadmap phase 2 timeline from July 2018 to 2019

1.4 Terminology

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

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

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

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

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

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

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

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

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

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

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

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

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

KhaosDB TRON has a KhaosDB in the full-node memory that can store all the newly-forked chains generated within a certain period of time and supports witnesses to switch from their own active chain swiftly into a new main chain. See 2.2.2 State Storage for more details.

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

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

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

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

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

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

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

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

TKC Token configuration.

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

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

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

Einführung

1.1 Vision

TRON ist ein ehrgeiziges Projekt, das sich der Einrichtung eines wirklich dezentralen Internets widmet Infrastruktur. Das TRON-Protokoll, eines der größten blockchain-basierten Betriebssysteme in der Welt Welt, bietet öffentliche blockchain Unterstützung für hohen Durchsatz, hohe Skalierbarkeit und hohe Verfügbarkeit für alle dezentralen Anwendungen (DApps) im TRON-Ökosystem. Die Übernahme von. im Juli 2018 BitTorrent festigte die Führungsrolle von TRON bei der Verfolgung eines dezentralen Ökosystems weiter.
1.2 Hintergrund

Die Einführung von Bitcoin im Jahr 2009 revolutionierte die gesellschaftliche Wahrnehmung des traditionellen Finanzwesens System im Zuge der Großen Rezession (2007-2008). Als zentralisierte Hedgefonds und Banken brach aufgrund von Spekulationen mit undurchsichtigen Finanzderivaten zusammen, blockchain Technologie lieferte a transparentes Universalbuch, aus dem jeder Transaktionsinformationen abrufen kann. Die Transaktionen wurden mithilfe eines Proof of Work (PoW)-Konsensmechanismus kryptografisch gesichert, Dadurch werden Probleme mit doppelten Ausgaben verhindert.

Ende 2013 wurde im Whitepaper Ethereum ein Netzwerk vorgeschlagen, in dem smart contracts und a Turing-vollständige Ethereum Virtual Machine (EVM) würde es Entwicklern ermöglichen, mit der zu interagieren Netzwerk über DApps. Da jedoch die Transaktionsvolumina in Bitcoin und Ethereum im Jahr 2017 ihren Höhepunkt erreichten, Dies war an den geringen Transaktionsdurchlaufzeiten und hohen Transaktionsgebühren erkennbar Kryptowährungen wie Bitcoin und Ethereum waren in ihrem derzeitigen Zustand nicht für die weite Verbreitung skalierbar Adoption. Daher wurde TRON gegründet und als innovative Lösung für diese Pressungen konzipiert Skalierbarkeitsherausforderungen.

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

1.3 Geschichte Die TRON DAO wurde im Juli 2017 in Singapur gegründet. Im Dezember 2017 hatte TRON hat sein Open-Source-Protokoll eingeführt. Das waren Testnet, Blockchain Explorer und Web Wallet gestartet im März 2018. TRON Mainnet startete kurz darauf im Mai 2018 und markierte damit den Odyssey 2.0-Veröffentlichung als technischer Meilenstein. Im Juni 2018 erklärte TRON seine Unabhängigkeit mit der Schaffung des Genesis-Blocks, zusammen mit der Übernahme von BitTorrent im Juli 2018. In Im Oktober 2018 brachte TRON die TRON Virtual Machine (TVM) auf den Markt, ein komplettes Entwickler-Toolset. und 360-Support-System. Die TRON-Roadmap beinhaltet die Zusammenführung der 100 Millionen BitTorrent-Benutzer mit dem TRON-Netzwerk über Project Atlas sowie Förderung der Entwickler-Community beim Start aufregende neue DApps im Netzwerk TRON1. 1 V1.0 ist verfügbar unter https://tron.network/static/doc/white_paper_v_1_0.pdf

TRON development roadmap phase 2 timeline from July 2018 to 2019

1.4 Terminologie

Adresse/Geldbörse Eine Adresse oder ein Wallet, bestehend aus Kontoanmeldeinformationen im Netzwerk TRON, wird von a generiert Schlüsselpaar, das aus einem privaten Schlüssel und einem öffentlichen Schlüssel besteht, wobei letzterer vom ersteren abgeleitet ist durch einen Algorithmus. Der öffentliche Schlüssel wird normalerweise für die Verschlüsselung des Sitzungsschlüssels und die Signatur verwendet Verifizierung und Verschlüsselung von Daten, die mit einem entsprechenden privaten Schlüssel entschlüsselt werden könnten.

ABI Eine Application Binary Interface (ABI) ist eine Schnittstelle zwischen zwei binären Programmmodulen; normalerweise Eines dieser Module ist eine Bibliothek oder eine Betriebssystemfunktion, das andere wird vom Benutzer ausgeführt Programm.

API Eine Anwendungsprogrammierschnittstelle (API) wird hauptsächlich für die Entwicklung von Benutzerclients verwendet. Mit API Unterstützung können token-Ausgabeplattformen auch von Entwicklern selbst entworfen werden.

Vermögenswert In den Dokumenten von TRON ist der Vermögenswert derselbe wie token, der auch als TRC-10 token bezeichnet wird.

Bandbreitenpunkte (BP) Um den reibungslosen Betrieb des Netzwerks zu gewährleisten, nutzen TRON Netzwerktransaktionen BP als Treibstoff. Jedes Konto erhält 5000 kostenlose tägliche BP und mehr können durch das Einfrieren von TRX für BP erhalten werden. Sowohl TRX als auch TRC-10 token Überweisungen sind normale Transaktionen, die BP kosten. Intelligente Vertragsbereitstellung und -ausführung Transaktionen verbrauchen sowohl BP als auch Energie.

Blockieren Blöcke enthalten die digitalen Aufzeichnungen von Transaktionen. Ein vollständiger Block besteht aus der magischen Zahl, Blockgröße, Blockheader, Transaktionszähler und Transaktionsdaten.

Belohnung blockieren Blockproduktionsprämien werden an ein Unterkonto (Adresse/Wallet) gesendet. Supervertreter können Fordern Sie ihre Prämien auf Tronscan oder direkt über die API an.

Block-Header Ein Blockheader ist Teil eines Blocks. TRON-Blockheader enthalten die hash des vorherigen Blocks Merkle-Wurzel, Zeitstempel, Version und Zeugenadresse.Kalte Geldbörse Cold Wallet, auch Offline-Wallet genannt, hält den privaten Schlüssel vollständig von anderen getrennt Netzwerk. Cold Wallets werden in der Regel auf „kalten“ Geräten (z. B. Computern oder Mobiltelefonen) installiert offline bleiben), um die Sicherheit des privaten TRX-Schlüssels zu gewährleisten.

DApp Eine dezentrale Anwendung ist eine App, die ohne eine zentral vertrauenswürdige Partei funktioniert. Eine Bewerbung Dies ermöglicht eine direkte Interaktion/Vereinbarung/Kommunikation zwischen Endbenutzern und/oder Ressourcen ohne Zwischenhändler.

gRPC gRPC (gRPC Remote Procedure Calls) ist ein Open-Source-RPC-System (Remote Procedure Call). 2 ursprünglich bei Google entwickelt. Es verwendet HTTP/2 für den Transport, Protokollpuffer als Schnittstelle Beschreibungssprache und bietet Funktionen wie Authentifizierung, bidirektionales Streaming und Fluss Kontrolle, blockierende oder nicht blockierende Bindungen sowie Abbruch und Zeitüberschreitungen. Es erzeugt plattformübergreifende Client- und Serverbindungen für viele Sprachen. Die häufigsten Nutzungsszenarien Dazu gehören die Verbindung von Diensten in einer Microservices-Architektur und die Verbindung mobiler Geräte Browser-Clients bis hin zu Backend-Diensten.

Heiße Geldbörse Hot Wallet, auch Online-Wallet genannt, ermöglicht die Online-Nutzung des privaten Schlüssels des Benutzers anfällig für potenzielle Schwachstellen oder das Abfangen durch böswillige Akteure.

JDK Java Development Kit ist das Java SDK, das für Java-Anwendungen verwendet wird. Es ist der Kern von Java Entwicklung, bestehend aus der Java-Anwendungsumgebung (JVM+Java-Klassenbibliothek) und Java Werkzeuge.

KhaosDB TRON verfügt über eine KhaosDB im Vollknotenspeicher, die alle generierten neu gegabelten Ketten speichern kann innerhalb eines bestimmten Zeitraums und unterstützt Zeugen beim schnellen Wechsel aus der eigenen aktiven Kette in eine neue Hauptkette. Weitere Einzelheiten finden Sie unter 2.2.2 Zustandsspeicherung.

LevelDB LevelDB wurde ursprünglich mit dem primären Ziel eingeführt, die Anforderungen an schnelles Lesen/Schreiben und schnelles Lesen zu erfüllen Entwicklung. Nach dem Start des Mainnets hat TRON seine Datenbank auf eine vollständig angepasste aktualisiert Man geht auf seine ganz eigenen Bedürfnisse ein. Weitere Einzelheiten finden Sie unter 2.2.1 Blockchain-Speicher.

Merkle-Wurzel Eine Merkle-Wurzel ist der hash aller hashes aller Transaktionen, die als Teil eines Blocks in einem blockchain enthalten sind. Netzwerk. Weitere Einzelheiten finden Sie unter 3.1 Delegierter Nachweis des Einsatzes (DPoS). 2 https://en.wikipedia.org/wiki/GRPC

Öffentliches Testnetz (Shasta) Eine Version des Netzwerks, die in einer Einzelknotenkonfiguration ausgeführt wird. Entwickler können sich verbinden und testen Funktionen, ohne sich Gedanken über den wirtschaftlichen Verlust machen zu müssen. Testnet tokens haben keinen Wert und jeder kann es tun Fordern Sie mehr über den öffentlichen Wasserhahn an.

RPC
3 Beim verteilten Rechnen liegt ein Remoteprozeduraufruf (RPC) vor, wenn ein Computerprogramm eine Aktion auslöst Prozedur (Unterroutine), die in einem anderen Adressraum (üblicherweise auf einem anderen Computer) ausgeführt werden soll ein gemeinsam genutztes Netzwerk), das so codiert ist, als wäre es ein normaler (lokaler) Prozeduraufruf, ohne das Der Programmierer codiert explizit die Details für die Remote-Interaktion.

Skalierbarkeit Skalierbarkeit ist eine Funktion des TRON-Protokolls. Es ist die Fähigkeit eines Systems, Netzwerks oder Prozesses, dies zu tun ein wachsendes Arbeitsvolumen zu bewältigen oder sein Potenzial zu erweitern, um diesem Wachstum gerecht zu werden.

SONNE SUN ersetzte Drop als kleinste Einheit von TRX. 1 TRX = 1.000.000 SUN.

Durchsatz Hoher Durchsatz ist eine Funktion von TRON Mainnet. Es wird in Transaktionen pro Sekunde (TPS) gemessen. nämlich die maximale Transaktionskapazität in einer Sekunde.

Zeitstempel Der ungefähre Zeitpunkt der Blockproduktion wird als Unix-Zeitstempel aufgezeichnet, der die Anzahl angibt Millisekunden, die seit dem 1. Januar 1970, 00:00:00 UTC, vergangen sind.

TKC Token-Konfiguration.

TRC-10 Ein Krypto-Standard token auf der Plattform TRON. Bestimmte Regeln und Schnittstellen müssen beachtet werden bei einem Initial Coin Offering am TRON blockchain.

TRX TRX steht für Tronix, die offizielle Kryptowährung von TRON.

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

Architecture

Architecture

TRON adopts a 3-layer architecture divided into Storage Layer, Core Layer, and Application Layer. The TRON protocol adheres to Google Protobuf, which intrinsically supports multi-language extension.

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

Figure 1: TRON 3-layer Architecture

2.1 Core

There are several modules in the core layer, including smart contracts, account management, and consensus. A stack-based virtual machine is implemented on TRON and an optimized instruction set is used. In order to better support DApp developers, Solidity was chosen as the smart contract 4 language, followed by future support of other advanced languages. In addition, TRON's consensus mechanism is based on Delegated Proof of Stake (DPoS) and many innovations were made in order to meet its unique requirements. 2.2 Storage

TRON designed a unique distributed storage protocol consisting of Block Storage and State Storage. The notion of a graph database was introduced into the design of the storage layer to better meet the need for diversified data storage in the real world. 2.2.1 Blockchain Storage

TRON blockchain storage chooses to use LevelDB, which is developed by Google and proven successful with many companies and projects. It has high performance and supports arbitrary byte arrays as both keys and values, singular get, put and delete, batched put and delete, bi-directional iterators, and simple compression using the very fast Snappy algorithm. 2.2.2 State Storage

TRON has a KhaosDB in the full-node memory that can store all the newly forked chains generated within a certain period of time and supports witnesses to switch from their own active chain swiftly into a new main chain. It can also protect blockchain storage by making it more stable from being terminating abnormally in an intermediate state. 2.3 Application

Developers can create a diverse range of DApps and customized wallets on TRON. Since TRON enables smart contracts to be deployed and executed, the opportunities of utility applications are unlimited. 4 Solidity official documentation: https://solidity.readthedocs.io/

2.4 Protocol

TRON protocol adheres to Google Protocol Buffers , which is a language-neutral, platform-neutral, 5 and extensible way of serializing structured data for use in communications protocols, data storage, and more. 2.4.1 Protocol Buffers

Protocol Buffers (Protobuf) is a flexible, efficient, automated mechanism for serializing structured data, similar to JSON or XML, but much smaller, faster and simpler.

Protobuf (.proto) definitions can be used to generate code for C++, Java, C#, Python, Ruby, Golang, and Objective-C languages through the official code generators. Various third-party implementations are also available for many other languages. Protobuf eases development for clients by unifying the API definitions and also optimizing data transfers. Clients can take the API .proto from TRON’s protocol repository and integrate through the automatically-generated code libraries.

As a comparison, Protocol Buffers is 3 to 10 times smaller and 20 to 100 times faster than XML, with less ambiguous syntax. Protobuf generates data access classes that are easier to use programmatically. 2.4.2 HTTP

TRON Protocol provides a RESTful HTTP API alternative to the Protobuf API. They share the same interface but the HTTP API can be readily used in javascript clients. 2.5 TRON Virtual Machine (TVM)

The TVM is a lightweight, Turing complete virtual machine developed for TRON’s ecosystem. The TVM connects seamlessly with the existing development ecosystem to provide millions of global developers with a custom-built blockchain system that is efficient, convenient, stable, secure, and scalable.
2.6 Decentralized Exchange (DEX)

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

The TRON network natively supports decentralized exchange functions. A decentralized exchange consists of multiple trading pairs. A trading pair (notation “Exchange”) is an Exchange Market between TRC-10 tokens, or between a TRC-10 token and TRX. Any account can create a trading pair between any tokens, even if the same pair already exists on the TRON network. Trading and price fluctuations of the trading pairs follow the Bancor Protocol . The TRON network stipulates that 6 the weights of the two tokens in all trading pairs are equal, so the ratio of their balances is the price between them. For example, consider a trading pair containing two tokens, ABC and DEF. ABC has a balance of 10 million and DEF has a balance of 1 million. Since their weights are equal, 10 ABC = 1 DEF. This means that the ratio of ABC to DEF is 10 ABC per DEF. 2.7 Implementation

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

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

Architektur

TRON verwendet eine dreischichtige Architektur, die in Speicherschicht, Kernschicht und Anwendungsschicht unterteilt ist. Das TRON-Protokoll folgt Google Protobuf, das von Natur aus Mehrsprachen unterstützt Erweiterung.

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

Abbildung 1: TRON 3-Schicht-Architektur

2.1 Kern

In der Kernschicht gibt es mehrere Module, darunter smart contracts, Kontoverwaltung und Konsens. Eine stapelbasierte virtuelle Maschine wird auf TRON und einer optimierten Anweisung implementiert Satz verwendet wird. Um DApp-Entwickler besser zu unterstützen, wurde Solidity als smart contract ausgewählt. 4 Sprache, gefolgt von der zukünftigen Unterstützung anderer fortgeschrittener Sprachen. Darüber hinaus der Konsens von TRON Der Mechanismus basiert auf dem Delegated Proof of Stake (DPoS) und viele Innovationen wurden vorgenommen um seinen individuellen Anforderungen gerecht zu werden. 2.2 Lagerung

TRON hat ein einzigartiges verteiltes Speicherprotokoll entwickelt, das aus Blockspeicher und Status besteht Lagerung. Der Begriff einer Graphdatenbank wurde in das Design der Speicherschicht eingeführt den Bedarf an diversifizierter Datenspeicherung in der realen Welt besser erfüllen. 2.2.1 Blockchain-Speicher

TRON blockchain Speicher entscheidet sich für die Verwendung von LevelDB, das von Google entwickelt und bewährt wurde erfolgreich bei vielen Unternehmen und Projekten. Es verfügt über eine hohe Leistung und unterstützt beliebige Bytes Arrays sowohl als Schlüssel als auch als Werte, singuläres Abrufen, Einfügen und Löschen, gestapeltes Einfügen und Löschen, bidirektional Iteratoren und einfache Komprimierung mit dem sehr schnellen Snappy-Algorithmus. 2.2.2 Zustandsspeicher

TRON verfügt über eine KhaosDB im Vollknotenspeicher, die alle neu generierten gegabelten Ketten speichern kann innerhalb eines bestimmten Zeitraums und unterstützt Zeugen beim schnellen Wechsel aus der eigenen aktiven Kette in eine neue Hauptkette. Es kann auch den Speicher blockchain schützen, indem es ihn stabiler macht endet abnormal in einem Zwischenzustand. 2.3 Anwendung

Entwickler können auf TRON eine Vielzahl von DApps und benutzerdefinierten Wallets erstellen. Seit TRON ermöglicht die Bereitstellung und Ausführung von smart contracts, die Möglichkeiten von Dienstprogrammanwendungen sind groß unbegrenzt. 4 Offizielle Solidity-Dokumentation: https://solidity.readthedocs.io/

2.4 Protokoll

Das TRON-Protokoll folgt Google Protocol Buffers, einem sprach- und plattformneutralen Protokoll. 5 und erweiterbare Möglichkeit zur Serialisierung strukturierter Daten zur Verwendung in Kommunikationsprotokollen, Datenspeicherung, und mehr. 2.4.1 Protokollpuffer

Protocol Buffers (Protobuf) ist ein flexibler, effizienter und automatisierter Mechanismus zur Serialisierung strukturierter Daten Daten, ähnlich wie JSON oder XML, aber viel kleiner, schneller und einfacher.

Protobuf-Definitionen (.proto) können zum Generieren von Code für C++, Java, C#, Python, Ruby, Golang- und Objective-C-Sprachen über die offiziellen Codegeneratoren. Diverse Drittanbieter Implementierungen sind auch für viele andere Sprachen verfügbar. Protobuf erleichtert die Entwicklung für Clients durch Vereinheitlichung der API-Definitionen und Optimierung der Datenübertragung. Kunden können die API nutzen .proto aus dem Protokoll-Repository von TRON herunterladen und über den automatisch generierten Code integrieren Bibliotheken.

Im Vergleich dazu ist Protocol Buffers 3 bis 10 Mal kleiner und 20 bis 100 Mal schneller als XML. mit weniger mehrdeutiger Syntax. Protobuf generiert Datenzugriffsklassen, die einfacher zu verwenden sind programmatisch. 2.4.2 HTTP

Das TRON-Protokoll bietet eine RESTful-HTTP-API-Alternative zur Protobuf-API. Sie teilen dasselbe Schnittstelle, aber die HTTP-API kann problemlos in Javascript-Clients verwendet werden. 2.5 TRON Virtuelle Maschine (TVM)

Der TVM ist eine leichte, vollständige virtuelle Turing-Maschine, die für das Ökosystem von TRON entwickelt wurde. Die TVM verbindet sich nahtlos mit dem bestehenden Entwicklungsökosystem, um Millionen von Menschen auf der ganzen Welt bereitzustellen Entwicklern ein maßgeschneidertes blockchain-System zur Verfügung, das effizient, bequem, stabil, sicher und effizient ist skalierbar.
2.6 Dezentraler Austausch (DEX)

5 Offizielle Dokumentation zu Google Protocol Buffers: https://developers.google.com/protocol-buffers/Das Netzwerk TRON unterstützt nativ dezentrale Austauschfunktionen. Eine dezentrale Börse besteht aus mehreren Handelspaaren. Ein Handelspaar (Bezeichnung „Börse“) ist ein Börsenmarkt zwischen TRC-10 tokens oder zwischen einem TRC-10 token und TRX. Jedes Konto kann einen Handel erstellen Paar zwischen beliebigen tokens, auch wenn das gleiche Paar bereits im TRON-Netzwerk vorhanden ist. Handel und Preisschwankungen der Handelspaare folgen dem Bancor-Protokoll. Das Netzwerk TRON schreibt dies vor 6 Die Gewichte der beiden tokens in allen Handelspaaren sind gleich, daher ist das Verhältnis ihrer Salden der Preis zwischen ihnen. Betrachten Sie beispielsweise ein Handelspaar mit zwei tokens, ABC und DEF. ABC hat ein Saldo von 10 Millionen und DEF hat einen Saldo von 1 Million. Da ihre Gewichte gleich sind, ist 10 ABC = 1 DEF. Das bedeutet, dass das Verhältnis von ABC zu DEF 10 ABC pro DEF beträgt. 2.7 Umsetzung

Der Code TRON blockchain ist in Java implementiert und war ursprünglich ein Fork von EthereumJ.

6 Offizielle Website des Bancor-Protokolls: https://about.bancor.network/protocol/

Consensus

Consensus

3.1 Delegated Proof of Stake (DPoS)

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

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

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

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

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

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

To solve the energy waste issue, the Proof of Stake (PoS) consensus mechanism was proposed by many new networks. In PoS networks, token holders lock their token balances to become block validators. The validators take turns proposing and voting on the next block. However, the problem with standard PoS is that validator influence correlates directly to the amount of tokens locked up. This results in parties hoarding large amounts of the network’s base currency wielding undue influence in the network ecosystem.

The TRON consensus mechanism uses an innovative Delegated Proof of Stake system in which 27 Super Representatives (SRs) produce blocks for the network. Every 6 hours, TRX account holders who freeze their accounts can vote for a selection of SR candidates, with the top 27 candidates deemed the SRs. Voters may choose SRs based on criteria such as projects sponsored by SRs to 9 PAAR, C., PELZL, J., ​Understanding Cryptography: A Textbook for Students and Practitioners​, 2010 ed. Springer-Verlag Berlin Heidelberg, 2010.
10 https://www.sciencedirect.com/science/article/pii/S2542435118301776

increase TRX adoption, and rewards distributed to voters. This allows for a more democratized and decentralized ecosystem. SRs’ accounts are normal accounts, but their accumulation of votes allows them to produce blocks. With the low throughput rates of Bitcoin and Ethereum due to their PoW consensus mechanism and scalability issues, TRON’s DPoS system offers an innovative mechanism resulting in 2000 TPS compared to Bitcoin’s 3 TPS and Ethereum’s 15 TPS.

The TRON protocol network generates one block every three seconds, with each block awarding 32 TRX to Super Representatives. A total of 336,384,000 TRX will be awarded annually to the 27 SRs. Each time an SR finishes block production, rewards are sent to a sub-account in the super-ledger. SRs can check, but not directly make use of these TRX tokens. A withdrawal can be made by each SR once every 24 hours, transferring the rewards from the sub-account to the specified SR account.

The three types of nodes on the TRON network are Witness Node, Full Node, and Solidity Node. Witness nodes are set up by SRs and are mainly responsible for block production and proposal creation/voting. Full nodes provide APIs and broadcast transactions and blocks. Solidity nodes sync blocks from other Full Nodes and also provide indexable APIs.

Konsens

3.1 Delegierter Nachweis des Einsatzes (DPoS)

Der früheste Konsensmechanismus ist der Proof of Work (PoW)-Konsensmechanismus. Dies Das Protokoll ist derzeit in Bitcoin und Ethereum implementiert. In PoW-Systemen Transaktionen 7 8 Über das Netzwerk gesendete Daten werden zur Bestätigung durch den Miner in neu entstehende Blöcke gruppiert. Die Der Bestätigungsprozess umfasst das hashing von Transaktionen mithilfe kryptografischer hashing-Algorithmen, bis a Die Merkle-Wurzel wurde erreicht, wodurch ein Merkle-Baum erstellt wurde:

Abbildung 2: 8 TRX-Transaktionen werden im Merkle-Root hashed. Diese Merkle-Wurzel wird dann in den Block-Header eingefügt, der wird an die zuvor bestätigten Blöcke angehängt, um einen blockchain zu bilden. Dies ermöglicht eine einfache und transparente Nachverfolgung Transaktionen, Zeitstempel und andere verwandte Informationen.

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

Kryptografische Algorithmen sind bei der Verhinderung von Netzwerkangriffen nützlich, da sie Folgendes besitzen mehrere Eigenschaften:
9

● Größe der Eingabe-/Ausgabelänge – Der Algorithmus kann eine Eingabe beliebiger Länge und Größe übergeben gibt einen Wert mit fester Länge hash aus.
● Effizienz: Der Algorithmus ist relativ einfach und schnell zu berechnen.
● Urbildwiderstand – Für einen gegebenen Ausgang z ist es unmöglich, einen solchen Eingang x zu finden h(x) =​ ​z​. Mit anderen Worten, der hashing-Algorithmus ​h(x)​ ist eine Einwegfunktion, in der nur die Ausgabe kann gefunden werden, wenn eine Eingabe gegeben ist. Das Umgekehrte ist nicht möglich.
● Kollisionswiderstand – Es ist rechnerisch nicht möglich, Paare ​x​1 ​≠ x​2​ ​zu finden, so dass ​h(x​1​) = h(x​2​)​. Mit anderen Worten, die Wahrscheinlichkeit, zwei unterschiedliche Eingaben zu finden, die auf denselben Wert verweisen Die Leistung ist extrem gering. Diese Eigenschaft impliziert auch einen Widerstand gegen das zweite Urbild.
● Zweiter Urbildwiderstand: Bei gegebenem x1 und damit h(x1) ist dies rechnerisch nicht möglich Finden Sie ein beliebiges ​x​2​ mit ​h(x​1​) = h(x​2​)​. Während diese Eigenschaft der Kollisionsbeständigkeit ähnelt, ist die Die Eigenschaft unterscheidet sich darin, dass sie besagt, dass ein Angreifer mit einem bestimmten ​x​1​ es rechnerisch finden wird Es ist unmöglich, ​x​2​ hashzu finden, die zum gleichen Ausgang führen.
● Deterministisch – ordnet jede Eingabe einer und nur einer Ausgabe zu. ● Avalanche-Effekt – eine kleine Änderung der Eingabe führt zu einer völlig anderen Ausgabe.

Diese Eigenschaften verleihen dem Kryptowährungsnetzwerk seinen inneren Wert, indem sie dafür sorgen, dass es nicht zu Angriffen kommt das Netzwerk gefährden. Wenn Miner einen Block bestätigen, erhalten sie als integrierte Belohnung tokens Anreiz zur Netzwerkbeteiligung. Allerdings als die globale Marktkapitalisierung der Kryptowährung Die Zahl der Miner nahm stetig zu, die Miner wurden zentralisiert und konzentrierten ihre Rechenressourcen darauf Horten von tokens als Vermögenswerte und nicht für Zwecke der Netzwerkbeteiligung. CPU-Miner gaben nach GPUs, die wiederum leistungsstarken ASICs Platz machten. In einer bemerkenswerten Studie wurde die Gesamtleistung ermittelt Der Verbrauch von Bitcoin Bergbau wurde auf bis zu 3 GW geschätzt, vergleichbar mit Irland 10 Stromverbrauch. Dieselbe Studie geht davon aus, dass der Gesamtstromverbrauch in naher Zukunft 8 GW erreichen wird Zukunft.

Um das Problem der Energieverschwendung zu lösen, wurde der Proof of Stake (PoS)-Konsensmechanismus vorgeschlagen viele neue Netzwerke. In PoS-Netzwerken sperren token-Inhaber ihre token-Guthaben, um sie zu blockieren validators. Die validators schlagen abwechselnd den nächsten Block vor und stimmen darüber ab. Allerdings ist das Problem Beim Standard-PoS korreliert der Einfluss von validator direkt mit der Anzahl der gesperrten tokens. Dies führt dazu, dass die Parteien große Mengen der Basiswährung des Netzwerks horten und unrechtmäßig handeln Einfluss auf das Netzwerk-Ökosystem.

Der Konsensmechanismus TRON verwendet ein innovatives Delegated Proof of Stake-System, bei dem 27 Super Representatives (SRs) produzieren Blöcke für das Netzwerk. Alle 6 Stunden, TRX-Kontoinhaber Wer sein Konto einfriert, kann für eine Auswahl von SR-Kandidaten stimmen, darunter die besten 27 Kandidaten gelten als die SRs. Wähler können SRs auf der Grundlage von Kriterien auswählen, beispielsweise von Projekten, die von SRs gesponsert werden 9 PAAR, C., PELZL, J., ​Understanding Cryptography: A Textbook for Students and Practitioners​, Ausgabe 2010. Springer-Verlag Berlin Heidelberg, 2010.
10 https://www.sciencedirect.com/science/article/pii/S2542435118301776Erhöhen Sie die TRX-Akzeptanz und die Verteilung der Belohnungen an die Wähler. Dies ermöglicht eine stärkere Demokratisierung und dezentrales Ökosystem. Die Konten der SRs sind normale Konten, aber ihre Ansammlung von Stimmen ermöglicht es ihnen, Blöcke zu produzieren. Aufgrund der geringen Durchsatzraten von Bitcoin und Ethereum PoW-Konsensmechanismus und Skalierbarkeitsprobleme: Das DPoS-System von TRON bietet eine Innovation Mechanismus führt zu 2000 TPS im Vergleich zu 3 TPS von Bitcoin und 15 TPS von Ethereum.

Das Protokollnetzwerk TRON generiert alle drei Sekunden einen Block, wobei jeder Block 32 vergibt TRX an Supervertreter. Insgesamt werden jährlich 336.384.000 TRX an die 27 SRs vergeben. Jedes Mal, wenn ein SR die Blockproduktion abschließt, werden Belohnungen an ein Unterkonto im Super-Ledger gesendet. SRs können diese TRX tokens prüfen, aber nicht direkt nutzen. Ein Widerruf kann von jedem vorgenommen werden SR einmal alle 24 Stunden, wobei die Prämien vom Unterkonto auf den angegebenen SR übertragen werden Konto.

Die drei Knotentypen im Netzwerk TRON sind Witness Node, Full Node und Solidity Node. Zeugenknoten werden von SRs eingerichtet und sind hauptsächlich für die Blockproduktion und -vorschläge verantwortlich Erstellung/Abstimmung. Vollständige Knoten stellen APIs bereit und übertragen Transaktionen und Blöcke. Solidity-Knoten werden synchronisiert Blöcke von anderen Full Nodes und stellen auch indizierbare APIs bereit.

Account

Account

4.1 Types

The three types of accounts in the TRON network are regular accounts, token accounts, and contract accounts.

1. Regular accounts are used for standard transactions.
2. Token accounts are used for storing TRC-10 tokens.
3. Contract accounts are smart contract accounts created by regular accounts and can be triggered by regular accounts as well. 4.2 Creation

There are three ways to create a TRON account:

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

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

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

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

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

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

​bytes​ vote_address = ​1​;

​int64​ vote_count = ​2​;

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

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

Konto

4.1 Typen

Die drei Arten von Konten im TRON-Netzwerk sind reguläre Konten, token-Konten und Vertragskonten.

1. Für Standardtransaktionen werden reguläre Konten verwendet.
2. Token-Konten werden zum Speichern von TRC-10 tokens verwendet.
3. Vertragskonten sind smart contract Konten, die von regulären Konten erstellt wurden und können wird auch durch reguläre Konten ausgelöst. 4.2 Schöpfung

Es gibt drei Möglichkeiten, ein TRON-Konto zu erstellen:

1. Erstellen Sie über die API ein neues Konto 2. Übertragen Sie TRX auf eine neue Kontoadresse 3. Übertragen Sie alle TRC-10 token in eine neue Kontoadresse

Ein Offline-Schlüsselpaar, das aus einer Adresse (öffentlicher Schlüssel) und einem privaten Schlüssel besteht und nicht von der Adresse aufgezeichnet wird TRON Netzwerk, kann ebenfalls generiert werden. Der Algorithmus zur Generierung der Benutzeradresse besteht aus Erzeugen eines Schlüsselpaars und anschließendes Extrahieren des öffentlichen Schlüssels (64-Byte-Byte-Array, das x, y darstellt). Koordinaten). Hashen Sie den öffentlichen Schlüssel mithilfe der SHA3-256-Funktion (das verwendete SHA3-Protokoll ist). KECCAK-256) und extrahieren Sie die letzten 20 Bytes des Ergebnisses. Fügen Sie 41 am Anfang des Byte-Arrays hinzu und stellen Sie sicher, dass die anfängliche Adresslänge 21 Byte beträgt. Hashen Sie die Adresse zweimal mit der SHA3-256-Funktion und nehmen Sie die ersten 4 Bytes als Bestätigungscode. Fügen Sie den Bestätigungscode am Ende der Initiale hinzu Adresse und erhalten Sie die Adresse im Base58-Check-Format durch Base58-Codierung. Eine verschlüsselte Die Mainnet-Adresse beginnt mit T und ist 34 Byte lang. 4.3 Struktur

Die drei verschiedenen Kontotypen sind Normal, AssetIssue und Contract. Ein Konto enthält 7 Parameter:

1. Kontoname​: der Name für dieses Konto – z.B. RechnungenKonto.
2. Typ​: Um welchen Typ handelt es sich bei diesem Konto – z.B. 0 (steht für Typ „Normal“).
3. Saldo​: Saldo dieses Kontos – z.B. 4213312.

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

​bytes​ vote_address = ​1​;

​int64​ vote_count = ​2​;

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

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

Block

Block

A block typically contains a block header and several transactions.

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

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

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

​int64​ timestamp = ​1​;

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

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

​bytes​ witness_address = ​6​;

} ​bytes​ witness_signature = ​2​; ​bytes​ blockID = ​3​;
} 5.1.1 Raw Data

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

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

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

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

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

Block ID is denoted as ​blockID​ in Protobuf. It contains the atomic identification of a block. A Block ID contains 2 parameters: 1. hash​: the hash of block. 2. number​: the hash and height of the block. 5.2 Transaction 5.2.1 Signing

TRON’s transaction signing process follows a standard ECDSA cryptographic algorithm, with a SECP256K1 selection curve. A private key is a random number, and the public key is a point on the elliptic curve. The public key generation process consists of first generating a random number as a private key, and then multiplying the base point of the elliptic curve by the private key to obtain the public key. When a transaction occurs, the transaction raw data is first converted into byte format. The raw data then undergoes SHA-256 hashing. The private key corresponding to the contract address then signs the result of the SHA256 hash. The signature result is then added to the transaction.
5.2.2 Bandwidth Model

Ordinary transactions only consume bandwidth points, but smart contract operations consume both energy and bandwidth points. There are two types of bandwidth points available. Users can gain bandwidth points from freezing TRX, while 5000 free bandwidth points are also available daily.

When a TRX transaction is broadcast, it is transmitted and stored in the form of a byte array over the network. Bandwidth Points consumed by one transaction = number of transaction bytes multiplied by bandwidth points rate. For example, if the byte array length of a transaction is 200, then the transaction consumes 200 bandwidth points. However, if a TRX or token transfer results in the target account being created, then only the bandwidth points consumed to create the account will be deducted, and additional bandwidth points will not be deducted. In an account creation scenario, the network will first consume the bandwidth points that the transaction initiator gained

from freezing TRX. If this amount is insufficient, then the network consumes the transaction initiator’s TRX.

In standard TRX transfer scenarios from one TRX account to another, the network first consumes the bandwidth points gained by the transaction initiator for freezing TRX. If that is insufficient, it then consumes from the free 5000 daily bandwidth points. If that is still not enough, then the network consumes the TRX of the transaction initiator. The amount is calculated by the number of bytes in the transaction multiplied by 10 SUN. Thus, for most TRX holders who may not necessarily freeze their TRX to participate in SR voting, the first step is automatically skipped (since TRX balance frozen = 0) and the 5000 daily free bandwidth powers the transaction.

For TRC-10 token transfers, the network first verifies whether the total free bandwidth points of the issued token asset are sufficient. If not, the bandwidth points obtained from freezing TRX are consumed. If there is still not enough bandwidth points, then it consumes the TRX of the transaction initiator.

5.2.3 Fee

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

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

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

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

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

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

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

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

Block

Ein Block enthält typischerweise einen Blockheader und mehrere Transaktionen.

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

Ein Blockheader enthält ​raw_data​, ​witness_signature​ und ​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 Rohdaten

Rohdaten werden in Protobuf als ​raw_data​ bezeichnet. Es enthält die Rohdaten einer Nachricht, bestehend aus 6 Parameter:

1. Zeitstempel​: Zeitstempel dieser Nachricht – z.B. 1543884429000. 2. txTrieRoot​: die Wurzel des Merkle-Baums – z.B. 7dacsa…3ed. 3. parentHash​: der hash des letzten Blocks – z.B. 7dacsa…3ed. 4. Zahl​: die Blockhöhe – z.B. 4638708. 5. Version​: reserviert – z.B. 5.

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

6. Zeugenadresse​: die Adresse des in diesem Block enthaltenen Zeugen – z.B. 41928c...4d21. 5.1.2 Unterschrift des Zeugen

Die Zeugensignatur wird in Protobuf als ​witness_signature​ bezeichnet, was die Signatur dafür ist Blockheader vom Zeugenknoten. 5.1.3 Block-ID

Die Block-ID wird in Protobuf als ​blockID​ bezeichnet. Es enthält die atomare Identifikation eines Blocks. Ein Block ID enthält 2 Parameter: 1. hash​: der hash des Blocks. 2. Nummer: hash und Höhe des Blocks. 5.2 Transaktion 5.2.1 Unterzeichnung

Der Transaktionssignierungsprozess von TRON folgt einem standardmäßigen kryptografischen ECDSA-Algorithmus mit a SECP256K1-Auswahlkurve. Ein privater Schlüssel ist eine Zufallszahl und der öffentliche Schlüssel ist ein Punkt auf dem elliptische Kurve. Der Prozess der Generierung eines öffentlichen Schlüssels besteht darin, zunächst eine Zufallszahl als eine zu generieren privaten Schlüssel und dann Multiplikation des Basispunkts der elliptischen Kurve mit dem privaten Schlüssel, um den zu erhalten öffentlicher Schlüssel. Wenn eine Transaktion stattfindet, werden die Rohdaten der Transaktion zunächst in das Byte-Format konvertiert. Anschließend werden die Rohdaten SHA-256 hashing unterzogen. Der dem Vertrag entsprechende private Schlüssel Die Adresse signiert dann das Ergebnis des SHA256 hash. Das Signaturergebnis wird dann dem hinzugefügt Transaktion.
5.2.2 Bandbreitenmodell

Gewöhnliche Transaktionen verbrauchen nur Bandbreitenpunkte, smart contract-Vorgänge verbrauchen jedoch beide Energie- und Bandbreitenpunkte. Es stehen zwei Arten von Bandbreitenpunkten zur Verfügung. Benutzer können gewinnen Bandbreitenpunkte durch das Einfrieren von TRX, während täglich auch 5000 kostenlose Bandbreitenpunkte verfügbar sind.

Wenn eine TRX-Transaktion gesendet wird, wird sie in Form eines Byte-Arrays übertragen und gespeichert das Netzwerk. Von einer Transaktion verbrauchte Bandbreitenpunkte = Anzahl der Transaktionsbytes multipliziert mit der Bandbreitenpunktrate. Wenn beispielsweise die Byte-Array-Länge einer Transaktion 200 beträgt, dann verbraucht die Transaktion 200 Bandbreitenpunkte. Wenn jedoch eine TRX- oder token-Übertragung erfolgt das Zielkonto, das erstellt wird, dann nur die Bandbreitenpunkte, die zum Erstellen des Kontos verbraucht wurden abgezogen, zusätzliche Bandbreitenpunkte werden nicht abgezogen. Bei einer Kontoerstellung In diesem Szenario verbraucht das Netzwerk zunächst die Bandbreitenpunkte, die der Transaktionsinitiator gewonnen hatvom Einfrieren von TRX. Reicht dieser Betrag nicht aus, verbraucht das Netzwerk die Transaktion TRX des Initiators.

In Standard-TRX-Übertragungsszenarien von einem TRX-Konto zu einem anderen verbraucht das Netzwerk zuerst die Bandbreitenpunkte, die der Transaktionsinitiator für das Einfrieren von TRX gewonnen hat. Wenn das nicht ausreicht, dann verbraucht von den kostenlosen 5000 täglichen Bandbreitenpunkten. Wenn das immer noch nicht reicht, dann das Netzwerk verbraucht den TRX des Transaktionsinitiators. Die Menge wird anhand der Anzahl der Bytes berechnet die Transaktion multipliziert mit 10 SUN. Daher ist für die meisten TRX-Inhaber dies nicht unbedingt der Fall Wenn ihr TRX an der SR-Abstimmung teilnehmen möchte, wird der erste Schritt automatisch übersprungen (da TRX-Guthaben eingefroren = 0) und die tägliche freie Bandbreite von 5000 treibt die Transaktion an.

Bei TRC-10 token-Übertragungen überprüft das Netzwerk zunächst, ob die gesamten freien Bandbreitenpunkte des ausgestelltes token-Vermögenswert sind ausreichend. Wenn nicht, sind es die Bandbreitenpunkte, die durch das Einfrieren von TRX erhalten werden verbraucht. Wenn immer noch nicht genügend Bandbreitenpunkte vorhanden sind, wird der TRX der Transaktion verbraucht Initiator.

5.2.3 Gebühr

Das Netzwerk TRON erhebt jedoch systembedingt grundsätzlich keine Gebühren für die meisten Transaktionen Einschränkungen und Fairness, Bandbreitennutzung und Transaktionen erfordern bestimmte Gebühren.

Die Gebühren werden in die folgenden Kategorien unterteilt: 1. Normale Transaktionen kosten Bandbreitenpunkte. Benutzer können die kostenlosen täglichen Bandbreitenpunkte nutzen (5000) oder TRX einfrieren, um mehr zu erhalten. Wenn Bandbreitenpunkte nicht ausreichen, wird TRX ausreichen direkt vom sendenden Konto verwendet werden. Der benötigte TRX ist die Anzahl der Bytes * 10 SUN. 2. Intelligente Verträge kosten Energie (Abschnitt 6), benötigen dafür aber auch Bandbreitenpunkte Die Transaktion muss übertragen und bestätigt werden. Die Bandbreitenkosten sind die gleichen wie oben. 3. Alle Abfragetransaktionen sind kostenlos. Es kostet weder Energie noch Bandbreite.

Das Netzwerk TRON definiert außerdem eine Reihe fester Gebühren für die folgenden Transaktionen: 1. Erstellen eines Zeugenknotens: 9999 TRX 2. Ausgabe eines TRC-10 token: 1024 TRX 3. Erstellen eines neuen Kontos: 0,1 TRX 4. Erstellen eines Austauschpaares: 1024 TRX 5.2.4 Transaktion als Proof of Stake (TaPoS)

TRON verwendet TaPoS, um sicherzustellen, dass alle Transaktionen den Haupt-blockchain bestätigen, während sie ausgeführt werden Es ist schwierig, gefälschte Ketten zu fälschen. In TaPoS verlangen die Netzwerke, dass jede Transaktion einen Teil davon umfasst der hash eines aktuellen Blockheaders. Diese Anforderung verhindert, dass Transaktionen wiederholt werden Forks enthalten nicht den referenzierten Block und signalisieren dem Netzwerk auch, dass ein bestimmter Benutzer und seinDer Einsatz liegt auf einer bestimmten Gabel. Dieser Konsensmechanismus schützt das Netzwerk vor Denial of Service, 51 %, egoistisches Mining und Double-Spend-Angriffe.
5.2.5 Transaktionsbestätigung

Eine Transaktion wird in einen zukünftigen Block aufgenommen, nachdem sie an das Netzwerk gesendet wurde. Nach 19 Blöcken sind abgebaut auf TRON (einschließlich seines eigenen Blocks), die Transaktion wird bestätigt. Jeder Block wird von erzeugt einer der 27 besten Super-Repräsentanten im Round-Robin-Verfahren. Jeder Block dauert ca. 3 Sekunden auf dem blockchain abgebaut werden. Aufgrund des Netzwerks kann die Zeit für jeden Super-Repräsentanten leicht variieren Bedingungen und Maschinenkonfigurationen. Im Allgemeinen gilt eine Transaktion danach als vollständig bestätigt ~1 Minute. 5.2.6 Struktur

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

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

TRON Virtual Machine

TRON Virtual Machine

6.1 Introduction

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

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

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

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

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

Figure 3: TVM Workflow

6.3 Performance 6.3.1 Lightweight Architecture

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

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

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

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

TRON Virtuelle Maschine

6.1 Einführung

TRON Virtual Machine (TVM) ist eine leichte, vollständige Turing-virtuelle Maschine, die für entwickelt wurde Das Ökosystem von TRON. Sein Ziel ist es, ein maßgeschneidertes blockchain-System bereitzustellen, das effizient ist, bequem, stabil, sicher und skalierbar.

TVM wurde ursprünglich von EVM abgezweigt und kann nahtlos mit der bestehenden Solidität smart contract verbunden werden. 11 Entwicklungsökosystem. Auf dieser Grundlage unterstützt TVM zusätzlich den Konsens DPoS.

TVM verwendet das Konzept der Energie. Anders als beim Gasmechanismus auf EVM, Operationen von Transaktionen und smart contracts auf TVM sind kostenlos, es wird kein TRX verbraucht. Technisch ausführbar Die Rechenkapazität auf TVM ist nicht durch den Gesamtbestand von tokens eingeschränkt. 6.2 Arbeitsablauf

Der Compiler übersetzt zunächst den Solidity smart contract in lesbaren und ausführbaren Bytecode der TVM. Das TVM verarbeitet die Daten dann über den Opcode, was dem Betrieb der Logik entspricht eines stapelbasierten Finite-State-Automaten. Schließlich greift der TVM auf blockchain-Daten zu und ruft sie auf Externe Datenschnittstelle über die Interoperation-Schicht. 11 EVM: Ethereum Virtuelle Maschine (https://github.com/ethereum/ethereumj)

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

Abbildung 3: TVM-Workflow

6.3 Leistung 6.3.1 Leichtbauarchitektur

TVM übernimmt eine leichtgewichtige Architektur mit dem Ziel, einen reduzierten Ressourcenverbrauch zu gewährleisten Systemleistung. 6.3.2 Robust

TRX-Übertragungen und smart contract-Ausführung kosten nur Bandbreitenpunkte, anstelle von TRX, was befreit TRON von Angriffen. Der Bandbreitenverbrauch ist vorhersehbar und statisch Die Kosten für den Rechenschritt sind festgelegt. 6.3.3 Hohe Kompatibilität

TVM ist mit EVM kompatibel und wird in Zukunft mit weiteren Mainstream-VMs kompatibel sein. Dadurch sind alle smart contracts auf EVM auf TVM ausführbar. 6.3.4 Niedrige Kosten

Aufgrund der Bandbreiteneinrichtung von TVM werden die Entwicklungskosten reduziert und Entwickler können sich auf das konzentrieren logische Entwicklung ihres Vertragscodes. TVM bietet auch All-in-One-Schnittstellen für Verträge an Bereitstellung, Auslösung und Anzeige, um Entwicklern Komfort zu bieten.

Smart Contract

Smart Contract

7.1 Introduction

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

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

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

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

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

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

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

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

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

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

Intelligenter Vertrag

7.1 Einführung

Ein smart contract ist ein Protokoll, das Vertragsverhandlungen digital überprüft. Sie definieren die Regeln und Strafen im Zusammenhang mit einer Vereinbarung zu verhängen und diese Verpflichtungen auch automatisch durchzusetzen. Der Schlaue Der Vertragskodex erleichtert, überprüft und erzwingt die Aushandlung oder Erfüllung einer Vereinbarung oder Transaktion. Aus Sicht der tokenisierung ermöglichen smart contracts auch automatische Mittel Übertragungen zwischen teilnehmenden Parteien, sofern bestimmte Kriterien erfüllt sind.

TRON smart contracts sind in der Solidity-Sprache geschrieben. Sobald sie geschrieben und getestet sind, können sie es sein In Bytecode kompiliert und dann im Netzwerk TRON für die virtuelle Maschine TRON bereitgestellt. Einmal Im Einsatz können smart contracts über ihre Vertragsadressen abgefragt werden. Der Vertragsantrag Binary Interface (ABI) zeigt die Aufruffunktionen des Vertrags an und wird für die Interaktion mit dem verwendet Netzwerk. 7.2 Energiemodell

Die maximale Energiegrenze für die Auslösung und Auslösung eines smart contract hängt von mehreren Faktoren ab Variablen:

● Die dynamische Energie aus dem Einfrieren von 1 TRX beträgt 50.000.000.000 (Gesamtenergielimit) / (Gesamtenergie). Gewicht) ● Das Energielimit ist das tägliche Energielimit des Kontos durch das Einfrieren von TRX ● Die verbleibende tägliche Kontoenergie aus dem Einfrieren von TRX wird als Energielimit – Energie berechnet Gebraucht ● Das Gebührenlimit in TRX wird in smart contract Deploy/Trigger Call festgelegt ● Verbleibender nutzbarer TRX im Konto ● Energie pro TRX bei direktem Kauf (10 SUN = 1 Energie) = 100.000, SRs können darüber abstimmen Anpassung

Es gibt zwei Verbrauchsszenarien zur Berechnung der maximalen Energiegrenze für den Einsatz und Auslöser. Die Logik kann wie folgt ausgedrückt werden:
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 Bereitstellung

Wenn eine Solidität TRON smart contract kompiliert wird, liest die virtuelle Maschine TRON die kompilierte Datei Bytecode. Der Bytecode besteht aus einem Abschnitt für die Codebereitstellung, dem Vertragscode und den Auxdata. Bei den Auxdata handelt es sich um den kryptografischen Fingerabdruck des Quellcodes, der zur Verifizierung verwendet wird. Der Einsatz Bytecode führt die Konstruktorfunktion aus und richtet die anfänglichen Speichervariablen ein. Der Einsatz code berechnet auch den Vertragscode und gibt ihn an den TVM zurück. Die ABI ist eine JSON-Datei beschreibt die Funktionen eines TRON smart contract. Diese Datei definiert die Funktionsnamen, ihre Bezahlbarkeit, die Funktionsrückgabewerte und ihre Zustandsveränderlichkeit. 7.4 Triggerfunktion

Sobald die TRON smart contracts bereitgestellt sind, können ihre Funktionen einzeln entweder über ausgelöst werden TronStudio oder über API-Aufrufe. Zustandsverändernde Funktionen erfordern Energie, während schreibgeschützte Funktionen vorhanden sind ohne Energie ausführen. 7,5 TRON Solidität

TRON Solidity ist eine Abzweigung aus der Solidity-Sprache von Ethereum. TRON ändert das ursprüngliche Projekt in unterstützen TRX- und SUN-Einheiten (1 TRX = 1.000.000 SUN). Der Rest der Sprachsyntax ist kompatibel mit Solidity ^0.4.24. Somit ist die Tron Virtual Machine (TVM) nahezu 100 % kompatibel mit EVM Anweisungen.

Token

Token

8.1 TRC-10 Token

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

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

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

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

tokens); }

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

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

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

Token

8.1 TRC-10-Token

Im TRON-Netzwerk kann jedes Konto tokens auf Kosten von 1024 TRX ausgeben. ​Um tokens auszugeben, Der Emittent muss einen token-Namen, die Gesamtkapitalisierung, den Wechselkurs zu TRX angeben. Verbreitungsdauer, Beschreibung, Website, maximaler Bandbreitenverbrauch pro Account, Gesamt Bandbreitenverbrauch und die Menge der eingefrorenen token. Jede token-Ausgabe kann auch konfiguriert werden die maximale tägliche token Übertragungsbandbreitenpunkte jedes Kontos, die maximale tägliche Bandbreite des gesamten Netzwerks token Übertragungsbandbreitenpunkte, Gesamtangebot token, Sperrdauer in Tagen und Gesamtbetrag von tokens gesperrt. 8.2 TRC-20-Token

TRC-20 ist ein technischer Standard, der für smart contracts verwendet wird, die von der unterstützte tokens implementieren TRON Virtuelle Maschine. Es ist vollständig kompatibel mit ERC-20.

Die Schnittstelle ist wie folgt:
Vertrag TRC20Interface { ​Funktion​ ​totalSupply​() ​public​ ​constant​ ​returns​ (uint); ​Funktion​ ​balanceOf​(Adresse tokenOwner) ​öffentliche​ ​Konstante​ ​gibt​ zurück (uint Gleichgewicht); ​Funktion​ ​Zulage​(Adresse tokenEigentümer, Adressgeber) ​Öffentliche​ ​Konstante gibt zurück (uint übrig); ​Funktion​ ​Übertragung​(Adresse an, uint tokens) ​öffentliche​ ​Rückgaben​ (Bool-Erfolg); ​Funktion​ ​approve​(address spender, uint tokens) ​public​ ​returns​ (bool Erfolg); ​Funktion​ ​transferFrom​(Adresse von, Adresse an, uint tokens) ​public return​ (bool success);

​Ereignis​ ​Übertragung​(Adresse indiziert von, Adresse indiziert nach, uint tokens); 
​Ereignis​ ​Genehmigung​(Adresse indiziert tokenEigentümer, Adresse indizierter Spender, uint

tokens); }

Aus Entwicklersicht gibt es mehrere Unterschiede zwischen TRC-10 und TRC-20. Einige Einer der Hauptunterschiede besteht darin, dass TRC-10-tokens über APIs und smart contracts zugänglich sind TRC-20 tokens ermöglichen die Anpassung der Benutzeroberfläche, sind jedoch nur innerhalb von smart contracts zugänglich.

Aus Kostengründen haben TRC-10 tokens Transaktionsgebühren, die 1000-mal niedriger sind als TRC-20, verursachen jedoch Bandbreitenkosten für API-Übertragungen und -Einzahlungen. Überweisungen und Einzahlungen in smart Verträge für TRC-10 tokens kosten sowohl Bandbreite als auch Energie.
8.3 Darüber hinaus

Da TRON dieselbe Solidity-Version wie Ethereum verwendet, könnten problemlos weitere token-Standards implementiert werden portiert auf TRON.

Governance

Governance

9.1 Super Representative 9.1.1 General

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.2.3 Create Proposal

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

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

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

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

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

  1. DApp Development 10.1 APIs

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

10.2 Networks

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

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

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

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

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

  1. Conclusion

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

Regierungsführung

9.1 Supervertreter 9.1.1 Allgemeines

Jeder Account im TRON-Netzwerk kann sich bewerben und hat die Möglichkeit, ein Super zu werden Vertreter (bezeichnet als SR). Jeder kann für SR-Kandidaten stimmen. Die 27 besten Kandidaten mit Die meisten Stimmen erhalten SRs mit dem Recht und der Pflicht, Blöcke zu generieren. Die Stimmen sind alle 6 Stunden gezählt und die SRs ändern sich entsprechend.

Um böswillige Angriffe zu verhindern, ist es mit Kosten verbunden, ein SR-Kandidat zu werden. Bei der Bewerbung 9999 TRX wird vom Konto des Antragstellers gelöscht. Bei Erfolg kann ein solches Konto dem SR beitreten Wahl. 9.1.2 Wahl

TRON Macht (bezeichnet als TP) ist zum Wählen erforderlich und die Höhe der TP hängt von der des Wählers ab eingefrorene Vermögenswerte (TRX).

TP wird auf folgende Weise berechnet:
TP 1 TRX eingefroren, um Bandbreite zu erhalten 1 =

Jedes Konto im Netzwerk TRON hat das Recht, für seine eigenen SRs zu stimmen.

Nach der Veröffentlichung (Entsperrung, verfügbar nach 3 Tagen) haben Benutzer keine eingefrorenen Assets mehr und verlieren alle TP entsprechend. Dadurch werden alle Stimmen für die laufende und zukünftige Abstimmungsrunde ungültig, es sei denn TRX ist erneut für die Abstimmung eingefroren.

Beachten Sie, dass das Netzwerk TRON nur die letzte Abstimmung aufzeichnet, also jede neue Abstimmung wird alle vorherigen Abstimmungen negieren. 9.1.3 Belohnung a. Abstimmungsbelohnung

Auch als Kandidatenbelohnung bekannt, die die 127 besten Kandidaten einmal pro Runde aktualisieren (6 Stunden) werden 115.200 TRX wie abgebauten teilen. Die Belohnung wird entsprechend der Stimmengewichtung aufgeteilt Jeder Kandidat erhält. Jedes Jahr beträgt die Gesamtprämie für Kandidaten 168.192.000 TRX. Gesamtstimmenbelohnung pro Runde Warum 115.200 TRX jede Runde? 15.00 TRX Gesamtstimmenbelohnung pro Runde (V R/Runde) 1 2 =
V R/Runde = 16 T RX/Block × 20 Blöcke/Minute × 60 Minuten/Std. × 6 Stunden/Runde Hinweis: Dies wird durch WITNESS_STANDBY_ALLOWANCE = 115.200 TRX festgelegt. Siehe dynamische Netzwerkparameter. Gesamtstimmenbelohnung pro Jahr Warum 168.192.000 TRX jedes Jahr? 168.192.000 T RX = Gesamtstimmenbelohnung pro Jahr (V R/Jahr) V R/Jahr = 115, 200 T RX/Runde × 4 Runden/Tag × 365 Tage/Jahr b. Belohnung blockieren Auch bekannt als Super Representative Reward, der den 27 besten Kandidaten (SRs) verliehen wird, die gewählt werden In jeder Runde (6 Stunden) werden etwa 230.400 TRX abgebaut. Die Belohnung wird gleichmäßig aufgeteilt zwischen den 27 SRs (abzüglich der gesamten aufgrund eines Netzwerkfehlers verpassten Belohnungsblöcke). Insgesamt 336.384.000 TRX werden jährlich an die 27 SRs vergeben. Gesamtblockbelohnung pro Runde Warum 230.400 TRX jede Runde? 230, 400 T RX = Gesamtblockbelohnung pro Runde (BR/Runde) BR/Runde = 32 T RX/Block × 20 Blöcke/Minute × 60 Minuten/Std. × 6 Stunden/Runde Hinweis: Die Einheitsblockbelohnung wird durch WITNESS_PAY_PER_BLOCK = 32 TRX festgelegt. Siehe dynamisches Netzwerk Parameter. Gesamtblockbelohnung pro Jahr Warum jedes Jahr 336.384.000 TRX? 336.384.000 T RX = Gesamtblockbelohnung pro Jahr (BR/Jahr) BR/Jahr = 230, 400 T RX/Runde × 4 Runden/Tag × 365 Tage/Jahr 1. Januar 2021 Vor dem 1. Januar 2021 wird es im Netzwerk TRON keine Inflation geben, im Netzwerk TRON DAO jedoch Vergeben Sie alle Blockprämien und Kandidatenprämien vor diesem Datum. C. Belohnungsberechnung

Berechnung der SR-Belohnung totale Belohnung Abstimmungsbelohnung (V R) Blockbelohnung (BR) t =
+

R Gesamt-V R V =
×
Gesamtstimmen Stimmen, die der SR-Kandidat erhalten hat
R

Block verpasst 2 B =
27 Gesamt-BR − × 3
Hinweis: Die Belohnung wird pro SR pro Runde (6 Stunden) berechnet.

Berechnung der Belohnung für SR-Kandidaten von Rang 28 bis Rang 127 totale Belohnung Abstimmungsbelohnung (V R) t =

R Gesamt-V R V =
×
Gesamtstimmen Stimmen, die der SR-Kandidat erhalten hat
Hinweis: Die Belohnung wird pro SR-Kandidat und Runde (6 Stunden) berechnet. 9.2 Ausschuss 9.2.1 Allgemeines

Das Komitee wird zum Ändern dynamischer Netzwerkparameter TRON verwendet, beispielsweise zur Blockgenerierung Belohnungen, Transaktionsgebühren usw. Das Komitee besteht aus den 27 SRs der aktuellen Runde. Jeder SR hat das Recht, Vorschläge vorzulegen und darüber abzustimmen. Wenn ein Vorschlag 19 oder mehr Stimmen erhält, ist dies der Fall genehmigt und die neuen Netzwerkparameter werden in der nächsten Wartungsperiode (3 Tage) angewendet. 9.2.2 Dynamische Netzwerkparameter 0. MAINTENANCE_TIME_INTERVAL a. Beschreibung
Ändern Sie die Wartungsintervallzeit in ms. Bekannt als SR-Abstimmungsintervallzeit pro rund.
B. Beispiel [6 * 3600 * 1000] ms – das sind 6 Stunden. C. Reichweite [3 * 27* 1000, 24 * 3600 * 1000] ms 1. ACCOUNT_UPGRADE_COST a. Beschreibung Ändern Sie die Kosten für die Beantragung eines SR-Kontos. B. Beispiel [9.999.000.000] SUN – das sind 9.999 TRX. C. Reichweite [0,100 000 000 000 000 000] SONNE 2. CREATE_ACCOUNT_FEE a. Beschreibung Ändern Sie die Gebühr für die Kontoerstellung.B. Beispiel [100.000] SUN – das ist 1 TRX. C. Reichweite [0,100 000 000 000 000 000] SONNE 3. TRANSACTION_FEE a. Beschreibung Ändern Sie die Höhe der Gebühr, um zusätzliche Bandbreite zu gewinnen. B. Beispiel [10] SUN/Byte. C. Reichweite [0,100 000 000 000 000 000] SUN/Byte 4. ASSET_ISSUE_FEE a. Beschreibung Ändern Sie die Gebühr für die Ausgabe von Vermögenswerten. B. Beispiel [1024.000.000] SUN – das sind 1024 TRX. C. Reichweite [0,100 000 000 000 000 000] SONNE 5. WITNESS_PAY_PER_BLOCK a. Beschreibung Ändern Sie die Belohnung für die SR-Blockgenerierung. Wird als Unit-Block-Belohnung bezeichnet. B. Beispiel [32.000.000] SUN – das sind 32 TRX. C. Reichweite [0,100 000 000 000 000 000] SONNE 6. WITNESS_STANDBY_ALLOWANCE a. Beschreibung Ändern Sie die Belohnungen für die 127 besten SR-Kandidaten. Wird als Gesamtstimmenbelohnung bezeichnet pro Runde. B. Beispiel [115.200.000.000] SUN – das sind 115.200 TRX. C. Reichweite [0,100 000 000 000 000 000] SONNE 7. CREATE_NEW_ACCOUNT_FEE_IN_SYSTEM_CONTRACT a. Beschreibung Ändern Sie die Kosten für die Kontoerstellung. Kombinieren Sie die dynamischen Netzwerkparameter Nr. 8, um zu erhalten Gesamtkosten für die Kontoerstellung:
REATE_NEW_ACCOUNT_FEE_IN_SY STEM_CONTRACT REATE_NEW_ACCOUNT_BANDWIDTH_RATE
C × C

b. Beispiel [0] SONNE. C. Reichweite [0,100 000 000 000 000 000] SONNE 8. CREATE_NEW_ACCOUNT_BANDWIDTH_RATE

a. Beschreibung Ändern Sie die Kosten für die Kontoerstellung. Kombinieren Sie die dynamischen Netzwerkparameter Nr. 7, um zu erhalten Gesamtkosten für die Kontoerstellung:
REATE_NEW_ACCOUNT_FEE_IN_SY STEM_CONTRACT REATE_NEW_ACCOUNT_BANDWIDTH_RATE
C × C

b. Beispiel [1]. C. Reichweite [0.100.000.000.000.000.000] 9. ALLOW_CREATION_OF_CONTRACTS a. Beschreibung So aktivieren Sie Tron Virtual Machine (TVM). B. Beispiel True – aktiviert und wirksam seit dem 10.10.2018 23:47 UTC. C. Reichweite Richtig/Falsch 10. REMOVE_THE_POWER_OF_THE_GR a. Beschreibung Entfernen Sie die anfänglichen GR-Genesis-Stimmen b. Beispiel Stimmt – gültig am 04.11.2018 08:46 UTC. C. Reichweite Wahr/Falsch – Hinweis: Von „Wahr“ kann nicht auf „Falsch“ zurückgesetzt werden. 11. ENERGIEGEBÜHR a. Beschreibung Ändern Sie die Gebühr von 1 Energie. B. Beispiel 20 SO. C. Reichweite [0,100 000 000 000 000 000] SONNE 12. EXCHANGE_CREATE_FEE a. Beschreibung Ändern Sie die Kosten für die Erstellung von Handelspaaren. Bekannt als die Kosten für die Erstellung eines Handelsauftrags. B. Beispiel [1.024.000.000] SUN – das sind 1024 TRX. C. Reichweite [0,100 000 000 000 000 000] SONNE 13. MAX_CPU_TIME_OF_ONE_TX a. Beschreibung Ändern Sie die maximale Ausführungszeit einer Transaktion. Bekannt als das Timeout-Limit von eine Transaktion. B. Beispiel 50 ms. C. Reichweite

[0, 1000] ms 14. ALLOW_UPDATE_ACCOUNT_NAME a. Beschreibung Ändern Sie die Option, damit ein Konto seinen Kontonamen aktualisieren kann.
B. Beispiel Falsch – was ab Java-Tron Odyssey v3.2 vorgeschlagen werden kann. C. Reichweite Wahr/Falsch – Hinweis: Von „Wahr“ kann nicht auf „Falsch“ zurückgesetzt werden. 15. ALLOW_SAME_TOKEN_NAME a. Beschreibung Ändern Sie die Validierung, um zuzulassen, dass verschiedene token einen doppelten Namen haben.
B. Beispiel Falsch – was ab Java-Tron Odyssey v3.2 vorgeschlagen werden kann. C. Reichweite Wahr/Falsch – Hinweis: Von „Wahr“ kann nicht auf „Falsch“ zurückgesetzt werden. 16. ALLOW_DELEGATE_RESOURCE a. Beschreibung Ändern Sie die Validierung, sodass token mit einem doppelten Namen ausgegeben werden darf tokenID​ des token im Datentyp „Long Integer“ wäre die einzige atomare Variable Identifizierung eines token.
B. Beispiel Falsch – was ab Java-Tron Odyssey v3.2 vorgeschlagen werden kann. C. Reichweite Wahr/Falsch – Hinweis: Von „Wahr“ kann nicht auf „Falsch“ zurückgesetzt werden. 17. TOTAL_ENERGY_LIMIT a. Beschreibung Ändern Sie den Gesamtenergiegrenzwert des gesamten Netzwerks. B. Beispiel [50.000.000.000.000.000] SUN – das sind 50.000.000.000 TRX. C. Reichweite [0.100.000.000.000.000.000] SONNE 18. ALLOW_TVM_TRANSFER_TRC10 a. Beschreibung TRC-10 token-Übertragung innerhalb von smart contracts zulassen. ALLOW_UPDATE_ACCOUNT_NAME, ALLOW_SAME_TOKEN_NAME, ALLOW_DELEGATE_RESOURCE-Vorschläge müssen alle genehmigt werden, bevor sie vorgeschlagen werden diese Parameteränderung.
B. Beispiel Falsch – was ab Java-Tron Odyssey v3.2 vorgeschlagen werden kann. C. Reichweite Wahr/Falsch – Hinweis: Von „Wahr“ kann nicht auf „Falsch“ zurückgesetzt werden.9.2.3 Angebot erstellen

Nur die SR-Konten haben das Recht, eine Änderung der dynamischen Netzwerkparameter vorzuschlagen. 9.2.4 Abstimmungsvorschlag

Nur Ausschussmitglieder (SRs) können für einen Vorschlag stimmen und das Mitglied, das nicht rechtzeitig abstimmt wird als Nichtübereinstimmung gewertet. Das Angebot ist nach seiner Erstellung drei Tage lang aktiv. Die Abstimmung kann können während des dreitägigen Abstimmungsfensters geändert oder abgerufen werden. Sobald die Frist abgelaufen ist, wird der Vorschlag eingereicht entweder erfolgreich (19+ Stimmen) oder scheitern (und enden). 9.2.5 Angebot stornieren

Der Antragsteller kann den Vorschlag vor Inkrafttreten stornieren. 9.3 Struktur

SRs sind die Zeugen neu generierter Blöcke. Ein Zeuge enthält 8 Parameter:
1. Adresse​: die Adresse dieses Zeugen – z.B. 0xu82h…7237.
2. voteCount​: Anzahl der erhaltenen Stimmen zu diesem Zeugen – z.B. 234234.
3. pubKey​: der öffentliche Schlüssel für diesen Zeugen – z.B. 0xu82h…7237.
4. URL​: die URL für diesen Zeugen – z.B. https://www.noonetrust.com.
5. totalProduced: Die Anzahl der Blöcke, die dieser Zeuge erzeugt hat – z. B. 2434.
6. totalMissed​: Die Anzahl der Blöcke, die dieser Zeuge verpasst hat – z.B. 7.
7. LatestBlockNum​: die neueste Blockhöhe – z.B. 4522. 8. isjobs​: eine boolesche Flagge.

Protobuf-Datenstruktur: Nachricht​ ​Zeuge​{
​Bytes​ Adresse = ​1​;
​int64​ voteCount = ​2​;
​Bytes​ pubKey = ​3​;
​string​ url = ​4​;
​int64​ totalProduced = ​5​;
​int64​ totalMissed = ​6​;
​int64​ LatestBlockNum = ​7​; ​bool​ isJobs = ​8​; }

  1. DApp-Entwicklung 10.1 APIs

Das TRON-Netzwerk bietet eine große Auswahl von über 60 HTTP-API-Gateways für die Interaktion mit dem Netzwerk über Full und Solidity Nodes. Darüber hinaus ist TronWeb eine umfassende JavaScript-Bibliothek Enthält API-Funktionen, die es Entwicklern ermöglichen, smart contracts bereitzustellen. Ändern Sie die blockchain Status, Abfrage von blockchain- und Vertragsinformationen, Handel am DEX und vieles mehr. Diese API Gateways können auf ein lokales Privatenet, das Shasta-Testnet oder das TRON Mainnet gerichtet sein.

10.2 Netzwerke

TRON verfügt sowohl über ein Shasta-Testnetz als auch über ein Mainnet. Entwickler können eine Verbindung zu den Netzwerken herstellen Bereitstellung von Knoten, Interaktion über TronStudio oder Verwendung von APIs über den TronGrid-Dienst. Das TronGrid Der Dienst besteht aus Knotenclustern mit Lastausgleich, die auf AWS-Servern weltweit gehostet werden. Als DApp Die Entwicklung nimmt zu und das API-Aufrufvolumen nimmt zu. TronGrid bewältigt den Anstieg erfolgreich API-Verkehr.
10.3 Werkzeuge

TRON bietet eine Reihe von Entwicklungstools, mit denen Entwickler innovative DApps erstellen können.
TronBox ist ein Framework, das es Entwicklern ermöglicht, smart contracts über TronWeb zu testen und bereitzustellen API. TronGrid ist ein lastenausgleichender und gehosteter API-Dienst, der Entwicklern den Zugriff ermöglicht TRON Netzwerk, ohne einen eigenen Knoten betreiben zu müssen. TronGrid bietet Zugriff auf beide Shasta testnet sowie das TRON Mainnet. TronStudio ist eine umfassende integrierte Entwicklung Umgebung (IDE), die es Entwicklern ermöglicht, ihre Solidity Smart zu kompilieren, bereitzustellen und zu debuggen Verträge. TronStudio enthält einen internen Vollknoten, der eine private lokale Umgebung für erstellt smart contract Tests vor der Bereitstellung. Die TronWeb API-Bibliothek verbindet Entwickler mit dem Netzwerk über eine große Auswahl an in JavaScript verpackten HTTP-API-Aufrufen.
10.4 Ressourcen

Der TRON Developer Hub ist eine umfassende API-Dokumentationsseite, die darauf zugeschnitten ist 12 Entwickler, die auf dem Netzwerk TRON aufbauen möchten. Der Developer Hub bietet ein High-Level konzeptionelles Verständnis von TRON und führt Benutzer durch die Details der Interaktion mit dem 12 Entwickler-Hub: https://developers.tron.network/

Netzwerk. Die Leitfäden führen Entwickler durch die Knoteneinrichtung, Bereitstellung und Interaktion mit smart Verträge, API-Interaktion und -Implementierung, Erstellen von Beispiel-DApps und Verwenden jeder dieser Entwicklertools. Darüber hinaus sind Entwickler-Community-Kanäle über Discord verfügbar.
13

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

  1. Fazit

TRON ist eine skalierbare blockchain Lösung, die innovative Methoden zur Bewältigung eingesetzt hat Herausforderungen, mit denen alte blockchain-Netzwerke konfrontiert sind. Mit über 2 Millionen Transaktionen pro Tag, Mit über 700.000 TRX-Konten und mehr als 2.000 TPS hat TRON der Community geholfen Schaffung eines dezentralen und demokratisierten Netzwerks.