Das jüngste Update für Arbitrum beinhaltet das Stylus VM-Upgrade mit mehreren Verbesserungen:

• Erweiterte Sprachunterstützung
• Reduzierte Kosten und Speicherverbrauch
• Anpassbare Pre-Compiler
• EVM-Kompatibilität

Diese Verbesserungen sind auf die Integration von WASM zurückzuführen, das für seine zahlreichen Vorteile in Cloud-nativen Umgebungen bekannt ist. Weitere Einzelheiten zur Rolle von WASM werden in den folgenden Abschnitten behandelt.

Pioniere

Arbitrum hat WASM in seine Kette eingeführt, aber es ist nicht die erste Plattform dafür. Polkadot erlaubte zuvor die Erstellung von WASM-Smart Contracts. Dafür bietet es zwei Sprachen: ein Assembler-Skript ähnlich einem eingebetteten DSL und eine von Rust inspirierte Sprache namens Ink!

Ebenso nutzt Cosmos CosmWasm für die Ausführung intelligenter Verträge. Entwickler können hier intelligente Verträge mit Rust erstellen.

Bevor wir die Affinität der Blockchain zu WASM untersuchen, werfen wir einen Blick auf die Gründe von Cosmos und Polkadot für die Wahl von WASM.

Cosmos lobt WASM für diese Vorteile:

• Kompatibilität der Rust-Bibliothek
• Eine breite Entwickler-Community
• Verbesserte Sicherheit, einschließlich Schutz vor Wiedereintrittsangriffen
• Vereinfachte Testverfahren
• Überlegene Leistung

Die WASM-Laufzeitumgebung von Polkadot bietet Funktionen wie:

• Außergewöhnliche Leistung
• EVM-Interoperabilität
• Unabhängigkeit von Hardware- und Softwareplattform
• Kompakte Größe
• Unterstützung für Rust und Assembly Script, ähnlich wie Typescript

Polkadot, Cosmos und Arbitrum haben mehrere WASM-induzierte Vorteile gemeinsam. Allerdings verfügt Arbitrum über besondere Angebote, die wir später besprechen werden, zusammen mit den Besonderheiten von Cosmos.

WASM

Lassen Sie uns genauer untersuchen, was WASM ist und welche Beweggründe dahinter stehen.

Was ist WASM?

WebAssembly (WASM) ist ein binäres Befehlsformat. Es ermöglicht die Ausführung von Code mit vergleichbaren Geschwindigkeiten wie native Anwendungen, insbesondere in Webbrowsern. Als Kompilierungsziel für Sprachen wie C und Rust ist es auf Geschwindigkeit, Effizienz und Sicherheit optimiert. WASM verbessert die Web-Performance erheblich und erweitert die Web-Funktionalitäten.

WASM ist eng mit dem Web verbunden, da es in JavaScript-Umgebungen wie Browsern funktioniert. Innerhalb dieser Umgebungen haben Entwickler vollen Zugriff auf WASM-APIs sowie vollständige Web-API-Unterstützung. Dieses Steuerelement ermöglicht Entwicklern die Feinabstimmung von Webinteraktionen.

Die Entwicklung von WASM

Das Konzept von WASM basiert auf dem Ideal, Code einmal zu schreiben, um ihn überall auszuführen.

Im Jahr 2016 führten Programme häufig neue Funktionen über Domain Specific Languages (DSLs) ein. Bei der Erstellung eines DSL mussten Wartung, Effizienz und Sicherheit in Einklang gebracht werden. Die Branche suchte nach einer Methode, um Funktionen auf zahlreichen Servern bereitzustellen, ohne Kompromisse bei diesen Aspekten einzugehen.

Verschiedene Lösungen wurden geprüft, jede mit ihren eigenen Herausforderungen:

• Virtuelle Systemmaschinen hatten mit Overhead, mangelnder Code-Sichtbarkeit aus Sicherheitsgründen zu kämpfen und waren für eine hohe Leistung zu abstrakt.
• Den Containern fehlte außerdem die Code-Sichtbarkeit und sie waren ähnlich abstrakt, was einen erheblichen Mehraufwand verursachte.
• Virtuelle Maschinen auf Sprachebene erforderten aus Sicherheitsgründen häufige Modifikationen, verursachten Mehraufwand durch eingebettete VMs wie V8 und führten nur langsam bei der Übernahme neuer Sprachen zur Anpassung an Sicherheitsmodelle durch.
• Befehlssatzarchitekturen (ISAs) waren für ein effizientes Sandboxing schwer zu modifizieren und es fehlten ausgereifte Implementierungen.

