IOTA Teil 1

"Blockchain Bottleneck"

 Bevor wir uns mit der Funktionsweise von Iota beschäftigen, werden wir erstmal darauf eingehen, welche Vorteile Iota dank des DAG als Ledger denn im Vergleich zu den normalen DLT Kryptowährungen  deren Ledger eine Blockchain ist bietet. Bei einer Blockchain gibt es das große Problem, dass eine Blockchain zwar super funktioniert (skaliert), wenn nur relativ wenige Transaktionen pro Zeit aufgegeben werden, aber, dass sobald die Anzahl an Transaktionen steigt, immer schlechter skaliert wird. Das heißt grob gesagt, dass Blockchainbasierte Projekte nicht für Anwendungsbereiche mit extrem vielen Transaktionen(pro Zeit) geeignet sind.
 Das liegt daran, dass die Blockchain nur alle x-Zeiteinheiten einen Block in die Blockchain aufnimmt (Stichwort Schwellenwert und Block-ID). Bei Bitcoin wird die durchschnittliche Zeit zur Annahme eines neuen Blocks durch Veränderung (Senkung) des Schwellenwertes (erhöhen der Difficulty) auf circa 10 Minuten gehalten. Da ein Block nicht unendlich viele Transaktionen enthalten kann, entsteht hier ein Flaschenhals. Außerdem ist diese Durchschnittszeit zur Blockannahme auch gleichzeitig der Grund für die lange Bestätigungszeit einer Transaktion. Die Durchschnittliche Bestätigungszeit einer Bitcoin Transaktion liegt zwar nicht bei 10 Minuten jedoch kann sie durchaus (über) 10 Minuten betragen. Für viele Anwendungsfälle ist das zu lange. 

 Der Tangle löst dieses Problem des Flaschenhalses, in dem jede Transaktion um valide zu sein zwei weitere Transaktionen bestätigen muss. Die einzelnen Transaktionen im Tangle, die sich gegenseitig bestätigen verbinden sich, wodurch der Tangle nicht als Kette wächst und somit parallel mehrere Transaktionen (gleichzeitig) bestätigt werden können. Sprich umso mehr Transaktionen im Tangle getätigt werden, umso mehr Transaktionen werden auch bestätigt, wodurch Iota bei steigender Nutzung besser skaliert.
 Bei Bitcoin (und anderen Blockchain-basierten Projekten) bleibt die „Bestätigungsrate“ von Transaktionen immer gleich und ändert sich auch bei steigendem Traffic nicht. Die Blockchain stellt hier per Definition immer einen Flaschenhals dar, da die Blöcke, deren Inhalt an Transaktionen natürlich begrenzt ist, nacheinander aufeinander aufbauen. Es herrscht ständig eine Art „Block Race“, bei der die Blöcke als erstes in die Blockchain kommen wollen und so teilweise Blöcke mit gleichem Transaktionsinhalt um den Platz in der Blockchain konkurrieren. Die Blockchain kann nur aus einer Kette bestehen (bzw nur eine wird als gültig angesehen). Bei der Blockchain kann also nur an einer Stelle bestätigt werden, was die Anzahl an bestätigten Transaktionen pro Zeiteinheit auf einem konstanten Level hält, sodass nur durch die Reduzierung der durchschnittlichen Blockannahmezeit oder/und eine Vergrößerung der max Anzahl an Transaktionen pro Block,  die Zahl der Bestätigten  Transaktionen pro Zeit erhöht werden kann. Und auch dann wird die Blockchain ein Flaschenhals bleiben.
 Bei Iota dagegen steigt die Bestätigung bei steigender Transaktionszahl (pro Zeit) an und es gibt keine Transaktionsgebühren.
 

Der Tangle  

