Telegram Open Network: Theorie und Praxis vom Netzwerkvalidator

In den letzten Monaten wurde die gesamte Aufmerksamkeit der weltweiten Blockchain-Community auf den Start eines der größten Kryptowährungsprojekte gelenkt - Telegram Open Network (TON).
Wie ist die TON-Blockchain wirklich? Ist das TON-Netzwerk wirklich dezentralisiert? Was ist ihre tatsächliche Skalierbarkeit? Wie werde ich ein Netzwerkvalidator?

Die Antworten auf diese und andere Fragen suchte das Team des Mercuryo- Projekts, das seit Anfang September 2019 aktiv am Testnetzwerk beteiligt ist.

Am 15. November 2019 wurden die Telegrammdienste auf testnet 2 umgestellt und die dritte Testphase gestartet. Unser Team nahm weiterhin an Tests teil und wurde nach TON der erste Validierer im Netzwerk.

Um an dem Validierungsprozess teilzunehmen, muss der Benutzer nicht nur über eine ausreichende Anzahl von Münzen (GRAM-Token) verfügen, sondern auch über einen ständig laufenden vollständigen Netzwerkknoten (TON Blockchain Full Node).

Theoretisch kann jeder Benutzer ein Prüfer werden, sofern er den erforderlichen Mindestanteil des Vermögenswerts (in Gramm-Münzen) an der Master-Kette besitzt. In der Praxis stellen sich jedoch eine Reihe von Fragen, die unser Team in diesem Artikel beantworten wird.

Darüber hinaus möchten wir Erfahrungen im Umgang mit tonlib-cli , as austauschen Derzeit gibt es praktisch keine dokumentierten Informationen, im Gegensatz zu der in HowTo ausführlich beschriebenen Basisversion.

TON Blockchain

Die Hauptkomponente des Telegram Open Network ist ein flexibles Blockchain-System, im Folgenden als TON-Blockchain bezeichnet, das laut den Entwicklern selbst in der Lage ist, Millionen von Transaktionen pro Sekunde zu verarbeiten und dabei die aktualisierten offiziellen Blockchain-Spezifikationen von Turing Complete Smart Contracts zu unterstützen. Multicurrency Transfers sowie Micropayment-Kanäle für Off-Chain (Off-Chain) -Zahlungsnetze.

„Die TON-Blockchain-Architektur ist einzigartig, da sie über spezifische Funktionen wie einen selbstheilenden vertikalen Blockchain-Mechanismus und Instant Hypercube Routing verfügt, mit denen die Blockchain schnell und zuverlässig ist skalierbar und nachhaltig. “

Wie oben erwähnt, ist TON Blockchain die herkömmliche Bezeichnung für ein dezentrales Netzwerk (eine Reihe von Blockketten) oder eine 2D-Blockkette, die aus drei Haupttypen von Blockketten besteht.

Master-Blockchain oder Masterchain ist eine eindeutige Blockkette, die allgemeine Informationen zum Protokoll und den aktuellen Werten seiner Parameter, eine Reihe von Validatoren und deren Freigaben, eine Reihe von derzeit aktiven Workchains und deren „Shards“ sowie eine Reihe von Hashes der letzten Blöcke enthält meister und shardchaynov.

Working Blockchains oder Workchains - eine Gruppe (bis zu 232) von Blockchains, die "Arbeitspferde" sind und Asset-Transfer-Transaktionen und intelligente Verträge enthalten. Gleichzeitig können einzelne Workchains ihre eigenen "Regeln", Kontoadressenformate, Transaktionsformate, verschiedene virtuelle Maschinen (VMs) für intelligente Verträge, verschiedene grundlegende Token oder Kryptowährungen usw. haben. Sie alle müssen jedoch einige grundlegende Interoperabilitätskriterien erfüllen, um eine relativ einfache Interaktion untereinander zu gewährleisten. Daher ist die TON-Blockchain von Natur aus heterogen, genau wie die EOS- und Polkadot-Blockchain.

Shard-Blockchains oder Shard-Chains - eine Teilmenge von Blockchains (bis zu 260) innerhalb einer Reihe von Workchains, die den Betrieb des Sharding-Systems sicherstellen und dieselben Regeln und Blockformate wie die Workchains haben. Shardchains enthalten nur eine Teilmenge von Accounts, abhängig von den ersten (höchstwertigen) Bits der Adresse jedes einzelnen Accounts. Da alle Shardchains ein gemeinsames Format und Regeln für Bausteine ​​haben, ist die TON-Blockchain in dieser Hinsicht homogen und erfüllt die in einem der Ethereum-Skalierungsvorschläge beschriebenen Anforderungen.



