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

Dieser Text ist eine Fortsetzung einer Serie von Artikeln, in denen ich die Struktur des vermeintlich in diesem Jahr erscheinenden verteilten Netzwerks Telegram Open Network (TON) bespreche. In vorherigen Teile habe ich die grundlegendste Ebene beschrieben — die Art und Weise, wie Knoten miteinander interagieren.

Zur Erinnerung: Ich habe nichts mit der Entwicklung dieses Netzwerks zu tun, und das gesamte Material stammt aus einer offenen (wenn auch unbestätigten) Quelle — des Dokuments (es gibt auch eine beiliegende Broschüre, die die wichtigsten Punkte zusammenfasst), die Ende letzten Jahres erschienen ist. Nach meiner Einschätzung deutet das Volumen der Informationen in diesem Dokument auf seine Authentizität hin, obwohl es dafür keine offiziellen Bestätigungen gibt.

Heute schauen wir uns den Hauptbestandteil von TON — die Blockchain — an.

Grundlagen

Account (account). Eine Art Datensatz, der durch eine 256-Bit-Zahl identifiziert wird, account_id (meist handelt es sich um den öffentlichen Schlüssel des Kontoinhabers). Im Grundfall (siehe unten Null-Blockchain) bezieht sich dieser Datensatz auf das Guthaben des Benutzers. «Ausleihen» kann es jeder, aber den Wert zu ändern, ist nur nach bestimmten Regeln möglich. account_id Smart-Contract

Smart-Contract (smart-contract). Im Grunde genommen handelt es sich um einen speziellen Fall eines Kontos, das durch einen Smart-Contract-Code und dessen Variablen-Speicher ergänzt wird. Während es bei einem „Wallet“ möglich ist, Geld gemäß relativ einfachen und vorher festgelegten Regeln einzuzahlen und abzuheben, sind die Regeln für einen Smart Contract in seinem Code (in einer bestimmten 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, wobei die Schlüssel die Identifikatoren der Konten und die Werte die in den Konten gespeicherten Daten sind).

Nachricht (message). Ich habe zuvor den Ausdruck „Geld einzahlen und abheben“ verwendet – das ist ein spezifisches Beispiel für eine Nachricht („übertragen N Gramm von Konto account_1 auf Konto account_2“). Offensichtlich kann eine solche Nachricht nur von einem Knoten gesendet werden, der den privaten Schlüssel des Kontos besitzt. account_1 — und kann dies durch eine Signatur bestätigen. Das Ergebnis der Zustellung solcher Nachrichten an ein reguläres Konto ist eine Erhöhung seines Guthabens, während der Smart Contract seinen Code ausführt (der die Nachricht empfängt). Natürlich sind auch andere Nachrichten möglich (die nicht monetäre Beträge, sondern beliebige Daten zwischen Smart Contracts übertragen).

Transaktion (Transaktion). Die Tatsache der Nachrichtenübermittlung wird als Transaktion bezeichnet. Transaktionen ändern den Zustand der Blockchain. Tatsächlich bestehen Blöcke in der Blockchain aus Transaktionen (Aufzeichnungen über die Zustellung von Nachrichten). In dieser Hinsicht kann man sich den Zustand der Blockchain wie eine inkrementelle Datenbank vorstellen – alle Blöcke sind „Diffs“, die nacheinander angewendet werden müssen, um den aktuellen Zustand der DB zu erhalten. Über die Details der Verpackung dieser „Diffs“ (und die Wiederherstellung des vollständigen Zustands davon) wird im nächsten Artikel gesprochen werden.

Blockchain im TON: Was ist das und wozu dient es?

Wie im vorherigen Artikel erwähnt, ist die Blockchain eine Datenstruktur, deren Elemente (Blöcke) in einer „Kette“ angeordnet sind, und jeder nachfolgende Block in der Kette enthält den Hash des vorherigen.. In den Kommentaren wurde die Frage gestellt: Warum überhaupt eine solche Datenstruktur, wenn wir bereits DHT — eine verteilte Hash-Tabelle — haben? Offensichtlich können einige Daten auch in DHT gespeichert werden, aber das eignet sich nur für nicht zu „sensible“ Informationen. Kryptowährungsbilanzen können nicht in DHT gespeichert werden — vor allem wegen fehlender Integritätsprüfungen. Integrität. Tatsächlich entsteht die gesamte Komplexität der Blockchain-Struktur, um Eingriffe in die darin gespeicherten Daten zu verhindern.

