Autore: Yiping, IOSG Ventures
Il panorama Layer 2 si sta evolvendo rapidamente poiché ZKRU come zkSync e StarkNet lanciano la mainnet. Tradizionalmente, le OPRU come Arbitrum sono le prime a commercializzare e quindi hanno un ecosistema più forte. Al contrario, le ZKRU sono innovazioni tecnologiche che offrono una maggiore produttività e tariffe più basse.
Negli ultimi mesi, sempre più attività sono passate dal Layer 1 al Layer 2 alla ricerca di transazioni più veloci ed economiche. Nell’ultimo anno il TVL di Ethereum è sceso da quasi 40 miliardi di dollari a 20 miliardi di dollari. Tuttavia, la TVL per Layer 2 presenta un quadro diverso, con un’enorme crescita che indica che l’adozione di Layer 2 sta accelerando.
Arbitrum è in testa con una quota di mercato TVL di livello 2 superiore al 50%, sebbene anche le ZKRU si impegnino. Il vantaggio di first mover di Arbitrum gli consente di mantenere la sua posizione dominante.
L'analisi del numero di transazioni giornaliere mostra che le ZKRU come zkSync e StarkNet superano leggermente le OPRU in termini di throughput. Tuttavia, il vantaggio ecosistemico di Arbitrum rimane, nonostante sia leggermente indietro nel TPS giornaliero.
Gli OPRU esistono da più tempo degli ZKRU. Tuttavia, le ZKRU stanno lanciando le loro reti principali e attirando utenti da altri ecosistemi. In qualità di leader nello spazio OPRU, si prevede che Arbitrum contrasterà l'ascesa delle ZKRU con i loro nuovi aggiornamenti.
Decisione: stile
Man mano che gli sviluppatori ottimizzano la tecnologia e i costi a conoscenza zero, le ZKRU continueranno probabilmente a guadagnare quote di mercato grazie ai vantaggi della loro scalabilità. Tuttavia, gli effetti di rete di Arbitrum forniscono la capacità di rimanere robusti nonostante le pressioni competitive. Attraverso soluzioni innovative come Stylus, Arbitrum può integrare la propria posizione di leadership con capacità tecniche uniche e continuare a rimanere in prima linea nella corsa Layer 2.
In breve, Stylus è un nuovo e rivoluzionario ambiente di contratto intelligente progettato per Arbitrum che consente agli sviluppatori di scrivere programmi efficienti e interoperabili in linguaggi di programmazione come Rust, C++ e Solidity.
Apre l’informatica generale alla blockchain e accoglie gli sviluppatori che utilizzano diversi stack tecnologici.
WASM
Stylus funziona aggiungendo una macchina virtuale WebAssembly (WASM) che funziona in parallelo con l'esistente Ethereum Virtual Machine (EVM). I contratti intelligenti scritti in un linguaggio compilabile in WASM possono essere eseguiti nativamente 10 volte o più più velocemente di Solidity, riducendo significativamente i costi del gas. L’EVM rimane pienamente funzionante, quindi i contratti Solidity esistenti funzionano ancora come oggi. Due VM operano in modo sincrono, consentendo ai contratti scritti in diversi linguaggi di programmazione di chiamarsi a vicenda e modificando allo stesso tempo lo stesso stato blockchain sottostante.
Precompilazione personalizzata
Inoltre, Stylus supporta anche la precompilazione personalizzata.
Le precompilazioni sono moduli di basso livello su Ethereum e Arbitrum utilizzati per eseguire specifiche funzioni crittografiche o di utilità in modo molto efficiente. Ad esempio, esistono precompilazioni per la verifica della firma ECDSA e il calcolo degli hash SHA256.
L'aggiunta di nuove precompilazioni richiede che tutti i validatori coordinino l'aggiornamento dell'EVM, quindi la barriera all'ingresso è elevata. E con Stylus, gli sviluppatori possono facilmente distribuire i propri precompilatori scritti in Rust o C++.
Ad esempio, un team può prendere una libreria crittografica scritta in C e distribuirla su Arbitrum senza modifiche. Ciò consentirà a queste primitive crittografiche di essere eseguite a velocità native ultraveloci.
Altri contratti possono chiamare questo Stylus "precompilazione" proprio come chiamano precompilazione nativa per sfruttare questa tecnologia crittografica. Tutta la misurazione del gas e la verifica delle frodi funzionano automaticamente.
Ciò consente al team di prototipare crittografia personalizzata, curve speciali basate sull'accoppiamento e altre nuove primitive senza alcun supporto speciale per la catena. I ricercatori di Ethereum possono anche ottenere un vantaggio nell’iterazione delle proposte EIP distribuendole come versioni precompilate di Stylus su Arbitrum.
Dando agli sviluppatori la possibilità di introdurre nuove primitive crittografiche in modo nativo sulla catena, Stylus espande notevolmente la portata di ciò che può essere costruito. La precompilazione non è più limitata alle funzionalità supportate dall'EVM.
Come funziona lo stilo
Prima di approfondire il ruolo più ampio di WASM nell’universo blockchain, è fondamentale capire come Arbitrum orchestra la coesistenza di EVM e WASM. Non si tratta solo di avere due motori separati; è una relazione sinergica che esalta i punti di forza di entrambi.
L’architettura unica di Arbitrum consente operazioni fluide e sincronizzate tra EVM e WASM, grazie al suo stato unificato, all’invocazione di più VM e al modello economico compatibile.
I contratti intelligenti scritti in Solidity o altri linguaggi EVM vengono compilati come al solito nel bytecode EVM. Una volta eseguiti, questi contratti vengono eseguiti sull'EVM, proprio come fanno oggi.
Per i linguaggi compilabili in WASM, come Rust, C++ e C, il flusso di lavoro è:
Gli sviluppatori utilizzano compilatori WASM standardizzati come Clang o Rustc per compilare i propri contratti intelligenti in WASM.
Il bytecode WASM viene caricato sulla catena Arbitrum in formato compresso.
Il proprietario del contratto chiama il metodo "compileProgram" precompilato "ArbWasm", che imposta gli strumenti di sicurezza per WASM, lo analizza e lo compila in codice nativo ottimizzato per l'hardware del validatore.
Quando viene richiesto un contratto, viene eseguito su un runtime WASM come Wasmer, che è molto più veloce di EVM, risparmiando così sulle tariffe del gas.
La misurazione WASM addebita il gas prima di ogni blocco di base anziché per codice operativo come EVM. Questo è più efficiente e garantisce che il contratto non sfugga di mano.
EVM e WASM
Le due macchine virtuali (VM) funzionano in modo sincrono, consentendo loro di chiamarsi a vicenda condividendo lo stesso stato globale. Una transazione può essere eseguita parzialmente in EVM e parzialmente in WASM e i risultati vengono combinati senza soluzione di continuità.
Aspetta, come possono due VM funzionare perfettamente e in sincronia?
Polkadot raggiunge questo obiettivo tramite XVM. A differenza di Polkadot, WASM ed EVM funzionano perfettamente e in modo sincrono su Arbitrum per diversi motivi chiave:
Stato singolo: entrambe le macchine virtuali accedono alla stessa struttura dati sottostante e allo stesso trie di stato. Un contratto in una VM può leggere/scrivere nella stessa posizione di un contratto in un'altra VM. Ciò fornisce una visione unificata dello stato della catena.
Chiamate tra macchine virtuali: quando una transazione interagisce con un contratto EVM, Geth la elabora e fornisce un risultato. Se il contratto EVM richiama successivamente un programma WASM, la VM WASM subentra nel calcolo dei risultati di quella parte.
Contesto condiviso: le informazioni di sistema come i dati del blocco, l'indirizzo del mittente, ecc. sono disponibili per entrambe le VM. Un contratto WASM può ottenere il numero di blocco proprio come un contratto Solidity.
Consenso singolo: i validatori eseguono due VM per convalidare le transazioni e raggiungere il consenso sullo stato della catena corretto. Le controversie si avvarranno del sistema uniforme antifrode.
Economia compatibile: concetti come la misurazione del gas si estendono alle singole VM, garantendo costi di elaborazione e risorse adeguati in entrambi gli ambienti.
Per le prove di frode, il verificatore divide in due le esecuzioni EVM e WASM per identificare eventuali passaggi non validi, se necessario. La struttura di WASM consente al sistema di garantire la risoluzione e far valere la validità delle prove.
Blockchain |.WASM
Arbitrum non è l’unica piattaforma a riconoscere il potenziale trasformativo di WebAssembly (WASM). Sia Polkadot che Cosmos hanno anche integrato WASM nei loro ecosistemi, con ciascuna piattaforma che offre una serie unica di vantaggi e funzionalità.
Polkadot consente agli utenti di sviluppare contratti intelligenti con WASM e supporta due linguaggi: AssemblyScript, un DSL incorporato, e Ink!, che è simile a Rust.
Cosmos, d'altra parte, utilizza CosmWasm come runtime di contratto intelligente, consentendo agli sviluppatori di scrivere contratti in Rust.
Prima di approfondire il motivo per cui il settore blockchain è così ricettivo nei confronti di WASM, vale la pena comprendere i vantaggi specifici che si distinguono per Cosmos e Polkadot:
Cosmos evidenzia i seguenti vantaggi di WASM:
Compatibilità con le librerie Rust
Comunità di sviluppatori diversificata
Sicurezza avanzata, inclusa la protezione contro gli attacchi di rientro
Facile da testare
alte prestazioni
Il runtime WASM di Polkadot ha queste funzionalità:
alte prestazioni
Interoperabilità con EVM
Indipendente dalla piattaforma
Dimensione binaria compatta
Supporta sia Rust che AssemblyScript (sapore TypeScript)
Sebbene Polkadot, Cosmos e Arbitrum condividano alcuni vantaggi comuni offerti da WASM, ciascuna piattaforma ha anche i propri attributi unici.
L’adozione diffusa di WASM da parte di queste importanti piattaforme blockchain testimonia la sua crescente importanza nel settore, rendendo fondamentale comprendere perché questa tecnologia sta rapidamente diventando una pietra miliare della moderna architettura blockchain.
Perché scegliere WASM
Cos'è WASM
Per comprendere la sinergia tra blockchain e WebAssembly (WASM), bisogna prima capire cos’è WASM e la forza trainante dietro il suo sviluppo.
WebAssembly è un formato di istruzioni binarie che consente l'esecuzione del codice a una velocità quasi nativa all'interno di un browser Web. Serve come destinazione di compilazione per una gamma di linguaggi di programmazione, inclusi C e Rust, ed è progettato per essere veloce, efficiente e sicuro. WASM colma efficacemente il divario tra la programmazione basata sul web e quella a livello di sistema, migliorando così le prestazioni e le funzionalità web.
"Web" in WebAssembly evidenzia la sua capacità di essere eseguito all'interno di un ambiente JavaScript (di solito presente in un browser). In queste configurazioni, gli sviluppatori hanno pieno accesso all'API WASM e dispongono di un supporto completo dell'API Web, offrendo loro un notevole controllo sul comportamento web.
Storia del WASM
Seguendo il principio "scrivi una volta, esegui ovunque", WASM è emerso come una potente soluzione a una serie di sfide di lunga data. A partire dal 2016, molti programmi introducono nuove funzionalità attraverso linguaggi specifici del dominio (DSL), che spesso comportano compromessi tra manutenzione, efficienza e sicurezza. Esiste una crescente necessità di una soluzione in grado di fornire nuove funzionalità a innumerevoli server senza compromettere questi aspetti.
Sono state valutate le carenze delle varie soluzioni esistenti:
- Macchina virtuale del sistema
L'avvio e lo spegnimento frequenti comportano un sovraccarico eccessivo
Mancanza di visibilità del codice per garantire la sicurezza
Troppo astratto riguardo ai requisiti prestazionali
- contenitore
Mancanza di visibilità del codice per garantire la sicurezza
Inefficiente a causa dell'astrazione di alto livello
Le operazioni frequenti comportano un sovraccarico significativo
- Macchina virtuale a livello di lingua
Richiede frequenti modifiche per garantire la sicurezza
Le VM integrate, come la V8, richiedono molte risorse
Lento adattamento del nuovo linguaggio al modello di sicurezza
ancora troppo astratto
- Architettura del set di istruzioni (ISA)
Difficile eseguire un sandboxing efficace
I precedenti progetti Google sono stati spostati da esso a WASM
Mancanza di un'implementazione matura
Nel 2018, lo sviluppo di WASM ha acquisito slancio concentrandosi sull'esecuzione su varie architetture, server, hardware incorporato e persino sul supporto di più lingue. A differenza di Java, WASM è progettato senza compromettere la sicurezza. Entro il 2019 è stato introdotto un modello a componenti per migliorare il modulo WASM, consentendo l'interoperabilità tra lingue diverse. Ciò consente soluzioni come scrivere una libreria HTTP una volta e utilizzarla in più lingue.
Ad oggi, WASM ha una vasta gamma di funzionalità e viene sempre più adottato in scenari nativi del cloud, inclusa la blockchain. I suoi vantaggi includono:
alte prestazioni
Dimensione binaria compatta
Portabilità multipiattaforma
Supporta più linguaggi, come C/C++, Rust, AssemblyScript, ecc.
Esegui nel motore JavaScript
Sandbox potente con limiti di memoria e CPU
Tempi di avvio estremamente rapidi, in genere in millisecondi o meno
La comunità WASM continua a lavorare per una maggiore integrazione e prestazioni tra le lingue.
Comprendere l’evoluzione storica di WASM fornisce un contesto prezioso per comprendere i suoi ruoli attuali e potenziali in una varietà di contesti, inclusi progetti blockchain come Stylus. Questo background ci fornisce una comprensione articolata quando esploriamo le questioni e le preoccupazioni relative all’implementazione di WASM nell’ecosistema blockchain.
Domande e risposte sullo stilo
Supporto linguistico
L’evoluzione di WASM rivela perché Stylus è un’aggiunta entusiasmante all’ecosistema Arbitrum, ma evidenzia anche alcune limitazioni e preoccupazioni. Una delle preoccupazioni è il supporto linguistico. Sebbene Stylus abbia ampliato la comunità di sviluppatori Arbitrum per includere linguaggi come C++ e Rust, non è riuscito ad abbracciare linguaggi popolari come JavaScript e Python.
Sebbene esistano progetti preliminari volti a portare Python e JavaScript in WASM, questi sforzi non sono ancora pronti per un'adozione diffusa a causa delle sfide legate alla raccolta dei rifiuti e ai problemi di prestazioni.
Compatibilità linguistica
Attualmente, Stylus supporta gli SDK C/C++ e Rust, integrandosi perfettamente con le toolchain per questi linguaggi. Gli sviluppatori possono persino integrare librerie di terze parti, come implementazioni crittografiche native, durante la creazione di contratti intelligenti. Il limite principale di fare qualcosa del genere sono i costi del gas associati.
Sebbene l'SDK Rust sia ancora agli inizi, sia l'SDK Rust che quello C presentano alcune funzionalità mancanti. Ad esempio, l'SDK C non supporta le funzioni esportate ABI e i modificatori non sono ancora supportati in nessuno dei due SDK.
Attualmente non esiste un ambiente di test Stylus locale, ma gli sviluppatori possono eseguire i test direttamente all'interno dell'SDK. Per l’implementazione dei contratti intelligenti, testnet è attualmente l’unica opzione e non supporta ancora la verifica dei contratti intelligenti. Sono attualmente in corso sforzi per portare vari token ERC e **[Uniswap V2]** nell'ecosistema Stylus.
Il dilemma della scelta della lingua
La scelta tra linguaggi specifici del dominio (DSL), DSL incorporati (eDSL) e linguaggi di uso generale richiede un compromesso tra controllo di basso livello e astrazione di alto livello. Lo sviluppo di una DSL completamente nuova richiede investimenti significativi nella catena di strumenti e nello sviluppo dell’ecosistema. Al contrario, come sottoinsieme di un linguaggio generico, l’eDSL consente una più facile integrazione con gli strumenti esistenti e ha una curva di apprendimento più bassa. Ad esempio, sarebbe utile creare una eDSL in un linguaggio popolare come JavaScript o Python.
Un linguaggio comune richiede l'uso di un SDK, che introduce strumenti aggiuntivi, aumenta la verbosità e rende il codice meno espressivo, insieme a chiamate API e operazioni sugli oggetti più lunghe.
Trovare il giusto equilibrio tra scelta della lingua e sviluppo eDSL può essere la chiave per attrarre una più ampia comunità di sviluppatori fornendo allo stesso tempo strumenti di facile utilizzo. Secondo i dati attuali, la principale comunità di sviluppatori di criptovalute è ancora concentrata attorno a Ethereum. Tuttavia, anche le piattaforme che sfruttano Rust per i contratti intelligenti, come Polkadot, Cosmos e Solana, stanno guadagnando terreno e crescendo rapidamente tra le loro comunità di sviluppatori.
prestazione
WASM migliora significativamente la velocità di esecuzione e riduce le dimensioni dei pacchetti. Sebbene Stylus non sia ancora distribuito sulla rete principale, i benchmark di altre reti possono servire come riferimento utile. I tempi di esecuzione osservati sono 4-8 volte più rapidi e la dimensione della compilazione è ridotta di circa il 50%.
Stylus attualmente ha un limite di dimensione sui suoi contratti, limitato a circa 128KB non compresso. Questa limitazione rende difficile il porting di contratti intelligenti di grandi dimensioni da altri linguaggi come Solidity. Nel codice base di Stylus, questo limite è descritto di seguito:
Vale la pena notare che WASM comporta un sovraccarico durante l'avvio e lo spegnimento. Per le operazioni leggere, l’EVM può effettivamente essere più conveniente rispetto al WASM.
Interoperabilità con EVM
EVM e WASM condividono gli stessi slot di archiviazione e alberi di stato, il che facilita l'interoperabilità di Stylus con EVM. Ciò si ottiene tramite l'API EVM implementata in WASM, utilizzando il popolare modello Host I/O. Un elenco completo delle API EVM supportate dimostra che l'interoperabilità è completamente supportata.
Contratto precompilato personalizzato
Questo aspetto è particolarmente emozionante perché rappresenta un territorio inesplorato. I contratti precompilati personalizzati hanno il potenziale per portare ulteriori primitive crittografiche sulla catena con costi di esecuzione inferiori. Possono anche ridurre il costo dell'inferenza introducendo calcoli tensoriali come contratti precompilati. Tuttavia, non sembra esistere alcun codice relativo ai contratti precompilati personalizzati. Sebbene esistano contratti precompilati per i componenti EVM, non sono sostituibili a caldo.
Questa funzionalità potrebbe essere ancora in fase di sviluppo, sfruttando le capacità di WASM. L'EVM può chiamare funzioni scritte in WASM e quindi compilarle in codice macchina.
Funzionalità rientrante
A differenza di CosmWasm (che adotta un modello Actor senza rientro), l'SDK Rust di Stylus disattiva il rientro come flag di funzionalità per impostazione predefinita. Gli sviluppatori hanno la possibilità di abilitare questa funzionalità manualmente.
L'attivazione del rientro richiederà alcune modifiche all'API. In particolare, gli sviluppatori devono prestare attenzione alle precauzioni di sicurezza come l’aggiornamento della cache di archiviazione durante le chiamate.
Intuizione
Stylus apre nuovi casi d'uso che richiederebbero troppo gas se si utilizzasse solo l'EVM, come crittografia ad alte prestazioni, giochi e intelligenza artificiale. Consente inoltre di personalizzare contratti precompilati, consentendo agli sviluppatori di aggiungere la propria crittografia e altre funzionalità di base senza attendere gli aggiornamenti. In passato, abbiamo visto alcuni ecosistemi non Ethereum adottare WASM, come Cosmos e Polkadot. Questa è la prima volta che WASM viene adottato dalla comunità Ethereum. Nel complesso, Stylus rappresenta un'evoluzione significativa nello sviluppo di contratti intelligenti e aiuterà Ethereum e Arbitrum a crescere mantenendo l'interoperabilità con tutte le applicazioni esistenti.
L'integrazione di Stylus nell'SDK Layer 2 di Arbitrum offre maggiore flessibilità agli sviluppatori Layer 3. Ora possono spostare sulla catena calcoli intensivi che in precedenza superavano i limiti di gas, aprendo nuove possibilità. Gli sviluppatori non si limitano più a Solidity ma possono anche scegliere Rust o C++ se questi linguaggi si adattano meglio alle loro esigenze e competenze. I contratti precompilati personalizzati consentono la migrazione senza soluzione di continuità delle funzioni crittografiche, di utilità e di altro tipo preferite sulla catena per prestazioni ottimali. Scrivere logica di basso livello direttamente in un linguaggio adattato a ciascun caso d'uso porta a uno sviluppo più fluido. Gli sviluppatori possono concentrarsi sulle funzionalità principali del prodotto anziché ricorrere a soluzioni alternative per evitare i costi del gas. Eliminando i vincoli di lingua e gas, Stylus consente agli sviluppatori di terzo livello di creare fin dall'inizio le esperienze utente più efficienti, utilizzando gli strumenti giusti per il loro dominio.
Stylus dimostra inoltre la capacità di Arbitrum di innovare su larga scala e integrare nuove macchine virtuali. Ed Felten, co-fondatore e scienziato capo di Arbitrum & Offchain Labs, ha affermato che Arbitrum è sviluppato sulla base di strumenti e linguaggi di programmazione popolari nel settore. Possono scrivere test più rapidamente e sviluppare nuove funzionalità sui sistemi legacy. OP è andata oltre sulla strada della ZKizzazione e si è gradualmente spostata verso l'idea ibrida di Rollup. Optimism sta attualmente lavorando con Risc0 per utilizzare Zeth per generare prove a conoscenza zero per OPRU. Utilizzando questa soluzione, Optimism non ha bisogno di apportare ulteriori modifiche a OPRU. Se sei interessato a Zeth, puoi leggere quello che ho scritto prima [Twitter].
Non vediamo davvero l’ora di vedere le applicazioni AI ad Arbitrum. Attualmente, l’esecuzione del machine learning on-chain richiede molto impegno, rendendo lo sviluppo costoso. Il machine learning a conoscenza zero può ridurre i costi, ma introduce anche una significativa complessità aggiuntiva per gli sviluppatori. Se potessimo implementare le operazioni tensoriali come contratti precompilati personalizzati tramite Stylus ed eseguirle in modo nativo a una frazione del costo, si aprirebbero nuove possibilità per l'apprendimento automatico on-chain ad alte prestazioni. Consentendo agli sviluppatori di creare e distribuire rapidamente algoritmi ML come contratti precompilati facili da integrare in un linguaggio con cui hanno familiarità, come Python, Arbitrum può guidare la prossima generazione di innovazione dell'intelligenza artificiale in DeFi, GameFi e altro ancora. Le prestazioni e la flessibilità di Stylus ci consentiranno di concentrarci su architetture ML innovative piuttosto che sull'ottimizzazione del gas. Non vediamo l’ora di vedere la creatività della comunità applicata a questo paradigma emergente.
