TON: Telegram Open Network. Teil 2: Blockchains, Sharding

Dieser Text ist die Fortsetzung einer Reihe von Artikeln, in denen ich die Struktur des (vermutlich) in diesem Jahr zur Veröffentlichung anstehenden dezentralen Netzwerks Telegram Open Network (TON) behandle. In vorherigen Teil habe ich die grundlegende Ebene beschrieben – die Art und Weise, wie Knoten miteinander interagieren.

Zur Sicherheit erinnere ich daran, dass ich mit der Entwicklung dieses Netzwerks nichts zu tun habe und das gesamte Material aus einer offenen (wenn auch unbestätigten) Quelle stammt – des Dokuments (es gibt auch eine beiliegende Broschüre, die die Hauptpunkte kurz zusammenfasst), die Ende letzten Jahres erschien. Das Volumen der Informationen in diesem Dokument spricht meines Erachtens für seine Echtheit, obwohl es keine offiziellen Bestätigungen dafür gibt.

Heute schauen wir uns die Hauptkomponente von TON an – die Blockchain.

Grundbegriffe

Konto (account). Eine Datenmenge, die durch eine 256-Bit-Zahl identifiziert wird account_id (häufig der öffentliche Schlüssel des Kontoinhabers). Im grundlegenden Fall (siehe unten Null-Blockchain), bezieht sich diese Datenmenge auf das Guthaben des Nutzers. Jeder kann einen bestimmten account_id ausleihen, aber seinen Wert kann man nur nach bestimmten Regeln verändern.

Smart Contract (Smart-Contract). Im Wesentlichen handelt es sich um eine spezielle Art von Konto, die mit dem Code eines Smart-Contracts und dem Speicher seiner Variablen ergänzt wird. Wenn im Fall eines „Wallets“ Geld nach relativ einfachen und im Voraus festgelegten Regeln eingezahlt und abgebucht werden kann, sind diese Regeln im Fall eines Smart-Contracts in Form seines Codes (in einer Turing-vollständigen Programmiersprache) festgelegt.

Zustand der Blockchain (state of blockchain). Die Gesamtheit der Zustände aller Konten/Smart-Contracts (im abstrakten Sinne – eine Hash-Tabelle, in der die Schlüssel die Identifikatoren der Konten und die Werte die in den Konten gespeicherten Daten sind).

Nachricht (message). Ich habe den Ausdruck „Geld einzahlen und abheben“ verwendet – ein konkretes Beispiel für eine Nachricht („übertragen N Gramm von Konto account_1 auf das Konto account_2“). Offensichtlich kann eine solche Nachricht nur von einem Knoten gesendet werden, der im Besitz des privaten Schlüssels des Kontos ist account_1 und dies durch eine Unterschrift bestätigen kann. Das Ergebnis der Zustellung solcher Nachrichten an ein normales Konto ist die Erhöhung seines Guthabens, und für den Smart-Contract die Ausführung seines Codes (der die Ankunft der Nachricht verarbeitet). Natürlich sind auch andere Nachrichten möglich, die nicht monetäre Beträge, sondern beliebige Daten zwischen Smart-Contracts übertragen.

Die Transaktion (transaction). Die Zustellungsbestätigung einer Nachricht wird als Transaktion bezeichnet. Transaktionen ändern den Zustand der Blockchain. Genau aus diesen Transaktionen (Aufzeichnungen über die Zustellung von Nachrichten) bestehen die Blöcke in der Blockchain. In diesem Sinne kann man sich den Zustand der Blockchain als eine inkrementelle Datenbank vorstellen – alle Blöcke sind „Diffs“, die nacheinander angewendet werden müssen, um den aktuellen Zustand der Datenbank zu erhalten. Über die spezifische Verpackung dieser „Diffs“ (und die Wiederherstellung des vollständigen Zustands aus ihnen) wird im nächsten Artikel die Rede sein.