Jeder Block der Shardchain (wie auch der Masterchain) ist eigentlich nicht nur ein Block, sondern eine kleine Blockchain. In der Regel besteht diese „Block-Block-Kette“ oder „vertikale Block-Kette“ aus genau einem Block, sodass sie nur als Block der entsprechenden „normalen“ Block-Kette (oder „horizontalen Block-Kette“) betrachtet werden kann. Wenn es jedoch notwendig wird, falsche Blöcke zu korrigieren, wird ein neuer Block in die „vertikale Blockkette“ eingefügt, der entweder das Ersetzen des vorhandenen „horizontalen“ Blocks oder die „Blockdifferenz“ enthält und nur eine Beschreibung der Teile der vorherigen Version des Blocks enthält, die ersetzt werden müssen. Dieser TON-spezifische Mechanismus zum Ersetzen erkannter ungültiger Blöcke, ohne dass eine harte Gabel erforderlich ist, wird als 2D-Blockchain oder einfach als 2-Blockchain bezeichnet.

Konsensalgorithmen und Netzwerkschutzmechanismus

TON bietet eine Blockchain an, die auf dem Infinite Sharding Paradigma (Proof of Stake oder PoS) basiert. Laut der Entwicklerdokumentation:

„Fast alle Implementierungen von Blockchains mit Sharding basieren auf dem Top-Down-Modell: Zuerst stellen wir uns eine Blockchain vor und dann entscheiden wir, wie diese in mehrere Teile unterteilt wird, die miteinander interagieren (Shardchains), um die Effizienz zu steigern und die Skalierbarkeit zu erhöhen.

Der Sharding-Ansatz von TON basiert auf dem Bottom-up-Prinzip, was bedeutet, dass die ursprüngliche Blockchain extrem skalierbar ist und jede einzelne Shardchain nur ein Konto oder einen Smart Contract enthält. Auf der nächsten Ebene gibt es eine große Anzahl von „Kontoketten“, von denen jede die Übergänge zwischen den Zuständen nur eines Kontos beschreibt und sich gegenseitig Nachrichten sendet, die Informationen zu Transaktionen enthalten. Gleichzeitig ist es nicht sinnvoll, Hunderte von Millionen von Blockketten zu haben, von denen Aktualisierungen (d. H. Neue Blöcke) eher selten auftreten. Daher haben wir diese "Konto-Ketten" für ihre effektivere Implementierung in "Shard-Ketten" gruppiert, von denen jeder Block im Wesentlichen ist ist eine Sammlung von Kontenblöcken, die an diesen bestimmten Shard gebunden sind. Somit sind "Account-Ketten" eigentlich nur virtuelle oder logische Blöcke innerhalb der tatsächlich vorhandenen "Shardchains". Dieser Mechanismus beleuchtet viele der Designentscheidungen der TON-Blockchain und wir nennen ihn das „Infinite Sharding Paradigm“.

Das TON-Konsensnetzwerk besteht aus verschiedenen Knotentypen: Validatoren, Nominatoren, Phisher und Kollatierer.



Validatoren sind PoS-Knoten und Blockhersteller. Fischer überwachen das Konsensnetzwerk, um einen Fehler zu finden oder einen vermeintlich böswilligen Konsensknoten zu identifizieren. Wenn der Phisher dies eindeutig bestätigt, erhält er eine Belohnung in Form der Einziehung eines Teils des Anteils dieses Validators.

Die Aufgabe von Kollatierern besteht darin, Shardchain-Blöcke vorzubereiten und sie für die Validierung an PoS-Knoten bereitzustellen, für die sie ihren Teil der Belohnung für die Erstellung des Blocks erhalten. Gleichzeitig sind Collatoren im Wesentlichen zusätzliche Teilnehmer am Konsens, da Validatoren fast immer selbst Blöcke generieren.

