Chrysalis - Der Weg zu IOTA 1.5

03. Feb'20

Übersetzung des Blogartikel von Autor David Sønstebø, IOTA Foundation, mit zusätzlichen Erklärungen.

 

Bei der Grundlagenforschung zum Coordicide und der Umsetzung in GoShimmer wurden erhebliche Fortschritte erzielt. Sie haben vielleicht bemerkt, dass einige Coordicide-Module bereits dabei sind, dem IOTA-Mainnet hinzugefügt zu werden, einschließlich Autopeering und Objekt-Speicherung. Wir sind auf dem besten Weg, unser Kernziel eines koordinationsfreien IOTA-Mainnet zu verwirklichen.

Neben Coordicide ist es jedoch das Ziel der IOTA-Stiftung, das IOTA-Mainnet vor dem Coordicide vollständig zu optimieren und eine unternehmenstaugliche Lösung für unser Ökosystem anzubieten. Wir haben daher eine Zwischenaktualisierung mit dem Namen Chrysalis geplant. Dieser Plan wurde erstmals mit unserer Roadmap angekündigt, aber der Umfang wurde inzwischen erweitert. Dieser Beitrag enthält weitere Informationen zu den Auswirkungen dieses Upgrades auf das IOTA-Mainnet.

Eine Chrysalis ist "die Form, die eine Raupe annimmt, bevor sie als voll ausgebildete Motte oder als Schmetterling aus ihrem Kokon hervortritt". Im Kontext von IOTA ist Chrysalis das Zwischenstadium des Mainnet, bevor der Coordicide abgeschlossen ist. Um es klar zu sagen: Chrysalis ist von den Coordicide-Bemühungen getrennt und zielt darauf ab, die Nutzbarkeit des derzeitigen IOTA-Mainnet vor dem Coordicide zu verbessern.

 

 

Warum ist dieser Prozess der Adoption wichtiger Protokollverbesserungen bei IOTA unter den erlaubnislosen DLTs relativ einzigartig? Die einfache Antwort ist die Abwesenheit von Minern. Bei den meisten erlaubnisfreien DLTs stehen die wirtschaftlichen Anreize der Miner in Konflikt mit denen der Nutzer des Netzwerks. Ein besserer Durchsatz und niedrigere Latenzen können den Gebührenmarkt stören, auf den sich die Miner verlassen und daher kann die Zustimmung zur Verbesserung des Netzwerks ihre eigene Rentabilität beeinträchtigen.

Bei IOTA sind die Validierer und Nutzer ein und dieselbe Person. Es gibt keinen hartnäckigen Konflikt der Anreize, was einen viel reibungsloseren Weg zu Verbesserungen des Netzwerks bedeutet. Wir werden dies mit den bevorstehenden inkrementellen Upgrades des Netzes unter Chrysalis demonstrieren.

 


Was sind diese inkrementellen Upgrades?

 

 

  • Ein White-Flag-Ansatz zur Berechnung der Guthaben. Ein einfacherer, konfliktvermeidender Ansatz (gültig für die Zeit vor dem Coordicide), der die Geschwindigkeit und Effizienz der Tip-Auswahl verbessert, bestimmte Angriffe eliminiert und die Notwendigkeit von reattachments deutlich reduziert.

 

 

 

 

  • Neue URTS-Tip-Auswahl in der Node-Software. Deutlich schneller und effizienter als der derzeitige Ansatz.

 

 

  • Unterstützung für ein neues Signaturschema parallel zu WOTS. Das Netzwerk wird daher sowohl quantenresistente Einmal-Signaturen als auch ein gebräuchlicheres Signaturschema ermöglichen, das die Wiederverwendung von privaten Schlüsseln erlaubt. Dies wird die Transaktionsgröße drastisch reduzieren und folglich eine deutliche Erhöhung der TPS ermöglichen. Durch die Einführung eines neuen Signaturschemas werden wir auch wiederverwendbare Adressen ermöglichen, eine sehr beliebte Forderung der Community.

 

