<\/a><\/noindex><\/p>\nGrundbegriffe<\/h3>\n <\/p>\n
Konto<\/strong> (account<\/em>). Eine Datenmenge, die durch eine 256-Bit-Zahl identifiziert wird account_id<\/em> (h\u00e4ufig der \u00f6ffentliche Schl\u00fcssel des Kontoinhabers). Im grundlegenden Fall (siehe unten Null-Blockchain<\/em>), bezieht sich diese Datenmenge auf das Guthaben des Nutzers. Jeder kann einen bestimmten account_id<\/em> ausleihen, aber seinen Wert kann man nur nach bestimmten Regeln ver\u00e4ndern.<\/p>\n<\/p>\n
Smart Contract<\/strong> (Smart-Contract<\/em>). Im Wesentlichen handelt es sich um eine spezielle Art von Konto, die mit dem Code eines Smart-Contracts und dem Speicher seiner Variablen erg\u00e4nzt wird. Wenn im Fall eines \u201eWallets\u201c 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\u00e4ndigen Programmiersprache) festgelegt.<\/p>\n<\/p>\n
Zustand der Blockchain<\/strong> (state of blockchain<\/em>). Die Gesamtheit der Zust\u00e4nde aller Konten\/Smart-Contracts (im abstrakten Sinne \u2013 eine Hash-Tabelle, in der die Schl\u00fcssel die Identifikatoren der Konten und die Werte die in den Konten gespeicherten Daten sind).<\/p>\n<\/p>\n
Nachricht<\/strong> (message<\/em>). Ich habe den Ausdruck \u201eGeld einzahlen und abheben\u201c verwendet \u2013 ein konkretes Beispiel f\u00fcr eine Nachricht (\u201e\u00fcbertragen N Gramm<\/em> von Konto account_1<\/em> auf das Konto account_2<\/em>\u201c). Offensichtlich kann eine solche Nachricht nur von einem Knoten gesendet werden, der im Besitz des privaten Schl\u00fcssels des Kontos ist account_1<\/em> und dies durch eine Unterschrift best\u00e4tigen kann. Das Ergebnis der Zustellung solcher Nachrichten an ein normales Konto ist die Erh\u00f6hung seines Guthabens, und f\u00fcr den Smart-Contract die Ausf\u00fchrung seines Codes (der die Ankunft der Nachricht verarbeitet). Nat\u00fcrlich sind auch andere Nachrichten m\u00f6glich, die nicht monet\u00e4re Betr\u00e4ge, sondern beliebige Daten zwischen Smart-Contracts \u00fcbertragen.<\/p>\n<\/p>\n
Die Transaktion<\/strong> (transaction<\/em>). Die Zustellungsbest\u00e4tigung einer Nachricht wird als Transaktion bezeichnet. Transaktionen \u00e4ndern den Zustand der Blockchain. Genau aus diesen Transaktionen (Aufzeichnungen \u00fcber die Zustellung von Nachrichten) bestehen die Bl\u00f6cke in der Blockchain. In diesem Sinne kann man sich den Zustand der Blockchain als eine inkrementelle Datenbank vorstellen \u2013 alle Bl\u00f6cke sind \u201eDiffs\u201c, die nacheinander angewendet werden m\u00fcssen, um den aktuellen Zustand der Datenbank zu erhalten. \u00dcber die spezifische Verpackung dieser \u201eDiffs\u201c (und die Wiederherstellung des vollst\u00e4ndigen Zustands aus ihnen) wird im n\u00e4chsten Artikel die Rede sein.<\/p>\n<\/p>\n
Blockchain in TON: Was ist das und wozu brauchen wir das?<\/h3>\n <\/p>\n
Wie im vorherigen Artikel erw\u00e4hnt, ist die Blockchain eine Datenstruktur, deren Elemente (Bl\u00f6cke) in einer \u201eKette\u201c angeordnet sind, und jeder folgende Block der Kette enth\u00e4lt den Hash des vorherigen.<\/em>. In den Kommentaren wurde die Frage gestellt: Warum ben\u00f6tigen wir \u00fcberhaupt eine solche Datenstruktur, wenn wir bereits DHT \u2013 eine verteilte Hash-Tabelle \u2013 haben? Offensichtlich k\u00f6nnen einige Daten auch in der DHT gespeichert werden, aber das eignet sich nur f\u00fcr nicht allzu \u201esensiblen\u201c Informationen. Kryptow\u00e4hrungsbilanzen k\u00f6nnen nicht in der DHT gespeichert werden \u2013 haupts\u00e4chlich aufgrund des Fehlens von \u00dcberpr\u00fcfungen auf Integrit\u00e4t.<\/em>Die gesamte Komplexit\u00e4t der Blockchain-Struktur entsteht also, um Eingriffe in die darin gespeicherten Daten zu verhindern.<\/p>\n<\/p>\n
Die Blockchain in TON sieht jedoch noch komplizierter aus als in den meisten anderen verteilten Systemen \u2013 und daf\u00fcr gibt es zwei Gr\u00fcnde. Der erste ist der Versuch, den Bedarf an Forks<\/em>. In traditionellen Kryptow\u00e4hrungen sind alle Parameter zu Beginn festgelegt, und jeder Versuch, sie zu \u00e4ndern, f\u00fchrt praktisch zur Schaffung eines \u201ealternativen Universums\u201c der Kryptow\u00e4hrung. Der zweite Grund ist die Unterst\u00fctzung von Sharding (Sharding<\/em>, ) der Blockchain. Die Blockchain ist eine Struktur, die mit der Zeit nicht kleiner werden kann; und normalerweise ist jeder Knoten, der f\u00fcr die Funktionsf\u00e4higkeit des Netzwerks verantwortlich ist, gezwungen, sie vollst\u00e4ndig zu speichern. In traditionellen (zentralisierten) Systemen wird zur L\u00f6sung solcher Probleme Sharding verwendet: Teile der Aufzeichnungen in der Datenbank befinden sich auf einem Server, Teile auf einem anderen usw. Im Fall von Kryptow\u00e4hrungen ist eine solche Funktionalit\u00e4t bisher recht selten \u2013 insbesondere weil es schwierig ist, Sharding in ein System einzuf\u00fcgen, in dem es urspr\u00fcnglich nicht eingeplant war.<\/em>Wie plant TON also, beide oben beschriebenen Probleme zu l\u00f6sen?<\/p>\n<\/p>\n
Wie plant TON, die beiden oben beschriebenen Probleme zu l\u00f6sen?<\/p>\n
<\/p>\n
Inhalt der Blockchain. Workchains.<\/h3>\n <\/p>\n
<\/p>\n
Zun\u00e4chst sprechen wir dar\u00fcber, was im Blockchain gespeichert werden soll. Dort gespeichert werden die Zust\u00e4nde von Konten (in der einfachsten Form \u201eWallets\u201c) 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 \u2013 die Schl\u00fcssel darin sind die Identifikatoren account_id<\/strong>, und die Werte sind Datenstrukturen, die Dinge wie Folgendes enthalten:<\/p>\n<\/p>\n
\nBalance;<\/li>\n Code des Smart Contracts (nur f\u00fcr Smart Contracts);<\/li>\n Datenspeicher des Smart Contracts (nur f\u00fcr Smart Contracts);<\/li>\n Statistik;<\/li>\n (optional<\/em>) \u00f6ffentlicher Schl\u00fcssel f\u00fcr \u00dcberweisungen vom Konto, standardm\u00e4\u00dfig account_id;<\/li>\nWarteschlange ausgehender Nachrichten (hier werden sie f\u00fcr den Versand an den Empf\u00e4nger erfasst);<\/li>\n Liste der zuletzt an dieses Konto zugestellten Nachrichten.<\/li>\n<\/ul>\n<\/p>\n
Wie bereits erw\u00e4hnt, bestehen die Bl\u00f6cke direkt aus Transaktionen \u2013 Nachrichten, die an verschiedene Konten account_id zugestellt werden. Neben account_id enthalten die Nachrichten auch ein 32-Bit-Feld workchain_id<\/em> \u2013 die Kennung der sogenannten Workchain<\/strong> (workchain<\/em>, arbeitsblockchain<\/em>). Dies erm\u00f6glicht mehrere unabh\u00e4ngige Blockchains mit unterschiedlichen Konfigurationen. Dabei gilt workchain_id = 0 als Sonderfall, Null-Workchain<\/strong> \u2013 die dortigen Salden entsprechen der Kryptow\u00e4hrung TON (Grams). H\u00f6chstwahrscheinlich wird es in den ersten Phasen keine anderen Workchains geben.<\/p>\n<\/p>\n
Shardchains. Unendliches Sharding-Paradigma.<\/h3>\n <\/p>\n
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 \u2013 dort liegen alle eingehenden Nachrichten \u2013 und die Zust\u00e4nde all dieser Blockchains werden auf separaten Knoten gespeichert.<\/p>\n
<\/p>\n
Nat\u00fcrlich ist das sehr verschwenderisch: Wahrscheinlich werden die Transaktionen in jeder dieser Shardchains<\/strong> (Shardchain<\/em>, Shard-Blockchain<\/em>) nur sehr selten eintreffen, und es werden viele leistungsstarke Knoten ben\u00f6tigt (um es vorwegzunehmen, dies bezieht sich nicht nur auf Clients auf Mobiltelefonen \u2013 sondern auf ernsthafte Server).<\/p>\n<\/p>\n
Deshalb fassen Shardchains Konten nach den bin\u00e4ren Pr\u00e4fixen ihrer Identifikatoren zusammen: Wenn der Shardchain einen Pr\u00e4fix von 0110 hat, werden alle account_id, die mit diesen Ziffern beginnen, Transaktionen in ihn gelangen. Dieses shard_prefix<\/em> kann eine L\u00e4nge von 0 bis 60 Bit haben \u2013 und das Wichtigste ist, dass es dynamisch ver\u00e4ndert werden kann.<\/p>\n<\/p>\n
<\/p>\n
Sobald in einen der Shard-Chains \u00fcberm\u00e4\u00dfig viele Transaktionen eingehen, teilen die daran arbeitenden Knoten ihn gem\u00e4\u00df vorab festgelegten Regeln in zwei Tochter-Chain \u2013 ihre Pr\u00e4fixe werden um ein Bit l\u00e4nger sein (und f\u00fcr einen von ihnen wird dieses Bit 0 sein, f\u00fcr den anderen 1). Zum Beispiel, shard_prefix<\/em> = 0110<\/u>b wird aufgeteilt in 0110<\/u>0b und 0110<\/u>1b. Wenn zwei \"benachbarte\" Shard-Chains sich lange genug wohlf\u00fchlen, werden sie wieder zu einer Einheit verschmelzen.<\/p>\n <\/p>\n
So wird Sharding \"von unten nach oben\" durchgef\u00fchrt \u2013 wir nehmen an, dass jedes Konto seinen eigenen Shard hat, aber sie sind bis auf Weiteres nach Pr\u00e4fixen \"verklebt\". Das impliziert Infinite Sharding Paradigm<\/strong> (die Paradigma des unendlichen Shardings<\/em>).<\/p>\n<\/p>\n
Es ist wichtig zu betonen, dass Workchains nur virtuell existieren \u2013 in Wirklichkeit ist workchain_id<\/em> es ein Teil des Identifikators eines bestimmten Shard-Chains. In formellen Worten wird jeder Shard-Chain durch ein Zahlenpaar definiert (workchain_id<\/em>, shard_prefix<\/em>).<\/p>\n<\/p>\n
Fehlerbehebung. Vertikale Blockchains.<\/h3>\n <\/p>\n
Traditionell wird angenommen, dass jede Transaktion in der Blockchain \"in Stein gemei\u00dfelt\" ist. Im Fall von TON besteht jedoch die M\u00f6glichkeit, die \"Geschichte neu zu schreiben\" \u2013 falls jemand (sogenannter Fishing-Node<\/em>) nachweisen kann, dass einer der Bl\u00f6cke nicht korrekt signiert wurde. In diesem Fall wird dem entsprechenden Shard-Chain ein spezieller Korrekturblock hinzugef\u00fcgt, der den Hash des zu korrigierenden Blocks (und nicht des letzten Blocks im Shard-Chain) enth\u00e4lt. Wenn man den Shard-Chain als eine horizontal angeordnete Kette von Bl\u00f6cken betrachtet, kann man sagen, dass der Korrekturblock nicht nach rechts, sondern von oben an den fehlerhaften Block angeh\u00e4ngt wird \u2013 daher wird angenommen, dass er Teil einer kleinen \"vertikalen Blockchain\" wird. So kann man sagen, dass Shard-Chains zweidimensionale Blockchains sind<\/em>.<\/p>\n<\/p>\n
<\/p>\n
Im Falle, dass nach einem fehlerhaften Block auf die von ihm vorgenommenen \u00c4nderungen in sp\u00e4teren Bl\u00f6cken verwiesen wurde (d. h., es wurden neue Transaktionen auf Basis ung\u00fcltiger Daten durchgef\u00fchrt), werden auch zu diesen Bl\u00f6cken oben Korrekturbl\u00f6cke hinzugef\u00fcgt. Wenn die Bl\u00f6cke die \"betroffene\" Information nicht beeintr\u00e4chtigt 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\u00f6ht, als fehlerhaft angesehen \u2013 daher muss auch die Transaktion, die das Guthaben dieses Kontos im dritten Block verringert, annulliert werden, und ein Korrekturblock muss \u00fcber dem Block verbucht werden.<\/p>\n
<\/p>\n
Es ist zu beachten, dass, obwohl Korrekturbl\u00f6cke als \"\u00fcber\" den Originalbl\u00f6cken dargestellt werden, sie in Wirklichkeit am Ende des entsprechenden Blockchains hinzugef\u00fcgt werden (dort, wo sie chronologisch hingeh\u00f6ren). Die zweidimensionale Anordnung zeigt lediglich, an welchem Punkt im Blockchain sie \"angeh\u00e4ngt\" werden (mittels des in ihnen enthaltenen Hashes des Originalblocks).<\/p>\n
<\/p>\n
Man k\u00f6nnte separat philosophieren, wie gut die Entscheidung ist, \"die Vergangenheit zu ver\u00e4ndern\". Es scheint, dass, wenn wir die M\u00f6glichkeit eines ung\u00fcltigen Blocks im Shard-Chain zulassen, wir auch die M\u00f6glichkeit eines fehlerhaften Korrekturblocks nicht ausschlie\u00dfen k\u00f6nnen. Hier, soweit ich urteilen kann, liegt der Unterschied in der Anzahl der Knoten, die einen Konsens \u00fcber neue Bl\u00f6cke erreichen m\u00fcssen \u2013 \u00fcber jedem Shard wird eine relativ kleine \"Arbeitsgruppe<\/em>\" von Knoten (die sich recht h\u00e4ufig \u00e4ndern) arbeiten, w\u00e4hrend die Einf\u00fchrung von Korrekturbl\u00f6cken die Zustimmung aller \" Validator-Knoten<\/em>erfordert. Mehr Informationen \u00fcber Validatoren, Arbeitsgruppen und andere Rollen von Knoten werde ich im n\u00e4chsten Artikel geben.<\/p>\n<\/p>\n
Eine Blockchain, um alles zu verwalten<\/h3>\n <\/p>\n
Oben wurde viel Informationen \u00fcber verschiedene Arten von Blockchains aufgef\u00fchrt, die ebenfalls irgendwo gespeichert werden sollten. Insbesondere geht es um folgende Daten:<\/p>\n
<\/p>\n
\n\u00fcber die Anzahl und Konfigurationen der Workchains;<\/li>\n \u00fcber die Anzahl der Shardchains und ihre Pr\u00e4fixe;<\/li>\n dar\u00fcber, welche Knoten derzeit f\u00fcr welche Shardchains verantwortlich sind;<\/li>\n Hashes der zuletzt hinzugef\u00fcgten Bl\u00f6cke f\u00fcr alle Shardchains.<\/li>\n<\/ul>\n<\/p>\n
Wie Sie bereits vermuten konnten, werden all diese Dinge in ein weiteres Speicher-Blockchain - Masterchain<\/strong> (Masterchain<\/em>, Master Blockchain<\/em>). Dank der Verwendung von Hashes aus den Bl\u00f6cken aller Shard-Blockchains in seinen Bl\u00f6cken 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\u00f6cke in den Shard-Blockchains erfolgt \u2013 es wird erwartet, dass die Bl\u00f6cke in den Shard-Blockchains fast gleichzeitig alle 5 Sekunden erscheinen, und der n\u00e4chste Block in der Masterchain eine Sekunde sp\u00e4ter entsteht.<\/p>\n<\/p>\n
Aber wer ist verantwortlich f\u00fcr die Umsetzung dieser titanischen Arbeit \u2013 f\u00fcr das Versenden von Nachrichten, das Ausf\u00fchren von Smart Contracts, das Erstellen von Bl\u00f6cken in den Shard-Blockchains und der Masterchain, und auch f\u00fcr die \u00dcberpr\u00fcfung der Bl\u00f6cke auf Fehler? Werden das tats\u00e4chlich 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\u00fcher auf ihren Servern erledigen?<\/p>\n
<\/p>\n
In Wirklichkeit ist keine der beiden Antworten korrekt. Aber die Seiten dieses Artikels neigen sich dem Ende zu, daher wird die Diskussion \u00fcber die verschiedenen Rollen der Knoten (vielleicht haben Sie bereits einige ihrer Erw\u00e4hnungen bemerkt), sowie \u00fcber die Mechaniken ihrer Funktionsweise im n\u00e4chsten Teil fortgesetzt.<\/p>\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u0430\u043d\u043d\u044b\u0439 \u0442\u0435\u043a\u0441\u0442 \u2014 \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u0441\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0442\u0435\u0439, \u0432 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 (\u043f\u0440\u0435\u0434\u043f\u043e\u043b\u043e\u0436\u0438\u0442\u0435\u043b\u044c\u043d\u043e) \u0433\u043e\u0442\u043e\u0432\u044f\u0449\u0435\u0439\u0441\u044f \u043a \u0432\u044b\u0445\u043e\u0434\u0443 \u0432 \u044d\u0442\u043e\u043c \u0433\u043e\u0434\u0443 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438 Telegram Open Network (TON). \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0447\u0430\u0441\u0442\u0438 \u044f \u043e\u043f\u0438\u0441\u0430\u043b \u0435\u0451 \u0441\u0430\u043c\u044b\u0439 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u2014 \u0441\u043f\u043e\u0441\u043e\u0431 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0443\u0437\u043b\u043e\u0432 \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0431\u043e\u0439. \u041d\u0430 \u0432\u0441\u044f\u043a\u0438\u0439 \u0441\u043b\u0443\u0447\u0430\u0439 \u043d\u0430\u043f\u043e\u043c\u043d\u044e, \u0447\u0442\u043e \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u044d\u0442\u043e\u0439 \u0441\u0435\u0442\u0438 \u044f \u043e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u043d\u0435 \u0438\u043c\u0435\u044e \u0438 \u0432\u0435\u0441\u044c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26098,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34631","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"TON:](\"\/wp-content\/uploads\/2019\/05\/e2a24aa1dda6a435e60da257af662853.png\")
<\/p>\n