Autor: Yiping, IOSG Ventures

Dieser Artikel ist der Originalinhalt von IOSG und dient nur zu Lern- und Austauschzwecken in der Branche und stellt keine Investitionsreferenz dar. Wenn Sie ein Zitat benötigen, geben Sie bitte die Quelle an. Für einen Nachdruck wenden Sie sich bitte an das IOSG-Team, um eine Genehmigung und Anweisungen zum Nachdruck zu erhalten. Alle in diesem Artikel erwähnten Projekte stellen keine Empfehlungen oder Anlageberatung dar.

Die Layer-2-Landschaft entwickelt sich schnell weiter, da ZKRUs wie zkSync und StarkNet das Mainnet starten. Traditionell werden OPRUs wie Arbitrum als erste auf den Markt gebracht und verfügen daher über ein stärkeres Ökosystem. Im Gegensatz dazu handelt es sich bei ZKRUs um technologische Durchbrüche, die einen höheren Durchsatz und niedrigere Gebühren bieten.

In den letzten Monaten sind auf der Suche nach schnelleren und günstigeren Transaktionen immer mehr Aktivitäten von Layer 1 auf Layer 2 verlagert worden. Der TVL von Ethereum ist im vergangenen Jahr von fast 40 Milliarden US-Dollar auf 20 Milliarden US-Dollar gesunken. Bei TVL für Layer 2 ergibt sich jedoch ein anderes Bild: Das enorme Wachstum deutet darauf hin, dass sich die Einführung von Layer 2 beschleunigt.

Arbitrum ist mit einem Layer-2-TVL-Marktanteil von über 50 % führend, obwohl auch ZKRUs ihre Anstrengungen unternehmen. Der First-Mover-Vorteil von Arbitrum ermöglicht es dem Unternehmen, seine marktbeherrschende Stellung zu behaupten.

Die Analyse der Anzahl der täglichen Transaktionen zeigt, dass ZKRUs wie zkSync und StarkNet die OPRUs im Durchsatz leicht übertreffen. Der Ökosystemvorteil von Arbitrum bleibt jedoch bestehen, obwohl es bei den täglichen TPS leicht zurückfällt.

OPRUs gibt es schon länger als ZKRUs. ZKRUs starten jedoch ihre Mainnets und ziehen Benutzer aus anderen Ökosystemen an. Als führendes Unternehmen im OPRU-Bereich wird Arbitrum voraussichtlich mit seinen neuen Updates dem Aufstieg der ZKRUs entgegenwirken.

Entscheidung: Stil

Da Entwickler die Zero-Knowledge-Technologie und die Kosten optimieren, werden ZKRUs aufgrund ihrer Skalierbarkeitsvorteile wahrscheinlich weiterhin Marktanteile gewinnen. Die Netzwerkeffekte von Arbitrum bieten jedoch die Möglichkeit, trotz des Wettbewerbsdrucks robust zu bleiben. Durch innovative Lösungen wie Stylus kann Arbitrum seine Führungsposition durch einzigartige technische Fähigkeiten ergänzen und weiterhin an der Spitze des Layer-2-Rennens bleiben.

Kurz gesagt, Stylus ist eine revolutionäre neue Smart-Contract-Umgebung, die für Arbitrum entwickelt wurde und es Entwicklern ermöglicht, effiziente, interoperable Programme in Programmiersprachen wie Rust, C++ und Solidity zu schreiben.

Es öffnet die allgemeine Datenverarbeitung für Blockchain und heißt Entwickler willkommen, die unterschiedliche Technologie-Stacks verwenden.

WASM

Stylus fügt eine virtuelle WebAssembly (WASM)-Maschine hinzu, die parallel zur vorhandenen Ethereum Virtual Machine (EVM) läuft. Intelligente Verträge, die in einer Sprache geschrieben sind, die zu WASM kompiliert werden kann, können nativ zehnmal oder schneller als Solidity ausgeführt werden, was die Gaskosten erheblich senkt. Das EVM bleibt voll funktionsfähig, sodass bestehende Solidity-Verträge weiterhin wie heute funktionieren. Zwei VMs arbeiten synchron, sodass in verschiedenen Programmiersprachen geschriebene Verträge sich gegenseitig aufrufen und gleichzeitig denselben zugrunde liegenden Blockchain-Status ändern können.

