Tangle 2.0 (nach dem Coordicide)

IOTA funktioniert nicht wie eine herkömmliche Blockchain, sondern arbeitet mit dem innovativen Konzept des „Tangle“ (dt. Wirrwarr), zudem werden Transaktionen im Tangle anders bezeichnet als bei Blockchain-Lösungen, im Tangle gibt es nicht die "eine" Transaktion, es gibt verschiedene "Objekt-Typen", da das IOTA-Protokoll nicht nur eine Anwendung zur Übertragung von Werten ist, sondern auch eine Plattform zur sicheren Übertragung von Daten.

Der Tangle selbst ist in dem IOTA-Protokoll, eine angehängte Datenstruktur, die durch die Verbindungen zwischen den Objekt-Typ im verteilten Ledger auf allen Nodes entsteht. Mathematisch ausgedrückt ist der Tangle ein directed acyclic graph - DAG (dt. gerichteter azyklischer Graph).

  • eine Menge von Transaktionen ist durch Pfade verbunden, dies ist ein Graph
  • jeder dieser Pfade besitzt eine eindeutig festgelegte Laufrichtung, damit ist es ein gerichteter Graph
  • lässt sich niemals ein Pfad finden, der zu seinem Ausgangspunkt zurückkehrt, ist der Graph azyklisch (im Kreis laufenden Pfade wären dagegen zyklisch)

 

Um ein Objekt-Typ an diese Datenstruktur anhängen zu können, müssen zuvor zwei andere Objekt-Typen bestätigt werden. Bekommt ein Objekt-Typ auf diese Weise ein Mindestmaß an Bestätigungen, gilt es als validiert. Eine Ausnahme ist das sogenannte Message(-Objekt), das ist ein generisches Datenobjekt, Messages werden nicht "validiert", sie sind unveränderlich und notarisiert, auf ihnen lässt sich keine "Logik" wie beispielsweise ein Token-Transfer durchführen.

 

Objekt-Typ-Status

grün = vollständig bestätigt   /   weiß = teilweise bestätigt   /   grau = unbestätigt (Tips)

 

In dieser chaotischen Ordnung werden sämtliche Objekt-Typen mehr oder weniger parallel validiert. Diese Funktionsweise ermöglicht von Natur aus eine nach oben hin offener Skalierung, da mit steigender Anzahl der angehängten Objekt-Typen auch die Bestätigungsraten ansteigen, statt sich genau gegenläufig zu entwickeln, wie es derzeit bei den klassischen Blockchains der Fall ist.

 

 

 

Aufbau des Protokolls

Das IOTA-Protokoll ist in drei Schichten (Layer) unterteilt: die Netzwerk-, die Kommunikations- und die Anwendungsschicht. Es gibt Parallelen zwischen den IOTO-Schichten und den oberen Schichten des OSI-Modells, bezüglich des Tangle machen tiefergehende Vergleiche allerdings keinen Sinn.

 

Die Netzwerkschicht verwaltet die Verbindungen und Paketübertragungen wie Autopeering- und Peer-Discovery-Module und das Gossip-Protokoll, vergleichbar mit der Internet-Kommunikation wie TCP.

 

Die Kommunikationsschicht (Message Tangle) schafft eine standardisierte Plattform für die Speicherung und Kommunikation von Informationen. Diese Schicht enthält das "Distributed Ledger" bzw. das Tangle, sowie die Ratensteuerung und die Zeitstempel. Die Messages werden von einem Node ausgegeben und dann auf der Netzwerkschicht geklatscht (engl. gossiped). Sie haben ein effizientes flexibles Format mit variabler Größe und enthalten neben den Hashes der Parents weitere Ausgabeinformationen (engl. Issuing Info) wie beispielsweise Ausgabenodes-ID, Zeitstempel usw., eine Nutzlast (engl. Payload) die die Daten enthält, sowie die Signatur des Ausgabe-Nodes.

 

Die Anwendungsschicht

Das IOTA-Protokoll ermöglicht die Ausführung einer Vielzahl von Anwendungen auf der Kommunikationsschicht (Message Tangle), um daten zu Senden und zu Speichern. Jeder kann eine Anwendung entwerfen, und die Benutzer können entscheiden, welche Anwendungen auf ihren Nodes ausgeführt werden sollen. Jeder Node wird jedoch bestimmte Kernanwendungen ausführen müssen, die für den Betrieb des Protokolls erforderlich sind. Dazu gehören zum Beispiel:

  • Die value transfer application (dt. Wertetransfer-Anwendung)
  • Der distributed random number Generator (DRNG), (dt. verteilte Zufallszahlengenerator)
  • Das Fast Probabilistic Consensus (FPC)-Protokoll