Um den Tangle zu verstehen, klären wir jetzt erstmal den im letzten Artikel erwähnten Begriff DAG (directed acyclic graph) Dafür gehen wir jetzt kurz in den Bereich der Mathematik/Informatik. Ein graph (in der graphentheorie:D) ist eine Ansammlung von Objekten(vertices bzw Knoten) die untereinander verbunden sind (durch edges bzw kanten). Diese Kanten können jetzt gerichtet(directed) oder ungerichtet sein. Dem aufmerksamen Leser wird das Wort „directed“ aufgefallen sein. Wir wollen ja wissen, was ein directed! Acyclic graph ist (DAG). Das wichtige beim directed graph ist, dass die Kanten hier eine Richtung haben. Die Verbindungen zwischen den Knoten sind beim directed graph also gerichtet und können daher gut mit einem Pfeil dargestellt werden.
 Ein directed acyclic graph ist ein endlicher directed graph ohne directed cycles (Knoten die durch Pfeile verbunden sind und einen Kreis ergeben).
 Das bedeutet, dass du in einem directed acyclic graph nicht von einem Knoten starten kannst, den gerichteten Kanten folgen kannst und dann wieder zu dem Knoten kommst, an dem du begonnen hast.
 Ein directed acyclic graph baut sich also immer weiter auf und es entstehen keine „Kreise“.
 Ein Beispiel wäre hier zum Beispiel ein Stammbaum.Die Verbindungen zwischen den einzelnen Familienmitgliedern sind gerichtet (du bist der Sohn deines Vaters und nicht andersrum), der graph baut sich immer weiter auf und es entstehen keine „Kreise“ (außer man ist der Meinung, dass Gott uns alle erschaffen hat und wir wenn wir sterben zu ihm zurückkommen und wiedergeboren werden:D).
 Ein DAG ist also ein directed graph, mit einer topologischen Sortierung.
 Dem Begriff Topologie sind wir schon in meiner Artikelreihe über Bitcoin begegnet, wo wir festgestellt haben, dass die Netzwerktopologie von Bitcoin zufällig ist.
 Topologische Sortierung bezeichnet (in der Mathematik), eine Reihenfolge von Dingen durch die bestimmte Abhängigkeiten erfüllt werden.
 Vereinfacht gesagt bedeutet das, dass „A“ vor „B“ erfüllt werden muss, damit „C“ erfüllt werden kann, woraufhin „D“ erfüllt werden kann. Wenn man zuerst „C“ erfüllen könnte würde man „A“ und „B“ nicht mehr erfüllen können.
 Ein beliebtes Beispiel hierfür ist, wie man sich anzieht. Also erst Unterwäsche, dann Hose, dann Socken und dann Schuhe. Wenn man seine Schuhe vor den Socken anziehen würde könnte man diese nicht mehr anziehen. Man benötigt also eine Reihenfolge, bei der die Bedingung, dass man erst die Socken anziehen muss, bevor man sich die Schuhe anziehen kann erfüllt wird. Diese Reihenfolge nennt man topologische Sortierung der anstehenden Tätigkeiten.
 Kurz zusammengefasst haben wir mit dem Tangle (DAG) also eine neue Art eines Protokolls. Im Gegensatz zu der Blockchain, bei der die Transaktionen in Blöcken zusammengefasst werden (mehrere Transaktionen die zusammen eine Prüfsumme (hashwert) ergeben) und aneinandergereiht eine Linie ergeben (Blockchain) gibt es bei Iota keine „Blöcke“. Und im Register werden die Transaktionen nicht durch referenzieren des vorherigen Datenpakets in einem Strang (einer Linie sprich Chain)  zu einer immer länger werdenden Kette gespeichert.
 Der Name Tangle (zu deutsch „Gewirr“) beschreibt ganz gut den Aufbau des Iota Ledgers. Anstatt wie bei der Blockchain die Transaktionen in „Blöcken“ zusammenzufassen und einen Hahswert aus den zusammengefügten Transaktionen zu berechnen, auf den sich der nachfolgende Block dann referenziert, besteht der Tangle aus einem „Gewirr“ von unabhängigen einzelnen Transaktionen.
 Die einzelnen unabhängigen Transaktionen im Tangle (vertices/Knoten) sind durch mehrere Kanten (edges) miteinander verbunden.
 Mit diesem Wissen kennen wir das grobe Schema, nach dem der Tangle aufgebaut ist und können nun darauf aufbauen.

Transaktionen

Im Iota Netzwerk lassen sich Transaktionen mit dem Wert 0 tätigen. Desweiteren können an die Transaktionen beliebige Daten angehängt werden. Maschinen könnten sich also auch ohne monetären Austausch (0 Iotas) miteinander über das Iota Netzwerk austauschen bzw mit dem Verschicken von Iotas an eine Maschine könnte auch ein Datensatz usw mitgeschickt werden.

