IOTA – Konsistent mit der Inkonsistenz

Mit IOTA verbindet mich eine ungewöhnliche Hassliebe. Die Liebe fusst auf der Idee des Tangles, die ich so faszinierend wie seltsam finde. Der Hass ist vor allem in den Marketinggebarden der IOTA Foundation begründet. So habe ich mich vor ein paar Wochen wieder mit Abra, der Programmiersprache für Qubic, beschäftigt. Die Vorankündigungen für Qubic sind ja mittlerweile alt – all das geschah im Sommer.

Als ich mich dann durchgerungen habe, dem #qubic Discord-Channel beigetreten bin und mich näher damit beschäftigt. Der vollmundigen Ankündigungen zum trotz, wird da noch mit heißer Nadel an einem ersten Alpha-Versions Prototypen gestrickt. Allerdings (und das sollte nicht unerwähnt bleiben) ist Eric Hop trotz dieser Bemühungen, sehr in Diskussion involviert und sich nicht zu schade lange Erklärungen auf Fragen zu posten. Die Begeisterung war selbst durch einen simplen Text-Chat spürbar. Die Beispiele und Syntax-Diagramme die herumgereicht wurden gaben schon viel Aufschluss über die kommende Sprache. Ich habe mir etwas anderes erwartet, aber die Erklärung im Channel, dass der Compiler bereits in der Lage ist, Abra-Code in Baupläne für ASICs zu kompilieren, war dennoch aufmunternd. Wer einen Blick auf die Syntax werfen möchte, kann dazu in das Oktober-Update von Hop schauen.

Klar war aber auch, dass die großmundigen Ankündigungen im Sommer vor allem eines waren: Heiße Luft. Man kann ihnen nur gratulieren, dass die IOTA Foundation es geschafft hat ein kleines Team von sehr motivierten Entwicklern zu finden die dem tatsächlich relativ zeitnah Leben einhauchen.

Unabhängig von der IOTA Foundation, hat Bosch einen Blog-Eintrag veröffentlicht in dem sie über die Integration von IOTA in ihrem Bosch XDK schreiben. Dabei handelt es sich um ein so genanntes Entwicklungs-Kit mit dem Prototypen programmiert werden können. Die dazugehörige Hardware ist ein mit vielen Sensoren ausgestattetes Gerät, dass über eine Software-Bibliothek namens XDK2MAM an den IOTA Data Marketplace angeschlossen werden kann um Sensordaten zu verkaufen.

Das könnte der erste Schritt sein, der dem viel beschworenen Machine-to-Machine-Szenario von IOTA endlich etwas Leben einhaucht und das Netz unter vernünftige Last setzt. Nur der grovolumige Einsatz wird zeigen wo tatsächlich die Schrauben festgezogen werden müssen um zu skalieren – oder wo etwas ausgetauscht werden muss.

„Unendlich Skalierbar“ – das kann nur Marketinggeschwätz

Es gibt Systeme die theoretisch unendlich skalierbar sind. Das sind allerdings keine Distributed Ledgers wie Bitcoin oder IOTA. Denn ein Distributed Ledger ist eine besondere Art von verteilter Datenbank und jeder Informatikstudent lernt in den ersten paar Semestern das CAP-Theorem kennen.

Um was geht es da? Sehr simpel gesagt: Man kann eben nicht alles haben. Alles bezieht sich dabei auf drei Eigenschaften eines verteilten Datenspeichers:

  • Konsistenz der Daten (zu Englisch Consistency) – das bedeutet, wenn Berti Frank einen Euro überweist, muss diese Information überall hinwandern. Tut sie das nicht, könnte Berti den selben Euro zweimal ausgeben (Double-Spend)
  • Verfügbarkeit der Daten (zu Englisch Availability)
  • Partitionstoleranz – das heißt, Toleranz gegenüber dem Ausfall von Verbindungen zwischen Computern auf die sich der Datenspeicher verteilt.

CAP-Theorem besagt, dass man sich immer nur zwei dieser Eigenschaften aussuchen kann. Dabei handelt es sich auch nicht nur um eine Mehrheitsmeinung sondern um einen formal bewiesenen Satz. Die Korrektheit dieser Aussage ist genauso fest in Stein gemeißelt wie die das Ergebnis von 4 bei der Rechnung 2 + 2 (in den Natürlichen Zahlen).

Das Stempelspielproblem