Blockchain in TON: Was ist das und wozu brauchen wir das?

Wie im vorherigen Artikel erwähnt, ist die Blockchain eine Datenstruktur, deren Elemente (Blöcke) in einer „Kette“ angeordnet sind, und jeder folgende Block der Kette enthält den Hash des vorherigen.. In den Kommentaren wurde die Frage gestellt: Warum benötigen wir überhaupt eine solche Datenstruktur, wenn wir bereits DHT – eine verteilte Hash-Tabelle – haben? Offensichtlich können einige Daten auch in der DHT gespeichert werden, aber das eignet sich nur für nicht allzu „sensiblen“ Informationen. Kryptowährungsbilanzen können nicht in der DHT gespeichert werden – hauptsächlich aufgrund des Fehlens von Überprüfungen auf Integrität.Die gesamte Komplexität der Blockchain-Struktur entsteht also, um Eingriffe in die darin gespeicherten Daten zu verhindern.

Die Blockchain in TON sieht jedoch noch komplizierter aus als in den meisten anderen verteilten Systemen – und dafür gibt es zwei Gründe. Der erste ist der Versuch, den Bedarf an Forks. In traditionellen Kryptowährungen sind alle Parameter zu Beginn festgelegt, und jeder Versuch, sie zu ändern, führt praktisch zur Schaffung eines „alternativen Universums“ der Kryptowährung. Der zweite Grund ist die Unterstützung von Sharding (Sharding, ) der Blockchain. Die Blockchain ist eine Struktur, die mit der Zeit nicht kleiner werden kann; und normalerweise ist jeder Knoten, der für die Funktionsfähigkeit des Netzwerks verantwortlich ist, gezwungen, sie vollständig zu speichern. In traditionellen (zentralisierten) Systemen wird zur Lösung solcher Probleme Sharding verwendet: Teile der Aufzeichnungen in der Datenbank befinden sich auf einem Server, Teile auf einem anderen usw. Im Fall von Kryptowährungen ist eine solche Funktionalität bisher recht selten – insbesondere weil es schwierig ist, Sharding in ein System einzufügen, in dem es ursprünglich nicht eingeplant war.Wie plant TON also, beide oben beschriebenen Probleme zu lösen?

Wie plant TON, die beiden oben beschriebenen Probleme zu lösen?

Inhalt der Blockchain. Workchains.

Zunächst sprechen wir darüber, was im Blockchain gespeichert werden soll. Dort gespeichert werden die Zustände von Konten (in der einfachsten Form „Wallets“) und Smart Contracts (der Einfachheit halber betrachten wir diese als die gleichen wie Konten). Im Grunde wird es sich um eine normale Hash-Tabelle handeln – die Schlüssel darin sind die Identifikatoren account_id, und die Werte sind Datenstrukturen, die Dinge wie Folgendes enthalten:

• Balance;
• Code des Smart Contracts (nur für Smart Contracts);
• Datenspeicher des Smart Contracts (nur für Smart Contracts);
• Statistik;
• (optional) öffentlicher Schlüssel für Überweisungen vom Konto, standardmäßig account_id;
• Warteschlange ausgehender Nachrichten (hier werden sie für den Versand an den Empfänger erfasst);
• Liste der zuletzt an dieses Konto zugestellten Nachrichten.

Wie bereits erwähnt, bestehen die Blöcke direkt aus Transaktionen – Nachrichten, die an verschiedene Konten account_id zugestellt werden. Neben account_id enthalten die Nachrichten auch ein 32-Bit-Feld workchain_id – die Kennung der sogenannten Workchain (workchain, arbeitsblockchain). Dies ermöglicht mehrere unabhängige Blockchains mit unterschiedlichen Konfigurationen. Dabei gilt workchain_id = 0 als Sonderfall, Null-Workchain – die dortigen Salden entsprechen der Kryptowährung TON (Grams). Höchstwahrscheinlich wird es in den ersten Phasen keine anderen Workchains geben.

