Coordicide ist der Name für den Entwicklungsschritt, der IOTA endlich dezentral aufstellen soll. Es gibt schon lange Gerüchte darüber, wie das passieren soll und es gab auch schon viele Ideen. Der bombastisch aufgemachte Trailer weckt Hoffnungen:
Allerdings ist das IOTA-Marketing-Team berüchtigt für große Ankündigungen, die erst noch mit Leben gefüllt werden müssen. Schweiß und vermutlich literweise Kaffee müssen nach diesen Ankündigungen fließen, um sie tatsächlich Wirklichkeit werden zu lassen.
So war es bei Abra bzw. Qubic und nachdem ich das Coordicie-Whitepaper gelesen habe, kann ich auch sagen, dass es hier so sein wird.
30 Seiten Coordicide-Whitepaper in einer Minute
Das Whitepaper kommuniziert im Gegensatz zum Marketingmaterial sehr offen und transparent den frühen Stand der Forschung. Von Produktreife oder gar „Blueprints“, um diese zu erreichen, kann man da noch nicht sprechen.
Das Whitepaper definiert vier grobe Stoßrichtungen für die Dolche im Rücken des Coordinators:
- Node Accountability (Spam Protection)
- Auto-Peering (Full-Nodes automatisch eingliedern)
- Rate-Control (Spam Protection)
- Consensus (Milestone-Transaktion)
Alle vier Lösungswege enthalten offene Fragen, die teilweise direkt, teils implizit oder gar nicht im Whitepaper erwähnt werden.
Das Whitepaper weist auch auf die Referenzimplementierung ohne Coordinator (CLIRI) hin. Während der Erstellung dieses Artikels (31. Mai 2019) sind die angesprochenen Lösungen nicht implementiert bzw. nachprüfbar.
Spam Protection mit erzwungener Pseudonymität
Das Herzstück der Node Accountability ist die Möglichkeit der Zuordnung von Transaktionen zu eindeutigen ID’s. Wie die ID’s generiert werden, wird nur angedeutet. Angeblich sollen sie frei gewählt werden und auf Public-Key-Kryptographie basieren.
Dementsprechend werden auch Signaturen und Public Keys mit den Transaktionen verschickt. Das Whitepaper spricht davon, diese getrennt von den Transaktionen aufzubewahren – ähnlich wie SegWit bei Bitcoin. Ob und wie diese ID’s für die Validierung von Transaktionen aus dem Netz geladen werden sollen, wenn sie nicht im Tangle gespeichert sind, habe ich nicht herausgefunden.
Zuckerbrot und Peitsche
Wenn der Coordinator als Big Boss nicht mehr vorgibt, welchen Transaktionen zu trauen ist und welchen nicht, stellt sich die Frage, wer das sonst tun soll. Ähnlich zu Proof of Stakes (PoS) gilt die Regel: wer hat, dem wird gegeben.
Bei jeder Transaktion kann – entsprechend der Anzahl an transferierten MIOTA’s – auch eine interne Währung namens Mana ausgeschüttet werden. Die Empfänger müssen bei Erstellung der Transaktion bereits feststehen.
Mana ist messbare Vertrauenswürdigkeit. Umso mehr Plus auf dem virtuellen Kontostand eines IOTA-Nutzers, umso vertrauenswürdiger ist er. Darüber hinaus hat das keinen Nutzen.
ID’s als Schlüssel zur Box voller Lösungen
Die generierten ID’s sind neben der Notwendigkeit des Mana-Erhalts allerdings auch für alle anderen Maßnahmen notwendig. Sowohl für das Auto-Peering, Rate-Limiting und je nach Implementierung auch für die Tip-Selection (Consensus).
Auto-Peering – Endlich nicht mehr betteln!
Die erste Referenzimplementierung von IOTA (IRI) setzte voraus, dass sich die Betreiber entweder über andere Kanäle wie Discord oder Reddit miteinander vernetzten und darauf hoffen, dass sich jemand erbarmt, ihnen Neighbour-Node-Adressen zu geben oder auf Drittlösungen wie Vitalys und Romans Semkos Nelson-Projekt auszuweichen.
Auto-Peering erlaubt es den Netzwerkknoten, sich miteinander zu vernetzten. Eine entscheidende Rolle spielt dabei die ID des Knotens, da diese herangezogen wird, um andere Knoten zu finden.
Beim ersten Hochfahren wird eine bekannte Liste von Knoten abgeklopft, die dann entweder die Verbindung aufbauen oder passendere Nachbarn empfehlen.
Wie gut oder schlecht zwei Netzwerkknoten zueinander passen, hat per se nichts mit deren räumlichen Distanz zu tun, sondern nur mit der ID. Das hat den Vorteil, dass verschiedene Teile des Tangles so miteinander verbunden werden.
Rate Control – Himmelsbrot und Einzelaufgaben
Rate Control bedeutet auf Deutsch „Transaktionslimitierung“ und meint damit die Beschränkung der Anzahl an Transaktionen, die ein Knoten senden darf. Die Basis dafür bildet das verdiente Mana: Umso mehr ein Knoten davon hat, umso mehr Transaktionen kann er gleichzeitig versenden.
Die Basis dafür ist ein mathematisches Rätsel, das allerdings so gestellt ist, dass weder ASIC’s noch hohe Parallelisierung an der Anzahl an benötigten Schritten etwas ändern können – ganz im Gegensatz zu Bitcoin’s Proof of Work. Die formale Definition dieser Art von Rätsel findet man unter dem Begriff Verifiable Delay Functions.
Interessant wird das Ganze, wenn man einen Schritt zurück geht. Denn umso mehr Mana jemand besitzt, umso einfacher wird das Rätsel für ihn.
Dies macht gleich mehrere Dinge möglich:
- Es wird keine Mining-Wars geben, da keine spezielle Hardware dafür gebaut werden kann. (Wie die schon lang angekündigte trinäre Hardware da ins Bild passt, weiß ich auch nicht.)
- Auch schwächere Hardware soll nicht wesentlich benachteiligt werden, da sie zwar pro Rechenschritt länger braucht, aber dennoch nur genauso viele Schritte machen muss wie stärkere Hardware.
Consensus – Konsens ohne absoluten Herrscher
Während der COO durch seine Milestone-Transaktionen eindeutig kennzeichnet, welchen Transaktionen zu trauen ist und welchen nicht, muss ohne COO jeder Netzwerkteilnehmer selbst wissen, welche Transaktionen vertrauenswürdig sind.
Die Idee bricht auf zwei Dinge hinunter:
- Die Netzwerkteilnehmer überlegen sich genau, welche Transaktionen sie validieren wollen und welche nicht. (sg. Tip-Selection)
- Sie stimmen sich regelmäßig miteinander ab, ob die Masse sinnvoll Transaktionen validiert hat oder ob Unsinn validiert wurde.
Transaktionen auswählen – Tip-Selection für Dummies
Die Auswahl der Transaktionen erfolgte mit COO mittels eines so genannten Random-Walks. Dabei wurde die letzte Milestone-Transaktion hergenommen, um dann davon rückwärts bis zur neuesten Transaktion zu marschieren. Bei jeder Weggabelung wurde dann gewürfelt, um auszuwählen, wohin es weiter geht. Die ausführliche Erklärung habe ich in IOTA – Ein Blick unter die Haube geliefert.
Da es nun keinen COO mehr gibt, besteht die große Gefahr, dass viele Transaktionen verhungern, da sie im Meer der neuen Transaktionen zu schnell altern und unvalidiert im Tangle verrotten. Der Transaktionssender müsste dann ständig prüfen, wie es seiner Transaktion geht und bei ausbleibenden Validierungen die Transaktion re-attachen bzw. neu senden.
Dies ist Mehraufwand und eine Bremse – auch durch die Rate-Limitierung. Im schlimmsten Fall bildet sich dann eine Wall an unvalidierten Transaktionen, welche den Knoten zum Erliegen bringt, da dieser nicht mehr mit dem Reattachen hinterher kommt.
Um dieser Gefahr vorzubeugen, weist das Whitepaper auf zwei unterschiedliche Algorithmen für die Transaktionsauswahl hin. Einer soll so funktionieren wie früher und der andere soll dessen Schwächen ausgleichen. Ebenso sollen Ergebnisse aus dem Voting bei der Auswahl einfließen. Ob oder wie genau das funktioniert, wird nicht weiter definiert.
Da das Kapitel mit der Bitte um Mithilfe der Community beginnt, liest sich das für mich wie die Einsicht, einem (noch?) ungelöstem Problem gegenüberzustehen.
Voting – Tratsch über Meinungen
Als ich das „Gossip about Opinion“ im Whitepaper gelesen habe, kam sofort der Verdacht auf, es wäre Gossip about Gossip von Hashgraph gemeint. Doch dem ist nicht der Fall.
Während Hashgraphs Virtual Voting vorgibt, wer wem welche Daten weiterschicken kann, sieht das Coordicide-IOTA-Protokoll tatsächlich echte Abstimmungen vor.
Das Whitepaper meint damit das Hervorheben von Transaktionen. Dabei werden alle Transaktionen kontrolliert und in „Like“ und „Dislike“ eingeteilt. Bei den Like-Kandidaten handelt es sich um Transaktionen, die von jungfräulichen Adressen stammen. Wurde bereits einmal von einer Adresse aus etwas überwiesen, wird sie automatisch mit dislike markiert.
Wie genau das zu passieren hat, wird nicht definiert. Es wird nur auf zwei Möglichkeiten hingewiesen.
- Probabilistic Consensus Voting
- Cellular Consensus
Die erste Variante verwendet Stichproben zur Ermittlung der Votings, während der Zelluläre Automat tatsächlich durch den ganzen Tangle tingelt.
Mich lässt das Gefühl nicht los, dass es sich dabei in der Praxis um einen zeitaufwendigen Schritt handelt. Aber bevor die neueste CLIRI-Version nicht veröffentlicht wurde, lässt sich das schwer beurteilen.
Conclusio
In IOTA – Konsistent mit der Inkonsistenz habe ich herausgearbeitet, dass ein System wie IOTA sich immer für einen Kompromiss zwischen Konsistenz, Verfügbarkeit und Partitionstoleranz der Daten entscheiden muss.
Das Whitepaper hat gezeigt, dass IOTA sich mehr für Partitionstoleranz und Verfügbarkeit statt Konsistenz entschieden hat.
Außerdem hat es – wie so oft bei IOTA-Ankündigungen – gezeigt, dass viele Fragen bei genauerem Hinsehen unbeantwortet bleiben. Auch dieses Mal handelt es sich um nicht mehr als ein Zwischenbericht der Forschungsabteilung.
Marktreifes Produkt? Mit substantiellen Verbesserungen aktueller Lösungen? Fertiger Source-Code?
Nope, nein – noch nicht hier.
Interessante Ideen? Ja!
Jetzt muss nur noch abgeliefert werden.