Was heißt das in der Praxis? Am einfachsten erklärt sich das anhand eines Beispiels. Nehmen wir an, dass der Wiener Uhrenhändler Novak jedes Jahr ein Gewinnspiel veranstaltet und dessen Preis eine goldene Rolex ist. Dafür händigt er Zettel aus. Diese sind dazu da um sie in den vielen Zweigstellen, die der fiktive Uhrenhändler auf der ganzen Welt hat, abstempeln zu lassen. Derjenige der am Ende die meisten Stempel gesammelt hat, bekommt die Rolex. Stichtag dafür ist der Tag des Schutzpatrons der Uhrenmacher bzw. der 29. Juni.

Jedes Mal bevor eine Zweigstelle einen solchen Zettel abstempelt, prüft sie ob die davor eingestempelten Markierungen echt oder gefälscht sind und wenn alles in Ordnung ist wird der Zettel abgestempelt.

Dieses Spiel hat eine sehr hohe Partitionstoleranz, da es völlig gleich ist ob und wieviele der Mitspieler miteinander in Kontakt stehen. Die Geschäfte können anhand einer speziellen Tinte erkennen ob die Stempel gültig sind und müssen keine Rückfrage halten. (Diese Tinte ist im Falle von Kryptowährungen die Kryptographie) Die Verfügbarkeit der Daten ist sehr schlecht, da man zwar weiß wieviele der Zettel ausgegeben wurden aber niemand genau weiß wieviele der Spieler tatsächlich noch Stempel sammeln und wieviele der Stempel eingesammelt wurden.

Die Konsistenz der Daten ist auch eindeutig gegeben, da die Uhr nur einmal herausgegeben werden kann. Allerdings handelt es sich dabei um eine Form der eventuall consistency bzw. der letzendlichen Konsistenz. Zwischendurch ist nicht klar wer die Uhr bekommt, auch wenn schon viele Stempelzettel eingetroffen sind, gibt es einen Stichtag an dem ausgezählt wird. Erst dann steht fest wer der neue Besitzer der Uhr ist.

Aktuell bestimmt der Coordinator wann dieser Stichtag ist. Auch die Stempel, bzw. Bestätigungen von Transaktionen, sind nur ein Anhaltspunkt für den Coordinator. Für eine IOTA-Full-Node ist vor allem interessant wann der Coordinator eine Transaktion bestätigt hat.

In der Praxis bedeutet das, dass IOTA sich entscheiden muss wofür es wirbt:

  • Schnelle und sichere Transaktionen mit Coordinator
  • Schnelle und sichere Transaktionen ohne Netzwerkpartitionen bzw. Offline-Transaktionen
  • Netzwerkpartitionen mit Offline-Transaktionen und sicher – aber langsam
  • Netzwerkpartitionen mit Offline-Transaktionen und schnell – aber unsicher

Wegweiser Bosch

Das spannende an der Bosch-Integration ist also nicht, dass ein IOTA etwas positive Presse bekommt, sondern die Möglichkeit, dass es ausprobiert wird und sich zeigt, wohin der Weg gehen soll. Nach meiner Beobachtung hat IOTA keinen abgeschlossenen Master-Plan sondern bewegt sich sehr schnell und probiert viel aus um aus dem Kryptowährungs-Use-Case rauszukommen und die Rolle als Kommunikations-Middleware einzunehmen. Dafür spricht auch die Omega-Initiative die sich mit der Entwicklung von IoT-Anbindungen (bzw. Internet of Things) und Erweiterungen beschäftigt – siehe auch IOTA Controlled Agent.

Für diese Interpretation spricht auch die Artikelreihe (Coordinator – Path to Coordinicide) rund um das Ersetzen des Coordinators. Die Kommunikation wirkt auf mich sehr offen und ehrlich, auch wenn ich nur zwei Punkte daraus mitnehme:

Der dezentralisierte Coordinator ist ein Problem und die IOTA Foundation arbeitet an einer Lösung. Zwei Experimente die in Test-Netzen gestartet werden drehen sich darum, zu prüfen wie sich der Tangle verhält ohne COO und wie ein Netz funktioniert in dem es keinen zentralen sondern mehrere COOs gibt.

Welche der zwei der drei CAP-Punkte sich schlussendlich als am wichtigsten herausstellen werden ist offen. Es bleibt allerdings spannend.

Prinzipiell neugierig und mit starkem Hintergrund in Informatik, bin ich Software-Entwickler bei Tag und Krypto-Enthusiast bei Nacht.

Über Martin Keiblinger 57 Artikel
Prinzipiell neugierig und mit starkem Hintergrund in Informatik, bin ich Software-Entwickler bei Tag und Krypto-Enthusiast bei Nacht.

1 Trackback / Pingback

  1. IOTA und Project Alvarium – Blockchain Investment

Antworten

Ihre E-Mail-Adresse wird nicht veröffentlicht.


*


*

code