Radix Engine: Ein besseres Modell für „Enshrinement

In meinem Vorheriger Artikel Ich habe erläutert, wie Radix Engine einige der Fehler in Suis MoveVM vermieden hat. Zusammenfassend:

• Suis MoveVM ist zu niedrigstufig und allgemein, was eine umständliche DeFi-Programmierumgebung ergibt.
• Radix Engine ist hochrangig und auf Asset- und Geschäftslogik ausgerichtet, sodass sich Entwickler auf die DeFi-Logik statt auf Details auf niedriger Ebene konzentrieren können.

Suis MoveVM folgt dem Original Ethereum-Philosophie eines „sauberen, einfachen, schönen“ Protokolls, das alles an die Anwendungsschicht delegiert. Dies gibt Entwicklern die Freiheit, jede Domäne zu erkunden, auch unbekannte.

Ein zu einfaches und unstrukturiertes Protokoll führt jedoch zu erheblichen Kompromissen. So würden beispielsweise gängige Systemfunktionen wie die Autorisierung eine komplexe Implementierung im Anwendungsbereich erfordern, Standardschnittstellen könnten stärker fragmentiert werden und die Leistungsoptimierung würde schwieriger.

Radix Engine hingegen ist auf die Ausführung nicht-generischer, systemweiter Logik als zentrales technisches Ziel ausgelegt, da es uns Folgendes ermöglicht:

• Setzen Sie systemweite Standards/Implementierungen durch . Ein eigenwilliger Standard erleichtert die Entwicklung/Wartung/Werkzeugbereitstellung über den gesamten Stack hinweg, da die APIs nicht fragmentiert sind (z. B. ERC-20 vs. ERC-721 vs. ERC-404) und das Verständnis des Verhaltens keine Bytecode-Interpretation erfordert (keine ERC-20-Rug-Pulls mehr). Dies bietet Entwicklern und Endbenutzern ein sichereres und konsistenteres DeFi-Erlebnis.
• Führen Sie die Logik näher an der Hardware aus . Da die Systemlogik für ihre Richtigkeit nicht von einem Interpreter ausgeführt werden muss, kann die Ausführung dieser Logik so nah wie möglich an der Hardware erfolgen.
• Parallelisieren Sie die Ausführung. Wenn Sie das Verhalten bestimmter Objekte genau kennen, können Sie vor der Ausführung leichter Entscheidungen zur statischen Analyse treffen, was eine parallele Ausführung ermöglicht.

Vitalik hat diese Idee kürzlich mit dem Begriff „ Verankerung “ oder die Idee, sich selektiv von der Abstraktion zu lösen, um die Vorteile einer protokollgestützten Logik zu nutzen. Er klaut eines seiner Bilder und stellt das Problem als einen Kompromiss zwischen Abstraktion und Verankerung dar:

Dieses Gleichgewicht zwischen der Unterstützung von Abstraktion (also zukünftigen/diversen Benutzeranforderungen) und der Aufrechterhaltung von Leistung, Sicherheit und Benutzerfreundlichkeit (also der Verankerung) ist eigentlich ein sehr altes Problem der Informatik. Insbesondere bei der Entwicklung von Betriebssystemen wird seit Jahrzehnten versucht, ein ähnliches Problem zu lösen: Wie unterstützen wir eine Reihe abstrakter Anwendungen und halten gleichzeitig ein schnelles, sicheres und benutzbares System aufrecht?

In diesem Artikel werde ich erläutern, wie Radix Engine das Betriebssystemmodell verwendet, um ein Framework zu erstellen, das alle Arten der „Verankerung“ ermöglicht, ohne dass es zu einer Belastung der Protokollkomplexität oder einem von Vitalik befürchteten Flexibilitätsverlust kommt.

Sehen wir uns zunächst den aktuellen Industriestandard an, die Ethereum Virtual Machine („EVM“).

EVM als VM

Das EVM ist so einfach, dass es als virtuelle Maschine („VM“) mit den folgenden Opcodes modelliert werden kann:

• Turing-vollständiger Opcode-Satz
• Opcodes für Aufrufe anderer Smart Contracts
• Opcodes zum Lesen/Schreiben in den persistenten Speicher des aktuellen Smart Contracts

In EVM-Bytecode kompilierte Smart Contracts können dann auf einer solchen VM ausgeführt werden.

In diesem Modell erfordert jede Form der „Verankerung“ Änderungen an der EVM oder der VM-Hardware. Beispielsweise würde die Verankerung der BLS-Signaturunterstützung das Hinzufügen einer neuen Vorkompilierung erfordern. Die Implementierung EIP-2938 würde das Hinzufügen neuer Opcodes erfordern. Die Erweiterung dessen, was verankert ist, führt zwangsläufig zu einer größeren, komplizierteren VM und zwingt den Protokolldesigner, die von Vitalik beschriebene Entscheidung zu treffen.

Das allgemeine Problem bei diesem Modell ist, dass die Dichotomie Abstraktion/Verankerung zu sehr mit der Dichotomie Software/Hardware verknüpft ist. Das heißt, wenn Logik in das Protokoll eingebettet wird, muss sie in die VM eingebettet werden. Es gibt keine Möglichkeit, „verankerte Software“ oder Software auszudrücken, die Teil des Systems ist.

Betriebssysteme haben diese Dichotomie mit dem Begriff „Systemsoftware“ gelöst. Sehen wir uns das genauer an.

Das Betriebssystemmodell

Eines der Hauptziele eines Betriebssystems ist die Verwaltung der Software/Hardware-Dichotomie – oder genauer gesagt der Anwendung/Hardware-Dichotomie. Der Kern jedes Betriebssystems ist der Kernel, eine Software, die Anwendungen im Benutzerbereich und deren Zugriff auf die Hardware verwaltet. Kernelmodule und -treiber sind zusätzliche Systemsoftwareteile, die den Satz unterstützter Hardware erweitern oder die Kernelfunktionalität erweitern.

\Aus der Perspektive der „Verankerung“ sind der Kernel und seine Module verankerte Teile des Systems, verfügen aber über die Flexibilität von Software. Kernelmodule, virtuelle Maschinen („VMs“) und Systemprozesse im Benutzerbereich sind sogar noch „weicher“, da sie vom Kernel selbst abstrahiert sind.

In diesem Modell ermöglicht die Indirektionsschicht zwischen Anwendungen und Hardware, die Dichotomie Software/Hardware von der Dichotomie Abstraktion/Verankerung zu entkoppeln. „Systemsoftware“ ermöglicht die Verankerung, ohne die Hardware zu überlasten.

Radix Engine als Betriebssystem

Radix Engine nutzt dieses Betriebssystemmodell als Inspiration und umfasst mehrere Schichten, jede mit einer bestimmten Verantwortung und Abstraktion, wodurch Modularität und Plug-in-Fähigkeit des Systems ermöglicht werden.

Ein solcher modularer Aufbau ermöglicht die Durchsetzung der Systemlogik und ermöglicht gleichzeitig Folgendes:

• Erbt die Isolationseigenschaften der Schicht, in der es sich befindet . Beispielsweise kann ein verankertes Paket, obwohl es verankert ist, nicht auf beliebige Zustände zugreifen, sondern muss die Grenzen der Anwendungsschicht einhalten. Dies ist eine ähnliche Art von Sicherheit, die in Benutzerbereichstreibern oder im Mikrokernel-Design zu finden ist. Das heißt, das Risiko wird gemindert, indem jeder Teil des Systems isoliert wird, sodass Aktualisierungen im System (Verankerungen) nicht das gesamte System einem Risiko aussetzen.
• Greifen Sie auf die Funktionen der Ebene zu, in der es sich befindet. Beispielsweise kann ein verankertes Paket vom System bereitgestellte Authentifizierungs- und/oder Aktualisierbarkeitsfunktionen erben.
• Entkoppeln Sie die Governance. Dieses modulare Design ermöglicht, dass Innovationen in jedem dieser Module parallel und in unterschiedlichem Tempo erfolgen.

