Protokolldetails – IOTA 1.5 Chrysalis

Unterstützung  für ein neues Signaturschema: Das alte IOTA-Protokoll basierte noch auf dem Winternitz One-Time Signature (W-OTS) Schema, einem Hash-basierten Signaturschema, das die ternäre 243-Trit-Hash-Funktion Kerl verwendet. Dieses Signaturschema ist nachweislich resistent gegen einen ausreichend leistungsfähigen Quantencomputer, auf dem der Shor-Algorithmus läuft. Allerdings hat es im Gegensatz zu herkömmlichen ECDSA- oder EdDSA-Signaturen auch erhebliche Nachteile.

Zustandsabhängigkeit: W-OTS erlaubt nur einen einzigen sicheren Signiervorgang. Ab der zweiten Signatur sind so viele Informationen offengelegt, dass der private Schlüssel und damit das Geld auf dieser Adresse als unsicher gilt. Dies stellt ein ernsthaftes Sicherheitsrisiko dar, da das Signieren einer einzigen ungültigen Transaktion als ebenso gefährlich angesehen werden muss wie die Offenlegung des privaten Schlüssels selbst.

Größe: Die erzeugten Signaturen sind recht groß. In IOTA werden 2187 bis 6561 Trytes oder 1300 bis 3900 Bytes (je nach gewählter Sicherheitsstufe) für die Signatur reserviert.

Geschwindigkeit: Sie basiert auf der Hash-Funktion Keccak-384 und wurde entwickelt, um einen Kompromiss zwischen Größe und Geschwindigkeit zu erreichen. So muss die Hashing-Funktion in der Standardeinstellung 702 Mal ausgeführt werden, um eine Signatur zu validieren, was selbst auf leistungsfähiger Hardware zu erheblichem System-Overhead führen kann.

Mit Chrysalis wird das neue gebräuchliche Signaturschema Ed25519 eingeführt, welches das alte W-OTS Schema vollständig ersetzt. Das Ed25519 ist ein modernes EdDSA-Signaturschema, das SHA-512 und Curve25519 verwendet, es reduziert drastisch die Transaktionsgröße und ermöglicht folglich eine deutliche Erhöhung der möglichen messages per second (mps). Ein weiterer Vorteil ist die Wiederverwendbarkeit von Adressen, wodurch sich die Benutzerfreundlichkeit deutlich erhöht und auch die Implementierung der IOTA Technologie in Apps, Börsen oder anderen Systemen erheblich vereinfacht. Ein Nachteil ist allerdings, dass es weniger quanten-robust ist, dieses Problem haben derzeit aber die meisten herkömmlichen Verschlüsselungssysteme. Derzeit wird bereits weltweit an geeigneten neuen Signaturschemen geforscht und sobald es eine praktikable Lösung gibt, kann diese von IOTA einfach übernommen werden.

Atomic Transactions: IOTA 1.0 verwendete das Konzept der Bundles zur Erstellung von Transfers. Bundles sind eine Reihe von Transaktionen, die über ihre Stamm-Referenz (Trunk) miteinander verbunden sind. Diese Transaktionen haben ein festes Layout und eine feste Größe unabhängig von ihrem “Inhalt”. Eine Signatur mit Security Level 1 würde zwar auch in nur eine Transaktion passen, aber per default werden Security Level 2 Signaturen verwendet. Da die Level 2 Signatur von Wert-Transaktionen aber nicht in eine einzelne Transaktion passt, müssen mindestens 3 Transaktionen verwendet werden, um eine einfache Übertragung zu erstellen: 2 Transaktionen für die Eingabe + ihre Signatur und 1 Transaktion (ohne Signatur). Mit einem weiteren Nachteil von Bundles haben vor allem die Entwickler zu kämpfen, denn es ist viel komplizierter, alle Transaktionen von einem Bundle zu bekommen und diese richtig zu ordnen, anstatt nur eine einzelne Message zu verarbeiten.

Mit dem Update auf IOTA 1.5 wurde das alte Bundle-Konstrukt entfernt, stattdessen wurden die einfacheren Atomic-Transactions eingeführt. Dieser Wechsel bringt folgende Vorteile mit sich:

Weniger Netzwerk-Overhead: Das Transaktions-Format kann so angepasst werden, dass nur die wirklich benötigten Informationen übertragen werden. Auf viele unnötige Informationen, wie für die aufeinanderfolgenden Transaktionen eines Bundle (2. Signaturtransaktion) kann verzichtet werden. Der Einsatz des UTXO Modells würde diese Situation noch verschlimmern und noch mehr Transaktionen verwenden, um eine einfache Übertragung zu erstellen.