Die Nominatoren verleihen den Validatoren ihr Vermögen ( Gram- Token), um Gewinne zu erzielen. In der Tat sind Nominees nicht in der Infrastruktur der Validatoren enthalten, sondern teilen nur ihren großen Anfangsanteil des Vermögens zwischen ihnen im Austausch für einen proportionalen Prozentsatz der Gesamtvergütung. Das System und die Höhe der Vergütung, die die Nominierten erhalten, hängen somit vollständig von den Ergebnissen der Arbeit der Validierer ab, während die Nominierten für die Validierer „stimmen“ und ihnen Gramm-Token verleihen. Die Nominierer können entweder einzelne Token-Inhaber oder Pools sein, die die Gelder einzelner TON-Benutzer verwalten und gleichzeitig als Validierer fungieren und über den TON-Smart-Vertrag als Delegierte fungieren. In diesem Fall wird die Gesamtvergütung eines solchen Pools anteilig auf seine Teilnehmer aufgeteilt.

Der Prozess des Erzeugens neuer Blöcke läuft wie folgt ab: Eine bestimmte Anzahl von Validatoren wählt Masterchain-Blöcke (Shards) aus, die zur Validierung unter Verwendung eines speziellen Algorithmus geeignet sind, und dann wird eine kleinere Teilmenge von Validatoren für jeden solchen Shard in der Reihenfolge ausgewählt, die auf pseudozufällige Weise mit einem Intervall von ungefähr 1024 Blöcken bestimmt wird.

Somit gibt es für jeden Block einen pseudozufällig ausgewählten Satz von Validatoren, um zu bestimmen, wessen Kandidatenblock die höchste Priorität hat. Validatoren und andere Knoten überprüfen die Gültigkeit der vorgeschlagenen Blockkandidaten. Unterschreibt der Prüfer automatisch (nicht absichtlich) einen ungültigen Kandidaten für Sperren, so wird er mit dem Verlust eines Teils oder seiner gesamten Vergütung oder mit der zeitweiligen Aussetzung der Teilnahme an der Auswahl der Prüfer bestraft.

Als nächstes müssen Validierer einen Konsens auf der Grundlage des BFT-Algorithmus (Byzantine Resiliency Protocol) erzielen , ähnlich dem pBFT- oder Honey Badger-BFT- Protokoll. Nachdem ein Konsens erreicht wurde, wird ein neuer Block erstellt, während die Transaktionsgebühren auf die Prüfer verteilt werden.

Es sollte beachtet werden, dass jeder Validator ausgewählt werden kann, um an mehreren Untersätzen von Validatoren teilzunehmen, weshalb angenommen wird, dass alle Validierungs- und Konsensalgorithmen parallel ausgeführt werden.

Nachdem alle neuen Blöcke der Kette generiert wurden oder das Timeout abgelaufen ist, wird eine Meldung angezeigt, dass ein neuer Block der Master-Kette erstellt wurde, der Hashes der letzten Blöcke aller Shards basierend auf dem pBFT-Konsens aller Prüfer enthält.

TON Testnet: praktische Erfahrung im Telegram Open Network

Das Mercuryo- Projektteam nimmt seit September 2019 aktiv am Testnetzwerk teil. Während des Testzeitraums haben wir einige Erfahrungen gesammelt, die wir gerne mit Ihnen teilen möchten.

Netzwerkzugriffsmethoden

Bei der Interaktion mit dem TON-Netzwerk werden auf die eine oder andere Weise TL-Spezifikationen verwendet, die die Interaktion mit der API beschreiben. Spezifikationsdateien finden Sie hier .

Es gibt drei Arten von APIs:

ton_api - für die Interaktion mit der Full Node Validator-Engine-Konsole
lite_api - für die Arbeit mit lite-client
tonlib - hier wird alles über den Geldbeutel gesammelt und dies ist die einzige öffentlich verfügbare tonlib-cli-API

Brieftaschenerstellung

Am einfachsten erstellen Sie eine Brieftasche mit der Test-Gramm-Brieftasche, die auf der offiziellen Website für die Betriebssysteme Windows, macOS und Linux verfügbar ist.




Es gibt auch verschiedene Möglichkeiten, über die Befehlszeilenschnittstelle zu interagieren: einfach und mit tonlib-cli . Leider gibt es im Moment keine Kompatibilität zwischen ihnen.

Hier werden nur die Tools betrachtet, die die TON-Entwickler selbst anbieten. Wenn die Basisversion in HowTo ausführlich dokumentiert ist, fehlen praktisch keine Informationen zur Verwendung von tonlib-cli .

Wie oben erwähnt, gibt es in TON 3 APIs für verschiedene Aufgaben. Die mit der Bedienung der Brieftasche verbundenen Funktionen sind für tonlib verantwortlich .