Die Iotas kommen bei Iota nicht wie bei zb Bitcoin aus dem Mining (Stichwort Coinbase Transaction) sondern aus der Genesis transaction (die erste Transaktion im Tangle; ihr erinnert euch vielleicht dunkel an den Begriff, den es bei Bitcoin usw auch gibt). Diese Anzahl an Iotas, die in der Genesis transaction festgelegt wurde wird sich nie verändern.

1.(Grundlegende)Bestandteile einer Transaktion

Eine grobe Übersicht über die Bestandteile einer Transaktion. Eine genaue Übersicht steht unten in den Literatur Quellen.

• Input oder Output der Transaktion
• Transaktionswert
• Angehängte Daten
• Zeitstempel (nicht notwendig)
• Der Hash der ersten referenzierten (bestätigten) Transaktion, sowie der der zweiten
• Nonce (PoW für Spam-Schutz)

Die Transaktion wird, bevor sie über das Iota Netzwerk propagiert wird mithilfe des private keys signiert. Damit wird die Transaktionslegitimität geprüft (ob der Initiiant der Transaktion wirklich der Eigentümer dieses Guthabens ist). Dann werden zwei Transaktionen ausgewählt (nach einem bestimmten Algorithmus, den wir später kennenlernen werden). Diese zwei Transaktionen werden dann in deiner Transaktion referenziert (du bestätigst sie und machst deine Transaktion damit gültig). Dann wird ein sehr kurzer PoW ausgeführt, der vor Spam schützen soll und in dem die Nonce berechnet wird.

  Damit eine neue Transaktion in den Tangle kommen kann, muss sie (wie gerade erwähnt) zwei Transaktionen, die sich bereits im Tangle befinden bestätigen. Die neue Transaktion verbindet sich daraufhin durch zwei Stränge (edges) mit den zwei Transaktionen, die sie bestätigen muss. Siehe abbildung
 Wie ausgewählt wird, welche zwei Transaktionen die neue Transaktion bestätigen muss, ist sehr wichtig, damit Iota gut läuft aber auch kompliziert weshalb wir erstmal davon ausgehen, dass zwei zufällig ausgewählte Transaktionen bestätigt werden (in Wirklichkeit gibt es einen Algorithmus, nachdem die Transaktionen ausgewählt werden). In der Abbildung wählen die Transaktionen also nach dem Zufallsprinzip zwei Transaktionen aus, die sie bestätigen. Um zu sehen, wie der Tangle (mit diesem Zufallsprinzip beim bestätigen der Transaktionen) dann bei mehr Transaktionen als im Bild gezeigt sind aussieht, könnt ihr euch hier die Iota visualization anschauen.
 Bei dieser Simulation wird euch auffallen, dass der Tangle jedesmal anders aussieht. Das Aussehen des Tangles ist logischerweise abhängig von der Anzahl der Gesamt Transaktionen und besonders von der Transaction rate. Der Rate mit der neue Transaktionen hinzukommen. Im echten Leben („Alltag“) verläuft eigentlich nichts linear. Auch die Anzahl an Transaktionen die in einem gewissen Zeitraum in den Tangle kommen wird nicht linear sein. Es wird wie in der Abbildung Momente geben, in denen sehr viele Transaktionen auf einmal kommen und dann wieder Pausen. Würde die Anzahl an Transaktionen pro Zeit konstant und klein sein, dann würde auch der Tangle eine Chain bilden: eine Transaktion bestätigt nur eine Transaktion, da neue Transaktionen so langsam kommen, dass es immer nur eine Transaktion zum bestätigen gibt.  (transaction rate in der simulation auf 0,1 stellen dann seht ihr die Chain).
 
 Wenn dagegen (am Anfang) extrem viele Transaktionen aufeinmal kommen, dann haben sie alle nur die Genesis Transaktion zum bestätigen. (die Transaktionen brauchen alle eine gewisse Zeit bis sie durch das komplette Netzwerk propagiert sind und wenn alle Transaktionen gleichzeitig kommen gibt es in der Simulation eben nur die Genesis trx zum bestätigen; extrem hohe transaction rate zu beginn)
 Wie oben beschrieben verhält sich die Anzahl der neuen Transaktionen pro Zeit nicht gleichmäßig sondern mit „Höhen und Tiefen“. Ist beispielsweise beim Stromverbrauch auch so, dass es Tageszeiten gibt, an denen Spitzenlasten benötigt werden und andere Zeiten wo weniger Strom benötigt wird. Auch in der (Iota) Simulation wurde ein Modell verwendet, nachdem die Transaktionen nicht alle gleichmäßig in bestimmten Zeitabständen kommen sondern mit Momenten, an denen es viele Transaktionen aufeinmal gibt und dann wieder eine „gemäßigtere“ Zeit:D 

