IOTA Foundation verlagert Fokus von Qubic auf Smart Contracts

Smart Contracts gehören zu den wichtigsten Funktionen moderner Blockchain-Ökosysteme. Diese Entwicklung hat auch die IOTA Foundation erkannt und den Fokus auf die Entwicklung entsprechender Smart Contracts verlagert. Dabei stellen diese softwarebasierten Verträge eine Layer-2-Lösung dar. Die technische Grundlage hierfür ist die Coordicide-Implementierung in GoShimmer. Allerdings bedeutet der neue Fokus auch, dass die Entwicklung von Qubic eine geringe Priorität einnimmt.

Wie ist der aktuelle Stand bei Qubic?

Ein genauer Blick auf Qubic verdeutlicht, dass es sich hierbei um ein Schichtsystem mit zwei lose gekoppelten Schichten handelt.

• Smart-Contract-Nachrichtenschicht (SC): ein Level-2-Protokoll, welches auf dem Tangle ausgeführt wird. Die Aufgabe dieser Schicht ist die Ausführung von Smart Contracts über Verarbeitungsknoten. Dabei entsteht ein Quorum-Konsens mitsamt eines Prüfpfads für das Tangle.
• Abra-Virtual-Machine-Schicht (VM):Diese Schicht regelt die Ausführung der Smart Contracts. Dabei soll die VM auch eine Ausführung auf ressourcenarmen IoT-Geräten ermöglichen.
• Qubic Computation Model (QCM): Die SC- und VM-Schicht werden durch das QCM, ein Ereignisverarbeitungssystem kombiniert. Folglich regelt das QCM das Versenden der Eingabedaten von der SC- an die VM-Schicht sowie die Rückgabe der Daten. Grundsätzlich handelt es sich um ein einfaches Model, welches einen Versandmechanismus beschreibt.

Grundsätzlich zeigt sich, dass die beiden Schichten nur lose gekoppelt sind. Auch die Prüfergebnisse lassen sich unabhängig überprüfen, ohne dass der Qubic-spezifische Qupla Code zur Ausführung kommt. Vielmehr lässt sich jede Programmiersprache und Virtual Machine bei kompatiblem SC-Code verwenden. Laut den Angaben der Entwickler muss hierbei jedoch gewährleistet sein, dass Anomalien wie unendliche Schleifen effektiv unterbunden werden. Im Ethereum-Ökosystem sorgen etwa die Gasgebühren für einen regulierten Ablauf. Bei Qubic kommt dahingegen ein funktionales Datenfluss-Programmiermodell in der Abra VM zum Einsatz. Dieses unterbindet unbegrenzte Schleifen durch eine maximale Anzahl von Aufrufen auf der Funktionsebene.

Die Abra VM – ehrgeizige Entwicklung für Qubic

Das gesamte Abra-Programmiermodell kann durchaus als ehrgeizig bezeichnet werden. Immerhin haben sich die Entwickler von den sequenziellen Anweisungen, welche auf komplexen CPUs verarbeitet werden, entfernt.

Mithilfe eines Datenflussmodells, welches lediglich aus Lookup Tables und Mergers besteht, lässt sich eine maximale Parallelisierung der Operationen erreichen. Durch diesen Ansatz lassen sich die Operationen einfacher in den Schaltkreisen der Maschinen instanziieren.

Außerdem ist das Abra-Programmiermodell so einfach, dass auch ein eigener Interpreter zur Ausführung auf einen Standardprozessor funktioniert.

Sollten die Smart Contracts komplexer ausfallen und eine Hardwarebeschleunigung erfordern, dann muss eine Hardware-Implementierung stattfinden. Hierfür stehen drei Ebenen der Hardware-Implementierung zur Verfügung:

1. FPGAs nutzen und VM-Schaltung einmalig einrichten. Anschließend können die Geräte die VM-Codes ausführen. Eine Änderung des Codes erfordert lediglich eine erneute Kompilierung des Codes.
2. ASIC zur Implementierung verwenden. Statt Bausteine für das FPGA zu entwickeln, können diese direkt auf ASIC-Schaltkreisen erstellt werden. Der Vorteil ist eine steigende Geschwindigkeit und eine geringe Menge der Schaltungen. Ein solcher Abra VM ASIC könnte als Co-Prozessor für IoT-Anwendungen fungieren.
3. Schlussendlich kann man den programmierten Abra-VM-Code auf einem ASIC implementieren. Hierbei geht allerdings die Programmierbarkeit verloren. Für die Zukunft ist das ein riesiges Anwendungsszenario bei nicht veränderbaren Komponenten wie Sensoren.