Um mit tonlib-cli arbeiten zu können , müssen Sie zusätzlich zur Befehlszeilenschnittstelle selbst eine Konfigurationsdatei für die Verbindung zum öffentlichen TON-Netzwerk-Liteserver haben, die hier verfügbar ist .

Der Anschluss erfolgt durch das Team

tonlib-cli -c ton-lite-client-test1.config.json -v 0

Dabei ist -v 0 der Parameter, der für die Ausgabe der Debugging-Informationen verantwortlich ist.

Liste der Befehle:

Verwenden Sie zum Erstellen einer Brieftaschenadresse den Befehl genkey und eine Liste mit mnemonischen Ausdrücken, die erforderlich sein können, um den Zugriff auf die Adresse bei Verlust des privaten Schlüssels wiederherzustellen.

Schlüsselliste

Der Befehl keys zeigt eine Liste von Schlüsseln an. Für weitere Operationen beim Ausführen anderer Befehle ist es erforderlich, deren Seriennummer zu verwenden, d. H. Für den ersten Schlüssel gibt es die ID 0 .

Adressinitialisierung

Nach dem Erstellen der Adresse muss diese im Netzwerk registriert werden. Dazu müssen Sie es zuerst auffüllen. Ursprünglich wurde hierfür ein spezieller Smart-Vertrag verwendet - Testgiver . Jetzt ist es einfacher und bequemer, einen speziellen Bot im @test_ton_bot- Telegramm zu verwenden.

Unmittelbar nach dem Auffüllen wird der Status des Kontos als uninited_accountState definiert und ändert sich erst, nachdem Sie GRM-Testtoken von dieser Adresse gesendet haben.

Wenn Sie bereits Token auf Ihrem Guthaben haben und eine andere Brieftasche aktivieren müssen, können Sie den Befehl transferf verwenden. Anschließend wird diese zusammen mit der Auffüllung der Brieftasche initialisiert.



Sie können den Status der Brieftasche mit dem Befehl getstate 0 ermitteln.



Abrufen des Transaktionsverlaufs mit dem Befehl

gethistory <num_of_key>

Dabei ist <num_of_key> die Schlüsselsequenznummer

Netzwerkbasis

Wie bei den meisten vorhandenen Blockchains basiert TON auf Servern, die einen vollständigen Verlauf aller Blockchains speichern, die jemals im Netzwerk erstellt wurden.

Um einen vollständigen Knoten im TON-Testnetzwerk auszuführen, reichen 8 produktive Kerne und 4 bis 8 GB RAM aus. Zum Zeitpunkt des Schreibens belegten die Daten etwa 50 GB Festplatte, es ist jedoch besser, einen Spielraum von mindestens 100 GB zu haben. Es ist zu beachten, dass es besser ist, ein SSD-Laufwerk zu verwenden, da Für die Aufzeichnung ist eine große Anzahl von IOPS erforderlich, da sonst die Synchronisation mit dem Netzwerk sehr langsam ist.

Als funktionierendes Betriebssystem verwenden Sie am besten Ubuntu 18.04, as Die meisten Community-Tests werden darauf durchgeführt.

Installationsanleitungen

README.txt
FullNode-HOWTO.txt
Validator-HOWTO.txt

Validator-System

Es ist bekannt, dass die TON-Blockchain aus Shardchain- und Masterchain-Blöcken besteht, die von speziell bezeichneten Knoten, sogenannten Validatoren, erstellt und verifiziert werden. Validatoren erhalten eine gewisse Belohnung für ihre „Arbeit“: die Aufrechterhaltung der Integrität der TON-Blockchain, während das Einkommen innerhalb der Validator-Community proportional verteilt wird.

Auf den ersten Blick ist alles klar, aber in der Praxis stellen sich in diesem Zusammenhang eine Reihe von Fragen:

• Gibt es eine Netzwerkbeschränkung für das maximale Validator-Steak?

Die Begrenzung der Größe einer Freigabe für einen Prüfer kann immer mit dem Befehl getconfig 17 überprüft werden, der die tatsächlichen Größen der zulässigen Steaks anzeigt :