2. Algorithmus zur Auswahl der Transaktionen

 Wie vorher geschrieben, sind wir bis jetzt davon ausgegangen, dass eine neue Transaktion die zwei Transaktionen die sie bestätigen muss nach dem Zufallsprinzip auswählt. Dies ist natürlich nicht sonderlich effizient, weshalb es bei Iota einen bestimmten Algorithmus gibt, nach dem die zu bestätigenden Transaktionen ausgewählt werden. Um diesen zu verstehen, werden wir jetzt erstmal den sogenannten Random Unweighted Walk kennenlernen. Auch hierfür gibt es wieder eine Simulation von Iota, mit der ihr das ganze visuell austesten könnt. Bei diesem Algorithmus gibt es einen „Walker“, der beginnend bei der Genesis Transaktion die Tips abläuft und bestätigt. In der Simulation ist der Weg, den der Walker gelaufen ist rot markiert und die verschiedenen Wege die er laufen könnte blau. Die wenigen Transaktionen, die für diesen Random walk nicht sichtbar sind, sind grau markiert. Für den Walker sind beim Unweighted Walk alle Transaktionen gleichberechtigt (komplett zufällig, welche Transaktionen ausgewählt werden).
 Doch warum brauchen wir überhaupt einen Algorithmus, nachdem die zu bestätigenden Transaktionen ausgewählt werden? Der Sinn eines solchen Algorithmus ist es, sogenannte lazy tips zu vermeiden. Ein lazy tip ist eine Transaktion, die alte bereits bestätigte Transaktionen bestätigt statt neue, die noch bestätigt werden müssen. Eine solche Transaktion hilft dem Netzwerk nicht, da so keine neuen Transaktionen bestätigt werden.
 In der Abbildung ist Transaktion 14 ein lazy tip, da diese Transaktion zwei schon bestätigte Transaktionen (1 und 3) bestätigt. Der Random unweighted walk ist hierfür keine Lösung.
 Die Lösung, die das Team um Iota sich hierfür ausgedacht hat, heißt weighted random walk (MCMC Algorithmus) und geht folgendermaßen. Diese sogenannten lazy tips, die wir aufgrund dessen, dass sie nicht dazu beitragen neue Transaktionen zu bestätigen, nicht wollen, werden von neuen Transaktionen nicht bestätigt (bzw es ist unwahrscheinlich). Es liegt also im Interesse jeder Transaktion kein lazy tip zu sein. Dies wird mithilfe des cumulative weights umgesetzt. Mit diesem cumulative weight können wir ausdrücken, wie wichtig eine Transaktion ist. Unser Walker läuft dann beim weighted random walk lieber über die wichtigen/schweren Transaktionen, die demzufolge zuerst bestätigt werden. Das weight einer Transaktion wird berechnet, indem man die Menge an approvern (Transaktionen, die die Transaktion deren cumulative weight wir berechnen wollen bestätigen) zählen und eins hinzu zählen. Das Ergebnis ist das cumulative weight der Transaktion. Auch hierfür gibt es wieder eine Simulation von Iota, bei der ihr das cumulative weight und den Lauf des Walkers sehen könnt. Das der Walker erst über eine „schwere“ Transaktion läuft (sie bestätigt wird) ist mit diesem Algorithmus wahrscheinlicher, als das er über eine „leichte Transaktion“/einen lazy tip läuft.   Wie wichtig das cumulative weight beim Lauf des Walkers  ist, hängt vom Parameter  α ab. Umso größer das α wird, umso wahrscheinlicher wird es, dass der Walker beim random weighted walk über die „schweren“ Transaktionen läuft. Wenn wir α dagegen kleiner machen, dann nähert sich der Lauf des Walkers immer mehr dem komplett zufälligen unweighted random walk an. Bei der Wahl des Wertes von  α gilt es also einen Wert zu finden, bei dem lazy tips möglichst vermieden werden, aber auch nicht zuviele Transaktionen unbestätigt bleiben, da bei einem sehr großen  α der Walker nicht mehr „random“ wäre und somit Transaktionen mit einem geringeren cumulative weight nicht mehr bestätigt werden würden, sondern nur noch die „schwersten“ Transaktionen.
 

  Hiermit wurde erreicht, dass es im Interesse jeder Transaktion liegt kein lazy tip zu sein (um bestätigt zu werden). Dies führt dazu, dass es nur wenige lazy tips gibt, wodurch neue Transaktionen vorrangig unbestätigte Transaktionen bestätigen, was der Grund für die bei steigender Nutzung besser werdende Skalierung von Iota ist. 