Allerdings sieht die Blockchain im TON noch komplexer aus als in den meisten anderen verteilten Systemen — und dafür gibt es zwei Gründe. Der erste ist der Wunsch, die Notwendigkeit von Forkszu minimieren. In traditionellen Kryptowährungen sind alle Parameter zu Beginn festgelegt, und jeder Versuch, diese zu ändern, führt faktisch zur Entstehung eines „alternativen Universums“ der Kryptowährung. Der zweite Grund ist die Unterstützung von Sharding (Sharding, Sharding).) Blockchain. Die Blockchain ist eine Struktur, die im Laufe der Zeit nicht kleiner werden kann; und in der Regel 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 eingesetzt: Ein Teil der Datenbankinhalte befindet sich auf einem Server, ein anderer Teil auf einem anderen, usw. Bei Kryptowährungen ist eine solche Funktionalität bisher recht selten — insbesondere, weil es schwierig ist, Sharding in ein System einzufügen, das nicht von Anfang an dafür geplant wurde.

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

Inhalt der Blockchain. Währungen.

Zunächst sprechen wir darüber, was in der Blockchain gespeichert werden soll. Dort werden die Zustände der Konten (im einfachsten Fall „Wallets“) und der Smart Contracts gespeichert (der Einfachheit halber nehmen wir an, dass dies dasselbe ist wie die Konten). Im Grunde wird es sich um eine gewöhnliche Hash-Tabelle handeln — die Schlüssel darin sind die Identifikatoren account_id, und die Werte sind Datenstrukturen, die solche Dinge enthalten wie:

• Kontostand;
• Code des Smart Contracts (nur für Smart Contracts);
• Datenablage für Smart Contracts (nur für Smart Contracts);
• Statistik;
• (optional) öffentlicher Schlüssel für Überweisungen vom Konto, standardmäßig account_id;
• Warteschlange für ausgehende Nachrichten (hier werden sie zur Weiterleitung an den Empfänger abgelegt);
• Liste der zuletzt an dieses Konto gelieferten Nachrichten.

Wie bereits erwähnt, bestehen die Blöcke direkt aus Transaktionen – Nachrichten, die an verschiedene Konten (account_id) geliefert werden. Neben account_id enthalten die Nachrichten auch ein 32-Bit-Feld workchain_id – die Kennung des sogenannten Workchains (workchain, arbeitenden Blockchain). Dies ermöglicht die Existenz mehrerer unabhängiger Blockchains mit unterschiedlichen Konfigurationen. Dabei wird workchain_id = 0 als Sonderfall angesehen, Null-Workchain – die darin befindlichen Guthaben entsprechen der Kryptowährung TON (Grams). Vermutlich wird es anfangs keine anderen Workchains geben.

Shardchains. Infinite Sharding Paradigm.

Doch das Wachstum der Anzahl der Blockchains stoppt hier nicht. Lassen Sie uns mit Sharding vertrautmachen. Stellen Sie sich vor, dass jedem Konto (account_id) eine eigene Blockchain zugewiesen ist, in der alle eingehenden Nachrichten liegen, und die Zustände aller dieser Blockchains auf separaten Knoten gespeichert werden.

Natürlich ist das ziemlich verschwenderisch: Wahrscheinlich werden in jede dieser Shardchains (shardchain, Shard-Blockchain) Transaktionen nur sehr selten eingehen, und es werden viele leistungsstarke Knoten benötigt (vorweggenommen sei, dass es nicht nur um mobile Telefonkunden geht – sondern um ernsthafte Server).

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

Sobald ein Shardchain übermäßig viele Transaktionen erhält, teilen die Knoten, die daran arbeiten, ihn gemäß vordefinierten Regeln in zwei Tochterchains auf – deren Präfixe sind um ein Bit länger (wobei für einen das Bit 0 und für den anderen das Bit 1 ist). Zum Beispiel, shard_prefix = 0110wird b aufgeteilt in 01100b und 01101b. Umgekehrt, wenn zwei "benachbarte" Shardchains sich über einen gewissen Zeitraum hinweg wohlfühlen, können sie wieder zu einer Einheit zusammengeführt werden.

Somit erfolgt das Sharding „von unten nach oben“ – wir gehen davon aus, dass jedes Konto seinen eigenen Shard hat, diese jedoch – vorübergehend – nach Präfixen „verklebt“ sind. Das bringt uns zur Unendliches Sharding-Paradigma (Paradigmen des endlosen Shardings.).