Die Winternitz One-Time Signature (w-OTS) wird im aktuelle IOTA-Protokoll (IOTA 1.0) angewendet, es ist ein hashbasiertes Signaturschema, das die ternäre 243-trit Hashfunktion Kerl verwendet. Dieses Signaturschema ist nachweislich resistent gegen einen ausreichend leistungsfähigen Quantencomputer mit dem Shor-Algorithmus. Im Gegensatz zu traditionellen ECDSA- oder EdDSA-Signaturen hat es jedoch auch erhebliche Nachteile. W-OTS erlaubt nur einen einzigen sicheren Signaturprozess. Ab der zweiten Signatur sind so viele Informationen offengelegt worden, dass der private Schlüssel und damit die Gelder auf dieser Adresse als unsicher gelten. Dies stellt ein ernstes Sicherheitsrisiko dar, da das Signieren einer ungültigen Transaktion als ebenso gefährlich angesehen werden muss wie das Offenlegen des privaten Schlüssels selbst.

Die erzeugten Signaturen sind ziemlich groß. In der IOTA sind 2187 bis 6561 Trytes oder 1300 bis 3900 Bytes (je nach gewählter Sicherheitsstufe) für die Signatur reserviert.

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

 

Das Ed25519 Signaturschema ist ein modernes EdDSA-Signaturschema, das SHA-512 und Curve25519 verwendet. Es zielt darauf ab, alle oben genannten Punkte anzusprechen, mit dem Nachteil, dass es weniger quanten-robust ist. Dieses Problem kann jedoch teilweise gemildert werden, wenn es mit einem Commitment-Schema kombiniert wird: Die Adresse wird als Hash des öffentlichen Schlüssels gewählt, der selbst erst während des eigentlichen Signierprozesses offenbart wird. Auf diese Weise kann der Algorithmus von Shor erst angewendet werden, nachdem das signierte Bündel an das Netzwerk ausgegeben wurde, so dass dieses Signaturschema effektiv gegen diesen Angriff immun ist, wenn Adressen nicht wiederverwendet werden.

 

Schlussfolgerung

Die neue hybride Lösung verwendet beide Signaturschemata parallel, die alte Winternitz-OTS und die neue Ed25519, dieser Ansatz erfordert nur minimale Änderungen an bestehenden Konzepten und Arbeitsabläufen, Transaktions-Layout und das Adressformat können vollständig beibehalten werden.

Mit der Implementierung von Chrysalis, kann man wählen, welches Signaturschema man verwenden möchte, dass langsamere aber Quanten-robuste Winternitz-OTS, oder das schnellere und für wiederverwendbare Adressen (engl. Reseuable Adresses) geeignete Ed25519. Um wiederverwendbare Adressen nutzen zu können, müssen die IOTA-Token auf eine neue Adresse (ED25) gesendet werden, falls nicht können die IOTA-Token auf der alten WOTS gelassen werden.

 

 

  • Atomic Transactions. Entfernen Sie sich vom aktuellen Bundle-Konstrukt und verwenden Sie stattdessen einfachere atomic Transaktionen. Dies reduziert den Netzwerk-Overhead und die Belastung bei der Signaturüberprüfung, verbessert den Spam-Schutz sowie die Überlastungskontrolle und verkürzt die Länge der Merkle-Proofs (für künftiges Sharding). Darüber hinaus wird der Implementierungsaufwand reduziert und die Wartbarkeit unserer Core-Node Software wird erhöht.

 

IOTA 1.0 verwendet 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". Da die Signatur von Wert-Transaktionen 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 eine Transaktion für den Rest (ohne Signatur).

 

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 + Rest) kann verzichtet werden. Der Einsatz des UTXO Modells nach dem Coordicide wird 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 des Node enthalten, der 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 wird, 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 atomaren Transaktionen (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. Dadurch könnte es passieren, dass eine bestimmte Anzahl von Transaktionen akzeptiert und weitergeleitet wird, um dann später festzustellen, dass der 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 Personen ausgibt, die alle anfangen, die Transaktionen des Bundles zu verarbeiten und sie dann zu verschiedenen Zeiten wieder fallen 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.

 

Schlussfolgerung

Atomic Transaktionen 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  vom aktuellen Guthaben-Modell auf das UTXO-Modell. Jeder Token auf einer  Adresse ist dann eindeutig identifizierbar und jede Ausgabe benennt genau den  Token, die sie bewegen möchten. Dies ermöglicht eine schnellere und genauere  Konfliktbehandlung und verbessert die Belastbarkeit sowie  die Sicherheit des Protokolls. Darüber hinaus wird die Umstellung auf  UTXO die Verwendung von Tokenized Assets auf IOTA ermöglichen. Zusammen mit Mana (Coordicide) ergibt  dies in naher Zukunft ein sehr attraktives Tokenisierungsmodell und wird  die Adoption des IOTA-Tokens weiter vorantreiben.

 

Die Implementierung des 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.

 

Status Quo

Gegenwärtig verwendet die IOTA ein Guthabenmodell zur Verfolgung von Adressen, bei dem jeder Adresse lediglich ein einziger Wert zugeordnet ist (der aktuelle Guthabenstand). Der Ledger-Status 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 bearbeiten, 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 ist 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).

 