Shardchains. Unendliches Sharding-Paradigma.

Aber das Wachstum der Anzahl der Blockchains stoppt hier nicht. Lassen Sie uns mit dem Sharding befassen. Stellen wir uns vor, dass jedem Konto (account_id) eine eigene Blockchain zugeordnet ist – dort liegen alle eingehenden Nachrichten – und die Zustände all dieser Blockchains werden auf separaten Knoten gespeichert.

Natürlich ist das sehr verschwenderisch: Wahrscheinlich werden die Transaktionen in jeder dieser Shardchains (Shardchain, Shard-Blockchain) nur sehr selten eintreffen, und es werden viele leistungsstarke Knoten benötigt (um es vorwegzunehmen, dies bezieht sich nicht nur auf Clients auf Mobiltelefonen – sondern auf ernsthafte Server).

Deshalb fassen Shardchains Konten nach den binären Präfixen ihrer Identifikatoren zusammen: Wenn der Shardchain einen Präfix von 0110 hat, werden alle account_id, die mit diesen Ziffern beginnen, Transaktionen in ihn gelangen. Dieses shard_prefix kann eine Länge von 0 bis 60 Bit haben – und das Wichtigste ist, dass es dynamisch verändert werden kann.

Sobald in einen der Shard-Chains übermäßig viele Transaktionen eingehen, teilen die daran arbeitenden Knoten ihn gemäß vorab festgelegten Regeln in zwei Tochter-Chain – ihre Präfixe werden um ein Bit länger sein (und für einen von ihnen wird dieses Bit 0 sein, für den anderen 1). Zum Beispiel, shard_prefix = 0110b wird aufgeteilt in 01100b und 01101b. Wenn zwei "benachbarte" Shard-Chains sich lange genug wohlfühlen, werden sie wieder zu einer Einheit verschmelzen.

So wird Sharding "von unten nach oben" durchgeführt – wir nehmen an, dass jedes Konto seinen eigenen Shard hat, aber sie sind bis auf Weiteres nach Präfixen "verklebt". Das impliziert Infinite Sharding Paradigm (die Paradigma des unendlichen Shardings).

Es ist wichtig zu betonen, dass Workchains nur virtuell existieren – in Wirklichkeit ist workchain_id es ein Teil des Identifikators eines bestimmten Shard-Chains. In formellen Worten wird jeder Shard-Chain durch ein Zahlenpaar definiert (workchain_id, shard_prefix).

Fehlerbehebung. Vertikale Blockchains.

Traditionell wird angenommen, dass jede Transaktion in der Blockchain "in Stein gemeißelt" ist. Im Fall von TON besteht jedoch die Möglichkeit, die "Geschichte neu zu schreiben" – falls jemand (sogenannter Fishing-Node) nachweisen kann, dass einer der Blöcke nicht korrekt signiert wurde. In diesem Fall wird dem entsprechenden Shard-Chain ein spezieller Korrekturblock hinzugefügt, der den Hash des zu korrigierenden Blocks (und nicht des letzten Blocks im Shard-Chain) enthält. Wenn man den Shard-Chain als eine horizontal angeordnete Kette von Blöcken betrachtet, kann man sagen, dass der Korrekturblock nicht nach rechts, sondern von oben an den fehlerhaften Block angehängt wird – daher wird angenommen, dass er Teil einer kleinen "vertikalen Blockchain" wird. So kann man sagen, dass Shard-Chains zweidimensionale Blockchains sind.