Benutzerdefinierte Vorkompilierung

Darüber hinaus unterstützt Stylus auch benutzerdefinierte Vorkompilierungen.

Vorkompilierungen sind Low-Level-Module auf Ethereum und Arbitrum, mit denen bestimmte kryptografische oder Dienstprogrammfunktionen sehr effizient ausgeführt werden. Es gibt beispielsweise Vorkompilierungen für die ECDSA-Signaturprüfung und die Berechnung von SHA256-Hashes.

Das Hinzufügen neuer Vorkompilierungen erfordert, dass alle Validatoren die Aktualisierung der EVM koordinieren, sodass die Eintrittsbarriere hoch ist. Und mit Stylus können Entwickler ganz einfach ihre eigenen, in Rust oder C++ geschriebenen Precompiler bereitstellen.

Beispielsweise kann ein Team eine in C geschriebene kryptografische Bibliothek nehmen und sie ohne Änderungen auf Arbitrum bereitstellen. Dadurch können diese kryptografischen Grundelemente mit ultraschneller nativer Geschwindigkeit ausgeführt werden.

Andere Verträge können diesen Stylus „Vorkompilierung“ nennen, genau wie sie es als native Vorkompilierung bezeichnen, um die Vorteile dieser kryptografischen Technologie zu nutzen. Die gesamte Gasmessung und Betrugssicherheit erfolgt automatisch.

Dies ermöglicht es dem Team, Prototypen für benutzerdefinierte Kryptografie, spezielle paarungsbasierte Kurven und andere neuartige Grundelemente ohne spezielle Kettenunterstützung zu erstellen. Ethereum-Forscher können EIP-Vorschläge sogar frühzeitig wiederholen, indem sie sie als vorkompilierte Stylus-Versionen auf Arbitrum bereitstellen.

Indem Stylus Entwicklern die Möglichkeit gibt, neue kryptografische Grundelemente nativ in der Kette einzuführen, erweitert es den Umfang dessen, was erstellt werden kann, erheblich. Die Vorkompilierung ist nicht mehr auf die vom EVM unterstützten Funktionen beschränkt.

Wie Stylus funktioniert

Bevor wir uns mit der breiteren Rolle von WASM im Blockchain-Universum befassen, ist es wichtig zu verstehen, wie Arbitrum die Koexistenz von EVM und WASM orchestriert. Es geht nicht nur darum, zwei separate Motoren zu haben; es ist eine synergetische Beziehung, die die Stärken beider stärkt.

Die einzigartige Architektur von Arbitrum ermöglicht dank ihres einheitlichen Zustands, des VM-übergreifenden Aufrufs und des kompatiblen Wirtschaftsmodells nahtlose und synchronisierte Abläufe zwischen EVM und WASM.

In Solidity oder anderen EVM-Sprachen geschriebene Smart Contracts werden wie gewohnt in EVM-Bytecode kompiliert. Bei der Ausführung laufen diese Verträge wie heute auf dem EVM.

Für Sprachen, die zu WASM kompiliert werden, wie Rust, C++ und C, ist der Workflow wie folgt:

  • Entwickler verwenden handelsübliche WASM-Compiler wie Clang oder Rustc, um ihre Smart Contracts in WASM zu kompilieren.

  • Der WASM-Bytecode wird in komprimierter Form in die Arbitrum-Kette hochgeladen.

  • Der Vertragseigentümer ruft die vorkompilierte „compileProgram“-Methode „ArbWasm“ auf, die die Sicherheitstools für WASM einrichtet, Gaskosten berechnet und sie in nativen Code kompiliert, der für die Validator-Hardware optimiert ist.

  • Wenn ein Vertrag aufgerufen wird, läuft er auf einer WASM-Laufzeitumgebung wie Wasmer, die viel schneller als EVM ist, wodurch Gasgebühren gespart werden.