Es ist wichtig zu betonen, dass Workchains nur virtuell existieren – tatsächlich ist workchain_id dies ein Teil der Identifikationsnummer eines bestimmten Shardchains. Formell ausgedrückt wird jeder Shardchain durch ein Zahlenpaar bestimmt (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 gibt es jedoch die Möglichkeit, die 'Geschichte neu zu schreiben' – wenn jemand (ein sogenannter Fisher-Knoten) beweist, dass einer der Blöcke fehlerhaft signiert wurde. In diesem Fall wird ein spezieller Korrekturblock zum entsprechenden Shard-Chain hinzugefügt, der den Hash des zu korrigierenden Blocks (und nicht des letzten Blocks in der Shard-Chain) enthält. Wenn man die Shard-Chain als eine horizontal ausgelegte Kette von Blöcken betrachtet, kann man sagen, dass der Korrekturblock nicht rechts an den fehlerhaften Block angehängt wird, sondern oben – weshalb man sagt, dass er Teil einer kleinen 'vertikalen Blockchain' wird. Daher kann man sagen, dass Shard-Chains zweidimensionale Blockchains sind..

Wenn nach einem fehlerhaften Block die Änderungen, die er vorgenommen hat, von nachfolgenden Blöcken referenziert wurden (d.h. es wurden neue Transaktionen auf Basis ungültiger Daten durchgeführt), werden auch diesen Blöcken "Korrekturen" "von oben" hinzugefügt. Wenn die Blöcke jedoch keine "betroffenen" Informationen berührten, gelten diese "Korrekturwellen" nicht für sie. Zum Beispiel wurde in der obigen Abbildung die Transaktion des ersten Blocks, die das Guthaben des Kontos C erhöht, als fehlerhaft angesehen – daher muss die Transaktion, die das Guthaben dieses Kontos im dritten Block verringert, ebenfalls annulliert werden, und über diesem Block wird ein Korrekturblock vermerkt.

Es ist anzumerken – obwohl Korrekturblöcke als "über" den Originalblöcken dargestellt werden, werden sie tatsächlich an das Ende der entsprechenden Blockchain angehängt (dort, wo sie chronologisch hingehören). Die zweidimensionale Anordnung zeigt lediglich, an welchen Punkt in der Blockchain sie "angehängt" werden (mittels des in ihnen enthaltenen Hashes des Originalblocks).

Man könnte lange darüber philosophieren, wie gut die Lösung „die Vergangenheit zu ändern“ tatsächlich ist. Es scheint, dass wenn wir die Möglichkeit eines fehlerhaften Blocks in der Blockchain zulassen, wir ebenso die Möglichkeit eines fehlerhaften Korrekturblocks zulassen müssen. Hier, so viel ich beurteilen kann, liegt der Unterschied in der Anzahl der Knoten, die Konsens über neue Blöcke erreichen müssen — an jedem Shard-Chain wird eine relativ kleine "Arbeitsgruppe" von Knoten arbeiten (die sich ziemlich oft verändert), während das Einfügen von Korrekturblöcken die Zustimmung aller Validator-Knotenerfordert. Mehr Details über Validatoren, Arbeitsgruppen und andere Rollen von Knoten werde ich im nächsten Artikel erläutern.

Eine Blockchain, um alle zu regieren

Ich habe oben viele Informationen über verschiedene Arten von Blockchains aufgelistet, die selbst irgendwo gespeichert werden sollten. Insbesondere handelt es sich um folgende Angaben:

• über die Anzahl und Konfigurationen von Workchains;
• über die Anzahl der Shard-Chains und deren Präfixe;
• darüber, welche Knoten derzeit für welche Shard-Chains verantwortlich sind;
• Hashes der zuletzt hinzugefügten Blöcke zu allen Shard-Chains.

Wie Sie sich vielleicht schon denken können, werden all diese Dinge in einem weiteren Speicher – der Masterchain (Masterchain, Master-Blockchain). Durch die Hashes der Blöcke aller Shardchains in seinen Blöcken wird das System stark miteinander verbunden. Das bedeutet auch, dass die Generierung eines neuen Blocks in der Masterchain direkt nach der Erstellung der Blöcke in den Shardchains erfolgt – erwartet wird, dass die Blöcke in den Shardchains fast gleichzeitig alle 5 Sekunden erscheinen, und ein neuer Block in der Masterchain eine Sekunde danach.

Aber wer wird verantwortlich sein für die Durchführung dieser titanischen Aufgaben – das Versenden von Nachrichten, das Ausführen von Smart Contracts, die Bildung von Blöcken in den Shardchains und in der Masterchain sowie die Überprüfung der Blöcke auf Fehler? Werden all dies heimlich die Smartphones von Millionen Nutzern mit dem Telegram-Client darauf erledigen? Oder wird das Team von Durov die Ideen der Dezentralisierung aufgeben und es werden ihre Server auf die altmodische Weise tun?

Tatsächlich ist ke Antworten richtig. Doch der Platz in diesem Artikel neigt 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 Mechanismen ihres Betriebs in der nächsten Folge fortgesetzt.

Quelle: habr.com