Weniger Signaturüberprüfungen: Nach dem Coordicide muss jede Transaktion die Node-ID und die Signatur der Node enthalten, welche die Transaktion ausgestellt hat. Das bedeutet, dass für eine einfache Übertragung die Signaturen von mindestens 3 Transaktionen überprüft werden müssen. Die Signaturüberprüfung ist der aufwendigste Teil der Transaktionsverarbeitung, dies bedeutet, dass die Einführung von Node-IDs die Leistung der Nodes um mindestens 300% reduzieren würde, wenn der ursprüngliche Bundle-Ansatz beibehalten wird (noch mehr bei größeren Bundles). Unter dem Strich werden die Nodes Hunderte, vielleicht sogar Tausende von Transaktionen weniger verarbeiten können, als dies bei Atomic-Transactions (nicht in Bundles aufgeteilt) der Fall wäre.

Besserer Spam-Schutz und Überlastungskontrolle: Die Größe des Bundle ist erst bekannt, wenn die letzte Transaktion eingetroffen ist und geprüft werden kann, ob es sich um ein valides Bundle handelt. Dadurch könnte es passieren, dass eine bestimmte Anzahl von Transaktionen akzeptiert und weitergeleitet wird, um dann später festzustellen, dass die ausgebende Node seine Quote (Ratensteuerung) überschritten hat, und anschließend alle weiteren Transaktionen nicht mehr berücksichtigt. Das bedeutet, dass derzeit Transaktionen geroutet und verarbeitet wurden, die von Anfang an hätten gefiltert werden müssen, wenn bekannt gewesen wäre, dass der ausgebende Node versucht, einen zu großen Transfer zu senden. Dies könnte sogar einen Angriffsvektor eröffnen, bei dem ein Node verschiedene Bundles an verschiedene Nodes ausgibt, die alle anfangen, die Transaktionen des Bundles zu verarbeiten und sie dann zu verschiedenen Zeiten wieder fallen zu lassen, wodurch die Last im Netzwerk unnötig erhöht wird.

Kürzere Merkle-Proofs (für Sharding): Die Merkle-Proofs für Inter-Shard-Transaktionen werden viel kürzer (mindestens 300%), wenn nicht alle Transaktionen in einem Bundle durchlaufen werden müssen, um zum nächsten Transfer zu gelangen. Dadurch werden die Inter-Shard-Transaktionen viel schneller und leichtgewichtiger.

Entwickler-freundlich: Einzelne Messages lassen sich viel einfacher verarbeiten.

Schlussfolgerung: Atomic-Transactions sind viel schneller, flexibler (variable Transaktionsgröße) und belasten das Netzwerk weniger, zudem sind sie für das später Sharding/Slicing besser geeignet als Bundles.

Umstellung auf das UTXO-Modell: Die Implementierung des neuen Ledger-State (dt. Kassenbuchstatus) ist eines der letzten Sprungbretter zu einem voll funktionsfähigen Prototyp des Tangle ohne Koordinator, daher soll es mit dem UTXO-Modell sofort und auf die richtige Art implementiert werden. UTXO steht für “unspent transaction output”, was einfach bedeutet, dass man nicht nur die Guthaben auf der Adresse im Auge behält, sondern auch den Überblick darüber behält, woher die Guthaben stammen und wohin sie versendet werden, wenn sie ausgegeben werden. Jeder Token ist eindeutig identifizierbar und jede Ausgabe benennt genau den Token, die sie bewegen möchten.

Das Modell der “nicht verbrauchten Transaktionsausgaben (UTXO)” definiert einen Ledger-Zustand, bei dem die Salden nicht direkt mit Adressen, sondern mit den Ausgaben von Transaktionen verbunden sind. In diesem Modell geben Transaktionen die Ausgaben früherer Transaktionen als Eingaben an, die verbraucht werden, um neue Ausgaben zu erzeugen. Eine Transaktion muss die Gesamtheit der angegebenen Eingaben verbrauchen.

Das alte Modell: IOTA 1.0 verwendete  ein Guthabenmodell zur Verfolgung von Adressen, bei dem jeder Adresse lediglich ein einziger Wert zugeordnet war (der aktuelle Guthabenstand). Der Ledger-State kann daher als ein einfaches Verzeichnis von Adressen und ihren entsprechenden Guthaben betrachtet werden:

Adresse1 = Guthaben1

Adresse2 = Guthaben2

Adresse3 = Guthaben3 

