Telegram Open Network, das sagenumwobene Blockchain-Projekt der Telegram-Schöpfer, geistert in Gerüchten und in der From von Whitepaper durch das Netz. Leider nicht nur so, sondern auch in der Form von Scam-ICOs wie Gram. Es ist also nicht klar, wie viel von den angeblichen Leak-Dokumenten zu halten ist. Ich habe mich durch das Technical Whitepaper gemüht und fasse es hier in diesem Artikel zusammen. Wenn es das „echte Ding“ ist, kommt eine eierlegende Wollmilchsau auf uns zu, die auch noch selbstständig den Mais anbaut.

Das Technical Whitepaper zeigt stolze 132 Seiten im PDF-Reader an. Es besteht aus technischen Beschreibungen die nicht 100% ins Detail gehen aber dennoch so weit, dass es nach einem glaubhaften Überblickdokument aussieht.

Der folgende Artikel fasst dieses Dokument zusammen. Daher kann und will ich keine Garantie für Vollständigkeit geben. Dem Sinn der Sache bleibt es geschuldigt, dass ich stark verkürze und auch auslasse. Details finden Sie im entsprechenden Whitepaper. Schmerzlich aber notwendig sind das Entfallen von Bag of Cells Algebra und Typtheorie hinter der virtuellen Maschine für Smart Contracts. Doch bereits die Einführung in diese Thematik würde den Rahmen sprengen.

TON Blockchain

Die TON-Blockchain ist eine Blockchain die auf mehrere Ebenen aufgeteilt ist. Auf oberster Ebene befindet sich die Masterchain. Diese enthält Meta-Informationen über die darunter liegenden Workingchains und Shardchains. Workingchains sind Blockchains in denen die Transaktionen Werte verschieben bzw. Smart Contracts steuern. Diese Workingchains sind dann wiederum in mehrere Splitter-Blockchains aufgeteilt. Eine Workingchain wird anhand der darin enthaltenen Accounts aufgeteilt. Die Änderungen betreffend der einen Gruppe von Accounts werden in den einen Splitter und betreffend der anderen Gruppe in einen zweiten Splitter geschrieben. Diese Splitter nennt man Shardchain.

Das spannende dabei ist, dass eine Workingchain nicht fest definiert ist. Es wird nur eine Schnittstelle definiert über die sie kompatibel zum restlichen System bleiben muss. Die Details sind nicht vorgegeben. Das bedeutet, dass eine Workingchain eine relativ simple Transfer-Blockchain wie Bitcoin sein könnte und eine andere eine komplexe Smart-Contract Blockchain. Daraus folgt, dass es theoretisch so viele Währungen wie Workingchains im TON-System geben kann. Der Lebenszyklus der Workingchain wird über Transaktionen in der Masterchain gesteuert.

Es ist nicht in Stein gemeißelt welche Workingchains es gibt. Daher können ständig alte Blockchains verschwinden und neue dazu kommen. Die endgültigen Zustände werden in der Masterchain gespeichert und können nicht verloren gehen. Es kann maximal 2^32 Workingchains gleichzeitig geben wobei jede Workingchain wiederum aus bis zu 2^60 Shardchains bestehen kann.

Mulitblockchains, 2-Blockchains und Struktur im Großen

Systeme die auf solche riesige Ausmaße ausgelegt sind, müssen auch bereits Fehlerbehandlung eingebacken haben. Einer dieser Mechanismen heißt in TON block blockchain bzw. 2-blockchain. Dabei werden einzelne Blöcke in der Masterchain sowie in der Shardchain als kleine Blockchains abgebildet.

Sollte sich eine einzelne Transaktion als ungültig herausstellen, muss nicht der ganze Block verworfen werden, sondern es kann in der Form eines block difference Updates, ein weiterer Block eingehängt werden der die ausgebesserte Version enthält.

In einer 2-Blockchain handelt es sich um eine Blockchains von Blockchains. Ein jeder Block ist dementsprechend als Blockchain modelliert um etwaige Updates abbilden zu können. Das ist praktisch wenn zB. zwei Soft-Forks vereint werden sollen.

Das heißt rein rechnerisch unterstützt das System bis zu 2^92 Blockchains – ohne die Blockchains anstatt simpler Blöcke einzurechnen. (2^92 wäre eine Zahl mit 27 Nullen!) Praktisch soll die Anzahl der Blockchains immer möglichst klein gehalten werden.

Das Whitepaper geht auch auf die so genannte Virtuelle Maschine im Hintergrund der Chains ein, der so genannten TVM. Unter virtueller Maschine kann man sich einen virtuellen Computer vorstellen, der über eine eigene Sprache programmiert werden kann. Diese Sprache ist darauf aufgebaut, Strukturen wie Listen oder azyklische, gerichtete Graphen zu modellieren. Theoretisch wäre es also möglich eine IOTA ähnliche Workingchain zu bauen.

Fischersmänner und die Rollen im TON-Netzwerk

Das TON-Netzwerk gibt nicht nur den PoS-Mechanismus vor, sondern auch bestimmte Rollen, die man zB. auch von Polkadot kennt. Nämlich Validator, Nominator, Fischermen und Collators.

Ein Validator übernimmt die Rolle des Miners. Das bedeutet, dieser überprüft die Transaktionen und Blöcke und erhält neue TON-Token zum Ausgleich.

Ein Nominator verleiht Glaubwürdigkeit in der From von Stake an Validatoren. Der Validator gibt dann zum Ausgleich einen Anteil an den erarbeiteten neuen Token an den Nominator zurück.

