Dieser Text ist eine Fortsetzung einer Artikelserie, in der ich die Struktur des (vermutlich) verteilten Netzwerks Telegram Open Network (TON) untersuche, dessen Veröffentlichung in diesem Jahr vorbereitet wird. IN Ich habe die grundlegendste Ebene beschrieben – die Art und Weise, wie Knoten miteinander interagieren.
Für alle Fälle möchte ich Sie daran erinnern, dass ich nichts mit der Entwicklung dieses Netzwerks zu tun habe und das gesamte Material einer offenen (wenn auch nicht überprüften) Quelle entnommen wurde – (Es gibt auch eine begleitende , in dem die wichtigsten Punkte kurz dargelegt werden), das Ende letzten Jahres erschien. Die Menge an Informationen in diesem Dokument weist meiner Meinung nach auf seine Echtheit hin, obwohl es dafür keine offizielle Bestätigung gibt.
Heute schauen wir uns die Hauptkomponente von TON an – die Blockchain.
Grundlegende Konzepte
Rechnung (Konto). Ein Datensatz, der durch eine 256-Bit-Zahl identifiziert wird Konto_ID (meistens ist dies der öffentliche Schlüssel des Kontoinhabers). Im Basisfall (siehe unten Null Arbeitskette), beziehen sich diese Daten auf das Guthaben des Benutzers. „Besetzen“-spezifisch Konto_ID Jeder kann es, aber sein Wert kann nur nach bestimmten Regeln geändert werden.
Intelligenter Vertrag (Smart-Vertrag). Im Wesentlichen handelt es sich um einen Sonderfall eines Kontos, ergänzt durch einen intelligenten Vertragscode und die Speicherung seiner Variablen. Wenn Sie im Fall einer „Wallet“ nach relativ einfachen und vorgegebenen Regeln Geld ein- und auszahlen können, dann sind diese Regeln im Fall eines Smart Contracts in Form seines Codes (in einer bestimmten Turing-vollständigen Form) geschrieben Programmiersprache).
Blockchain-Status (Zustand der Blockchain). Die Menge der Zustände aller Konten/Smart Contracts (im abstrakten Sinne eine Hash-Tabelle, in der die Schlüssel Kontokennungen und die Werte die in den Konten gespeicherten Daten sind).
Nachricht (Nachricht). Oben habe ich den Ausdruck „Kredit- und Debitgeld“ verwendet – dies ist ein besonderes Beispiel für eine Nachricht („Überweisung“) N Gramm vom Konto Konto_1 pro Konto Konto_2"). Offensichtlich kann nur der Knoten, der den privaten Schlüssel des Kontos besitzt, eine solche Nachricht senden Konto_1 - und kann dies mit einer Unterschrift bestätigen. Das Ergebnis der Zustellung solcher Nachrichten an ein reguläres Konto ist eine Erhöhung seines Guthabens, und das Ergebnis des Smart Contracts ist die Ausführung seines Codes (der den Empfang der Nachricht verarbeitet). Natürlich sind auch andere Nachrichten möglich (Übertragung nicht von Geldbeträgen, sondern von beliebigen Daten zwischen Smart Contracts).
Transaktion (Transaktion). Die Tatsache, dass eine Nachricht zugestellt wird, wird als Transaktion bezeichnet. Transaktionen verändern den Zustand der Blockchain. Es sind Transaktionen (Nachrichtenübermittlungsaufzeichnungen), die die Blöcke in der Blockchain bilden. In diesem Zusammenhang können Sie sich den Status der Blockchain als eine inkrementelle Datenbank vorstellen – alle Blöcke sind „Diffs“, die nacheinander angewendet werden müssen, um den aktuellen Status der Datenbank zu erhalten. Die Besonderheiten des Packens dieser „Diffs“ (und der Wiederherstellung des vollständigen Zustands daraus) werden im nächsten Artikel besprochen.
Blockchain in TON: Was ist das und warum?
Wie im vorherigen Artikel erwähnt, Blockchain ist eine Datenstruktur, deren Elemente (Blöcke) in einer „Kette“ angeordnet sind und jeder nachfolgende Block der Kette einen Hash des vorherigen enthält. In den Kommentaren wurde die Frage gestellt: Warum brauchen wir überhaupt eine solche Datenstruktur, wenn wir bereits eine DHT haben – eine verteilte Hash-Tabelle? Natürlich können einige Daten in DHT gespeichert werden, dies ist jedoch nur für nicht zu „sensible“ Informationen geeignet. Kryptowährungsguthaben können nicht in DHT gespeichert werden – vor allem aufgrund fehlender Kontrollen Integrität. Tatsächlich wächst die gesamte Komplexität der Blockchain-Struktur, um Eingriffe in die darin gespeicherten Daten zu verhindern.
Allerdings sieht die Blockchain in TON noch komplexer aus als in den meisten anderen verteilten Systemen – und das aus zwei Gründen. Der erste ist der Wunsch, den Bedarf zu minimieren Gabeln. Bei traditionellen Kryptowährungen werden alle Parameter in der Anfangsphase festgelegt und jeder Versuch, sie zu ändern, führt tatsächlich zur Entstehung eines „alternativen Kryptowährungsuniversums“. Der zweite Grund ist die Unterstützung für Crushing (Scherben, Scherben) Blockchain. Blockchain ist eine Struktur, die mit der Zeit nicht kleiner werden kann; und normalerweise ist jeder Knoten, der für den Betrieb des Netzwerks verantwortlich ist, gezwungen, es vollständig zu speichern. In traditionellen (zentralisierten) Systemen wird Sharding zur Lösung solcher Probleme eingesetzt: Einige der Datensätze in der Datenbank befinden sich auf einem Server, andere auf einem anderen usw. Bei Kryptowährungen ist eine solche Funktionalität noch recht selten – insbesondere aufgrund der Tatsache, dass es schwierig ist, Sharding in ein System einzubauen, wo es ursprünglich nicht geplant war.
Wie will TON die beiden oben genannten Probleme lösen?
Blockchain-Inhalte. Arbeitsketten.
Lassen Sie uns zunächst darüber sprechen, was in der Blockchain gespeichert werden soll. Dort werden die Zustände von Konten („Wallets“ im Basisfall) und Smart Contracts gespeichert (der Einfachheit halber gehen wir davon aus, dass es sich dabei um dasselbe wie bei Konten handelt). Im Wesentlichen handelt es sich hierbei um eine reguläre Hash-Tabelle – die darin enthaltenen Schlüssel sind Bezeichner Konto_ID, und Werte sind Datenstrukturen, die solche Dinge enthalten wie:
- Balance;
- Smart-Contract-Code (nur für Smart Contracts);
- Speicherung von Smart Contract-Daten (nur für Smart Contracts);
- Statistiken;
- (optional) öffentlicher Schlüssel für Überweisungen vom Konto, standardmäßig account_id;
- Warteschlange ausgehender Nachrichten (hier werden sie zur Weiterleitung an den Empfänger eingetragen);
- eine Liste der zuletzt an dieses Konto übermittelten Nachrichten.
Wie oben erwähnt, bestehen die Blöcke selbst aus Transaktionen – Nachrichten, die an verschiedene account_id-Konten gesendet werden. Zusätzlich zu „account_id“ enthalten Nachrichten jedoch auch ein 32-Bit-Feld workchain_id — sogenannter Identifikator Arbeitskette (Arbeitskette, funktionierende Blockchain). Dies ermöglicht Ihnen mehrere voneinander unabhängige Blockchains mit unterschiedlichen Konfigurationen. In diesem Fall gilt workchain_id = 0 als Sonderfall, Null Arbeitskette – Es sind die darin enthaltenen Guthaben, die der Kryptowährung TON (Gramm) entsprechen. Höchstwahrscheinlich wird es zunächst überhaupt keine anderen Arbeitsketten geben.
Splitterketten. Unendliches Sharding-Paradigma.
Doch das Wachstum der Zahl der Blockchains hört hier nicht auf. Kommen wir zum Sharding. Stellen wir uns vor, dass jedem Konto (account_id) eine eigene Blockchain zugewiesen wird – sie enthält alle eingehenden Nachrichten – und die Zustände aller dieser Blockchains werden auf separaten Knoten gespeichert.
Das ist natürlich sehr verschwenderisch: höchstwahrscheinlich in jedem dieser Fälle Shardchains (Shardchain, Shard-Blockchain) Transaktionen werden sehr selten eintreffen und es werden viele leistungsstarke Knoten benötigt (mit Blick auf die Zukunft stelle ich fest, dass es sich hier nicht nur um Clients auf Mobiltelefonen handelt, sondern um seriöse Server).
Daher kombinieren Shardchains Konten anhand der binären Präfixe ihrer Kennungen: Wenn eine Shardchain das Präfix 0110 hat, umfasst sie Transaktionen aller Konto-IDs, die mit diesen Nummern beginnen. Das shard_prefix kann eine Länge von 0 bis 60 Bit haben – und die Hauptsache ist, dass sie sich dynamisch ändern kann.
Sobald eine der Shardchains beginnt, zu viele Transaktionen zu empfangen, „teilen“ die daran arbeitenden Knoten sie nach vorgegebenen Regeln in zwei Kinder auf – ihre Präfixe werden ein bisschen länger sein (und für einen von ihnen wird dieses Bit sein). gleich 0 und für den anderen - 1). Zum Beispiel, shard_prefix = 0110b wird sich aufteilen in 01100b und 01101b. Wenn sich wiederum zwei „benachbarte“ Shardchains (für einige Zeit) ausreichend wohl fühlen, werden sie wieder zusammengeführt.
Das Sharding erfolgt also „von unten nach oben“ – wir gehen davon aus, dass jedes Konto seinen eigenen Shard hat, aber vorerst werden sie durch Präfixe „zusammengeklebt“. Das ist es, was es bedeutet Unendliches Sharding-Paradigma (unendliches Sharding-Paradigma).
Unabhängig davon möchte ich betonen, dass Arbeitsketten nur virtuell existieren – tatsächlich workchain_id Es ist Teil der Kennung einer bestimmten Shardchain. Formal wird jede Shardchain durch ein Zahlenpaar definiert (workchain_id, shard_prefix).
Fehler Korrektur. Vertikale Blockchains.
Traditionell gilt jede Transaktion auf einer Blockchain als „in Stein gemeißelt“. Allerdings ist es im Fall von TON möglich, „die Geschichte neu zu schreiben“ – falls jemand (der sogenannte. Fischerknoten) wird beweisen, dass einer der Blöcke falsch signiert wurde. In diesem Fall wird der entsprechenden Shardchain ein spezieller Korrekturblock hinzugefügt, der den Hash des Blocks selbst enthält, der korrigiert wird (und nicht des letzten Blocks in der Shardchain). Wenn man sich die Shardchain als eine Kette horizontal angeordneter Blöcke vorstellt, kann man sagen, dass der Korrekturblock nicht rechts, sondern von oben an den fehlerhaften Block angehängt wird – wir gehen also davon aus, dass er Teil einer kleinen „vertikalen Blockchain“ wird. . Daher können wir sagen, dass es Shardchains gibt zweidimensionale Blockchains.
Wenn nach einem fehlerhaften Block die von ihm vorgenommenen Änderungen von nachfolgenden Blöcken referenziert wurden (d. h. neue Transaktionen wurden auf der Grundlage ungültiger Transaktionen durchgeführt), werden diesen Blöcken auch korrigierende Transaktionen „oben“ hinzugefügt. Wenn sich die Sperren nicht auf die „betroffenen“ Informationen ausgewirkt haben, gelten diese „Korrekturwellen“ nicht für sie. In der obigen Abbildung wurde beispielsweise die Transaktion des ersten Blocks, die den Saldo von Konto C erhöht, als falsch erkannt – daher sollte die Transaktion, die den Saldo dieses Kontos im dritten Block verringert, ebenfalls storniert werden und ein Korrekturblock erstellt werden sollte über dem Block selbst festgeschrieben werden.
Es ist zu beachten, dass die Korrekturblöcke zwar so dargestellt sind, dass sie sich „über“ den Originalblöcken befinden, sie jedoch tatsächlich am Ende der entsprechenden Blockchain hinzugefügt werden (wo sie sich chronologisch befinden sollten). Der zweidimensionale Standort zeigt lediglich an, mit welchem Punkt in der Blockchain sie „verknüpft“ werden (über den Hash des darin befindlichen Originalblocks).
Sie können separat darüber philosophieren, wie gut die Entscheidung ist, „die Vergangenheit zu ändern“. Es scheint, dass wir, wenn wir die Möglichkeit zugeben, dass ein falscher Block in der Shardchain erscheint, die Möglichkeit eines fehlerhaften Korrekturblocks nicht vermeiden können. Soweit ich das beurteilen kann, liegt der Unterschied in der Anzahl der Knoten, die einen Konsens über neue Blöcke erzielen müssen – es wird eine relativ kleine Anzahl von Personen sein, die an jeder Shardchain arbeiten.“Arbeitsgruppe» Knoten (die ihre Zusammensetzung häufig ändern) und die Einführung von Korrekturblöcken erfordern die Zustimmung aller Validierungsknoten. Ich werde im nächsten Artikel mehr über Validatoren, Arbeitsgruppen und andere Knotenrollen sprechen.
Eine Blockchain, um sie alle zu beherrschen
Oben sind viele Informationen zu den verschiedenen Arten von Blockchains aufgeführt, die selbst auch irgendwo gespeichert werden sollten. Dabei handelt es sich insbesondere um folgende Informationen:
- über die Anzahl und Konfigurationen von Arbeitsketten;
- über die Anzahl der Shardchains und deren Präfixe;
- darüber, welche Knoten derzeit für welche Shardchains verantwortlich sind;
- Hashes der letzten Blöcke, die allen Shardchains hinzugefügt wurden.
Wie Sie vielleicht schon vermutet haben, werden all diese Dinge in einem anderen Blockchain-Speicher aufgezeichnet – Meisterkette (Meisterkette, Master-Blockchain). Aufgrund des Vorhandenseins von Hashes aus den Blöcken aller Shardchains in seinen Blöcken wird das System hochgradig vernetzt. Dies bedeutet unter anderem, dass die Generierung eines neuen Blocks in der Masterchain unmittelbar nach der Generierung von Blöcken in Shardchains erfolgt – es wird erwartet, dass Blöcke in Shardchains fast gleichzeitig etwa alle 5 Sekunden erscheinen und der nächste Block in der Masterchain – eine Sekunde danach.
Aber wer wird für die Umsetzung all dieser gigantischen Arbeit verantwortlich sein – für das Versenden von Nachrichten, die Ausführung intelligenter Verträge, die Bildung von Blöcken in Shardchains und der Masterchain und sogar für die Überprüfung von Blöcken auf Fehler? Wird dies alles heimlich von den Telefonen von Millionen von Benutzern durchgeführt, auf denen der Telegram-Client installiert ist? Oder vielleicht wird das Durov-Team die Ideen der Dezentralisierung aufgeben und ihre Server werden es auf die altmodische Art und Weise tun?
Tatsächlich ist weder die eine noch die andere Antwort richtig. Da der Rand dieses Artikels jedoch schnell erschöpft ist, werden wir im nächsten Teil über die verschiedenen Rollen von Knoten (Sie haben möglicherweise bereits die Erwähnung einiger von ihnen bemerkt) sowie über die Mechanismen ihrer Arbeit sprechen.
Source: habr.com