Tangle

IOTA funktioniert nicht nach der herkömmlichen Blockchain-Technologie, sondern arbeitet mit dem innovativen Konzept eines „Tangle“, dt. Wirrwar. Das Tangle ist das verteilte Hauptbuch (engl. Distributed Ledger) in IOTA, es enthält die aktuelle Transaktionshistorie. Der Tangle ist die einzige Quelle der Wahrheit, jeder Client auf der ganzen Welt kann gültige Transaktionen an eine Node senden, diese Transaktion wird im gesamten Netzwerk repliziert, um diese einzige Version der Wahrheit zu bilden.

Hinweis: Wer den technischen deep dive sucht wird im englischem IOTA WIKI fündig.


Die IOTA-Architektur umfasst die folgenden grundlegenden Komponenten:

  • Clients: Benutzer eines IOTA-Netzwerks (Wallets, Apps usw.), die Transaktionen an Nodes senden, um sie an den Tangle anzuhängen.
  • Nodes: Verbundene Geräte, die für die Gewährleistung der Integrität des Tangle verantwortlich sind, diese Geräte bilden ein IOTA-Netzwerk.
  • Tangle: Eine angehängte Datenstruktur, das Tangle stellt eine wachsende, teilweise geordnete Menge von Messages dar, die durch kryptografische Verfahren miteinander verbunden sind und auf alle Nodes im Peer-to-Peer-Netzwerk repliziert werden. Das Tangle ermöglicht den Ledger-State (das Hauptkassenbuch, das durch die in den Messages enthaltenen Transaktionen gebildet wird), sowie die Möglichkeit, Daten zu speichern.



Mathematisch ausgedrückt ist der Tangle ein Directed Acyclic Graph - DAG (dt. gerichteter azyklischer Graph).

  • eine Menge von Transaktionen/Messages 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)


grün =  bestätigt (Konsens)   /   lila = unbestätigt   /   weiß = neu angehängt (Tips)


Auf dem obigen Bild können wir sehen, wie der Tangle aussieht. Die Messages sind in dieser Darstellung des Graphen als Quadrate dargestellt und die Pfeile (Edges genannt) zwischen den Messages sind Referenzen. Auf der linken Seite des Graphen befinden sich die älteren Messages, während auf der rechten Seite des Graphen die neu angehängten Messages zu finden sind.  

Messages referenzieren bis zu acht vorherige Messages, sie können sich in einem der drei verschiedenen Zustände befinden: 

  • Bestätigt (grün): Messages gelten als bestätigt, wenn sie direkt oder indirekt von den Tips (lila) referenziert wurden, bei diesen Messages besteht Konsens.
  • Schwebend/unbestätigt (lila): Dies sind Messages, die darauf warten, referenziert zu werden.
  • Tip (weiß): Tips sind neu angehängte Messages, die noch nicht von anderen Messages referenziert wurden.


Die Blockchain-Datenstruktur

Die Blockchain-Datenstruktur besteht aus einer Kette von sequentiellen Blöcken, wobei jeder Block eine begrenzte Anzahl von Transaktionen enthält. Folglich können neue Transaktionen nur an einer Stelle angehängt werden: Einem Block am Ende der Kette. Aufgrund dieser Einschränkung kommt es in Blockchain-Netzwerken häufig zu langsamen Bestätigungszeiten. Diese Einschränkung wird als Blockchain-Bottleneck bezeichnet.



Die Tangle-Datenstruktur

Die Tangle-Datenstruktur ist ein gerichteter azyklischer Graph (DAG), bei dem jede Transaktion an bis zu acht vorhergehende Transaktionen angehängt ist. Anstatt auf einen einzigen Ort zum Anhängen neuer Transaktionen beschränkt zu sein, können Sie Transaktionen überall im Tangle anhängen, daraus ergibt sich eine chaotische Ordnung in der sämtliche Transaktionen parallel ablaufen. Diese Funktionsweise wird eine nach oben hin offener Skalierung ermöglichen, da mit steigender Anzahl der Transaktionen auch die Bestätigungsraten ansteigen, statt sich genau gegenläufig zu entwickeln, wie es derzeit bei den klassischen Blockchains der Fall ist.


Komponenten des Protokolls (IOTA 2.0)

Dieser Abschnitt enthält eine Beschreibung der Interaktion zwischen den Komponenten des GoShimmer-Protokolls. Das Protokoll kann in drei Hauptelemente unterteilt werden:

  • ein P2P-Overlay-Netzwerk (Network-Layer)
  •  eine unveränderliche Datenstruktur (Communication-Layer)
  • ein Konsensmechanismus (Dezentralized-Application-Layer) 

Ähnlich wie bei anderen Architekturen bauen die oberen Layer auf den Funktionen der darunter liegenden Layer auf. Bei der Definition der verschiedenen Layer geht es lediglich darum, eine klare Trennung der Anliegen zu schaffen.