Lassen Sie uns nun jede dieser Schichten durchgehen und ihre jeweiligen Verantwortlichkeiten betrachten.

Anwendungsschicht

Die Anwendungsschicht ist für die Definition der Logik auf hoher Ebene verantwortlich. Bytecode, der diese Logik beschreibt, wird zusammen mit anderen statischen Informationen in einem ausführbaren Format namens Paket gebündelt. Pakete werden dann im Ledger gespeichert und stehen zur Ausführung zur Verfügung.

In dieser Schicht befinden sich Anwendungen, die in Scrypto geschrieben sind, der Rust-basierten Sprache, die wir für die DeFi-Entwicklung entwickelt haben. Scrypto-Programme werden in WASM-Programme kompiliert, die Zugriff auf eine Reihe von Funktionsexporten haben, die dem Programm den Zugriff auf System-/Kerneldienste ermöglichen. Dies Systemaufruf-API ist ähnlich dem Linux Systemaufrufe , die Zugriff auf gemeinsam genutzte E/A ermöglichen.

VM-Schicht

Die nächste Schicht ist die VM-Schicht, die für die Bereitstellung der Rechenumgebung für die Anwendungsschicht verantwortlich ist. Dazu gehören eine Turing-vollständige VM sowie die Schnittstelle für den Zugriff auf die Systemschicht.

Radix Engine unterstützt derzeit zwei VMs: eine Scrypto WASM-VM zum Ausführen von Scrypto-Anwendungen und eine native VM, die native Pakete ausführt, die in die Umgebung des Hosts kompiliert werden.

Wenn wir uns speziell die Scrypto WASM VM ansehen, sieht sie folgendermaßen aus:

Dies mag im Wesentlichen dem EVM-Modell entsprechen, es gibt jedoch zwei entscheidende Unterschiede:

• Entfernung des direkten Zugriffs auf den Speicher. Anstatt dass jeder Smart Contract nur auf seinen eigenen Speicher zugreifen kann, erfolgt das Lesen und Schreiben von Zuständen über Systemaufrufe. Diese Indirektionsebene ermöglicht die Implementierung vieler interessanter Dinge im System, wie z. B. die gemeinsame Nutzung von Zuständen zwischen Anwendungen, die Virtualisierung von Zuständen usw. Diese Indirektionsebene ähnelt der Indirektionsebene von virtueller Speicher oder Linux Dateideskriptoren .

  
  

• Hinzufügen von Systemaufrufen . Systemaufrufe sind der Mechanismus, mit dem die Anwendungsschicht auf Dienste der Systemschicht zugreifen kann, z. B. um andere Anwendungen aufzurufen oder Daten in ein Objekt zu schreiben. Diese Systemaufrufe ähneln Software-Interrupt-Anweisungen in echten CPUs (z. B. INT Anweisung in x86).

Systemebene

Die Systemschicht ist für die Wartung einer Reihe von Systemmodulen oder steckbarer Software verantwortlich, die die Funktionalität des Systems erweitern können. Diese ähneln den Linux- Kernelmodule .

Bei jedem Systemaufruf wird jedes Systemmodul aufgerufen, bevor die Systemebene die Kontrolle an die Kernelebene übergibt. Beim Aufruf kann jedes Systemmodul einen bestimmten Status aktualisieren (z. B. ausgegebene Updategebühren) oder in Panik geraten, um die Transaktion zu beenden (z. B. wenn der Typprüfer fehlschlägt).

Dieses Muster ermöglicht dem System die Implementierung von Funktionen wie Autorisierung, Lizenzgebühren oder Typprüfung, während es von der Anwendungs- und Kernelebene entkoppelt ist.

Kernel-Schicht

Die Kernelschicht ist für die beiden Kernfunktionen der Radix Engine verantwortlich: Speicherzugriff und Kommunikation zwischen Anwendungen. Dies ähnelt der Verantwortung des herkömmlichen Betriebssystems für den Festplatten- und Netzwerkzugriff.

Für Radix Engine umfasst dies die folgende Low-Level-Verwaltung:

• Überprüfen Sie, ob die Move/Borrow-Semantik bei jedem Aufruf oder Datenschreiben beibehalten wird. Die Single-Owner-Regel und die Borrow-Regeln werden vom Kernel erzwungen. Bei einem Versagen einer dieser Regeln gerät die Transaktion in Panik.
• Verwalten Sie flüchtige und persistente Objekte. Ein Objekt kann sich zu jedem Zeitpunkt im globalen Raum befinden oder einem Aufrufrahmen gehören. Der Kernel verwaltet während der Laufzeit korrekte Zeiger auf diese Objekte, während Verweise auf diese Objekte weitergegeben werden.
• Verwalten Sie Aktualisierungen des Transaktionsstatus. Der Kernel verfolgt die Statusaktualisierungen, die während einer Transaktion aufgetreten sind und die anschließend am Ende der Transaktion in die Datenbank übertragen werden.

Verborgene Software

In welcher Beziehung stehen diese Schichten zur Verankerung in einem DLT-Protokoll? Ähnlich wie die Kernelschicht in Betriebssystemen bieten diese mittleren Schichten der Radix Engine die erforderliche Indirektion, um die Dichotomie Abstraktion/Verankerung von der Dichotomie Software/Hardware zu entkoppeln und den Begriff „verankerte Software“ zu schaffen.

Verankerte Software verfügt über die Flexibilität und Sicherheitseigenschaften von Software und behält gleichzeitig die Fähigkeit, systemweite Logik durchzusetzen.

Lassen Sie uns einige Verankerungsbeispiele durchgehen, die derzeit im Radix-Netzwerk ausgeführt werden, und sehen, wie sie implementiert werden.

Verankerte Ressourcen

Das Hauptunterscheidungsmerkmal der Radix DeFi/Web3-Plattform ist die Idee, dass eine Ressource (also ein Vermögenswert) ein grundlegendes Primitiv ist, das getrennt von der Geschäftslogik verstanden werden sollte. Durch die Verankerung dieses Konzepts können alle dApps, Wallets und Tools ein gemeinsames Verständnis davon entwickeln, wie die Schnittstelle und das Verhalten eines Vermögenswerts aussehen, was die Zusammensetzbarkeit erheblich erleichtert.

Obwohl Ressourcen zu den am tiefsten verwurzelten Bestandteilen des Systems gehören, sind für die Implementierung ihrer Verankerung lediglich zwei modulare Softwarekomponenten erforderlich:

• Ein natives Paket, das die Logik von Ressourcenobjekten wie Buckets, Vaults und Proofs verarbeitet

• Ein Systemmodul, das die Lebensdauerinvarianten dieser Objekte erzwingt (wie etwa die Verschiebbarkeit und Brennbarkeit von Ressourcen)

  
  

Die Tatsache, dass Radix Engine das tiefgreifende Konzept einer standardisierten, verschiebbaren Ressource ausdrücken konnte, während es vom System/Kernel abstrahiert wurde, zeigt die Leistungsfähigkeit eines modularen Systemsoftware-Frameworks.

Festgeschriebene Genehmigungen und Lizenzgebühren

Radix Engine standardisiert Autorisierung und Lizenzgebühren, indem diese Logik von der Geschäftslogik entkoppelt und als Systemfunktionen implementiert wird. Dadurch erhalten Benutzer und Entwickler eine integrierte gemeinsame Möglichkeit, die Anforderungen für den Zugriff auf alle Funktionen im Hauptbuch zu verstehen.

Die Modularität der Entkopplung der Geschäftslogik von der Systemlogik ermöglicht auch praktische Entwicklungs-/Debugging-Optionen, wie etwa die Möglichkeit, eine Vorschau einer Transaktion ohne die normalen Authentifizierungsprüfungen anzuzeigen (Sie möchten das Ergebnis der Überweisung von 10 Millionen USDC irgendwohin simulieren? Bei deaktivierter Autorisierung kann Ihre Vorschau-Transaktion die Prägung durchführen!).

Für die Verankerung von Authentifizierung und Lizenzgebühren sind vier modulare Softwarekomponenten erforderlich:

• Native Auth- und Royalties-Pakete, die der Anwendungsschicht den Zugriff auf die Authentifizierung/Royalties jedes Objekts ermöglichen (beispielsweise um die Authentifizierungsregel für den Zugriff auf eine Methode abzurufen oder Royalties zu beanspruchen).

• Die Systemmodule „Auth“ und „Royalties“ werden vor dem Aufruf einer Objektmethode aufgerufen, um zu überprüfen, ob der Anrufer über ausreichende Autorisierung verfügt, um den Aufruf zu tätigen und Lizenzgebühren einzuziehen.

  
  

  
  

Verankerte Transaktion

Die richtige Schnittstelle zwischen Benutzer und System ist für die Nutzbarkeit eines Systems von größter Bedeutung. Um nutzbar zu sein, muss die Schnittstelle das richtige Gleichgewicht zwischen Benutzerfreundlichkeit und Leistung/Flexibilität finden.

In der Welt der Betriebssysteme ist die gebräuchlichste Schnittstelle das Terminal, ein Benutzerbereichsprozess, der einem Benutzer ein Befehlszeilentool zum Aufrufen und Verfassen verschiedener Systemaufrufe bereitstellt.

In der DLT-Welt ist diese Schnittstelle die Transaktion. Der Industriestandard für eine Transaktion besteht in der Verwendung eines einzigen allgemeinen Aufrufs auf niedriger Ebene. Leider ist dies zu einfach, da es schwer zu verstehen ist, was man bei der Interaktion mit dem System tatsächlich tut.

Radix Engine hingegen verwendet das traditionelle Betriebssystemmuster und verankert eine Anwendungssprache (ähnlich einer Terminal-Skriptsprache wie Bash), um Systemaufrufe in einer einzigen Transaktion aufzurufen und zusammenzustellen.

Da der Einstiegspunkt einer Transaktion in der Anwendungsschicht erfolgt, wird der Sprachinterpreter durch Hinzufügen eines nativen Transaktionsprozessorpakets implementiert.

Verankertes BLS

BLS-Signaturen sind ein wichtiges Krypto-Grundelement, da sie die Möglichkeit von Schwellenwertsignaturen ermöglichen. Leider verbraucht das Ausführen einer solchen Logik in WASM schnell die maximale Kosteneinheit. Im jüngsten „Anemone“-Update haben wir BLS durch native Ausführung verankert und im Vergleich zu WASM eine 500-fache Leistungssteigerung festgestellt.

Da die BLS-Logik zustandslos ist, kann sie problemlos als zusätzliche Vorkompilierung zur Scrypto WASM-VM hinzugefügt werden.

Abschluss

Was verankert werden soll und was nicht, ist für jedes DLT-Protokoll wichtig. Leider macht das bestehende VM-Modell der Branche jede Verankerungsentscheidung zu einer Entscheidung mit hohem Risiko.

Radix Engine orientiert sich am Betriebssystemmodell und löst dieses Problem, indem es eine Indirektionsebene zwischen „Software“ und „Hardware“ hinzufügt. Dadurch kann Radix Engine den Begriff „verankerte Software“ ausdrücken und dem Protokoll das Hinzufügen, Ändern und Ausdrücken neuer verankerter Systeme erleichtern, ohne dass Kompromissentscheidungen mit hohem Risiko getroffen werden müssen.

Ursprünglich war das Betriebssystem als kleines Softwareprogramm zur Verwaltung gemeinsam genutzter Ressourcen für mehrere Anwendungen gedacht. Da die Anforderungen der Benutzer an eine bessere, schnellere und sicherere Plattform immer größer wurden, übernahm das Betriebssystem mit einer immer größeren Softwaresuite immer mehr Verantwortung.

Bei DeFi wird es nicht anders sein. Da die Nachfrage nach einer schnelleren, sichereren und benutzerfreundlicheren DeFi-Plattform wächst, wird auch die Verankerung weiter voranschreiten. Radix Engine wurde mit diesem Gedanken im Hinterkopf entwickelt und bietet das skalierbare und sichere Framework, das für eine zukünftige Ausweitung der Verankerung erforderlich ist.