Die WASM-Messung berechnet Gas vor jedem Basisblock und nicht pro Opcode wie bei EVM. Das ist effizienter und sorgt dafür, dass der Vertrag nicht aus dem Ruder läuft.

EVM und WASM

Die beiden virtuellen Maschinen (VMs) laufen synchron, sodass sie sich gegenseitig aufrufen können, während sie denselben globalen Status haben. Eine Transaktion kann teilweise in EVM und teilweise in WASM ausgeführt werden, und die Ergebnisse werden nahtlos kombiniert.

Moment, wie können zwei VMs nahtlos und synchron arbeiten?

Polkadot erreicht dies durch XVM. Im Gegensatz zu Polkadot arbeiten WASM und EVM auf Arbitrum aus mehreren wichtigen Gründen nahtlos und synchron:

  • Einzelstatus: Beide VMs greifen auf dieselbe zugrunde liegende Datenstruktur und denselben Statusversuch zu. Ein Vertrag in einer VM kann an derselben Stelle lesen/schreiben wie ein Vertrag in einer anderen VM. Dies bietet eine einheitliche Ansicht des Kettenstatus.

  • Cross-VM-Aufrufe: Wenn eine Transaktion mit einem EVM-Vertrag interagiert, verarbeitet Geth sie und stellt ein Ergebnis bereit. Wenn der EVM-Vertrag anschließend ein WASM-Programm aufruft, übernimmt die WASM-VM die Berechnung der Ergebnisse dieses Teils.

  • Gemeinsamer Kontext: Systeminformationen wie Blockdaten, Absenderadresse usw. stehen beiden VMs zur Verfügung. Ein WASM-Vertrag kann die Blocknummer genau wie ein Solidity-Vertrag erhalten.

  • Einzelkonsens: Validatoren betreiben zwei VMs, um Transaktionen zu validieren und einen Konsens über den richtigen Kettenstatus zu erzielen. Bei Streitigkeiten wird das Uniform Fraud Proof System herangezogen.

  • Kompatible Wirtschaftlichkeit: Konzepte wie die Gasmessung erstrecken sich auf einzelne VMs und sorgen so für angemessene Rechenkosten und Ressourcen in beiden Umgebungen.

Für Betrugsnachweise halbiert der Prüfer die EVM- und WASM-Ausführungen, um bei Bedarf ungültige Schritte zu identifizieren. Die Struktur von WASM ermöglicht es dem System, die Beendigung zu garantieren und die Gültigkeit von Beweisen durchzusetzen.

Blockchain |. WASM

Arbitrum ist nicht die einzige Plattform, die das transformative Potenzial von WebAssembly (WASM) erkennt. Sowohl Polkadot als auch Cosmos haben WASM ebenfalls in ihre Ökosysteme integriert, wobei jede Plattform einzigartige Vorteile und Funktionen bietet.

Polkadot ermöglicht Benutzern die Entwicklung intelligenter Verträge mit WASM und unterstützt zwei Sprachen: AssemblyScript, ein eingebettetes DSL, und Ink!, das Rust ähnelt.

Cosmos hingegen verwendet CosmWasm als intelligente Vertragslaufzeit, sodass Entwickler Verträge in Rust schreiben können.

Bevor wir näher darauf eingehen, warum die Blockchain-Branche so aufgeschlossen gegenüber WASM ist, lohnt es sich, die spezifischen Vorteile zu verstehen, die Cosmos und Polkadot hervorheben:

Cosmos hebt die folgenden Vorteile von WASM hervor:

  • Kompatibilität mit Rust-Bibliotheken

  • Vielfältige Entwickler-Community

  • Erhöhte Sicherheit, einschließlich Schutz vor Wiedereintrittsangriffen

  • Einfach zu testen

  • Hochleistung

Die WASM-Laufzeitumgebung von Polkadot verfügt über folgende Funktionen:

  • Hochleistung

  • Interoperabilität mit EVM

  • Plattformunabhängig

  • Kompakte Binärgröße

  • Unterstützt sowohl Rust als auch AssemblyScript (TypeScript-Variante)