WASM erwies sich als Lösung. Die Entwicklung von WASM-Compilern begann und bis 2018 wurde das Konzept der universellen Codekompatibilität über verschiedene Architekturen und Geräte hinweg erweitert. Im Gegensatz zu Java bestand das Ziel nicht darin, Kompromisse bei der Sicherheit einzugehen.

Im Jahr 2019 wurde das Komponentenmodell eingeführt, das WASM-Module für sprachübergreifende Interoperabilität verbessert. Diese Innovation ermöglichte beispielsweise die Schaffung einer universellen HTTP-Bibliothek, die in verschiedenen Sprachen anwendbar ist und komplexe Probleme auf innovative Weise angeht.

WASM heute

WASM verfügt über eine Reihe beeindruckender Funktionen:

• Hohe Leistung : WASM-Code läuft effizient und schnell.
• Kompakte Größe : Das Binärformat von WASM sorgt für einen geringen Platzbedarf.
• Portabilität : Ermöglicht die Ausführung desselben Bytecodes auf jeder WASM-kompatiblen Laufzeit.
• Sprachunterstützung : WASM unterstützt eine breite Palette von Sprachen, unter anderem von C/C++ und Rust bis hin zu Go und Swift.
• Kompatibilität mit JavaScript-Engines : WASM funktioniert nahtlos in JS-Engines.
• Sandboxing : Eine robuste Standard-Sandbox schränkt den Speicher- und CPU-Zugriff ein, um externe Störungen zu verhindern.
• Schneller Start : WASM-Module starten normalerweise in Millisekunden.

Die WASM-Community verbessert aktiv die Integration und Leistung verschiedener Programmiersprachen.

Stift

Die Erkundung des Potenzials von WASM und seiner Verwendung in Blockchains führt uns zurück zu den Einschränkungen von Arbitrum Stylus.

Funktionsweise des Stylus

Hier ist eine vereinfachte Aufschlüsselung der Funktionsweise von Stylus:

1. Entwickler verwenden Standard-WASM-Compiler wie Clang oder Rustc, um ihre Smart Contracts in WASM zu kompilieren.
2. Der resultierende WASM-Bytecode wird dann in komprimiertem Zustand in die Arbitrum-Kette hochgeladen.
3. Durch die Methode compileProgram der ArbWasm Vorkompilierung wird der Bytecode für Sicherheit und Gasmessung instrumentiert und in nativen Code kompiliert, der auf die Hardware des Validators zugeschnitten ist. Dieser Schritt ist entscheidend für die Verbesserung von Leistung und Sicherheit.
4. Beim Aufruf läuft der Vertrag auf einer WASM-Laufzeitumgebung wie Wasmer, die deutlich schneller und gaseffizienter als die EVM ist.

Der scheinbar zusätzliche dritte Schritt ist tatsächlich lebenswichtig. Die Konvertierung von WASM-Code in nativen Maschinencode beschleunigt die Ausführungsgeschwindigkeit. Darüber hinaus trägt diese zusätzliche Kompilierungsphase dazu bei, „Kompilierungsbomben“ zu verhindern.

Eine „Kompilierungsbombe“ ist bösartiger Code, der darauf ausgelegt ist, Systemressourcen während der Kompilierung zu erschöpfen und möglicherweise zum Absturz oder zum Stillstand des Compilers zu führen. Hierbei handelt es sich um einen Denial-of-Service-Angriff, der darauf abzielt, den Softwareentwicklungsprozess zu behindern.

Bedenken bezüglich des Stylus

Sprachunterstützung

Stylus hat die Entwicklergemeinschaft von Arbitrum um C++ und Rust erweitert. Es umfasst jedoch noch nicht die heute am weitesten verbreiteten Entwicklergemeinschaften. Es erleichtert die Ausführung intelligenter Verträge in Browsern, unterstützt jedoch noch kein JavaScript und Python.