Im Falle, dass nach einem fehlerhaften Block auf die von ihm vorgenommenen Änderungen in späteren Blöcken verwiesen wurde (d. h., es wurden neue Transaktionen auf Basis ungültiger Daten durchgeführt), werden auch zu diesen Blöcken oben Korrekturblöcke hinzugefügt. Wenn die Blöcke die "betroffene" Information nicht beeinträchtigt haben, finden diese "Korrekturwellen" auf ihnen keine Anwendung. Zum Beispiel wurde in der obigen Darstellung die Transaktion des ersten Blocks, die das Guthaben des Kontos C erhöht, als fehlerhaft angesehen – daher muss auch die Transaktion, die das Guthaben dieses Kontos im dritten Block verringert, annulliert werden, und ein Korrekturblock muss über dem Block verbucht werden.

Es ist zu beachten, dass, obwohl Korrekturblöcke als "über" den Originalblöcken dargestellt werden, sie in Wirklichkeit am Ende des entsprechenden Blockchains hinzugefügt werden (dort, wo sie chronologisch hingehören). Die zweidimensionale Anordnung zeigt lediglich, an welchem Punkt im Blockchain sie "angehängt" werden (mittels des in ihnen enthaltenen Hashes des Originalblocks).

Man könnte separat philosophieren, wie gut die Entscheidung ist, "die Vergangenheit zu verändern". Es scheint, dass, wenn wir die Möglichkeit eines ungültigen Blocks im Shard-Chain zulassen, wir auch die Möglichkeit eines fehlerhaften Korrekturblocks nicht ausschließen können. Hier, soweit ich urteilen kann, liegt der Unterschied in der Anzahl der Knoten, die einen Konsens über neue Blöcke erreichen müssen – über jedem Shard wird eine relativ kleine "Arbeitsgruppe" von Knoten (die sich recht häufig ändern) arbeiten, während die Einführung von Korrekturblöcken die Zustimmung aller " Validator-Knotenerfordert. Mehr Informationen über Validatoren, Arbeitsgruppen und andere Rollen von Knoten werde ich im nächsten Artikel geben.

Eine Blockchain, um alles zu verwalten

Oben wurde viel Informationen über verschiedene Arten von Blockchains aufgeführt, die ebenfalls irgendwo gespeichert werden sollten. Insbesondere geht es um folgende Daten:

• über die Anzahl und Konfigurationen der Workchains;
• über die Anzahl der Shardchains und ihre Präfixe;
• darüber, welche Knoten derzeit für welche Shardchains verantwortlich sind;
• Hashes der zuletzt hinzugefügten Blöcke für alle Shardchains.

Wie Sie bereits vermuten konnten, werden all diese Dinge in ein weiteres Speicher-Blockchain - Masterchain (Masterchain, Master Blockchain). Dank der Verwendung von Hashes aus den Blöcken aller Shard-Blockchains in seinen Blöcken ist das System stark miteinander verbunden. Das bedeutet unter anderem, dass die Erstellung eines neuen Blocks in der Masterchain unmittelbar nach der Erstellung der Blöcke in den Shard-Blockchains erfolgt – es wird erwartet, dass die Blöcke in den Shard-Blockchains fast gleichzeitig alle 5 Sekunden erscheinen, und der nächste Block in der Masterchain eine Sekunde später entsteht.

Aber wer ist verantwortlich für die Umsetzung dieser titanischen Arbeit – für das Versenden von Nachrichten, das Ausführen von Smart Contracts, das Erstellen von Blöcken in den Shard-Blockchains und der Masterchain, und auch für die Überprüfung der Blöcke auf Fehler? Werden das tatsächlich die Smartphones von Millionen Nutzern sein, auf denen der Telegram-Client installiert ist? Oder wird das Team von Durov die Ideen der Dezentralisierung aufgeben und das Ganze wieder wie früher auf ihren Servern erledigen?

In Wirklichkeit ist keine der beiden Antworten korrekt. Aber die Seiten dieses Artikels neigen sich dem Ende zu, daher wird die Diskussion über die verschiedenen Rollen der Knoten (vielleicht haben Sie bereits einige ihrer Erwähnungen bemerkt), sowie über die Mechaniken ihrer Funktionsweise im nächsten Teil fortgesetzt.

Quelle: habr.com