Während Polkadot, Cosmos und Arbitrum einige gemeinsame Vorteile von WASM haben, hat jede Plattform auch ihre eigenen einzigartigen Eigenschaften.

Die weit verbreitete Einführung von WASM durch diese großen Blockchain-Plattformen ist ein Beweis für seine wachsende Bedeutung in der Branche. Daher ist es wichtig zu verstehen, warum diese Technologie schnell zu einem Eckpfeiler der modernen Blockchain-Architektur wird.

Warum WASM wählen?

Was ist WASM?

Um die Synergie zwischen Blockchain und WebAssembly (WASM) zu verstehen, muss man zunächst verstehen, was WASM ist und welche treibende Kraft hinter seiner Entwicklung steckt.

WebAssembly ist ein binäres Befehlsformat, das die Ausführung von Code mit nahezu nativer Geschwindigkeit in einem Webbrowser ermöglicht. Es dient als Kompilierungsziel für eine Reihe von Programmiersprachen, einschließlich C und Rust, und ist auf Schnelligkeit, Effizienz und Sicherheit ausgelegt. WASM schließt effektiv die Lücke zwischen webbasierter und systembasierter Programmierung und verbessert so die Leistung und Funktionalität des Webs.

„Web“ in WebAssembly unterstreicht seine Fähigkeit, in einer JavaScript-Umgebung (normalerweise in einem Browser zu finden) ausgeführt zu werden. In diesen Setups haben Entwickler vollen Zugriff auf die WASM-API und umfassende Web-API-Unterstützung, wodurch sie erhebliche Kontrolle über das Webverhalten haben.

WASM-Geschichte

Nach dem Prinzip „Einmal schreiben, überall ausführen“ erwies sich WASM als leistungsstarke Lösung für eine Reihe langjähriger Herausforderungen. Seit 2016 führen viele Programme neue Funktionen über domänenspezifische Sprachen (DSLs) ein, die häufig Kompromisse zwischen Wartung, Effizienz und Sicherheit erfordern. Es besteht ein wachsender Bedarf an einer Lösung, die unzähligen Servern neue Funktionen bieten kann, ohne diese Aspekte zu beeinträchtigen.

Die Mängel verschiedener bestehender Lösungen wurden bewertet:

- Virtuelle Systemmaschine

  • Häufiges Starten und Herunterfahren verursacht übermäßigen Overhead

  • Mangelnde Code-Sichtbarkeit zur Gewährleistung der Sicherheit

  • Zu abstrakt in Bezug auf Leistungsanforderungen

- Behälter

  • Mangelnde Code-Sichtbarkeit zur Gewährleistung der Sicherheit

  • Ineffizient aufgrund der Abstraktion auf hoher Ebene

  • Häufige Operationen verursachen einen erheblichen Mehraufwand

- Virtuelle Maschine auf Sprachebene

  • Erfordert häufige Änderungen, um die Sicherheit zu gewährleisten

  • Eingebettete VMs wie V8 sind ressourcenintensiv

  • Langsame Anpassung der neuen Sprache an das Sicherheitsmodell

  • immer noch zu abstrakt

- Befehlssatzarchitektur (ISA)

  • Es ist schwierig, eine effektive Sandbox zu erstellen

  • Frühere Google-Projekte wurden von dort nach WASM verschoben

  • Mangel an ausgereifter Implementierung

Bis 2018 gewann die WASM-Entwicklung an Dynamik, wobei der Schwerpunkt auf der Ausführung auf verschiedenen Architekturen, Servern, eingebetteter Hardware und sogar der Unterstützung mehrerer Sprachen lag. Im Gegensatz zu Java ist WASM ohne Kompromisse bei der Sicherheit konzipiert. Bis 2019 wurde ein Komponentenmodell eingeführt, um das WASM-Modul zu verbessern und eine sprachübergreifende Interoperabilität zu ermöglichen. Dies ermöglicht Lösungen wie das einmalige Schreiben einer HTTP-Bibliothek und deren Verwendung in mehreren Sprachen.

