Mit IOTA verbindet mich eine ungewöhnliche Hassliebe. Die Liebe fußt auf der Idee des Tangles, die ich so faszinierend wie seltsam finde. Der Hass ist vor allem in den Marketinggebärden 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.
Also habe ich mich dann durchgerungen, dem #qubic Discord-Channel beizutreten und mich näher damit zu beschäftigen. Den vollmundigen Ankündigungen zum Trotz wird da noch mit heißer Nadel an einem ersten Alpha-Versionsprototypen 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, das ü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 großvolumige 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)
Ebenso gibt es die Verfügbarkeit der Daten (zu Englisch Availability) und die Partitionstoleranz – das heißt, Toleranz gegenüber dem Ausfall von Verbindungen zwischen Computern, auf die sich der Datenspeicher verteilt.
Das 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 der 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 wie viele 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ß wie viele der Zettel ausgegeben wurden, aber niemand genau weiß, wie viele der Spieler tatsächlich noch Stempel sammeln und wie viele 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 Eventual 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 irgendwann 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