Diese Anwendungen pflegen den Ledgerstatus, und andere Anwendungen können ebenfalls auf diesen Anwendungen arbeiten. Anwendungen lesen und erstellen Message-Payloads, die auf der Kommunikationsschicht gespeichert sind. Allen Entwicklern steht es frei, dezentralisierte Anwendungen auf der Anwendungsschicht zu entwerfen und gleichzeitig die wesentlichen unteren Schichten zu nutzen..

 

Objekte

Die Grundeinheit der Daten im IOTA-Protokoll wird als Objekt bezeichnet. Jedes Objekt hat eine Größe und einen in einem Schema genau definiert Typ, dieser gibt an, welche Felder das Objekt enthält und wie sie angeordnet sind. Der Typ bestimmt auch, wie ein Node das Objekt zerlegt bzw. für die Weiterverarbeitung in ein geeigneteres Format umwandelt (In der Informatik parsen genannt). Eine Message ist so ein Objekttyp, ein generisches Datenobjekt, bei dem es sich, wie der Name schon sagt, nur um Daten handelt. Jeder Node führt eine Liste der Objekttypen, die er erkennt und zu parsen weiß.

Wie bei Messages können Objekte ein Payload-Feld enthalten, welches immer mit einem anderen Objekt gefüllt werden muss, zudem kann ein Objekttyp verlangen, dass eine Payload einen bestimmten Typ hat. Beim Parsen eines Objekts parst ein Node seine Payload entsprechend seinem Typ, wenn der Node den Typ nicht kennt, behandelt er die Payload wie ein generisches Datenobjekt. Durch Payloads können Objekte ineinander verschachtelt werden, wodurch eine sehr flexible Plattform entsteht.

Um in der Kommunikationsschicht (Message Tangle) geklatscht (engl. gossiped) und gespeichert werden zu können, muss jedes Objekt innerhalb einer Message gekapselt werden, entweder direkt als Payload oder indirekt als Payload eines anderen Objekts. Hinweis, eine Message mit Payload-Typ X kann als X-Message bezeichnet werden.

Beispielsweise kann eine Lieferketten-Anwendung einen Objekttyp namens "Delivery" (dt. Lieferung) definieren. Die Nutzlast eines Delivery-Objekts könnte zwei verschiedene Objekttypen unterstützen: Parcel und Receipt (dt. Paket und Empfang). Beim Versenden eines Pakets kann ein Benutzer eine Delivery-Message (Message mit einem Delivery-Objekt) ausgeben, die ein Parcel-Objekt enthält, das das Paket beschreibt. Jedes Mal, wenn jemand das Paket empfängt, kann er eine Delivery-Message mit einem Receipt-Objekt ausgeben, das den Hash des Parcel-Objekts auflistet.

 

 

Nodes die diese Lieferketten-Anwendung nicht verwenden, können wie oben beschrieben das Delivery-Objekt nicht erkennen und können dementsprechend das Delivery-Objekt nicht parsen, daher werden in diesem Fall alle Delivery-Objekte als generische Daten behandelt. Allerdings müssen alle Nodes bestimmte Kernobjekttypen erkennen, die von den Kernanwendungen verwendet werden. Zu den Kernobjekttypen gehören:

  • Wert-Objekte (engl. Value)
  • FPC-Meinungs-Objekte
  • DRNG-Objekte
  • Salt deklarierte Objekte
  • Generische Daten Objekte

Wie bereits erwähnt, können Messages, die diese Objekte enthalten, jeweils Value-Messages, FPC-Messages, etc. genannt werden. Das IOTA-Protokoll wird sich in Zukunft wahrscheinlich von Zeit zu Zeit ändern, daher erhalten alle Objekttypen eine Versionsnummer, so dass jede Anwendung aktualisiert werden kann. Die Versionsnummer einer Message gibt an, welche Version des IOTA-Protokolls die Message verwendet. Die Versionsnummern ermöglichen es den Nodes, die Interoperabilität zwischen diesen verschiedenen Versionen zu verwalten.

 

 

Die Wertetransfer-Anwendung (Value-Tangle, dt. Werte-Tangle)

Die wichtigste Kernanwendung die jede Node ausführen muss ist die Wertetransfer-Anwendung, die Gelder bewegt und den Ledgerstatus aktualisiert. Diese Anwendung verwendet Value-Objekte und jedes dieser Value-Objekte referenziert zwei andere Value-Objekte, so dass die Value-Objekte ein "zusätzliches Tangle" über dem Message-Tangle (Kommunikationsschicht) bilden, das so genannte Value-Tangle. In diesem Value-Tangle stellen die Referenzierungen eine "Genehmigung" dar, welche die Ergebnisse der FPC-Abstimmungen speichern.

 