Probleme: Bei Konflikten wie double-spends (dt.doppelte Ausgaben) ist es schwierig herauszufinden, bei welcher von mehreren Transaktionen tatsächlich eine doppelte Ausgabe erfolgt und bei welcher Transaktion legitime Gelder verwendet werden. Dies schränkt die Möglichkeiten, Konflikte effizient zu lösen, massiv ein und erhöht die Größe der Konfliktsätze”. Siehe Beispiel im untenstehenden Bild:

Bild: Bei welcher dieser drei Transaktionen handelt es sich um double spending?
Bei einem Guthabenmodell ist dies unklar, daher müssten alle 3 als double spending betrachtet werden.

Bei IOTA 1.0 war dies kein Problem, da die Regel “heaviest subtangle wins” nur sicherstellen muss, dass die Adressen eines bestimmten subtangle niemals negativ wird.

Mit der neuen auf Abstimmungen (voting) basierenden Coordicid-Lösungen ist es notwendig, die auftretenden Konflikte bei Transaktionen so schnell und so genau wie möglich zu identifizieren, um über sie abstimmen zu können. Dadurch würde die Anzahl der Stimmabgaben, die ausgetauscht werden müssen, massiv reduziert.

Ein weiteres Problem bei der Verwendung eines Guthabenmodells hängt mit den reattachments (Transaktion wieder anfügen) zusammen. Wenn jemand jemals Gelder für eine Adresse erhält, von der bereits Ausgaben getätigt wurden, kann jeder einfach die vorherigen Ausgaben wieder anfügen und die Adresse erneut leeren (auch ohne Zugriff auf den privaten Schlüssel der Adresse). Dies wurde bereits als “Angriffsvektor” benutzt, wenn Benutzer den Ratschlag, Adressen nur einmal zu verwenden, nicht befolgt haben.

Die Lösung: Bei der Verwendung des UTXO-Modell, um die Guthaben zu verfolgen, würde jede Adresse 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 wäre daher eindeutig identifizierbar und jede Ausgabe würde genau den Token benennen, die sie bewegen möchten. Dies würde helfen, Konflikte zu erkennen und auch böswillige Akteure davon abhalten, neu erhaltene Gelder auszugeben, indem sie eine alte Transaktion wieder anfügen. Siehe Beispiel im untenstehenden Bild:

Bild: Bei einem UTXO-Modell identifiziert jede getätigte Ausgabe eindeutig, welche Gelder ausgegeben wurden.
Auf diese Weise kann direkt festgestellt werden, welche Transaktionen widersprüchlich sind (die gelben Gelder werden zweimal verwendet).

Die Verwendung eines UTXO-basierten Modells bietet mehrere Vorteile:

• Parallele Validierung von Transaktionen.
• Einfachere Erkennung von Doppelausgaben, da widersprüchliche Transaktionen auf dieselbe UTXO verweisen würden. Das bedeutet eine schnellere und genauere Konfliktbehandlung, dementsprechend wird die Belastbarkeit sowie die Sicherheit des Protokolls verbessert.   
• Wiederholungsschutz, der wichtig ist, wenn man wiederverwendbare Adressen hat. Die Wiederholung der gleichen Transaktion würde sich als bereits angewandt oder vorhanden manifestieren und somit keine Auswirkungen haben.
• DasUTXO-Modell ermöglicht auch, auf einfache Weise Features wie “DigitalAssets” zu implementieren, bei denen Benutzer IOTA-Token so markieren können, dass sie eine vorher festgelegt “Bedeutung” haben (und behalten). Wenn man bedenkt, dass 99% der bestehenden smart contracts versuchen, einfach “Token” zu erstellen, die sich auf einen bestimmten Anwendungsfall beziehen, ist dies ein interessantes Feature, welches einen großen Mehrwert für das IOTA-Ökosystem darstellt.

Technisch gesehen können Salden nicht mehr mit Adressen verknüpft werden, was den Abstraktionsgrad erhöht und somit andere Arten von Ausgaben ermöglicht. Betrachten Sie z. B. einen Ausgabetyp, der den Saldo angibt, der von einer Transaktion entsperrt werden soll, die eine Proof-of-Work-Schwierigkeit erfüllen oder einige andere Entsperrkriterien liefern muss, usw.

Innerhalb einer Transaktion, die UTXOs verwendet, bilden Eingänge und Ausgänge die zu signierenden Daten der Transaktion. Der Abschnitt, der die Eingänge entsperrt, wird Unlock-Block genannt. Ein Unlock-Block kann eine Signatur enthalten, die das Eigentum an der Adresse eines bestimmten Eingangs nachweist, und/oder andere Unlock-Kriterien.

Das folgende Bild zeigt den Geldfluss mit UTXO:

