von Phil Lucsok

Viele Blockchain-Entwickler, Enthusiasten und Technologen bekommen oft die Frage gestellt: "Was können wir auf eine Blockchain setzen?" Wir können die frühen Beispiele einer Währung wie Bitcoin oder dezentralisierte Anwendungen und Smart Contracts, die auf Ethereum basieren, anführen. Wir können auch neuere, spezialisierte Beispiele anführen, wie das Building Blocks-Projekt des UN-Welternährungsprogramms, das Flüchtlingen Bargeld für Lebensmittel an Orten zur Verfügung stellt, an denen Banken und Zahlungssysteme unzuverlässig sind, oder sogar die Verfolgung der Lieferung von Arzneimitteln in den USA mit Hilfe des Mediledger-Netzwerks. Parity Technologies hat mit Substrate und dem umgebenden Tech-Stack die Technologie entwickelt, die es ermöglicht, diese neuen Blockchains zu entwickeln und für jedes Projekt oder Unternehmen einzusetzen.

Aber was sollte nicht in einer Blockchain enthalten sein? Welche Arten von Systemen und Funktionen sind zu rechenintensiv, um auf der Chain verarbeitet zu werden? Hier hat Parity daran gearbeitet, den Standard zu verbessern, wie Arbeit außerhalb der Chain erledigt werden sollte. Die Off-Chain Workers von Substrate ermöglichen es, dass Prozesse, die zu rechenintensiv sind, oder Daten, die zu umfangreich sind, von spezialisierten Nodes im Netzwerk verarbeitet werden. Gleichzeitig wird der Code für die Ausführung der Arbeit auf der Chain gespeichert, um sicherzustellen, dass die Teilnehmer automatisch mit der neuesten Logik, die ihre Chain vorgibt, auf dem Laufenden gehalten werden.

Welche Art von Arbeit lässt sich am besten außerhalb der Chain erledigen?

Möglicherweise ist es besser, die gegenteilige Frage zu beantworten: Die On-Chain-Logik wird vom gesamten Netzwerk verarbeitet. Daher ist jede Rechenoperation, die für die Verarbeitung einer Transaktion erforderlich ist, teuer (Sie zahlen dafür, dass jeder sie ausführt und die Ergebnisse speichert), langsam (jeder muss sich Zeit nehmen, um sich auf die Antwort zu einigen) und vollständig deterministisch (jeder muss alle, genau gleichwertige, Daten haben, um das Ergebnis zu berechnen). Die Off-Chain-Logik ist daher nicht nur geeignet, sondern sogar erforderlich, wenn die Berechnung umfangreich ist (wie bei ausgeklügelten demokratischen Mechanismen wie delegierten Abstimmungen), der Speicherbedarf groß ist (wie bei der Archivierung von Staking-Informationen, die zu einem späteren Zeitpunkt benötigt werden) und die Zeit von entscheidender Bedeutung ist, wenn Elemente der Berechnung geheim bleiben müssen (z.B. wenn Nodes ihre eigenen Geheimnisse für eine eventuelle Identifizierung verwalten können) oder wenn die auszuführenden Operationen notwendigerweise nicht-deterministisch oder anderweitig lokalisiert sind (z.B. Übergabe von Zufallszahlen, Abruf von Daten von einer Website oder Aufruf eines externen RPC).

All diese Beispiele und mehr würden viele Blockchains und dezentrale Netzwerke bereichern und sie für eine Vielzahl neuer Märkte und Teilnehmer nützlicher machen, aber es gab bisher Probleme bei der Einrichtung dieser Dienste, auch außerhalb der Chain.

In traditionellen Off-Chain-Umgebungen gibt es ein paar große Probleme für sichere Off-Chain-Berechnungen:

• Off-Chain-Mechanismen sind ein unabhängiger Prozess und erfordern als solcher eine eigene Wartung, die getrennt von der Blockchain selbst koordiniert werden muss. Dadurch entsteht ein großer Overhead für das Netzwerk als Ganzes. Die Pflege und Aktualisierung von Off-Chain-Funktionen ist mit einem hohen Aufwand und viel Kommunikation verbunden. Möglicherweise werden neue Anforderungen benötigt oder es werden Fehler gefunden, die behoben werden müssen.
• Off-Chain-Berechnungen werden traditionell auch über RPC kommuniziert, was langsam und unzuverlässig sein kann. Den Status einer Blockchain abzufragen und alle erforderlichen Header zu erhalten, ist schwierig und unzuverlässig. Wenn der Status, den Sie abfragen, zu umfangreich ist, kann es für die Nodes im Netzwerk manchmal unmöglich sein, Schritt zu halten.