Es gibt Projekte in der Anfangsphase, die versuchen, Python und JavaScript mit WASM zu verbinden. Diese sind jedoch aufgrund der Komplexität der Speicherbereinigung und Leistungsbedenken noch nicht für eine breite Einführung geeignet.

Sprachkompatibilität

Stylus unterstützt derzeit C/C++ und Rust über seine SDKs. Diese SDKs sind mit den Tools der jeweiligen Sprachen kompatibel. Sie ermöglichen auch die Integration von Bibliotheken Dritter, beispielsweise nativer Kryptografie. Die Hauptbeschränkung sind die mit diesen Bibliotheken verbundenen Gaskosten.

Das Rust SDK befindet sich noch in der Anfangsphase und es fehlen einige Funktionen. Das C SDK unterstützt keine Exportfunktionen mit ABI. Darüber hinaus unterstützt keines der SDKs die Verwendung von Modifikatoren.

Derzeit verfügt Stylus über keine lokale Testumgebung. Entwickler werden ermutigt, Tests innerhalb der SDKs durchzuführen. Das Testnetz ist die einzige Möglichkeit, Smart Contracts auf Stylus auszuführen. Das Testnetz hat jedoch noch keine intelligente Vertragsüberprüfung implementiert.

Es wird laufend daran gearbeitet, verschiedene ERC-Token und Plattformen wie Uniswap V2 auf Stylus zu portieren.

Sprachwahl

Die Wahl zwischen einer domänenspezifischen Sprache (DSL), einer eingebetteten DSL (eDSL) oder einer allgemeinen Programmiersprache ist eine Herausforderung. Entwickler müssen die Vorteile des Arbeitens „nah am Metall“ zur Kontrolle gegen die Benutzerfreundlichkeit abwägen, die Abstraktionen auf höherer Ebene bieten, was die Flexibilität einschränken kann.

Die Erstellung eines neuen DSL erfordert Zeit für die Entwicklung seiner Toolchains und seines Ökosystems. Eine eDSL behält als Teilmenge einer allgemeinen Programmiersprache die gleiche Semantik und Syntax bei. Es ermöglicht Entwicklern, vorhandene Sprachen und Tools zu verwenden, was den Lernprozess vereinfachen kann. Ein eDSL bietet auch eine bessere Interoperabilität mit Allzweckcode. Beispielsweise wäre eine eDSL für JavaScript oder Python von strategischer Bedeutung, um die größten Entwicklergemeinschaften einzubeziehen.

Allgemeine Programmiersprachen erfordern die Verwendung eines SDK für die Entwicklung. Dadurch werden Werkzeugebenen hinzugefügt, die Ausführlichkeit erhöht und die Ausdruckskraft verringert. Dies kann auch zu langwierigen API-Aufrufen und komplexen Objektoperationen führen.

Die Wahl der richtigen Sprache und die Entwicklung einer eDSL könnten ein idealer Kompromiss sein. Es könnte Entwickler aus beliebten Communities anziehen und benutzerfreundliche Tools anbieten. Aktuelle Daten zeigen, dass die Ethereum-Community nach wie vor die größte unter den Krypto-Entwicklern ist. Allerdings ziehen auch Ökosysteme wie Polkadot, Cosmos und Solana, die Rust für Smart Contracts nutzen, eine beträchtliche Anzahl von Entwicklern an und verzeichnen ein rasantes Wachstum.

Leistung

WASM hat das Potenzial, die Ausführungsgeschwindigkeit deutlich zu steigern und die Bundle-Größe zu reduzieren. Obwohl Stylus nicht im Mainnet bereitgestellt wurde, dienen Benchmarks aus anderen Netzwerken als nützliche Referenz.

Diese Benchmarks deuten darauf hin, dass die Ausführungszeiten um das Vier- bis Achtfache reduziert und die kompilierte Größe halbiert werden können.