Ein UTXO-Modell würde es auch ermöglichen, auf einfache Weise Features wie "Tokenized Assets" 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.

 

Vorteile UTXO-Modell:

  • schnellere und genauere Konfliktbehandlung (weniger Aufwand für abstimmungsbasierten Konsens)
  • Unterstützung für Tokenized Assets
  • es ist unmöglich, Gelder zu stehlen, indem alte Transaktionen wieder angehängt werden (reattachment)

 

Nachteile UTXO-Modell:

  • Etwas komplexer zu implementieren
  • etwas größere Transaktionen (ein paar Trytes extra), da die Kennung der Token, die bewegt werden, "benannt" werden muss.

 

 

  • Umstellung auf eine interne binäre Darstellung der ternären Transaktion. Dies ermöglicht es uns, binäre Daten für Validierung, 1 / 0 und andere Verarbeitungen zu bearbeiten, ohne dass viele binär-ternäre Konvertierungen wie in der aktuellen Node-Software erforderlich sind. Der Bundle-Hash kann weiterhin als 243 Trits dargestellt werden, sodass das Signaturschema unverändert bleibt und kein Geldtransfer erforderlich ist. Dies sollte zu weiteren Leistungsverbesserungen führen.

 

Mit der Umstellung auf ein binäres System führt dies effektiv zu vielen binär-trinären Konvertierungen, um Transaktionen zu parsen/erstellen. Das Ziel bei dieser Umstellung ist es, dass Transaktionslayout durch eine binäre Struktur zu ersetzen, ohne dass ein Token-Transfer (kennt wann von andern Coins als Swap vom Testnetz zu Mainnet) für bestehende Adressen oder private Schlüssel erforderlich ist.

 

Technische Details

Im aktuellen Mainnet besteht eine Transaktion aus 2.673 tryte-kodierten Zeichen und setzt sich aus verschiedenen Feldern unterschiedlicher Tryte-Längen zusammen (siehe hier).

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 aktuelle ternäre Transaktionslayout besteht 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.

Für Kerl-Hashes (Adressen, Bundle-Hashes, Signaturen) ist die Darstellung als 48 Bytes bei weitem die schnellste und effizienteste, da sie keine aufwendige (und in diesem Fall nutzlose Konvertierung) nach ternär erfordert, dies funktioniert jedoch nur für Kerl.

Das Packen von 5 Trits in ein Byte führt zu einem besseren Kompressionsverhältnis, ist aber auch rechnerisch aufwendiger. Daher ist es die beste Option, 81 Zeichen/Bytes für den Transaktions-Hash zu verwenden, während alle anderen Zeichenkettenfelder als 48 Byte oder 1296 Byte für das Signatur-Fragment dargestellt werden.

Die Bundle-Essenz wird nun analog aus den Transaktionsdaten als binäre Struktur definiert. Die endgültige resultierende Struktur ist ein Vielfaches von 48 Bytes, damit sie der Chunk-Größe von keccak384 (verwendet in Kerl) entspricht. Der Bundle-Hash ist nun definiert als der keccak384 48-Byte-Hash der Bundle-Essenz. Für die tatsächliche Signierung wird dieser 48-Byte-Hash anschließend mit diesem Algorithmus in einen regulären 81-Tryte-Hash umgewandelt. Dieser Hash kann dann mit dem aktuellen W-OTS-Signaturschema signiert werden, wodurch eine 100%ige Kompatibilität mit den aktuellen Adressen und privaten Schlüsseln gewährleistet wird.

 

Schlussfolgerung

Bei dieser Umstellung bleibt das eigentliche Signierungsschema unverändert, daher ist kein Transfer (Swap) von Token/Geldern erforderlich.

 

 

Zuletzt bearbeitet 21.04.2020