29.’Mai’20
Übersetzung des Blogartikel von Autor William Sanders, IOTA Foundation.
Da die Coordicide-Spezifikationen kurz vor der Fertigstellung stehen, hat die Forschungsabteilung die Einzelheiten des neuen Protokolls an die technische Abteilung, externe Forscher und die Community kommuniziert. Diese Kommunikation erfordert eine einfache und einheitliche Terminologie für die neuen Komponenten. Bis vor kurzem haben Forscher, darunter auch ich, jedoch hauptsächlich potenziell verwirrende “in house”- und Ad-hoc-Namen verwendet.
So begannen mehrere Forscher und Ingenieure mit der Entwicklung einer angemessenen Terminologie. Kürzlich haben wir diese Aufgabe abgeschlossen und möchten diese Namen in diesem Blogbeitrag mit Ihnen teilen.
Das neue IOTA-Protokoll ist in drei Schichten (Layer) unterteilt: die Netzwerk-, die Kommunikations- und die Anwendungsschicht. Es gibt Parallelen zwischen unseren Schichten und den oberen Schichten des OSI-Modells, obwohl wir den Leser vor tiefgreifenden Vergleichen warnen. Die Netzwerkschicht verwaltet die Verbindungen und Paketübertragungen zwischen den Nodes. Die Kommunikationsschicht schafft eine standardisierte Plattform für die Speicherung und Kommunikation von Informationen. Den Entwicklern steht es dann frei, dezentralisierte Anwendungen auf der Anwendungsschicht zu entwerfen und gleichzeitig die unteren Schichten zu abstrahieren.
Die Netzwerkschicht
Diese Schicht verwaltet die unteren Schichten der Internet-Kommunikation wie TCP. Sie ist die technischste und in gewisser Weise die uninteressanteste. In dieser Schicht werden die Verbindungen zwischen den Nodes durch die Autopeering- und Peer-Discovery-Module und das Gossip-Protokoll verwaltet.
Die Kommunikationsschicht
Diese Schicht speichert und kommuniziert Informationen. Diese Schicht enthält das ” Distributed Ledger” bzw. das Tangle. Die Ratensteuerung und die Zeitstempel (engl. timestamps) befinden sich ebenfalls in dieser Schicht.
In der Kommunikationsschicht sehen wir viele neue Funktionen des Protokolls. Zunächst wird unser Signatur-” Tangle” in Message Tangle umbenannt, und die sogenannte Messages ersetzen Transaktionen und Bundles. Messages haben ein flexibles Format mit variabler Größe, die effizienter sind als Bundles von Transaktionen fester Größe. Außerdem werden wir die Bezeichnungen “Trunk und Branch” abschaffen: jede Message verweist auf zwei andere Messages, die wir jetzt die Parents (dt. Eltern) nennen.
Die Messages werden von einem Node ausgegeben und dann auf der Netzwerkschicht geklatscht (engl. gossiped). Neben den Hashes der Parents enthält eine Message bestimmte Ausgabeinformationen (Ausgabenodes-ID, Zeitstempel usw.), eine Payload (dt. Nutzlast), die die Daten enthält (mehr dazu später), und die Signatur des Ausgabenodes.
Der Begriff ” Message” wurde gewählt, um den Begriff “Transaktion” zu ersetzen, da das IOTA-Protokoll nicht nur eine Anwendung zur Übertragung von Werten ist, sondern eine Plattform zur sicheren Speicherung und Übertragung von Daten.
Die Anwendungsschicht
Das IOTA-Protokoll ermöglicht die Ausführung einer Vielzahl von Anwendungen auf dem Message-Tangle. Jeder kann eine Anwendung entwerfen, und die Benutzer können entscheiden, welche Anwendungen auf ihren Nodes ausgeführt werden sollen. Diese Anwendungen werden alle die Kommunikationsschicht zum Senden und Speichern von Daten verwenden.
Jeder Node wird jedoch bestimmte Kernanwendungen ausführen müssen, die für den Betrieb des Protokolls erforderlich sind. Dazu gehören zum Beispiel:
- Die value transfer application (dt. Wertetransfer-Anwendung)
- Der distributed random number Generator (DRNG), (dt. verteilte Zufallszahlengenerator)
- Das Fast Probabilistic Consensus (FPC)-Protokoll
Diese Anwendungen pflegen den Ledgerstatus, und andere Anwendungen können ebenfalls auf diesen Anwendungen arbeiten. Anwendungen lesen und erstellen Message-Payloads, die auf der Kommunikationsschicht gespeichert sind. Wir entwickeln einen flexiblen Rahmen, um diese Interaktion zu vermitteln.
Objekte
Die Grundeinheit der Daten im IOTA-Protokoll wird als Objekt bezeichnet. Jedes Objekt hat einen Typ und eine Größe. Der Typ ist in einem Schema genau definiert und gibt an, welche Felder das Objekt enthält und wie sie angeordnet sind. Der Typ bestimmt auch, wie ein Nodes das Objekt parst.
Message ist ein Objekttyp. Ein weiteres Beispiel ist das generische Datenobjekt, bei dem es sich, wie der Name schon sagt, nur um Daten handelt. Jeder Node führt eine Liste der Objekttypen, die er erkennt und zu parsen weiß.
Wie bei Messages können Objekte ein Payload-Feld enthalten. Eine Payload muss immer mit einem anderen Objekt gefüllt werden. Beim Parsen eines Objekts parst ein Node seine Payload entsprechend seinem Typ. Wenn der Node den Typ nicht kennt, behandelt er die Payload wie ein generisches Datenobjekt. Ein Objekttyp kann verlangen, dass eine Payload einen bestimmten Typ hat. Durch Payloads können Objekte ineinander verschachtelt werden, wodurch eine sehr flexible Plattform entsteht.
Um im Message-Tangle zu klatschen (engl. gossiped) und gespeichert werden zu können, muss jedes Objekt innerhalb einer Message gekapselt werden, entweder direkt als Payload oder indirekt als Payload eines anderen Objekts. Hinweis, eine Message mit Payload-Typ X kann als X-Message bezeichnet werden.
Beispielsweise kann eine Supply-Chain-Anwendung einen Objekttyp namens “Delivery” (dt. Lieferung) definieren. Die Nutzlast eines Delivery-Objekts könnte zwei verschiedene Objekttypen unterstützen: Parcel und Receipt (dt. Paket und Empfang). Beim Versenden eines Pakets kann ein Benutzer eine Delivery-Message (eine Message mit einem Delivery-Objekt) ausgeben, die ein Parcel-Objekt enthält, das das Paket beschreibt. Jedes Mal, wenn jemand das Paket empfängt, kann er eine Delivery-Message mit einem Receipt-Objekt ausgeben, das den Hash des Parcel-Objekts auflistet.
Jeder, der die Delivery-Anwendung nicht verwendet, könnte einfach alle Delivery-Objekte als generische Daten behandeln.
Allerdings muss jeder bestimmte Kernobjekttypen erkennen, die von den Kernanwendungen verwendet werden. Zu den Kernobjekttypen gehören
- Wert-Objekte
- FPC-Meinungs-Objekte
- DRNG-Objekte
- Salt deklarierte Objekte
- Generische Daten Objekte
Wie bereits erwähnt, können Messages, die diese Objekte enthalten, jeweils Wert-Messages, FPC-Messages, etc. genannt werden.
Alle Objekttypen enthalten eine Versionsnummer, so dass jede Anwendung aktualisiert werden kann. Die Versionsnummer einer Message gibt an, welche Version des IOTA-Protokolls die Message verwendet. Wir gehen davon aus, dass es das IOTA-Protokoll noch eine Weile geben wird und sich wahrscheinlich von Zeit zu Zeit ändern wird. Die Versionsnummern ermöglichen es den Nodes, die Interoperabilität zwischen diesen verschiedenen Versionen zu verwalten.
Die Wertetransfer-Anwendung (value transfer application)
Die wichtigste Kernanwendung ist die Wertetransfer-Anwendung, die Gelder bewegt und den Ledgerstatus aktualisiert. Diese Anwendung verwendet Wert-Objekte. Jedes dieser Werte-Objekte referenziert zwei andere Werte-Objekte, so dass die Werte-Objekte eine Art “zusätzliches Tangle” über dem Message Tangle bilden, das so genannte Value Tangle. (dt. Werte-Tangle)
In diesem Werte-Tangle stellen die Referenzen eine “Genehmigung” dar und zeichnen die Ergebnisse der FPC-Abstimmungen auf. Grob gesagt werden alle von FPC abgelehnten Werte-Objekte im Werte-Tangle verwaist (nicht berücksichtigt). Wir trennen das Wert- und das Message-Tangle, um die dabei unschuldig verwaisten Daten zu reduzieren.
Jedes Wert-Objekt hat eine Payload, die nur einen Objekttyp namens Transaktion unterstützt. Eine Transaktion enthält die Input-Transaktionen, die Output-Adressen und Salden (Balance), den Mana-Empfänger, eine Payload und eine Signatur. Da wir ein UTXO-Schema verwenden, macht der Begriff Transaktion Sinn: UTXO steht für Unspent (TX) transaction Output (dt. nicht ausgegebene Transaktionsausgabe).
Die Payload einer Transaktion kann eine Vielzahl von Objekttypen wie z.B. Smart Contracts unterstützen. Sobald die Payload signiert ist, ist sie grundsätzlich Teil der Transaktion. Gemäß dem UTXO-Schema kommt es zu Konflikten zwischen verschiedenen Transaktionen, die die gleichen Inputs verwenden. Daher kommt es zu Konflikten zwischen zwei ansonsten identischen Transaktionen, wenn sie unterschiedliche Payloads haben. Somit ist die Payload inhärent an die Ausgaben gebunden. Diese Funktionalität ermöglicht eine Vielzahl von Anwendungen, die auf der Wertetransfer-Anwendung aufbauen.
Betrachten Sie das Beispiel der Delivery-Anwendung. Wenn der Empfänger für das gelieferte Paket zahlen muss, könnte das Empfangsobjekt in der Payload der Zahlungstransaktion enthalten sein. Dann würde der Zahlungsnachweis den Zustellnachweis enthalten, und entweder sind beide oder keiner von beiden in dem Tangle enthalten.
Glossar der Begriffe
Wir nehmen nun ein Glossar der neuen Definitionen in dieses Dokument auf.
- Application Layer / Anwendungsschicht: Die oberste Schicht, die alle Anwendungen beherbergt.
- Core Application / Kern-Anwendung: Eine Anwendung, die von allen Benutzern ausgeführt werden muss.
- Communication Layer / Kommunikationsschicht: Die Schicht, die sich mit Messages und dem Message-Tangle befasst.
- Core Object type / Kern-Objekttyp: Ein Objekttyp, der von allen Benutzern geparst werden muss.
- Generisches Datenobjekt: Der grundlegendste Objekttyp. Alle nicht erkannten Datenobjekte werden so behandelt.
- Network Layer / Netzwerkschicht: Die grundlegendste Schicht, die die Verbindungen und den Klatsch zwischen Nachbarn verwaltet.
- Message: Der Objekttyp, über den zwischen Nachbarn getratscht wird. Alle geklatschten Informationen sind in einer Nachricht enthalten.
- Message-Tangle: Die Sammlung aller Nachrichten.
- Objekt: Die grundlegendste Informationseinheit des IOTA-Protokolls. Jedes Objekt hat einen Typ und eine Größe und enthält Daten.
- Payload / Nutzlast: Ein Feld in einem Objekt, das nur von einem anderen Objekt gefüllt werden kann.
- Tangle: Eine nur angehängte Datenstruktur, bei der jedes Objekt auf zwei andere Objekte verweist.
- Transaktion: Die Payload eines Werte-Objektes. Sie enthält die Angaben zu einem Geldtransfer.
- Value-Objekt / Werte-Objekt: Das Grundobjekt der Wertetransfer-Anwendung.
- Value Tangle / Werte-Tangle: Die Sammlung aller Wertobjekte.
- Value Transfer Application / Wertetransfer-Anwendung: Die Anwendung, die den Zustand des Ledgers aufrechterhält.
- Versionsnummer: Gibt das korrekte Format jedes Typs an.
Quellen
https://blog.iota.org/a-guide-to-upcoming-iota-2-0-coordicide-terminology-856872d7bbfc