Die Wertetransfer-Anwendung arbeitet ausschließlich mit Payloads vom Typ Value-Objekt. Dieser Layer hat nachfolgende Verantwortlichkeiten:

  • Bildung des Ledger-Status
  • Verarbeitung, Validierung und Ausgabe von Transaktionen
  • Erkennung von Konflikten
  • Konfliktlösung über FPC
  • Bildung einer DAG aus Value-Objekten
  • Tip-Auswahl (bei Value-Objekt-Tips)

 

Jetzt wird sich der ein oder andere Fragen, warum es einen zusätzlichen Werte-Tangle gibt? Alle von FPC abgelehnten Werte-Objekte im Werte-Tangle verwaisen und werden nicht weiter beachtet. Grundsätzlich sind verwaiste Messages oder Objekte insofern ein Problem, weil ggf. schon weitere neue Messages/Objekte zur Referenzierung anhängen und deshalb die Gefahr besteht, dass diese neuen Messages/Objekte ebenfalls verwaisen. Um diese neu angehängten unschuldig verwaisten Daten zu reduzieren trennt, die IOTA Foundation das Tangle in Wert- und Message-Tangle auf. Dadurch wird der Werte-Tangle praktisch Spam-Frei, den Spam würde hier Geld kosten, infolgedessen wird es auch viel weniger zu lösende Konflikte innerhalb des Werte-Tangle geben.






 

 

 

Jedes Wert-Objekt hat eine Payload, die nur einen Objekttyp namens Transaktion unterstützt. Eine Transaktion enthält die Input-Transaktionen, die Output-Adressen mit den Guthaben (Balance), den Mana-Empfänger, eine Payload und eine Signatur. Da IOTA ein UTXO-Schema verwenden, macht der Begriff Transaktion Sinn: UTXO steht für Unspent (TX) transaction Output (dt. nicht ausgegebene Transaktionsausgabe).

 

Die Payload einer Transaktion kann eine Vielzahl von Objekttypen wie z.B. Smart Contracts unterstützen. Sobald die Payload signiert ist, ist sie grundsätzlich Teil der Transaktion. Gemäß dem UTXO-Schema kommt es zu Konflikten zwischen verschiedenen Transaktionen, die die gleichen Inputs verwenden. Daher kommt es zu Konflikten zwischen zwei ansonsten identischen Transaktionen, wenn sie unterschiedliche Payloads haben. Somit ist die Payload inhärent an die Ausgaben gebunden. Diese Funktionalität ermöglicht eine Vielzahl von Anwendungen, die auf der Wertetransfer-Anwendung aufbauen.

Betrachten Sie das Beispiel der Delivery-Anwendung. Wenn der Empfänger für das gelieferte Paket zahlen muss, könnte das Empfangsobjekt in der Payload der Zahlungstransaktion enthalten sein. Dann würde der Zahlungsnachweis den Zustellnachweis enthalten, und entweder sind beide oder keiner von beiden in dem Tangle enthalten.

 

 

 

Glossar

  • Tangle: Eine nur angehängte Datenstruktur, bei der jedes Objekt auf zwei andere Objekte verweist.
  • Application Layer / Anwendungsschicht: Die oberste Schicht, die alle Anwendungen beherbergt.
  • Core Application / Kern-Anwendung: Eine Anwendung, die von allen Nodes ausgeführt werden muss.
  • Communication Layer / : Die Schicht, die sich mit Messages und dem Message-Tangle befasst.
  • Core Object type / Kern-Objekttyp: Ein Objekttyp, der von allen Nodes geparst werden muss.
  • Generisches Datenobjekt: Der grundlegendste Objekttyp. Alle nicht erkannten Datenobjekte werden so behandelt.
  • Network Layer / Netzwerkschicht: Die grundlegendste Schicht, die die Verbindungen und den Klatsch zwischen Nachbarn verwaltet.
  • Message: Der Objekttyp, über den zwischen Nachbarn getratscht wird. Alle geklatschten Informationen sind in einer Nachricht enthalten.
  • Message-Tangle: Die Sammlung aller Nachrichten (Kommunikationsschicht)
  • Objekt: Die grundlegendste Informationseinheit des IOTA-Protokolls. Jedes Objekt hat einen Typ und eine Größe und enthält Daten.
  • Payload / Nutzlast: Ein Feld in einem Objekt, das nur von einem anderen Objekt gefüllt werden kann.
  • Transaktion: Die Payload eines Werte-Objektes. Sie enthält die Angaben zu einem Geldtransfer.
  • Value-Objekt / Werte-Objekt: Das Grundobjekt der Wertetransfer-Anwendung.
  • Value Tangle / Werte-Tangle: Die Sammlung aller Wertobjekte (Anwendungsschicht)
  • Value Transfer Application / Wertetransfer-Anwendung: Die Anwendung, die den Zustand des Ledgers aufrechterhält.
  • Versionsnummer: Gibt das korrekte Format jedes Typs an.

 

 


 Zuletzt bearbeitet am 01.06.2020