Bildquellen

• Abbildung 1:habe ich selbst mithilfe von "Paint 3D" erstellt. Bei Verwendung bitte diesen Artikel als Quelle angeben.
• Abbildung 2:habe ich selbst mithilfe von "Paint 3D" erstellt. Bei Verwendung bitte diesen Artikel als Quelle angeben.
• Abbildung 3:https://blog.iota.org/on-the-tangle-white-papers-proofs-airplanes-and-local-modifiers-44683aff8fea
• Abbildung 4:http://tangle.glumb.de/
• Abbildung 5::habe ich selbst mithilfe von "Paint 3D" erstellt. Bei Verwendung bitte diesen Artikel als Quelle angeben.
• Abbildung 6: :habe ich selbst mithilfe von "Paint 3D" erstellt. Bei Verwendung bitte diesen Artikel als Quelle angeben. 
• Abbildung 7:https://blog.iota.org/the-tangle-an-illustrated-introduction-f359b8b2ec80

Literaturquellen

• Genauerer Überblick über die Bestandteile einer Transaktion: https://domschiener.gitbooks.io/iota-guide/content/chapter1/transactions-and-bundles.html
• Artikel von Serguei Popov:https://blog.iota.org/on-the-tangle-white-papers-proofs-airplanes-and-local-modifiers-44683aff8fea
• IotaWhitepaper:https://assets.ctfassets.net/r1dr6vzfxhev/2t4uxvsIqk0EUau6g2sw0g/45eae33637ca92f85dd9f4a3a218e1ec/iota1_4_3.pdf
• Die Artikel Reihe "The Tangle: an illustrated introduction" von Alon Gal: https://medium.com/@alon.gal
• Artikel von Clara Shikhelman: https://blog.iota.org/validity-in-the-tangle-the-good-the-bad-and-the-ugly-98bd3b53408a
• Video zum directed graph:

Artikel zum DAG:https://en.wikipedia.org/wiki/Directed_acyclic_graph

Artikel zur topologischen Sortierung: https://en.wikipedia.org/wiki/Topological_sorting; https://de.wikipedia.org/wiki/Topologische_Sortierung

Graphentheorie:https://de.wikipedia.org/wiki/Graph_(Graphentheorie)#Teilgraphen,_Wege_und_Zyklen

Artikel zu Iota:https://domschiener.gitbooks.io/iota-guide/content/chapter1.html

Artikel von Jakob Löhnertz: https://medium.com/@loehnertz/mit-der-kryptow%C3%A4hrung-iota-in-die-zukunft-der-maschinen%C3%B6konomie-88b96e972030

Erste Iota Simulation: https://public-rdsdavdrpd.now.sh/

Zweite Iota Simulation: https://public-xnmzdqumwy.now.sh/

Dritte Iota Simulation: https://public-qnbiiqwyqj.now.sh/

Das war es auch schon mit dem ersten Teil meiner Iota Artikel Serie. Ich hoffe er hat euch gefallen und konnte euch beim Verständnis von Iota helfen. 

Falls ihr Fragen, Anmerkungen habt oder mir einfach nur Feedback geben wollt, schreibt dies gerne in die Kommentare.