Network Layer

Das Netzwerk wird von den Modulen des Network Layers verwaltet, der als reines P2P-Overlay-Netzwerk charakterisiert werden kann, was bedeutet, dass es sich um ein System handelt, das auf einem anderen Netzwerk (z.B. dem Internet) läuft und in dem alle Nodes die gleichen Rollen haben und die gleichen Aktionen durchführen (im Gegensatz zu Client-Server-Systemen). Der Network Layer von GoShimmer besteht aus drei grundlegenden Modulen: dem Peer Discovery Modul (das eine Liste von Nodes bereitstellt, die das Netzwerk aktiv nutzen), und dem Neighbour Selection Modul (auch bekannt als Autopeering), das die Peers auswählt. Schließlich verwaltet die P2P-Kommunikation die Nachbarn einer Node, die entweder über Autopeering oder manuelles Peering ausgewählt werden.


Communication Layer

Der Communication Layer befasst sich mit den Informationen, die über den Network Layer weitergegeben werden und die in Objekten enthalten sind, die Messages genannt werden. Dieser Layer bildet ein DAG mit Messages als Scheitelpunkte, das Tangle genannt wird. Der Tangle ist eine replizierte, gemeinsam genutzte und verteilte Datenstruktur, die durch eine Kombination aus deterministischen Regeln, Kooperation und (entweder direkter oder virtueller) Abstimmung via OTVFPCS und auf der Zustimmungsgewicht basierende Finalität entsteht.  Da die Nodes über endliche Kapazitäten verfügen, ist die Anzahl der Messages, die das Netzwerk verarbeiten kann, begrenzt. Daher kann das Netzwerk überlastet werden, entweder einfach aufgrund von ehrlicher starker Nutzung oder aufgrund von böswilligen (Spam-)Angriffen. Um das Netzwerk davor zu schützen, dass es zum Stillstand kommt oder sogar inkonsistent wird, kontrollieren die Module zur Rate control (derzeit ein statischer PoW) und zur congestion control, wann und wie viele Messages per Gossip-Protokoll weitergegeben werden können.


(Decentralized) Application Layer

Über dem Communication Layer befindet sich der Application Layer. Jeder kann Anwendungen entwickeln, die auf diesem Layer laufen, und die Nodes können wählen, welche Anwendungen sie ausführen wollen. Natürlich können diese Anwendungen auch voneinander abhängig sein. Es gibt mehrere Kernanwendungen, die von allen Nodes ausgeführt werden müssen, wie z. B. die Wertübertragungsanwendungen, die den Ledger-State (einschließlich fortgeschrittener Ausgabetypen) aufrechterhalten, und eine knappe Ressource namens Mana, die als Sybil-Schutzmechanismus dient. Zusätzlich müssen auf allen Nodes die sogenannten Konsensanwendungen laufen, die die Timestamps in den Messages regulieren und Konflikte auflösen. Der in GoShimmer implementierte Konsensmechanismus ist führerlos und besteht aus den folgenden Komponenten:

  • On Tangle Voting (OTV): Das On Tangle Voting nutzt die zugrunde liegende Datenstruktur selbst als Abstimmungsmechanismus. Jede Message, die von einem Node ausgegeben wird, enthält bereits die Meinung dieser Node, da sie bestimmte Gelder ausgibt, die zu einer bestimmten Realität gehören (s.a. Parallel reality ledger state), zudem genehmigt die Node auch 2 oder mehr andere Messages im Tangle, die ebenfalls zu einer bestimmten Realität gehören. Die Meinung der ausstellenden Nodes ist also bereits bekannt, ohne sie fragen zu müssen.
  • On Tangle Voting mit FPCS (Fast Probabilistic Consensus on a Set): Das ist ein Mechanismus zum Brechen der Metastabilität, welcher zusätzlich zu OTV (On Tangle Voting) angewendet werden kann. Generell ist in IOTA2.0 das Erreichen einer hohen Zustimmungsgewichtung (Approval Weight) das Finalitätskriterium, wenn die Zustimmungsgewichtung hoch genug ist, wird die Message/Transaktion finalisiert. Mit OTVFPC wird die initiale Meinung mit OTV erstellt, wenn nach einiger Zeit die Meinungen der Nodes immer noch gespalten sind, aus welchem Grund auch immer, wird FPC aktiviert, um diesen metastabilen Zustand zu brechen. Die Endgültigkeit von Wert-Transaktionen sollte so schneller erreicht werden.
  • Approval Weight funktioniert ähnlich wie die Regel der längsten Kette im Nakamoto-Konsens (d.h. heaviest branch, dt. schwerster Zweig) für Zweige und Messages Finalität bietet.


Der Lebenszyklus einer Message (Transaktion)

Quelle dieses Textes ist IOTAPrices.com, eine gute Übersicht über die aktuellen IOTA-Preise an den verschiedenen Börsen.