Betrügerein in der Kryptowelt sind leider keine Seltenheit. Deshalb enthält das Protokoll auch die Rolle des Fisherman. Dieser überprüft ähnlich wie ein Validator Transaktionen und Blöcke und falls er einen Fehler in der Berechnung des Validators findent, bekommt er eine Belohnung.

Der Collator sammelt Transaktionen und Blöcke für den Validator und übermittelt diesem diese Empfehlungen. Dementsprechend ist es die Aufgabe Blöcke für den Validator zu generieren.

Rollen im TON-Netzwerk

Die einzelnen Rollen sind noch weit detaillierter ausspezifiziert und es sind bereits Mechanismen zur Arbeitsteilung definiert. Das würde allerdings den Rahmen dieses Artikels sprengen.

TON Networking

Technisch funktioneren die meisten Systeme im Internet auf TCP/IP oder UDP/IP. Darauf bauen dann weitere Netzwerkprotokolle wie HTTP für Websites oder SMTP für den Mailversand auf. Ähnlich ist auch TON gestrickt und definiert auf den Schultertn von UDP/IP das ADNL bzw. den Abstract Datagram Network Layer. Diese kümmert sich um die Art wie Adressen im Netzwerk aussehen, wie Nachrichten versandt werden können aber auch Channels wie sie zB. für Side-Channels ala Lightning-Network im Bitcoin-Falle nötig sind. Das Protokoll kümmert sich auch darum wie sich die verschiedenen Netzwerkknoten in diesem globalen System finden.

Dafür wird TON DHT verwendet. DHT steht für Distributed Hash Table und bedeutet, dass sich ein großer Setzkasten auf das ganze Netz verteilt. Die einzelnen Kästchen enthalten wiederum Schlüssel die angeben wo die verschiedenen anderen Komponenten im Netz zu finden sind wie zB. Shardchains, Workingchains oder andere Netzwerkknoten für die Synchronisierung der Daten.

Innerhalb dieses riesigen Netzwerks mit potentiell 2^92 vielen Blockchains, ist es notwendig zu definieren, dass nur bestimmte Updates interessant für einen Validator im Netz ist. Daher ist es dank des ADNL-Protokolls auch möglich virtuelle Netze zu definieren die nur diese Bereiche abdecken – sg. Overlay Networks.

Overlay-Network in rot macht die Kommunikation einfacher da weniger Parteien angesprochen werden müssen.

Diese Overlay-Netzwerke können sowohl privat wie auch öffentlich sein und daher auch Zugangskontrollen implementieren.

TON Services and Applications

In der TON-Terminologie wird ein Unterschied zwischen einer Anwendung und einem Service gemacht. Eine Anwendung ist für Menschen und ein Service für Programme gedacht – zB. für Smart Contract Interaktionen.

Technisch werden sie gleich implementiert und nur durch den Anwendungsfall unterschieden. Dementsprechend werde ich im folgenden Anwendung und Service völlig gleichbedeutend verwenden. Eine spannendere Unterscheidung ist, wo sich die Anwendung befindet.

  • On-Chain Anwendungen speichern alle Daten in der Blockchain und verarbeiten sie auch auf der Blockchain.
  • Off-Chain Anwendungen befinden sich außerhalb der Blockchain und sind über Server die in das TON-Netzwerk eingegliedert sind verfügbar.
  • Mixed Anwendungen haben einen Teil auf der Blockchain und einen Teil auf den entsprechenden Servern liegen.

Spannend ist vor allem, dass von Anfang an ein verteilter Speicherdienst ala Dropbox geplant ist: TON Storage. Dabei werden die Referenzen zu den Daten auf der Blockchain gespeichert aber die eigentlichen Daten nicht.

Die Idee von Mixed Anwendungen ist es, sg. Fog Computing zu ermitteln. Dabei werden Teilprobleme ausgelagert und so auf einen Nebel von Dienstleistern verteilt die dann die Teillösungen zurück geben. Das würde dann zB. so aussehen, dass jemand die Steuerabrechnung für seine Smart-Contract-Einkünfte ausschreibt an einen Fog Service und dann ein entsprechender Dienstleister ihn annimmt und das Ergebnis errechnet.

Dementsprechend liegt ein großer Augenmerk auch darauf Service-Suchende und Service-Anbietende auf der Blockchain zusammen zu führen. Ob dies in der Praxis gelingt und damit den in der Informatik lang gehegten Traum von Serviceorientierter Architektur umzusetzen bleibt offen.

TON Payments

Die ganzen technischen Ausführungen könnten fast vergessen machen, dass es sich auch um ein Netzwerk mit einem Payment-Token handelt.

TON definiert Mechanismen um aus der einen Workingchain in die andere zu überweisen. Auch Payment Channels ala Lightning-Network sind vorgesehen. Besonders sind dabei vor allem die in die virtuelle Maschine für Smart Contracts eingebackenen Mechanismen um mittels Smart Contract Payment Channel zu erzeugen.

Fazit

Die Whitepaper erschlagen den Leser fast mit all den technischen Termini und Protokolldefinitionen. Einige Kritiker haben es Fun Fiction genannt und als feuchten Traum von Kryptoenthusiasten die alle Features die ihnen einfallen zusammen gewürfelt haben.

Mein persönliches Resümee aus der Lektüre ist vor allem dieses: Sollte sich das Whitepaper als authentisch herausstellen und diese eierlegende Wohlmilchsau tatsächlich die Bühne der Öffentlichkeit betreten, möchte ich auch ein Stück davon haben.

Join the conversation

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

3 + six =