Für die relevanten Verbesserungen des Abra VM-Programmiermodells, etwa ein reduzierter Energiebedarf, Datenflussaspekte und Wave-Pipelining erfordern die letzte Implementierungsstufe.

Qubic-Vision – aktuelle Grenzen überschreiten

Mit Qubic hat die IOTA Foundation eine klare Vision verfolgt: die Grenzen bisheriger Ausführungsmodelle überschreiten. Insbesondere das Mooresche Gesetz, welches die regelmäßige Verdoppelung der integrierten Schaltkreise bei minimalen Komponentenkosten beschreibt, neigt sich dem Ende zu. Mithilfe eines ternären Ausführungsmodells ließen sich diese Grenzen überwinden und eine höhere Datendichte und Rechengeschwindigkeit gewährleisten.

Im Gegensatz zum binären System kann das ternäre System auch den Zustand null wiedergeben und somit eine höhere Effizienz und Geschwindigkeit gewährleisten. Außerdem tragen die 2b- und 3b-Codierungen dazu bei den Energiebedarf der Hardware zu reduzieren. Abra zwingt die einzelnen Entscheidungswege zur Verwendung der Null und unterbindet somit späte Schaltungen – der Zustandswechsel von 0 auf einen größeren Wert konsumiert die meiste Energie.

Schlussendlich muss aber auch gesagt werden, dass es keine entsprechende ternäre Programmierung gibt, da es schlichtweg an der nativen Hardware mangelt. Allerdings legt die Qubic-Forschung nahe, dass ein ternärer Prozessor mit drei Zuständen arbeitet.

Die Lehren aus dem FPGA Proof of Concept

Zur Vereinfachung des FPGA Programmiermodells haben die Entwickler sogenannte Qubic Lookup Tables, welche jeweils drei 2b-codierte Trits nutzen, verwendet. Durch  vordefinierte Suchoperationen lassen sich somit auch Fusionen zwischen den QLUTs darstellen.

Nichtsdestotrotz verfügt auch das FPGA über eine zusätzliche Konfigurationslogik, um die Ein- und Ausgangsoperationen zu verbinden. Die notwendige Logik lässt sich aus dem VM-Code generieren und während des Betriebs konvertieren. Der notwendige Konfigurationscode für die QLUTs befindet sich ebenfalls im generierten Code.

Sollte der Nutzer dann eine Funktion als hardwarebeschleunigt markieren, übergibt die Qupla-Umgebung die Konfigurationsdate in das FPGA. Der Emulator führt dann den Code aus und berechnet das Ergebnis, welches anschließend zurückläuft.

Der Qubic Supervisor, der die ausgeführten Codes validiert, funktioniert ebenfalls. Allerdings ist das End-to-End-PoC (Qupla-to-FPGA) noch nicht final implementiert.

Zusammenfassend lässt sich sagen, dass die Entwicklung wie erwartet vorangeschritten ist. Allerdings sorgt die Limitierung auf 512 QLEs dafür, dass sich lediglich kleinere Funktionen auf das FPGA laden lassen. Hierbei überwiegt der Kommunikationsaufwand den Nutzen der eigentlichen Funktion. Außerdem zeigt sich, dass das Datenflussmodell unter der Komplexität des Aufrufbaums leidet – dieser nimmt exponentiell zu. Eine Lösung für dieses Problem wurde bisher nicht gefunden. Die analysierten Probleme gelten dabei aber nicht für den Abra-Emulator, der lediglich auf Lookup-Tabellen zurückgreift.

Schlussfolgerung für die weitere Entwicklung von Qubic

Es zeigt sich, dass das Abra-Datenflussmodell mitsamt der Qupla-Programmiersprache auf einer dedizierten FPGA-Hardware ausführbar ist. Somit konnte die IOTA Foundation die Vision hinter Qubic verdeutlichen. Nichtsdestotrotz steht nun fest, dass weitere Forschung für die Inbetriebnahme von Qubic notwendig ist.

Wichtiger ist allerdings die Inbetriebnahme der Smart-Contract-Ebene. Die intelligenten Verträge, die in Verbindung mit der Coordicide-Knotensoftware funktionieren, sollen schnellstmöglich auf den Markt kommen. Mit IOTA Smart Contracts greift die IOTA Foundation die gewonnenen Erkenntnisse auf. Außerdem existiert nun eine neue Vision für Smart Contracts, die skalierbar und kosteneffizient sind. Zum aktuellen Zeitpunkt entsteht eine Alpha-Version auf Basis der GoShimmer-Implementierung. Außerdem stellt IOTA den Nutzern in Kürze weitere Informationen zum finalen Pfad zu Verfügung. Bereits mit der Alpha sollen PoCs zur Verfügung stehen, welche eine weitere Entwicklung maßgeblich vereinfachen.