Bis heute verfügt WASM über eine Reihe von Funktionen und wird zunehmend in Cloud-nativen Szenarien, einschließlich Blockchain, eingesetzt. Zu seinen Vorteilen gehören:

  • Hochleistung

  • Kompakte Binärgröße

  • Plattformübergreifende Portabilität

  • Unterstützt mehrere Sprachen wie C/C++, Rust, AssemblyScript usw.

  • In der JavaScript-Engine ausführen

  • Leistungsstarke Sandbox mit Speicher- und CPU-Limits

  • Extrem schnelle Startzeiten, typischerweise in Millisekunden oder weniger

Die WASM-Community arbeitet weiterhin an einer besseren Integration und Leistung in allen Sprachen.

Das Verständnis der historischen Entwicklung von WASM liefert uns wertvolle Kontexte zum Verständnis seiner aktuellen und potenziellen Rollen in einer Vielzahl von Umgebungen, einschließlich Blockchain-Projekten wie Stylus. Dieser Hintergrund ermöglicht uns ein differenziertes Verständnis bei der Untersuchung von Problemen und Bedenken im Zusammenhang mit der WASM-Implementierung im Blockchain-Ökosystem.

Fragen und Antworten zum Stift

Sprachunterstützung

Die Entwicklung von WASM verdeutlicht, warum Stylus eine spannende Ergänzung des Arbitrum-Ökosystems ist, zeigt aber auch einige Einschränkungen und Bedenken auf. Eines der Anliegen ist die Sprachunterstützung. Während Stylus die Arbitrum-Entwicklergemeinschaft um Sprachen wie C++ und Rust erweitert hat, ist es ihm nicht gelungen, populäre Sprachen wie JavaScript und Python zu übernehmen.

Obwohl es vorläufige Projekte gibt, die darauf abzielen, Python und JavaScript in WASM zu integrieren, sind diese Bemühungen aufgrund von Herausforderungen bei der Speicherbereinigung und Leistungsproblemen noch nicht für eine breite Einführung bereit.

Sprachkompatibilität

Derzeit unterstützt Stylus C/C++- und Rust-SDKs und lässt sich nahtlos in Toolchains für diese Sprachen integrieren. Entwickler können beim Erstellen intelligenter Verträge sogar Bibliotheken von Drittanbietern integrieren, beispielsweise native kryptografische Implementierungen. Die größte Einschränkung bei so etwas sind die damit verbundenen Gaskosten.

Während das Rust SDK noch in den Kinderschuhen steckt, fehlen sowohl im Rust- als auch im C-SDK einige Funktionen. Beispielsweise unterstützt das C-SDK keine von ABI exportierten Funktionen, und Modifikatoren werden in keinem SDK noch unterstützt.