1) Ein Benutzer oder ein Gerät fordert eine Node auf, eine Message zu erstellen, die eine Wertübertragung enthält. Das Gerät führt die Node-Software selbst aus oder stellt eine Verbindung zu Nodes von Drittanbietern her. Beachten Sie, dass die folgenden drei Schritte nur für neue Messages gelten. Nodes, die Gossip (dt. Klatsch und Tratsch) empfangen, springen direkt zu Schritt 5.

2) Die empfangenden Nodes erhalten so viel Access-Mana wie der übertragene Wert (falls vorhanden) und verlieren den gleichen Betrag an Consensus-Mana. Dieser Betrag wird dann dem in der Payload angegebenen Node zugewiesen, der das Consensus-Mana erhält. Diese Empfänger sind oft ein und derselbe, so dass das Nettoergebnis ein Gewinn an Access-Mana wäre.

3) Eine ordnungsgemäße Ratenkontrolle erfordert, dass entweder der Benutzer oder die Node einen Adaptive Proof-of-Work (APoW) durchführen. Der Arbeitsaufwand steigt mit der Message-Geschwindigkeit der Node (die Rate, mit der neue Messages ausgegeben werden), ist aber verschwindend gering im Vergleich zu der von Bitcoin. IOTA verwendet APoW nur zur Ratenkontrolle, während Bitcoin auf PoW zurückgreift, um einen Konsens zu erreichen.

4) Der Node wählt einige Tips aus und fährt fort, die Message zu signieren. Tips sind kürzlich empfangene Messages, die von der Node noch nicht referenziert wurden. Jede Node unterhält einen Pool von Tips, die ihm gefallen (was bedeutet, dass in seiner Historie keine Konflikte gefunden wurden), und der Algorithmus zur Auswahl der Tips wählt zufällig 2-8 davon aus.

5) Wenn unsere Message eine unvollständige Historie hat, werden die fehlenden Messages von den Peers während des Verfestigung -Prozesses (engl solidification-process) angefordert.

6) Die Überlastungskontrolle (engl Congestion Control) plant die Message für das Gossiping und die Hinzufügung zum Ledger (die lokale Wahrnehmung des Tangle DAG durch die Node). Je mehr Access-Mana eine Node besitzt, desto mehr Netzwerkressourcen erhält sie - wobei alle Messages nach kurzer Zeit an die Reihe kommen. Gossip, der von Nodes empfangen wird, die ihre erlaubte Rate überschreiten, beeinträchtigt den Durchsatz ebenfalls nicht - so wird ein konsistenter, sicherer und fairer Service garantiert.

7) Bestimmte Arten von Payloads werden besonders behandelt - Wertübertragungen sind ein gutes Beispiel dafür - aber alle Messages werden ge-gossiped (dt. geklatscht) und der Tangle DAG hinzugefügt. Das bedeutet, dass die Nodes nicht nur eine Message-Datenstruktur verfolgen, sondern, da die Transaktionen voneinander abhängig sind, auch eine UTXO-DAG (geformt durch Payloads).

8) Der Wertetransfer wird auf Gültigkeit geprüft, aber Konflikte werden nicht sofort gelöst. Sie werden stattdessen in einer dritten Datenstruktur verfolgt. Die Branch-DAG speichert kausale Beziehungen zwischen widersprüchlichen Branches (dt. Zweig) - zwei unterschiedliche Realitäten. Das bedeutet, dass mehrere Versionen des Ledger-State vorübergehend nebeneinander bestehen können. Es werden neue Branches generiert, die widersprüchliche Outputs mit denjenigen verbinden, die sie ausgeben, und jede Message wird mit dem Ergebnis gekennzeichnet, von dem sie abhängt. Sobald alle Konflikte der Vergangenheit gelöst sind, bleibt ein Branch übrig.

9) Beide Ergebnisse werden dem OTFPC zur Abstimmung vorgelegt, der das approval weight (dt. Zustimmungsgewicht) von Konflikten überwacht, sobald neue Messages (Meinungen) eintreffen. Diese Gewichtung spiegelt die kombinierte Stimmkraft der neueren Messages wider, die unsere genehmigen. Es ist der Anteil des aktiven Consensus-Mana im Future-Cone (der ausstellenden Nodes). Der Branch, der seine(n) Rivalen um 50 Punkte überwiegt, gewinnt. Die Finalität ist probabilistisch. Eine Transaktion gilt als bestätigt, wenn ihr Gewicht einen bestimmten Schwellenwert (z. B. 50 %) überschreitet.

10) Der verteilte Zufallszahlengenerator (dRNG) fügt dem OTFPC-Prozess ein gewisses Maß an Unvorhersehbarkeit hinzu - er dient als Metastabilitätsunterbrecher. Der dRNG von IOTA wird von einem Drand-Komitee bereitgestellt, das aus High Consensus-Mana Nodes besteht.