13.Apr’20
Übersetzung des Blogartikel von Autor Eric Hop, IOTA Foundation.
Die IOTA-Stiftung hat beschlossen, den Schwerpunkt auf einen neuen Smart Contract-Ansatz zu verlagern, der sich aus unserer früheren Arbeit ableitet. IOTA Smart Contracts ist eine 2-Layer-Lösung, die auf der Entwicklung von Coordicide in GoShimmer aufbaut. Eine kurze Einführung finden Sie hier. Die Weiterentwicklung von Qubic erfordert erhebliche Ressourcen und Zeit, und unser neuer Ansatz wird eine breitere und schnellere Anwendung ermöglichen. Wir haben einen funktionierenden Proof of Concept der Programmiersprache Qupla, der auf FPGA-Hardware ausgeführt werden kann, als Open Source zur Verfügung gestellt. Wir laden die Open-Source-Gemeinschaft ein, ihn zu erforschen.
Der Zustand von Qubic
Es ist schon eine Weile her, dass wir uns umfassend mit dem aktuellen Stand des Qubic-Projekts befasst haben. Dieser Artikel wird hier Abhilfe schaffen, indem er eingehend darauf eingeht, wo wir das Projekt derzeit sehen, wie weit wir gekommen sind, welche Lektionen wir gelernt haben und wie die IOTA-Stiftung die Entwicklung von Smart Contracts weiter vorantreiben wird.
Bitte beachten Sie: Wir gehen davon aus, dass der Leser über ein grundlegendes Verständnis des Qubic-Systems sowie der Artikelserie über das Qubic-Berechnungsmodell verfügt. Einige der in diesen Ressourcen verwendeten Begriffe haben sich möglicherweise im Laufe der Zeit aus Gründen der Klarheit etwas geändert.
Qubic: ein geschichtetes System
Wenn man sich Qubic genauer ansieht, dann besteht es eigentlich aus zwei sehr losen gekoppelten Schichten (Layern), die sich gegenseitig nicht allzu sehr zu benötigen scheinen. Diese beiden Schichten sind:
- Die Smart Contract (SC) Nachrichtenschicht, die als Level-2-Protokoll über dem IOTA Tangle läuft. Diese Schicht regelt die Ausführung von SCs durch ein Komitee von verarbeitenden Nodes. Die Nodes erzeugen einen Quorum-Konsens über die Verarbeitungsergebnisse und bieten einen Prüfungspfad über das Tangle. Diese Schicht kümmert sich nicht darum, wie die Verarbeitung erfolgt, sondern nur darum, dass die Ergebnisse durch den Prüfpfad, den SC-Code, die Eingabedaten und die Ausgabedaten nachweislich korrekt und überprüfbar sind.
- Die Ebene der virtuellen Maschine (VM) von Abra. Diese Schicht regelt die tatsächliche Ausführung des SC-Codes. Sie hat einen besonderen Schwerpunkt auf der Fähigkeit, auf IoT-Geräten mit geringem Ressourcenbedarf ausgeführt werden zu können. Die Schicht nimmt Eingabedaten entgegen, führt den (möglicherweise hardwarebeschleunigten) Code aus und gibt Ergebnisse aus. Dieser Schicht ist es gleichgültig, woher die Eingabedaten kommen und wohin die Ergebnisse gesendet werden.
Diese beiden separaten Schichten werden durch das Qubic Computation Model (QCM), einem Ereignisverarbeitungssystem, miteinander verbunden. Das QCM regelt die Weiterleitung der Eingabedaten von der SC-Schicht an die VM-Schicht und die Rückgabe der Ergebnisse von der VM-Schicht an die SC-Schicht. Das QCM ist ein sehr generisches Modell. Es nimmt nichts über die Ereignisverarbeitung vorweg, weder woher die Ereignisdaten kommen noch wohin die Verarbeitungsergebnisse gehen. Es handelt sich lediglich um einen einfachen Dispatching-Mechanismus, der eine vollständige Entkopplung zwischen den Schichten, die miteinander reden müssen, sicherstellt.
Verbindung der Schichten (Layer)
Wo also findet die Kopplung dieser beiden Systeme statt, wenn sie fast vollständig entkoppelt sind? Zunächst besteht die Notwendigkeit, Berechnungsergebnisse unabhängig voneinander verifizieren zu können. Das bedeutet, dass Sie neben einem Prüfpfad für die Eingabedaten und Ergebnisse der SC-Aufrufe auch den entsprechenden SC-Code benötigen, der aufgerufen wurde, um Teil dieses Prüfpfades zu sein. Auf diese Weise wissen Sie genau, welchen Code Sie mit den Eingabedaten ausführen müssen, wenn Sie das Ergebnis verifizieren wollen.
Beachten Sie, dass dies immer noch nicht die Verwendung des Qubic-spezifischen Qupla-Codes und des entsprechenden Abra VM zur Ausführung des SC erfordern würde. Sie könnten im Wesentlichen jede VM und jede Programmiersprache verwenden, solange der SC-Code mit diesen kompatibel ist. Unsere erste Proof-of-Concept-Implementierung des QCM vermischt in der Game of Life-Demo tatsächlich Qubic-spezifischen Abra-Code mit Standard-Java-UI-Code. Es gibt jedoch einen ganz bestimmten Grund, bei der Auswahl einer VM zur Ausführung Ihres SC-Codes vorsichtig zu sein. Da Nodes diesen Code immer dann ausführen, wenn Daten für die SC automatisch und unbeaufsichtigt ankommen, möchten Sie verhindern, dass laufende SC-Programme in der VM-Schicht ausgeführt werden (unbegrenzte Schleifen/Rekursionen). Sie benötigen einen Mechanismus, um das SC-Programm in Schach zu halten, so dass es nur für eine vernünftige, vorhersehbare Zeitspanne läuft.
In Ethereum wird dieses ausufernde Problem durch die Einführung von Gas-Gebühren gelöst. Die Höhe der Gebühren entspricht einem bestimmten Höchstbetrag der SC-Verarbeitung. Sobald dieses Maximum überschritten wird, wird die SC-Ausführung abgebrochen, wodurch verhindert wird, dass der unkontrollierte SC-Code unbegrenzt weiterläuft. Der Nachteil dieser Methode besteht darin, dass es schwierig sein kann, die Höhe der Gas-Gebühren, die Sie für Ihre SC benötigen werden, im Voraus vorherzusagen, wenn die SC irgendeine Art von nicht traditioneller Verarbeitung durchführt. Und wenn Sie zu wenig Gas-Gebühren bereitstellen, könnte dies dazu führen, dass Ihre SC-Ausführung abgebrochen wird, bevor sie abgeschlossen ist. In diesem Fall haben Sie die Gas-Gebühren verloren, ohne am Ende ein Vollzugsergebnis zu erhalten.
In Qubic lösen wir dieses Problem deterministisch, indem wir ein funktionales Datenflussprogrammierungsmodell in der Abra VM haben, dass keine unbegrenzten Schleifen/Rekursion zulässt und daher an und für sich nicht Turing-fähig ist. Jede Funktion definiert klar, wie viel Verarbeitung sie leisten wird. Es gibt keine direkte Verzweigung oder Schleifenbildung in der Abra VM, was bedeutet, dass jede Funktion immer genau die gleiche Anzahl von Anweisungen ausführt. Selbst wenn eine Funktion rekursiv aufgerufen wird, ist sie auf eine bestimmte maximale Anzahl von Aufrufen beschränkt. Unbegrenzte Schleifen können auf einer höheren Ebene, durch das QCM, aktiviert werden, aber die Einheit der Ausführung ist absolut klar und garantiert auf Funktionsebene begrenzt. Wenn Sie erwarten, dass Ihnen die Aufrufe für eine Funktion ‘ausgehen’, können Sie Ihren Code so gestalten, dass der Fortsetzungszustand des SC Teil der resultierenden Ausgabe ist. Und das wiederum ermöglicht es Ihnen, die Ausführung von diesem Punkt aus in einer nächsten Runde begrenzter Aufrufe fortzusetzen. Wir sagen daher, dass die Ausführung durch den QCM Quasi-Turing-Abschluss ist.
Beachten Sie, dass, obwohl die Möglichkeit der Bereitstellung von Belohnungen als potenzieller Anreiz für die Verarbeitung besteht, es in Qubic nicht erforderlich ist, das Äquivalent der Ethereum-Gebühren für die Verarbeitung bereitzustellen. Es könnte andere Anreize geben, die genauso gut oder sogar besser funktionieren. Zum Beispiel, wenn eine Baugruppe speziell dafür ausgelegt ist, bestimmte Sensordaten zu aggregieren. Ein Prüfpfad oder sogar redundante Berechnungen könnten in einem solchen Fall Anreiz genug sein.
Abra Virtual Machine
Das Abra VM-Programmiermodell ist insofern sehr ehrgeizig, als dass es uns nicht nur ein Programmiermodell zur Verfügung stellt, das Quasi-Turing-fähig gemacht werden kann, sondern es entfernt sich auch von Standard-Opcode-basierten sequenziellen Befehlen, die von einer komplexen CPU verarbeitet werden. Stattdessen bietet es uns eine maximale Parallelisierung von Operationen durch ein Datenflussmodell, das letztlich nur zwei Arten von Operationen hat, mit denen jede Funktion implementiert werden kann: Lookup-Tables (LUTs) und Fusionen. Diese Operationen wurden speziell wegen ihrer Fähigkeit ausgewählt, einfach direkt in der Schaltung instanziiert zu werden. Die maximale Parallelisierung von Operationen wird nur bei der Instantiierung in Schaltkreisen erreicht. Die einzigen sequenziellen Datenflusspfade werden durch Operationen gebildet, die direkt von den Ergebnissen früherer Operationen abhängen. Alles andere kann parallel ausgeführt werden. Sie erhalten also maximal parallele sequenzielle Datenflusspfade.
Die Einfachheit des Abra VM-Programmiermodells bedeutet auch, dass es sehr einfach ist, einen Software-Emulator (Interpreter) zu erstellen, der diese VM auf einem Standardprozessor ausführen kann. In diesem Fall gehen viele Möglichkeiten der Parallelverarbeitung verloren, aber es werden trotzdem korrekte Verarbeitungsergebnisse geliefert. Für einfache SCs, die nur spärlich aufgerufen werden, könnten Sie also auf eine software-emulierte Abra-VM zurückgreifen. Wenn Sie jedoch Hardware-Beschleunigung benötigen, müssen Sie die VM tatsächlich in einer Schaltung implementieren. An dieser Stelle stellen wir uns drei Ebenen der Hardware-Implementierung vor.
- Verwenden Sie vorhandene FPGAs, um die Abra-VM zu implementieren. Dies hat den Vorteil, dass Sie den VM-Schaltkreis nur einmal für jeden unterschiedlichen FPGA-Typ erstellen müssen und Sie anschließend beliebigen Abra-VM-Code auf einem solchen Gerät ausführen können. Allein diese Fähigkeit ist bahnbrechend. Derzeit benötigen Sie einen sehr leistungsfähigen PC, der lange Zeit läuft, um die Schaltung für ein Programm zu entwerfen, das auf einem bestimmten FPGA-Typ läuft, und das ist etwas, das Sie jedes Mal tun müssen, wenn Sie etwas an Ihrem Programm ändern oder wenn Sie einen anderen FPGA-Typ anvisieren. Stattdessen layouten Sie jetzt die Schaltung für unsere Open Source Abra VM nur einmal für jeden FPGA-Typ. Danach können Sie das Programm, das Sie auf der VM ausführen möchten, einfach ändern, neu kompilieren, laden und auf jedem FPGA ausführen, der die Abra-VM ohne weitere Änderungen implementiert hat.
- Verwenden Sie einen ASIC, um die Abra VM direkt zu implementieren. Das bedeutet, dass wir ein Open-Source-ASIC-Design für eine Abra-VM erstellen werden. Der Vorteil ist, dass wir die Erstellung eines programmierbaren Bauteils vermeiden, das auf einem anderen (proprietären) programmierbaren Bauteil (FPGA) läuft. Statt die Blöcke des FPGA zu programmieren, können wir direkt einen ASIC-Schaltkreis erstellen, der die Abra-VM implementiert. Das bedeutet nicht nur eine Geschwindigkeitssteigerung, sondern auch eine enorme Verringerung der Menge der erforderlichen Schaltungen. Ein solcher Abra VM ASIC könnte leicht als Co-Prozessor für aktuelle Hardware oder als Hauptprozessor für bestimmte IoT-Anwendungen eingesetzt werden.
- Wenn Sie einen spezifischen Code für den Abra VM programmiert haben und überprüft haben, dass er korrekt funktioniert, könnten Sie auch einen ASIC erstellen, der die Operationen für diesen spezifischen Code als dedizierte Schaltung implementiert. Sie würden den allgemeinen Aspekt der Programmierbarkeit der VM-Implementierung verlieren, aber es gibt viele Anwendungsfälle, in denen Sie die einmal eingesetzte Hardware nie mehr ändern werden. Vor allem bei Sensoren und anderen Geräten, die Sie in Bereichen einsetzen, in denen Sie nach dem Einsatz nicht mehr so leicht darauf zugreifen können. Dies ist die IoT-Vision, auf die wir letztendlich hinarbeiten. Die Einfachheit der Operationen, aus denen sich der spezifische Programmcode zusammensetzt, macht die Erstellung eines ASICs relativ einfach, und der generierte Schaltkreis erlaubt tatsächlich eine Reihe verrückter Optimierungen auf der Ebene der Logikgatter, da er keine programmierbaren Allzweck-Schaltkreise mehr verwendet.
Die wirklichen Verbesserungen des Abra VM-Programmiermodells, wie der reduzierte Energiebedarf, die Aspekte des Datenflusses und die Möglichkeit des Wave-Pipelining werden diese letzte Implementierungsebene benötigen, um wirklich zu glänzen. Die allgemeineren programmierbaren Ebenen sind mit bestimmten Designeinschränkungen verbunden, die zusätzlichen Overhead verursachen werden.
Ternäre Kodierung
Vielleicht ist Ihnen aufgefallen, dass in all dem oben genannten noch keine Erwähnung des Wortes Ternär enthalten ist. Natürlich wäre es möglich, diese gesamte Vision binär umzusetzen, aber ein Teil der Qubic-Vision war schon immer die Fähigkeit, über die Grenzen der derzeitigen Ausführungsmodelle hinauszugehen und die Hardware über das Mooresche Gesetz hinaus zu erweitern, das wohl sein Ende gefunden hat. Zu diesem Zweck haben wir immer die Vision eines ternären Ausführungsmodells gehabt. Auch wenn es noch keine nativen ternären Prozessoren gibt, so kann dieses Modell doch einige Vorteile bieten. Die bemerkenswertesten unmittelbaren Vorteile sind: Datendichte und Berechnungsgeschwindigkeit.
Unser Programmiermodell arbeitet mit Schaltungen und daher mit der Informationseinheit der untersten Ebene. Bei binären Systemen wäre das ein Bit. Aber das Abra-Datenflussmodell erfordert auch eine Darstellung der “Abwesenheit von Daten” (Null), die für seinen Entscheidungslogikmechanismus entscheidend ist. Die normale Art und Weise, dies in binären Systemen darzustellen, wäre, ein zusätzliches Bit zu haben, um diesen Zustand anzuzeigen. Das bedeutet, dass jedes Informationsbit durch zwei Bits repräsentiert werden muss, um alle drei möglichen sich gegenseitig ausschließenden Zustände (0, 1 und null) kodieren zu können. Da aber 2 Bits 4 Zustände repräsentieren können, erscheint es nur natürlich, dies in vollem Umfang zu nutzen. Durch die Verwendung der ternären Kodierung benötigen wir immer noch nur 2 Bits, um die 4 sich gegenseitig ausschließenden Zustände (-, 0, 1 und null) darzustellen. Das bedeutet, dass wir Werte im Vergleich zur binären Kodierung, die sonst einen dieser 4 möglichen Zustände verschwenden würde, effizienter kodieren können. Im Vergleich zur ternären Kodierung benötigt die binäre Kodierung etwa 50% mehr 2-Bit-Informationseinheiten, um den gleichen Wertebereich darstellen zu können. Beispielsweise können 16 Bit Werte von -32768 bis +32767 kodieren, während nur 11 Trits bereits Werte von -88573 bis +88573 kodieren können.
Sobald Sie weniger Informationseinheiten zur Darstellung desselben Wertebereichs benötigen, sind auch bestimmte Berechnungen viel schneller. Nehmen Sie zum Beispiel einen einfachen Ripple-Carry-Addierer. Um zwei Werte zu addieren, addiert er zwei entsprechende Informationseinheiten, was jedoch zu einem Übertrag auf die Addition der nächsten Einheit führen kann. Das heißt, wenn Sie 50 % mehr Einheiten benötigen, um einen Wertebereich darzustellen, dauert die Ausführung einer solchen Addition ebenfalls 50 % länger. Der Engpaß hierbei ist die Tatsache, dass jede Addition von der vorherigen Addition abhängt, da sie den Übertrag berücksichtigen muss. Die nächste Addition kann also erst dann erfolgen, wenn die vorhergehende vollständig ist und der Wert des Übertrags bekannt ist. Bringen Sie dies nun auf eine andere Ebene: Multiplikation. Wenn Sie die einfache Methode verwenden, jede Einheit mit jeder Einheit zu multiplizieren, erhalten Sie eine zweidimensionale Abhängigkeit, was bedeutet, dass die Verarbeitungszeit bei Verwendung desselben Algorithmus mit binärer Kodierung 150% x 150% oder 225% der Zeit benötigt, die der Algorithmus bei Verwendung einer ternären Kodierung benötigen würde.
Die ternäre Kodierung, die wir für unsere FPGA-Prototyp-Implementierung verwendet haben, nennen wir 2b-Kodierung. Diese kodiert die 4 Zustände (-, 0, 1 und null) jeweils als (10, 11, 01 und 00). Wir nennen diese 2b-Kodierung, weil sie, wie oben diskutiert, 2 Bits pro Informationseinheit verwendet. Wir haben auch eine Alternative entwickelt, die wir 3b-Kodierung nennen, die 3 Bits pro Informationseinheit verwendet und die 4 Zustände jeweils als (100, 010, 001 und 000) kodiert. Die 3b-Kodierung mag vielleicht verschwenderischer erscheinen, aber sie hat eine Reihe interessanter Eigenschaften, die für die dritte Ebene der Hardware-Implementierung (direkter Code zur Schaltung) von größerer Bedeutung sind und in Zukunft noch eingehender untersucht werden sollen. Der Abra-Code ist völlig unabhängig von der verwendeten Kodierung. Die tatsächlich verwendete Kodierung wird letztlich von der spezifischen Implementierung der Abra-VM diktiert.
Sowohl die 2b- als auch die 3b-Kodierung verwenden alle Nullen, um den Nullzustand zu kodieren. Dies sollte dazu beitragen, den Energiebedarf der Hardware zu reduzieren, da der Null-Zustand der Standardzustand für alle Schaltkreise ist und normalerweise die meiste Energie darauf verwendet wird, den Zustand zu ändern. Abra ist so konzipiert, dass Entscheidungspfade so früh wie möglich zur Verwendung des Null-Zustands gezwungen werden, so dass keine Daten durch den größten Teil der Schaltung wandern und nicht verwendete Schaltungen ohne Umschalten im Standard-Null-Zustand bleiben können.
„Echte” ternäre Hardware
Wie die Kodierung auf tatsächlich nativer ternärer Hardware aussehen wird, ist derzeit schwer vorstellbar, da wir noch kein funktionierendes ternäres System haben, mit dem wir arbeiten könnten. Eine interessante Idee, die aus der Qubic-Forschung hervorging, ist, dass man ein binäres Bit und den erforderlichen Nullzustand mit einem einzigen ternären Trit kodieren könnte da ternäre Prozessoren vermeintlich mit 3 Zuständen arbeiten. Dies würde bedeuten, dass ternäre Hardware unser Datenflussmodell direkt mit binärer Informationskodierung unterstützen kann. Anstatt also 2 Drähte und alle zugehörigen Schaltkreise pro Draht zu benötigen, um ein Bit und ein Null-Kennzeichen zu erzeugen, bräuchte man nur einen einzigen Draht und die zugehörigen Schaltkreise, wodurch vielleicht sogar die Schaltkreise/die benötigte Energie halbiert würde, die sonst für die gleiche binär codierte Verarbeitung in binärer Hardware erforderlich wäre. Ternäre Hardware ist derzeit in erster Linie eine Denksportaufgabe, aber es ist definitiv ein aufregendes Unterfangen für die Zukunft.
Hardware-Operationen
Das Abra-Programmiermodell hat ursprünglich 5 verschiedene explizite Operationen. 3 dieser Operationen reduzieren sich auf eine einfache Verdrahtung, sobald man sie auf Schaltungsebene implementiert. Sie sind nur notwendig, um Informationen als Trit-Vektoren zu gruppieren und weiterzugeben. Da aber auf der Schaltungsebene alles auf einzelnen Trits arbeitet, sind diese Trit-Vektoren meist konzeptionell. Daher erzwingen die Verkettungs- und Slicing-Operationen lediglich die korrekte Gruppierung von Informationen. Die Aufruf-Operation ist nur vorhanden, um effizient Code in einen Aufruf-Baum reduzieren zu können, aber sobald sie in einer Schaltung implementiert ist, erzwingt jede Aufruf-Operation die Instantiierung des gesamten aufgerufenen Funktionsbaums in der Schaltung und verknüpft die Eingangs- und Ausgangs-Trit-Vektoren mit ihren Quell- und Zielvektoren.
Damit bleiben nur noch 2 Operationen übrig, die tatsächlich als logische Schaltung implementiert werden. Die erste ist die ternäre Lookup-Operation, die 3 Eingangstrits nimmt und einen einzelnen Trit gemäß der entsprechenden Lookup-Tabelle ausgibt. Die zweite ist die Merge-Operation, die getrennte Datenfluss-Eingänge zu einem einzigen Ausgang kombiniert und entweder als eine sehr spezielle Lookup-Operation oder durch Verwendung einfacher ODER-Gatter implementiert werden kann. Nur eine Eingabe darf ungleich Null sein und wird zur Ausgabe. Die Sprache Qupla, die den Abra-Code generiert, stellt sicher, dass nur ein Pfad ungleich Null sein kann. Alle anderen Werkzeuge, die direkt Abra-Code erzeugen würden, sind erforderlich, um dies sicherzustellen.
Der FPGA-Proof of Concept
Um das Programmiermodell auf FPGA zu ermöglichen, haben wir den FPGA so programmiert, dass er eine Bank von so genannten QLUTs (Qubic Look-Up Tables) bereitstellt. Jeder QLUT nimmt drei 2b-kodierte Trits als Eingabe und gibt dann einen weiteren 2b-kodierten Trit über eine konfigurierbare Nachschlagetabelle aus. Fusionen werden innerhalb der QLUTs durch Setzen eines speziellen Konfigurationsbits implementiert, das sie veranlasst, eine vordefinierte Lookup-Operation mit leicht unterschiedlicher Semantik zu verwenden.
Natürlich enthält der FPGA auch die zusätzliche Konfigurationslogik, die notwendig ist, um jede Eingangsoperation mit jeder Ausgangsoperation verbinden zu können. Diese Logik kann durch eine spezielle binäre Konfigurationsdatei konfiguriert werden, die leicht direkt aus dem auszuführenden VM-Code generiert werden kann. Der Code wird derzeit “on the fly” konvertiert, wenn er an den FPGA gesendet wird. Sie enthält die Konfigurationsdaten für jedes einzelne QLUT und die Konfigurationsdaten für die Verbindungen zwischen den QLUTs.
Die QLUTs wurden bereits getestet, indem die gesamte Qupla-Testsuite im Emulator ausgeführt wurde, während eine bestimmte Funktion hardwarebeschleunigt wurde. Wir erlauben dem Benutzer, eine Funktion als hardwarebeschleunigt zu markieren, und die Qupla-Umgebung lädt automatisch die Konfigurationsdaten für diese Funktion in den FPGA. Wenn dann der Emulator ausgeführt wird, übergibt er jedes Mal, wenn er auf diese spezifische Funktion trifft, die Eingangsdaten der Funktion an das FPGA und verwendet die resultierenden Ausgangsdaten, anstatt das Ergebnis für diese Funktion vom Emulator berechnen zu lassen. Wir haben mehrere repräsentative Funktionen auf diese Weise getestet und freuen uns, berichten zu können, dass dies perfekt funktioniert.
Als Nächstes benötigen wir eine FPGA-Version des Qubic Supervisors, d.h. der Entität, die Eingangsdatenereignisse an den korrekten VM-Code sendet und die berechneten Ergebnisse weiterleitet. Um zu vermeiden, dass wir ein Miniaturbetriebssystem schreiben müssen, werden wir zunächst eine einfache Embedded-Linux-Version verwenden, die auf einer CPU laufen kann, die auf dem FPGA eingebettet ist. Auf diese Weise können wir bestimmte Funktionen out of the box nutzen, ohne sie selbst entwickeln zu müssen. Es ist uns bereits gelungen, dieses Linux auf dem FPGA zu booten und es zu verwenden, um die Kommunikation zwischen dem Emulator und dem FPGA über ein einfaches Socket-Protokoll abzuwickeln. Der nächste Schritt wird die Implementierung des Supervisors und einiger zusätzlicher Verknüpfungscodes sein, um stattdessen die Kommunikation mit der Außenwelt über HTTP zu ermöglichen.
Der nächste Schritt wäre die Implementierung eines HTTP-Listeners auf dem Embedded-Linux des FPGAs, der auf zwei Arten von Anfragen reagieren kann. Der erste Anfragetyp kann verwendet werden, um die Konfigurationsdatei auf den FPGA zu übertragen, und dieser wird dann zur Konfiguration des Programmiermodells, zur Einrichtung einer HTTP-Callback-Adresse und zur Initialisierung des Supervisors verwendet. Der zweite Anforderungstyp ist eine Eingabedatenanforderung, die verwendet werden kann, um die Ausführung einer Funktion mit den vom Supervisor bereitgestellten Eingabedaten auszulösen. Nach der Berechnung des Ergebnisses sendet der Supervisor die resultierenden Ausgabedaten asynchron an die HTTP-Callback-Adresse.
Beachten Sie, dass dies bedeutet, dass der anfängliche End-to-End-Proof of Concept (Qupla-to-FPGA, der ursprünglich für Ende Januar 2020 geplant war) noch nicht die volle Supervisor-Funktionalität haben wird, sondern nur in der Lage sein wird, eine einzige beliebige Funktion auf dem FPGA einzurichten und aufzurufen und das Ergebnis zurückzugeben. Das Laden und Aufrufen mehrerer Funktionen und komplexere Planung durch EEE wird der nächste Schritt für die Implementierung im Supervisor-Code sein.
Auf der Softwareseite ist der Qupla-Compiler jetzt in der Lage, eine spezifische Version des Abra-Codes zu erzeugen, die leichter eine 1-zu-1-Konvertierung in die binäre Konfigurationsdatei ermöglicht, indem alle Verkettungs-, Slice- und Aufrufoperationen eliminiert werden. Wir haben überprüft, dass der resultierende transformierte Code immer noch korrekt funktioniert, indem wir die Testsuite mit diesem Code im Emulator ausgeführt haben. Der Emulator selbst ist nun in der Lage, über die Socket-Schnittstelle eine Schnittstelle zum FPGA herzustellen. Er sendet die generierte Konfigurationsdatei an das FPGA und ruft diese Funktion bei Bedarf auf. In Zukunft wird der Qupla-Supervisor in der Lage sein, Ereignisse über die HTTP-Schnittstelle zum und vom FPGA zu senden.
Erste Lehren aus dem PoC
Bis jetzt funktioniert alles wie vorgesehen. Wir haben ein völlig neues Verarbeitungsmodell geschaffen, das jede Art von allgemeiner Verarbeitung durchführen kann. Das Modell behandelt die RAM-Speicherung genauso wie jede andere Art von E/A, d.h. es liegt außerhalb des Geltungsbereichs des Abra-Codes und wird an Entitäten weitergegeben, die Daten für uns mit Hilfe von EEE speichern/abrufen können. Dies erfordert eine andere Art der Problembetrachtung, und es wird wichtig sein, die resultierende Komplexität zu bewerten und/oder zu sehen, ob es eine Möglichkeit gibt, die Komplexität in Qupla-Sprachkonstrukten zu verbergen, oder ob eine noch höhere Computersprache erforderlich ist. So wurde beispielsweise bereits die Notwendigkeit einer Art von Schleifenkonstrukt erkannt.
Zwei unmittelbare Hürden zeichnen sich derzeit ab und erfordern eine Lösung.
- Der derzeitige Ressourcenbedarf der QLEs auf dem ausgewählten FPGA (DE10-Nano) beschränkt uns auf insgesamt nur 512 QLEs. Dies mag ein wenig optimiert werden, aber wir erwarten nicht, dass sich dieser Bedarf auf mehr als etwa das Doppelte erhöht. Natürlich könnten wir einen größeren, teureren FPGA auswählen, aber für das Prototyping wollen wir es einfach und erschwinglich halten für Leute, die unsere Anstrengungen kopieren und damit herumspielen möchten. Eine direkte Folge davon ist, dass wir nur einige kleinere Funktionen auf den FPGA laden können, und der Kommunikations-Overhead beim Aufruf dieser Funktionen überwiegt meist den Verarbeitungsgewinn. Das war zu erwarten, und wir hoffen, dass wir, sobald wir zum nächsten Schritt übergehen, einem ASIC Abra VM, über diese Größenordnung hinausgehen können.
- Die Instantiierung von Funktionsaufrufen wird sehr schnell unerschwinglich. Aufgrund der Aufrufbaum-Natur des Codes hat die Expansion eines solchen Aufrufbaums ein exponentielles Wachstum. Wenn X dreimal Y aufruft, was wiederum viermal Z aufruft, erhalten Sie drei vollständige Y-Instanziierungen, die 3×4 oder 12 vollständige Z-Instanziierungen verursachen. Sie können sehen, wie schnell dies eskaliert. Die Lösung dieses Problems wird unser Hauptaugenmerk sein müssen. Derzeit schwirren einige Ideen herum, aber wir haben uns noch nicht mit allen Konsequenzen für das Datenflussmodell befasst.
Übrigens leidet der Abra-Emulator nicht unter diesen Problemen, weil er die Funktionsinstantiierung durch einen gewöhnlichen stapelbasierten Funktionsaufrufmechanismus emuliert und die Lookup-Tabellen in einem von den Lookup-Anweisungen getrennten Speicher ablegt. Heutige Gigabyte RAM-Größen würden Millionen von Abra VM-Befehlen ohne Probleme ermöglichen.
Schlussfolgerung
Nach einem langen Weg mit vielen unvorhergesehenen Hürden haben wir bewiesen, dass das Abra-Datenflussprogrammiermodell durchgängig funktioniert, von der Programmiersprache Qupla bis zur Ausführung des generierten Codes auf dedizierter FPGA-Hardware. Wir laden alle ein, mit dem Qupla-Repository herumzuspielen und zu sehen, was Qupla kann und wie es im Emulator läuft. Diejenigen, die sich mehr für Hardware interessieren, können mit dem Qubic HDL-Repository herumspielen und tatsächlich Code auf einem DE10-Nano ausführen, so wie wir es tun, oder sogar den Code an Ihr eigenes bevorzugtes FPGA-System anpassen.
Eine neue Ausrichtung für Smart Contracts auf IOTA
Auch wenn diese Arbeit die Vision hinter Qubic beweist und einen großen Schritt nach vorn darstellt, sind noch weitere Fragen zu lösen und es sind noch erhebliche Entwicklungsinvestitionen erforderlich, um Qubic produktionsreif zu bekommen. Unsere umfangreiche Arbeit an Qubic hat viel wertvolle Forschung und Entwicklung hervorgebracht und bildet die Grundlage für unseren weiteren Ansatz. Dementsprechend hat die IOTA-Stiftung die Entscheidung getroffen, die Entwicklung von Qubic anzuhalten und den Fokus speziell auf den Smart Contract Layer zu richten.
Der Hauptgrund für diese Entscheidung besteht darin, dass IOTA mit der neuartigen Smart-Contract-Lösung, die in Verbindung mit der Coordicide-Node-Software arbeitet, schneller auf den Markt gebracht werden kann. Am Ende verfügen wir über ein komplettes System – bereit für eine breitere und schnellere Einführung.
IOTA Smart Contracts ist das, was wir unsere Smarte Layer-2-Contract Lösung nennen. Sie ist aus der in diesem Beitrag beschriebenen Entwicklung hervorgegangen und wurde von Grund auf neu konzipiert. Mit IOTA Smart Contracts wollen wir eine Vision für Smart Contracts verfolgen, die skalierbar ist und niedrige Transaktionskosten hat.
Wir arbeiten derzeit an einer Alpha-Version der IOTA Smart Contracts im Rahmen der GoShimmer-Implementierung, und wir werden in Kürze weitere Informationen über diesen neuen Weg veröffentlichen. Wenn die Alpha-Version fertig ist, wird sie von einer Reihe einfacher Smart Contract PoCs begleitet werden, um Community-Entwicklern den Einstieg zu erleichtern und zu demonstrieren, was möglich ist, um eine neue Ära von Anwendungen auf der Basis von IOTA anzustoßen.
Fühlen Sie sich jederzeit eingeladen, unser Ingenieursteam direkt in den Smart-Contract-Kanälen über den IOTA-Discord zu erreichen und Fragen zu diesem von uns eingeschlagenen neuen Weg zu stellen.
Quellen
https://blog.iota.org/the-state-of-qubic-63ffb097da3f