Der Screenshot zeigt, dass die minimale Freigabegröße derzeit 10.000 GRAM beträgt. Wenn ein Prüfer jedoch nicht mehr als 100.000 Gramm für eine Abstimmungsrunde erhält, ist er nicht berechtigt, an den Wahlen teilzunehmen. Gleichzeitig darf die maximale Anzahl von Tokens pro Validator 10.000.000 GRAM nicht überschreiten. Damit die Abstimmung stattfinden kann, muss die Mindestgröße des gesamten Steaks 1.000.000 GRAM überschreiten.

• Wie werden Validatoren ausgewählt?

Um sich für die Teilnahme am Validierungsprozess zu bewerben, müssen Sie mindestens 10.000 GRAM haben. Der Wahlprozess-Algorithmus ist im smart contract elector-code.fc ausführlich beschrieben
Höchstwahrscheinlich wird der Vertrag im Hauptnetzwerk anders sein, sodass die aktuelle Version nur für das Testnetzwerk gilt.

Ein Anteil von 10.000 Gramm bedeutet nicht, dass Sie Validator werden können Das Empfangen von Test-Tokens könnte durch Anfragen an den Testgeber leicht automatisiert werden.

Momentan setzen fast alle Validatoren bei der Teilnahme an der Abstimmung einen Höchstfaktor in Höhe von 2,7 und ein Steak in Höhe von 120.000 Gramm, da es die meisten Wetten gibt, da das Mindeststeak aufgrund seines Gewichts auf 120.000 / 2,7 = 45.000 Gramm ansteigt (im Gegensatz zu 100.000 nach offiziellen Unterlagen). Aber selbst mit solch einem Minimalsteak sind Ihre Chancen praktisch null, da die drei besten Prüfer einen Maximalfaktor von 2 haben, was den Mindestanteil auf 60.000 Gramm erhöht, wodurch Sie ein Prüfer im Testnetz werden können.

Wenn alle aktuellen Prüfer ihren Maximalfaktor erhöhen oder die Größe des Steaks verringern würden, wäre es möglich, ein Prüfer mit einem Minimalsteak zu werden, vorausgesetzt, die maximale Anzahl von Prüfern (1000 Knoten) würde nicht überschritten.

• Wenn das Validatorsystem zentralisiert ist, ist dann auch die gesamte Blockchain zentralisiert?

Es gibt keine Schecks, d.h. Niemand kontrolliert die Validatoren zentral, die Nominatoren bestimmen selbst die Risiken bei der Auswahl eines Validators.

• Welche Arten von Geldbußen werden für Validatoren bereitgestellt?

Derzeit liegen keine Informationen vor, höchstwahrscheinlich wird das Dokument einen Konsensmechanismus enthalten, da selbst die nicht synchronen Knoten im Testnetz Auszeichnungen erhalten haben.

• Intelligente Verträge

Für die Erstellung von TON-Smart-Verträgen werden zwei spezielle Programmiersprachen verwendet: Fift und FunC . Wenn Fift zumindest über eine allgemeine Dokumentation verfügt , ist es fast unmöglich, Informationen über FunC zu finden (selbst unter den Bedingungen eines Entwicklungswettbewerbs wird angegeben, dass diese nur durch Analyse des Quellcodes erhältlich sind).

Beim Testen konnte festgestellt werden, dass die FunC- Codebasis nicht so umfangreich ist (im Vergleich zu Fift ) und Sie sie viel schneller erlernen können, sodass die Arbeit mit FunC viel einfacher ist als mit Fift .

• Aktuelle / dringende / offene Fragen

Langsame Synchronisierung
https://github.com/ton-blockchain/ton/issues/100

Berechtigungen für die Validierungs-Engine
+0 = übliche Lite-Client-Anfragen
+1 = vollständige Knotenstatistikabfragen
+2 = vollständige Code-Konfigurationsänderungsabfragen
+4 = potenziell gefährliche Abfragen (z. B. Export von privaten Schlüsseln oder Signieren von beliebigen Zeichenfolgen)
+8 = reserviert für zukünftige Erweiterungen (macht im Moment nichts)

• Wie funktioniert PIPE mit Lite-Client?

Standardmäßig wird die Lite-Client-Ausgabe an stderr gesendet. Um sie zu verarbeiten, müssen Sie zuerst die Ausgabe von stderr an stdout umleiten:

$ lite-client 2 >> (grep ...)

• Welche Möglichkeiten gibt es für den programmgesteuerten Netzwerkzugriff?

https://github.com/ton-blockchain/ton/issues/76

• Welche Serverkonfiguration ist für den Validator erforderlich?

