Problem: Bei IOTA würde ohne gespeicherte Transaktionshistorie bis zur Genesis Transaktion ein hypothetischer Inflations-bug nicht auffallen.
Antwort: Selbstverständlich fällt das auf, IOTA ist eine Distributed-Ledger-Technologie und schafft damit eine einzige Quelle der Wahrheit, auf die alle Teilnehmer vertrauen können. Alle Full-Nodes im Netzwerk sind synchronisiert und es besteht Konsens über den Ledger-State (über alle Eintragungen ins Kassenbuch). Jeder Token auf einer Adresse ist eindeutig identifizierbar und jede Ausgabe benennt genau den Token, der bewegt werden soll. Das System muss dazu natürlich bugfrei, sicher und verteilt genug sein, sodass man es sich “leisten” kann nur die relevanten Daten zu verfolgen (den aktuellen Ledger-State) und die Transaktionshistorie nicht mehr aufbewahren muss.
IOTA ist ein Daten und Value-Transferprotokoll und keine dezentrale Datenbank
Die Nodes speichern nicht jede Transaktion, die jemals stattgefunden hat. Genau wie das Internet, speichert auch das IOTA-Protokoll keine Daten oder anders ausgedrückt, der Tangle ist kein Datenspeicher. Das IOTA Protokoll selbst löscht aber nichts, dafür können/müssen IOTA-Nodes so konfiguriert werden, dass sie alte, nicht mehr benötigte Daten löschen, genauso wie dies in Bitcoin auch möglich ist (siehe Pruning Mode von Bitcoin Core 0.11, im Jahr 2014 eingeführt). Trotz einer gelöschten Transaktionshistorie ist aber weiterhin möglich zu beweisen, dass in der Vergangenheit eine bestimmte Message im Tangle bestätigt wurde. Mit dem sogenannten “Proof of Inclusion” (Merkle Proofs) ist IOTA in der Lage zu beweisen, dass eine Transaktion direkt oder indirekt von einer anderen Transaktion referenziert wurde, ohne die gesamte Kette der tatsächlichen Transaktionen bereitstellen zu müssen.
Daten löschen macht das Protokoll aber nicht weniger sicher
Der Grund, warum Bitcoin, Ethereum, IOTA und so ziemlich jede größere Kryptowährung, die es gibt, eine Pruning-Funktion in ihrer Node-Software nutzen, ist die Tatsache, dass es keinen Einfluss auf die Sicherheit hat und die Nodes nicht auf diese alten Daten als Teil ihres Konsensmechanismus zurückgreifen.
Eine IOTA-Node produziert derzeit mehr Daten als eine Bitcoin-Node, also wird es höchstwahrscheinlich mehr Leute geben, die diesen Pruning-Modus aktiviert haben und weniger Leute, die eine vollständige Historie von allem, was jemals passiert ist, aufbewahren. Alle IOTA-Nodes werden die jüngste Transaktionshistorie von mindestens ein paar Wochen oder sogar Monaten speichern, das reicht für hypothetische Bugs vollkommen aus, denn was bringt es, einen Fehler Jahre später zu finden – niemand würde zustimmen, das Bitcoin-Netzwerk auf einen Zustand von z.B. 2017 zurückzusetzen, wenn man in diesem Zeitraum einen Fehler entdecken würde.
Benötigt wird im Wesentlichen eine “Dezentralisierung der Node-Implementierungen”.
Idealerweise erreicht man Resilienz gegen Bugs durch eine Implementierung von unterschiedlicher Node-Software von mehreren Entwickler-Teams. Sollte dann eine Node einen Bug haben, werden nur die Nodes mit derselben Software aus der Synchronisation fallen.
Dies ist einer der Gründe, warum IOTA “Bee”- und “Hornet”-Nodes betreibt, die von völlig unterschiedlichen Teams in völlig unterschiedlichen Programmiersprachen implementiert wurden. Es ist sehr unwahrscheinlich, dass zwei Teams den exakt gleichen Fehler machen, was das Netzwerk resilient gegen Bugs macht.
Werte.- und Datentransaktionen werden grundsätzlich unterschiedlich gehandhabt
Werte-Transaktionen
Der Tangle (DAG) ist die zugrunde liegende Technologie des IOTA-Kommunikationsprotokolls, er ist nur das “Kommunikationsmedium” zwischen den Nodes. In diesem Tangle (IOTA 2.0) verbirgt sich auf einer zweiten Ebene der sogenannte UTXO DAG (Ledger), der über die Historie Buch führt, diese Zahlungshistorie wird über einen viel größeren Zeitraum (Jahre) aufbewahrt als der eigentliche Tangle.
Bei IOTA wird keine Historie alle Transaktionen benötigt, um zu überprüfen, ob irgendwo Token aus dem Nichts (hypothetischer Inflations-bug) hinzugekommen sind. Das limitierte Guthaben ist komplett im Umlauf und allen synchronisierten Nodes bekannt und bevor Nodes IOTA-Token versenden können, müssen sie immer verifizieren, ob die Anzahl an IOTA-Token stimmt, dabei wird jede Änderung des Ledgers von allen synchronisierten Nodes validiert (Konsistenzprüfung des Ledgers), daher ist es sehr einfach, die existierende Gesamtmenge an limitierten IOTA-Token zu überprüfen. Alle Nodes halten eine Liste und prüfen, ob die Anzahl mit jeder Transaktion konsistent bleibt. Es ist unmöglich, die Menge an IOTA-Token zu ändern, ohne bei allen Nodes die Software (Hartkodiert) zu ändern, was ein zwingend zerstörendes Update wäre. Ein solches Update funktioniert natürlich nicht ohne die Unterstützung der gesamten Community und könnte bei Uneinigkeit sogar zu einer Spaltung des Netzwerks führen (erfordert bei IOTA 1.x einen zusätzlichen Koordinator, dem man vertrauen kann).
Zitat Hans Moog, Entwickler, IOTA Foundation: “Wenn mehr als 50% der Nodebetreiber beschließen nach einem Bug ihre Nodes manuell zurückzusetzen, dann geht das theoretisch. Inwiefern das in der Praxis tatsächlich funktioniert kommt wohl darauf an wie schwerwiegend das Problem ist. Als bei Bitcoin durch einen Fehler 184 Milliarden Bitcoins aus dem nichts erschaffen wurden, haben sich jedenfalls alle Miner gemeinsam dazu entschieden das Netzwerk zurückzusetzen. Aber das läuft dann über “social consensus” in der echten Welt und ist nicht Teil des Protokoll”
Nodes die nicht synchronisiert sind, bekommen lediglich eine Fehlermeldung und können nicht am Netzwerk teilnehmen. Wenn ein Full-Node online geht, nachdem sie offline war, muss die Node das Netzwerk abhören und alles herunterladen, um den Status des Ledgers zu sehen, die Node wird sich den Konsens ansehen und dabei auch den Status der hohen Mana-Nodes berücksichtigen. Die Wiederinbetriebnahme einer Node, ist ähnlich wie das Starten einer neuen Node von Grund auf.
Mit dem Abschluss des Chrysalis Update wurde bereits in Vorbereitung auf IOTA 2.0 der neue Ledger-State implementiert (eine erweiterte Version des UTXO-Modells), dieser neue Ledger-State basiert auf dem Prinzip der Parallel-Realität, dadurch entkoppelt sich der Konsens von der Saldenverfolgung. Dies ermöglicht hohe Flexibilität und reduziert die Komplexität der Messages massiv, indem nur über Konflikte abgestimmt wird. Des Weiteren wird es einfacher Guthaben zu verfolgen, jede Adresse wird nicht nur ihr Gesamtguthaben enthalten, sondern auch mehrere Unter-Guthaben, die mit einer Markierung versehen sind, welche anzeigt, durch welche Transaktion die Guthaben entstanden sind. Jeder Token auf einer Adresse ist daher eindeutig identifizierbar und jede Ausgabe würde genau den Token benennen, der bewegt werden soll.
Daten-Transaktionen
Wie bereits beschrieben kann die Historie bei reinen Daten-Transaktionen (0-Value) im Laufe der Zeit verloren gehen, neue Transaktionen werden vom Netzwerk nur verbreitet (nicht validiert), bestätigt und sind direkt notarisiert. Mithilfe der „Notarisierung“ kann bewiesen werden, dass ein elektronisches Dokument in einer bestimmten Form zu einem bestimmten Zeitpunkt existiert hat und seit der Erstellung nicht verändert wurde. Bei der Erstellung einer Notarisierung wird ein eindeutiger Hash (Fingerabdruck) eines Dokumentes berechnet und gemeinsam mit einem Zeitstempel im IOTA-Ledger (Tangle) unveränderbar gespeichert. Falls zu einem späteren Zeitpunkt verifiziert werden soll, dass das betreffende Dokument zum behaupteten Zeitpunkt existiert hat und/oder nicht verändert wurde, werden die Daten aus dem Tangle abgerufen und mit den vorliegenden Informationen verglichen. Auch hier, kann die Transaktion mit “Proof of Inclusion” überprüft werden.
Falls jemand die Historie der Transaktionen dezentral speichern möchte, kann er dafür selbst eine Second-Layer Lösung bauen, eine (Selektiv)Perma-Node betreiben oder dritte für eine Speicherung bezahlen. Für den IOTA Basis-Layer stehen Leistung, Durchsatz und Sicherheit im Vordergrund und nicht der Aufbau einer globalen Datenbank.