Selbst wenn diese Probleme irgendwie behoben werden, ist die Übermittlung von Transaktionen mit diesen Daten mit einem hohen Arbeitsaufwand verbunden und kann sich als zu teuer für den Wert erweisen, den sie bietet.

Einführung von Substrate Off-Chain-Arbeitern

Um die Off-Chain-Datenintegration sicher und effizienter zu gestalten, bietet Substrate Off-Chain-Arbeiter. Das Subsystem der Off-Chain-Arbeiter ermöglicht die Ausführung langwieriger und möglicherweise nicht deterministischer Aufgaben (z.B. Web-Anfragen, Ver-/Entschlüsselung und Signierung von Daten, Generierung von Zufallszahlen, CPU-intensive Berechnungen, Aufzählung/Aggregation von On-Chain-Daten usw.), die andernfalls länger als die Ausführungszeit des Blocks benötigen würden.

Der Code für die Off-Chain-Arbeiter wird auf der Chain gespeichert und hat Zugriff auf die On-Chain-Umgebung, wird aber nie im Rahmen der Blockverarbeitung ausgeführt. Off-Chain-Arbeiter erleichtern die Ausführung des richtigen Codes und ermöglichen die Ausführung länger laufender Aufgaben, ohne die Blockchain aufzuhalten. Der On-Chain-Code ermöglicht jedoch die Implementierung von Überprüfungsmechanismen wie Abstimmung, Mittelwertbildung und Herausfordern in der State- Transition-Funktion der Blockchain, auf der er ausgeführt wird. Es obliegt dem Designer des Blockchain/Oracle-Netzwerks und denjenigen, die Nodes im Netzwerk betreiben, sich darüber zu einigen, wer was wann tun soll und wie die Teilnehmer belohnt und bestraft werden.

Möchten Sie einen Einblick in den Code erhalten? Sehen Sie sich dieses Callback-Beispiel an.

Wenn Sie möchten, dass traditionelle Orakel von mehreren Nodes und Behörden in Ihrem Netzwerk betrieben werden, ist dies sehr schwierig zu erreichen, insbesondere wenn Sie sie auf neue Versionen aktualisieren möchten. Off-Chain-Arbeiter lösen dieses Problem, indem sie diesen Teil der Infrastruktur im gesamten Netzwerk veröffentlichen, so dass die Nodes wissen, wann sie nicht mehr aktuell sind. Dies erleichtert die Bereitstellung und Wartung von Oracle-Netzwerken, die mit der Zeit immer größer, komplexer und ausgeklügelter werden.

Da sie Teil des Runtime-Codes sind und nicht als separater Prozess laufen, werden sie von Substrate selbst auf die gleiche Weise ausgeführt wie die State- Transition-Funktion bei jedem Blockimport - sie werden entweder in der sandboxed WebAssembly (Wasm)-Umgebung ausgeführt, oder, wenn die On-Chain-Codeversion mit der Node-Implementierung übereinstimmt, profitieren sie von Leistungsverbesserungen, die nativ laufen.

Off-Chain-Arbeiter APIs

Seitdem die Off-Chain-Arbeiter in einer Sandbox-Umgebung laufen, können sie aus Sicherheitsgründen nur auf eine begrenzte Anzahl von APIs zugreifen. Sie haben jedoch vollen Zugriff auf alle On-Chain-Zustände und verfügen über zusätzliche Möglichkeiten zur Kommunikation mit der Außenwelt über eine erweiterte Gruppe von APIs.

• Lokaler Speicher. Eine zusätzliche, lokale Schlüsselwert-Datenbank, die von allen Off-Chain-Arbeiter gemeinsam genutzt wird.
• HTTP-Anfragen API. Ein voll funktionsfähiger HTTP-Client, der den Zugriff auf und das Abrufen von Daten von externen Diensten ermöglicht.
• Eine sichere, lokale Entropiequelle für die Erzeugung von Zufallszahlen.
• Zugriff auf die genaue Zeit des lokalen Nodes und die Möglichkeit, die Arbeit zu unterbrechen/fortzusetzen.
• Zugriff auf den lokalen Schlüsselspeicher, um Aussagen oder Transaktionen zu signieren und zu verifizieren.
• Die Möglichkeit, Transaktionen (entweder signiert oder unsigniert) zurück auf die Chain zu senden, um Berechnungsergebnisse zu veröffentlichen.

Hinweis: Einige dieser APIs befinden sich noch in der Entwicklung. Weitere Informationen und die Dokumentation zur Nutzung werden veröffentlicht, sobald die APIs zur Verfügung stehen.

Probieren Sie die Substrate Off-Chain-Arbeiter aus, indem Sie sich die Pallet als Beispiel ansehen, lernen Sie anhand dieses Callbacks, oder sprechen Sie mit den Entwicklern im technischen Kanal von Substrate.