Die Verwendung eines Servers mit zwei Prozessoren wird offiziell empfohlen (mindestens 8 Kerne pro Prozessor). Die Software stellt keine hohen Anforderungen an den Arbeitsspeicher, daher sind 16 GB ausreichend. Sie müssen eine SSD als primäres Laufwerk verwenden, deren empfohlene Mindestgröße 512 GB beträgt. Eine 8-TB-Festplatte reicht aus, um archivierte Daten zu speichern.

Sie müssen unbedingt über eine Hochgeschwindigkeits-Internetverbindung verfügen: Bei einer prognostizierten Durchschnittslast von 100 Mbit / s müssen Sie in der Lage sein, Spitzenlasten von bis zu 1 Gbit / s zu bewältigen.

Es wird empfohlen, XFS als Dateisystem zu verwenden, da die Informationen zu jedem Block in einer separaten Datei gespeichert werden. Es ist bekannt, dass ext4 zum Beispiel mit einer großen Anzahl kleiner Dateien nicht sehr gut funktioniert und dazu führen kann, dass Sie einfach keine freien Inodes mit genügend Speicherplatz haben.

• Woher weiß ich, dass ein Knoten synchronisiert ist?

Das Protokoll vervollständigt die Synchronisierungsnachricht oder verwendet validator-engine-console -c "getstats", wobei unixtime und masterchainblocktime nahezu identisch sein sollten.

• Wie viele Prüfer können online sein?

Getconfig 16
max_validators: 1000 max_main_validators: 100 min_validators: 5

• Wie finde ich aktuelle aktive Validatoren heraus?

Getconfig 34

Vorheriger getconfig 32-Validatorsatz

• Zeit für welche Prüfer werden ausgewählt?

Das Whitepaper zeigt an, dass die Validatoren für einen Monat ausgewählt sind, aber im Testnetz ist diese Zeit viel kürzer und Sie können sie in der getconfig 15-Konfiguration herausfinden.

Nach dem Neustart von testnet haben sich die Zeitintervalle für Validatoren geändert:

ConfigParam (15) = (validators_elected_for: 65536 elections_start_before: 32768 elections_end_before: 8192 stake_held_for: 32768)

Daraus folgt, dass eine Gruppe von Validatoren für 65536 Sekunden ausgewählt wird.

• Wie werden die Prüfer für die nächste Runde ausgewählt?

Der Bewerbungsprozess ist im Validator-HOWTO ausführlich beschrieben . Validatoren werden mit einem Smart Contract ausgewählt, dessen aktuelle Adresse immer mit dem Befehl getconfig 1 abgerufen werden kann . Dann müssen Sie den Start der Abstimmung verfolgen.



Wenn die Antwort Ergebnis ist: [0], dann ist die Abstimmung nicht aktiv, aber wenn die Antwort einen Zeitstempel enthält, dann können Sie die Teilnahme beantragen. Auch wenn Sie nicht teilnehmen, können Sie immer die Bewerbungen anderer Auswahlteilnehmer

einsehen : > runmethod -1: A4C2C7C05B093D470DE2316DBA089FA0DD775FD9B1EBFC9DC9D04B498D3A2DDA participant_list

• Ist es möglich, TON zu blockieren?

Trotz des komplexen Aufbaus des auf Overlay-Netzwerken basierenden Netzwerkstacks werden UDP und TCP weiterhin als TON-Transportprotokolle verwendet. Es ist bekannt, dass heutzutage Telegrammsperren recht erfolglos sind, weil Es ist möglich, IP-Adressen zu ändern, Proxys zu verwenden und Einstellungen per Push zu aktualisieren. TON wird jedoch keine solchen Möglichkeiten haben: Es ist nicht möglich, Knoten schnell zu verschieben, während Validierer ihre Anteile nicht riskieren wollen. Daher werden die Entwickler von Telegrammen wahrscheinlich in naher Zukunft neue Lösungen zur Umgehung von Sperren einführen, beispielsweise mithilfe des ADNL-Proxys.

Unten sehen Sie den Datenverkehr eines vollständigen Knotens nach der Verarbeitung von 10 Millionen Paketen. Eine Liste von 159 IP-Adressen, auf denen vollständige Testnetzknoten ausgeführt werden, lautet wie folgt:

126 DIGITAL OCEAN ( TON)
13 AMAZON
4 GOOGLE
3 HETZNER
3 ALIBABA CLOUD
2 OVH
2 SELECTEL
2 ONLINE.NET
1 LINODE
1 hosteurope.de
1 contabo.de
and 1 person possibly hosting it at home in Italy telecomitalia.it