Derzeit gibt es keine lokale Stylus-Testumgebung, aber Entwickler können Tests direkt im SDK ausführen. Für die Bereitstellung intelligenter Verträge ist Testnet derzeit die einzige Option und unterstützt die Überprüfung intelligenter Verträge noch nicht. Derzeit laufen Bemühungen, verschiedene ERC-Token und **[Uniswap V2](https://twitter.com/evmcheb/status/1697537852522049990)** in das Stylus-Ökosystem zu integrieren.

Das Dilemma der Sprachwahl

Die Wahl zwischen domänenspezifischen Sprachen (DSLs), eingebetteten DSLs (eDSLs) und Allzwecksprachen erfordert einen Kompromiss zwischen Kontrolle auf niedriger Ebene und Abstraktion auf hoher Ebene. Die Entwicklung eines völlig neuen DSL erfordert erhebliche Investitionen in die Toolchain- und Ökosystementwicklung. Im Gegensatz dazu ermöglicht eDSL als Teilmenge einer Allzwecksprache eine einfachere Integration in vorhandene Tools und weist eine geringere Lernkurve auf. Beispielsweise wäre es von Vorteil, eine eDSL in einer gängigen Sprache wie JavaScript oder Python zu erstellen.

Eine gemeinsame Sprache erfordert die Verwendung eines SDK, das zusätzliche Tools einführt, die Ausführlichkeit erhöht und den Code weniger ausdrucksstark macht, zusammen mit längeren API-Aufrufen und Objektoperationen.

Die richtige Balance zwischen Sprachauswahl und eDSL-Entwicklung zu finden, kann der Schlüssel sein, um die breitere Entwicklergemeinschaft anzuziehen und gleichzeitig benutzerfreundliche Tools bereitzustellen. Aktuellen Daten zufolge konzentriert sich die Top-Krypto-Entwickler-Community immer noch auf Ethereum. Allerdings gewinnen auch Plattformen, die Rust für Smart Contracts nutzen, wie Polkadot, Cosmos und Solana, an Bedeutung und wachsen in ihren Entwicklergemeinschaften schnell.

Leistung

WASM verbessert die Ausführungsgeschwindigkeit erheblich und reduziert die Paketgröße. Obwohl Stylus noch nicht im Mainnet bereitgestellt wird, können Benchmarks aus anderen Netzwerken als nützliche Referenz dienen. Die beobachteten Ausführungszeiten sind vier- bis achtmal schneller und die kompilierte Größe wird um etwa 50 % reduziert.

Stylus hat derzeit eine Größenbeschränkung für seine Verträge, die auf etwa 128 KB unkomprimiert begrenzt ist. Diese Einschränkung macht die Portierung großer Smart Contracts aus anderen Sprachen wie Solidity zu einer Herausforderung. In der Stylus-Codebasis wird dieser Grenzwert unten beschrieben:

Es ist zu beachten, dass WASM beim Starten und Herunterfahren einen gewissen Overhead verursacht. Für leichtgewichtige Vorgänge ist EVM möglicherweise tatsächlich kostengünstiger als WASM.

Interoperabilität mit EVM

EVM und WASM nutzen dieselben Speichersteckplätze und denselben Zustandsbaum, was die Interoperabilität von Stylus mit EVM erleichtert. Dies wird durch die in WASM implementierte EVM-API unter Verwendung des beliebten Host-I/O-Musters erreicht. Eine umfassende Liste der unterstützten EVM-APIs zeigt, dass die Interoperabilität vollständig unterstützt wird.

Benutzerdefinierter vorkompilierter Vertrag

Dieser Aspekt ist besonders spannend, weil er Neuland darstellt. Benutzerdefinierte vorkompilierte Verträge haben das Potenzial, zusätzliche kryptografische Grundelemente mit geringeren Ausführungskosten in die Kette zu bringen. Sie können auch die Inferenzkosten senken, indem sie Tensorberechnungen als vorkompilierte Verträge einführen. Allerdings scheint es keinen bestehenden Code zu benutzerdefinierten vorkompilierten Verträgen zu geben. Obwohl es vorkompilierte Verträge für EVM-Komponenten gibt, sind diese nicht im laufenden Betrieb austauschbar.

Diese Funktion befindet sich möglicherweise noch in der Entwicklung und nutzt die Funktionen von WASM. Das EVM kann in WASM geschriebene Funktionen aufrufen und diese dann in Maschinencode kompilieren.

Reentrant-Funktionalität

Im Gegensatz zu CosmWasm (das ein Actor-Modell ohne Reentranz verwendet), deaktiviert das Rust SDK von Stylus die Reentranz standardmäßig als Feature-Flag. Entwickler haben die Möglichkeit, diese Funktion manuell zu aktivieren.

Für die Aktivierung der Wiedereintrittsfähigkeit sind einige API-Anpassungen erforderlich. Insbesondere müssen Entwickler vorsichtig sein, wenn es um Sicherheitsvorkehrungen wie das Aktualisieren von Speichercaches während Aufrufen geht.

Einblick

Stylus eröffnet neue Anwendungsfälle, die bei alleiniger Verwendung des EVM zu gasintensiv wären, wie z. B. Hochleistungsverschlüsselung, Spiele und KI. Es ermöglicht auch die Anpassung vorkompilierter Verträge, sodass Entwickler ihre eigene Verschlüsselung und andere grundlegende Funktionen hinzufügen können, ohne auf Upgrades warten zu müssen. In der Vergangenheit haben wir gesehen, dass einige Nicht-Ethereum-Ökosysteme WASM übernommen haben, wie zum Beispiel Cosmos und Polkadot. Dies ist das erste Mal, dass WASM von der Ethereum-Community übernommen wurde. Insgesamt stellt Stylus eine bedeutende Weiterentwicklung in der Entwicklung intelligenter Verträge dar und wird die Skalierung von Ethereum und Arbitrum unterstützen und gleichzeitig die Interoperabilität mit allen bestehenden Anwendungen aufrechterhalten.

Die Integration von Stylus in das Layer-2-SDK von Arbitrum bietet Layer-3-Entwicklern mehr Flexibilität. Sie können nun intensive Berechnungen, die zuvor die Gasgrenzwerte überschritten haben, in die Kette verlagern, was neue Möglichkeiten eröffnet. Entwickler sind nicht mehr auf Solidity beschränkt, sondern können auch Rust oder C++ wählen, wenn diese Sprachen besser zu ihren Bedürfnissen und ihrem Fachwissen passen. Benutzerdefinierte vorkompilierte Verträge ermöglichen die nahtlose Migration bevorzugter kryptografischer, Dienstprogramm- und anderer Hilfsfunktionen in die Kette für optimale Leistung. Das direkte Schreiben von Low-Level-Logik in einer an den jeweiligen Anwendungsfall angepassten Sprache führt zu einer reibungsloseren Entwicklung. Entwickler können sich auf die Kernfunktionalität des Produkts konzentrieren, anstatt auf Problemumgehungen zurückzugreifen, um Gaskosten zu vermeiden. Durch die Beseitigung von Sprach- und Gaseinschränkungen ermöglicht Stylus Entwicklern der dritten Ebene, von Anfang an die effizientesten Benutzererlebnisse zu schaffen und dabei die richtigen Tools für ihre Domäne zu verwenden.

Stylus demonstriert auch die Fähigkeit von Arbitrum, in großem Maßstab Innovationen zu entwickeln und neue virtuelle Maschinen zu integrieren. Ed Felten, Mitbegründer und Chefwissenschaftler von Arbitrum & Offchain Labs, erwähnte, dass Arbitrum auf der Grundlage beliebter Tools und Programmiersprachen in der Branche entwickelt wird. Sie können Tests schneller schreiben und neue Funktionen auf Basis ihrer Altsysteme entwickeln. OP ist auf dem Weg der ZKisierung weiter vorangekommen und hat sich schrittweise der Hybrid-Rollup-Idee zugewandt. Optimism arbeitet derzeit mit Risc0 zusammen, um mithilfe von Zeth wissensfreie Beweise für OPRU zu generieren. Mit dieser Lösung muss Optimism keine zusätzlichen Änderungen an OPRU vornehmen. Wenn Sie sich für Zeth interessieren, können Sie lesen, was ich zuvor geschrieben habe [Twitter](https://x.com/glazecl/status/1709947992168710174?s=20).

Wir freuen uns sehr darauf, KI-Anwendungen bei Arbitrum zu sehen. Derzeit ist die Durchführung von maschinellem Lernen in der Kette sehr gasintensiv, was die Entwicklung teuer macht. Zero-Knowledge-ML kann die Kosten senken, bringt aber auch eine erhebliche zusätzliche Komplexität für Entwickler mit sich. Wenn wir Tensoroperationen als benutzerdefinierte vorkompilierte Verträge über Stylus implementieren und sie zu einem Bruchteil der Kosten nativ ausführen könnten, würde dies neue Möglichkeiten für leistungsstarkes maschinelles Lernen in der Kette eröffnen. Indem es Entwicklern ermöglicht, ML-Algorithmen schnell als einfach zu integrierende vorkompilierte Verträge in einer ihnen vertrauten Sprache wie Python zu erstellen und bereitzustellen, kann Arbitrum die nächste Generation von KI-Innovationen in DeFi, GameFi und mehr vorantreiben. Die Leistung und Flexibilität von Stylus wird es uns ermöglichen, uns auf innovative ML-Architekturen statt auf Gasoptimierung zu konzentrieren. Wir freuen uns darauf, die Kreativität der Community auf dieses entstehende Paradigma anzuwenden.