Stylus legt eine Begrenzung der Vertragsgröße fest, die unkomprimiert etwa 128 KB beträgt. Diese Einschränkung macht es schwierig, sehr große Smart Contracts von Sprachen wie Solidity nach Stylus zu migrieren. Diese Einschränkung ist in der Stylus-Codebasis offensichtlich:

 // arbos/programs/programs.go const MaxWasmSize = 128 * 1024 // Maximum WASM size allowed const initialFreePages = 2 // Number of initial free pages const initialPageGas = 1000 // Gas cost for an initial page const initialPageRamp = 620674314 // Adjusts for a target size cost const initialPageLimit = 128 // Maximum number of pages allowed const initialInkPrice = 10000 // Ink price per EVM gas const initialCallScalar = 8 // Scalar for call cost

Es ist wichtig zu beachten, dass WASM einen gewissen Overhead für das Starten und Herunterfahren verursacht. Für sehr einfache Vorgänge ist EVM möglicherweise kostengünstiger als WASM.

EVM-WASM-Interoperabilität

EVM und WASM verwenden dieselben Speicherplätze und denselben Statusbaum. Stylus erreicht Interoperabilität mit EVM durch die Implementierung von EVM-APIs innerhalb von WASM. Diese Integration nutzt den weit verbreiteten Host-I/O-Modus in WASM. Nachfolgend finden Sie die vollständige Liste der in WASM unterstützten EVM-APIs, die auf umfassende Interoperabilitätsunterstützung hinweist.

 read_args write_result storage_load_bytes32 storage_store_bytes32 call_contract delegate_call_contract static_call_contract do_call create1 create2 do_create read_return_data return_data_size emit_log account_balance account_codehash evm_gas_left evm_ink_left block_basefee block_coinbase block_gas_limit block_number block_timestamp chainid contract_address msg_reentrant msg_sender msg_value native_keccak256 tx_gas_price tx_ink_price tx_prigin memoery_grow console_log_text console_log console_tee

Benutzerdefinierte Vorkompilierungen

Benutzerdefinierte Vorkompilierungen sind ein innovatives Konzept. Sie haben das Potenzial, fortschrittliche Kryptoprimitive in der Kette zu geringeren Ausführungskosten zu integrieren. Beispielsweise könnten Tensorberechnungen vorkompiliert werden, um die Kosten für maschinelles Lernen in der Kette zu senken. Allerdings gibt es in der aktuellen Codebasis keine Hinweise auf eine benutzerdefinierte Vorkompilierungsfunktionalität. Für die EVM gibt es zwar Vorkompilierungen, diese sind jedoch nicht für den Austausch konzipiert.

Es ist wahrscheinlich, dass diese Funktionen noch in der Entwicklung sind und die Fähigkeiten von WASM nutzen. Dies würde es EVM ermöglichen, WASM-geschriebene Funktionen aufzurufen, die dann in Maschinencode kompiliert werden.

Wiedereintritt

Im Gegensatz zum Akteurmodell von CosmWasm, das keinen Wiedereintritt unterstützt, beinhaltet das Rust SDK von Stylus Wiedereintritt als optionale Funktion. Standardmäßig ist diese Funktion deaktiviert. Entwickler haben die Wahl, den Wiedereintritt in ihre Verträge zu ermöglichen.

Die Aktivierung der Wiedereintrittsfähigkeit wirkt sich auf die API aus, da Entwickler sicherstellen müssen, dass sie den Speichercache während Aufrufen leeren, und andere Sicherheitsmaßnahmen berücksichtigen müssen. Diese Vorsichtsmaßnahme ist wichtig, um potenzielle Schwachstellen im Zusammenhang mit wiedereintretenden Anrufen zu verhindern.

Abschluss

WASM erfreut sich im Cloud-nativen Bereich immer größerer Beliebtheit und wird von vielen Blockchains für die Ausführung intelligenter Verträge übernommen. Obwohl Arbitrum bei dieser Integration nicht der Pionier ist, könnte ihre Umsetzung äußerst wirkungsvoll sein. WASM ist nicht in der Lage, die Blockchain-Landschaft komplett zu überarbeiten oder EVM zu ersetzen. Es könnte jedoch den Vorsprung von Arbitrum gegenüber den aufkommenden ZK-Rollups stärken. Der Begriff „EVM+“ von Arbitrum beschreibt dieses Szenario treffend. EVM legt den Grundstein für Smart-Contract-Plattformen und WASM könnte Arbitrum einen zusätzlichen Leistungsschub verleihen.