IP- . , TON, -.

Tatsächlich ist das Telegram Open Network ein Versuch, ein unabhängiges dezentrales Internet nach dem Konzept von WEB 3.0 innerhalb des bestehenden globalen Netzwerks zu implementieren, dessen Interaktion über die bereits erstellte Informationsinfrastruktur des Telegram Messenger erfolgt.

Aus technischer Sicht ist TON ein einzigartiges Projekt, dessen technologischer Stapel von Grund auf neu erstellt wurde, ohne vorhandene vorgefertigte Lösungen zu verwenden. Heute kann man schon sagen:

• Der Quellcode des Projekts wurde von hochprofessionellen Entwicklern geschrieben, die alle Feinheiten der Blockchain-Technologie genau kennen.
• haben ihre eigenen einfachen Sprachen zum Schreiben intelligenter Verträge (Fift und FunC) erstellt, mit denen alle Funktionen einer virtuellen Maschine und das Debuggen effektiv genutzt werden können.
• , ;
• telegram-, TON;

TON

Das Infinite Sharding Paradigma klingt beeindruckend, muss jedoch in der Praxis sorgfältig getestet werden Wenn die Anzahl der Shards zunimmt, nimmt die Anzahl der Kreuzketten zu, was wahrscheinlich zu einer Verringerung der Transaktionsverarbeitungsgeschwindigkeit führt. Daher gibt es in der Tat eine effektive Obergrenze für den Durchsatz. TON plant, das, was die Entwickler selbst als "sofortiges Routing im Hypercube" bezeichnen, zu verwenden, um Kreuzketten und Blöcke zwischen Zeichenketten zu routen. Obwohl ein Routing-Pfad effizient gefunden werden kann, ist dies nicht die endgültige Lösung für das zugrunde liegende Problem der Skalierung der TON-Blockchain und der Erhöhung des Durchsatzes.

, , TON , , « » , , , .

Tatsächlich müssen TON-Knoten einen bestimmten Anteil des Vermögens (Gramm-Token) hinterlegen, um zur Teilnahme an der Konsensbildung berechtigt zu sein. Der Nachteil dieses Modells ist, dass es dazu führen kann, dass die Reichen noch reicher werden, da der Anteil des Vermögens der einzige entscheidende Faktor ist und TON den Reichen dementsprechend die Mittel zur Finanzierung des Managements von PoS-Knoten zur Verfügung stellt, was bedeutet, dass nur große Organisationen mit ausreichender Finanzierung zur Verfügung stehen Erhalten Sie Belohnungen von den meisten Websites ohne Aufwand und technisches Know-how.

PoS . , - , PoS , . PoS, , . , PoS , .

Grams Wallet — Gram

- TON Grams Wallet , Telegram, - , Telegram FZ-LLC ( ).

, , , , , 18 , , , , Telegram FZ-LLC .

, , (. Linux). , (. 4, . 4.3), , Telegram Open Network:

« TON Blockchain ».

Our open source

Go-binding library

, TON TONLIB.

Mercuryo Go, , -, .
https://github.com/mercuryoio/tonlib-go

tonlib api , , :

• (//// );
• /gram/boc- ;
• Abrufen des Status der Brieftasche und von Informationen dazu;
• Abrufen einer Liste von Transaktionen nach Brieftasche;
• Tongo ist ein leichtes Brieftaschen-Dienstprogramm.

Derzeit sind die Prioritäten bei der Entwicklung der Bibliothek:

• Netzwerküberwachung. Die Fähigkeit, Informationen zu jeder Transaktion von allen Netzwerkblöcken zu erhalten. Wir freuen uns sehr darauf, von tonlib selbst Unterstützung zu erhalten.
• Wechselwirkungen mit Verträgen. Die Arbeit ist bereits im Gange;
• Erweiterung der Funktionalität des Tongo Console Assistant. Wir versuchen, mit jeder Veröffentlichung etwas Neues hinzuzufügen.
• Erzeugung von Interface-Strukturen nach TL-Spezifikation. Es wird uns ermöglichen, mobiler zu sein und Updates mit minimalen Verzögerungen zu veröffentlichen.

Wir werden eine Reihe von Beiträgen zum Testen des Telegram Open Network, Grams Wallet, fortsetzen und unsere Beobachtungen teilen.