Auto-Peering: In Peer-to-Peer-Netzwerken wie IOTA sind die Nachbarn einer Node die einzige Informationsquelle. Ein Peering-Mechanismus muss sich daher auf eine gesunde Anzahl ehrlicher Nachbarn konzentrieren, daher auf Nodes, die nicht versuchen, das Netzwerk zu schädigen.Bei IOTAs Auto-Peering-Mechanismus hat jede Node seine eigenen Kriterien für die Auswahl potenzieller Nachbarn. Ein Angreifer kann die Entscheidungen eines Nodes im Peer-Auswahlprozess nicht beeinflussen. Daher ist die bestimmte „Ansicht“ eines Nodes über das Netzwerk sowohl lokal als auch unvorhersehbar. Dies dient dem Schutz vor Angriffen von außen (z. B. Eclipse-Angriffen) und macht es Angreifern praktisch unmöglich, bestimmte Nodes im Peering-Prozess anzugreifen, während sichergestellt wird, dass die Nodes immer mindestens eine bestimmte Anzahl ehrlicher Nachbarn haben.

Der White-Flag Ansatz zur Berechnung der Guthaben ist ein einfacherer, konfliktvermeidender Ansatz (nur IOTA 1.5)), der die Geschwindigkeit und Effizienz der Tip-Auswahl verbessert, bestimmte Angriffe (z. B. Konflikt-Spam) eliminiert und die Notwendigkeit von reattachments (neu anhängen) deutlich reduziert. Die Bereitstellung von Koordinator-Meilensteinen ist ein mächtiges Werkzeug, es liefert globale und unveränderliche Zeitstempel. Auf diese Weise wird eine genau definierte und global akzeptierte Methode angeben, um den Ledger-Status eines Meilensteins zu berechnen, selbst wenn er widersprüchliche Transaktionen in seiner Vergangenheit enthält.

Vorteile des neuen Ansatzes: 

• Die Komplexität der Bilanzberechnung entspricht der Komplexität der Sortierung aller neuen Transaktionen nach Hash (oder ähnlichem), was sehr effizient durchgeführt werden kann.
• Ein Konflikt hat keine anderen Auswirkungen auf das System als jede andere Transaktion. Somit ist der Konflikt-Spam-Angriff vollständig beseitigt.
• Das erneute Anhängen ist einfach: Wenn zwei erneute Anhänge durch Meilensteine genehmigt werden, wird das zweite ignoriert.
• Da Konflikte bei der Bilanzberechnung ignoriert werden, müssen sie bei der Auswahl der Spitzen der Knoten nicht berücksichtigt werden. Dies ermöglicht viel einfachere Algorithmen zur Auswahl von Spitzen und beschleunigt diesen Schritt erheblich.
• Wenn Sie diesen Ansatz in Kombination mit einer geeigneten TSA verwenden, muss bei regelmäßiger Verwendung keine ehrliche Transaktion jemals erneut angehängt werden.

Aufgrund des White-Flag-Bestätigungsalgorithmus ist es nicht mehr notwendig, eine komplexe Tip-Auswahl wie den “random walk” durchzuführen. Daher kann ein einfacherer, leistungsfähigerer Algorithmus zur Auswahl von Tips verwendet werden, was wiederum den gesamten Nachrichtendurchsatz erhöht. Die neue URTS-Tip-Auswahl in der Node-Software, dieser ist deutlich schneller und effizienter als der alte Ansatz bei IOTA 1.0.

Der Algorithmus zur Tip-Auswahl ist das Verfahren, nach dem Transaktionen zur Genehmigung ausgewählt werden. Ein guter Algorithmus ermöglicht es, dass das Tangle auf eine stabile und sichere Weise wächst. 

Um eine neue Transaktion an das Tangle anzuhängen, kann der Algorithmus bis zu acht vorherige Transaktionen auswählen und genehmigen – vorzugsweise Tips. Dieser Genehmigungsmechanismus repräsentiert den “Glauben” an das Tangle: Wenn Transaktion y die Transaktion x genehmigt, bedeutet dies, dass y glaubt, dass Transaktion x gültig ist und dass auch ihre gesamte Historie gültig ist.

In der Vergangenheit wurde als Algorithmus für die Tip-Auswahl der “random walk” (Zufallsweg) verwendet. Dieser war zwar für die Konsensbildung unerlässlich, brachte aber auch einige unerwünschte Eigenschaften mit sich:

• Ehrliche Transaktionen konnten verweisen, wenn sie nicht genügend Gewichtung hatten. Dies führte zu einem erhöhten Bedarf an Promotionen und Reattachments (auch ohne Angriffe), was wiederum die Zuverlässigkeit der Transaktionen deutlich beeinträchtigte.
• Angreifer haben mit dem “random walk” gespielt und bösartige Strukturen wie parasitäre Chains erschafft, damit wurde Splitting-Angriffe durchgeführt, um das Netzwerk daran zu hindern, einen Konsens zu erzielen.
• Die Berechnung der kumulierten Gewichtungen von Transaktionen ist relativ teuer und stellt ein Problem für die Skalierbarkeit des Protokolls dar, insbesondere in Hochdurchsatzszenarien.

Durch das Hinzufügen einer Abstimmungsebene zur Identifizierung des bevorzugten Teils des Tangle (als zusätzliches Modul) ergeben sich folgende Vorteile:

• Schnellere Konfliktlösung und damit geringere Wahrscheinlichkeit, dass eine Transaktion versehentlich an den falschen Teil des Tangle angehängt wird.
• Verwenden von verschiedene Mechanismen zur Tip-Auswahl, die nicht mehr auf der kumulativen Gewichtung basieren und eine geringere Chance haben, gültige Transaktionen zurückzulassen.

Ein neuer Meilenstein-Auswahlalgorithmus für den Koordinator (nur IOTA 1.X), der darauf abzielt, dass das Netzwerk so viel CTPS wie möglich unterstützt. 

Mit einer höheren Recheneffizienz wählt der Koordinator für den Meilstenstein nun intelligent Tips aus, um möglichst alle Messages so schnell wie möglich zu bestätigen.

Der Koordinator erzeugt etwa alle 10 Sekunden einen Meilenstein, welcher wie jede andere Message auch mindestens zwei Tips referenzieren sollte (es gibt spezielle Fälle in denen nur ein Tip vorhanden ist, dann wird nur dieser genommen). Tips sind die Messages im Tangle, die noch nicht von anderen Messages referenziert wurden (Grau im Bild1). 

Der alte Random Walk Algorithmus hat nur zufällige Tips ausgewählt. Der neue Algorithmus wählt zunächst auch  zufällige Tips aus, überprüft sie dann aber, um Tips zu nutzen, die möglichst viele andere Messages referenzieren.

Bild2: Ein Tip, der nur wenige von den neuen Messages referenziert 

Bild3: Ein Tip, der von mehreren neuen Messages referenziert wird

Umstellung auf eine interne binäre Darstellung der ternären Transaktion. Dies ermöglicht es binäre Daten (1,0) für Validierung  und andere Verarbeitungen zu verwenden, ohne dass viele binär-ternäre Konvertierungen wie in der alten IOTA 1.0 Node-Software erforderlich sind. Dies sollte zu weiteren Leistungsverbesserungen führen.

Technische Details: Im IOTA 1.0 Mainnet besteht eine Transaktion aus 2.673 tryte-kodierten Zeichen und setzt sich aus verschiedenen Feldern unterschiedlicher Tryte-Längen zusammen.

Wichtig ist, dass bei der derzeit verwendeten Kerl-Hash-Funktion ein Hash (und damit auch eine Adresse) naturgemäß nicht aus 243 Trits, sondern aus 48 Bytes besteht. Das bedeutet, dass für jede Adresse oder jeden Hash die 48-Byte-Darstellung absolut äquivalent zu der derzeit verwendeten 243-Trits-Darstellung ist, die nur das Ergebnis einer zusätzlichen Konvertierung zur Basis 3 ist.

Das alte ternäre Transaktionslayout bestand aus den folgenden Typen:

• Integers (dt. ganze Zahlen) > Ganze Zahlen sind einfachl in binärer Form zu kodieren.
• Hashes (hash (Curl), Adresse (Kerl), bundle (Kerl)
• Signature-Nachrichten-Fragment

Ternäre Zeichenketten werden zukünftig kodiert als

• 1 byte per tryte (3 trits),
• 1 byte per 5 trits or
• native 48 bytes for Kerl Hashes.

Quellen

https://blog.iota.org/chrysalis-b9906ec9d2de
https://github.com/iotaledger/protocol-rfcs/blob/ee07797acb5940b7dbb5c3411b184ccdc6afdbb1/text/0000-ed25519-signature-scheme/0000-ed25519-signature-scheme.md
https://iota.cafe/t/atomic-transfers-transactions-instead-of-bundles/318
https://iota.cafe/t/switching-to-utxo-model-for-balances-colored-coins-easier-conflict-resolution/229
https://iota.cafe/t/binary-transaction-layout/324
https://github.com/luca-moser/protocol-rfcs/blob/signed-tx-payload/text/0000-transaction-payload/0000-transaction-payload.md