Skip to main content

Cos'è una blockchain non-EVM

Nota: Questo documento è una traduzione automatica della versione originale in inglese.

Cos'è una blockchain non-EVM

Una blockchain non-EVM è qualsiasi blockchain che non usa la Ethereum Virtual Machine come motore di esecuzione. Invece di eseguire bytecode Solidity, le chain non-EVM usano macchine virtuali diverse, linguaggi di programmazione diversi e modelli di esecuzione diversi. Esempi includono Solana (SVM/Sealevel), le chain basate su Cosmos (CosmWasm, moduli applicativi specifici), NEAR (runtime basato su WebAssembly), Sui e Aptos (MoveVM) e Bittensor (runtime personalizzato basato su Substrate).

La distinzione è importante perché la scelta della macchina virtuale determina quali linguaggi di programmazione usano gli sviluppatori, come si comportano gli smart contract, quali strumenti sono disponibili e con quanta facilità un progetto può interagire con altre chain. Un progetto costruito su una chain non-EVM non può semplicemente copiare e incollare contratti Solidity da Ethereum — ha bisogno di una codebase diversa, di competenze di sviluppo diverse e di un diverso insieme di strumenti infrastrutturali.

In sintesi: le blockchain non-EVM usano ambienti di esecuzione diversi dalla Ethereum Virtual Machine. Ciò significa linguaggi di programmazione diversi, strumenti diversi e compromessi architetturali diversi — ma anche il potenziale per caratteristiche prestazionali che la EVM non può raggiungere.

In cosa l'esecuzione non-EVM differisce dalla EVM

La EVM è una macchina virtuale basata su stack che esegue bytecode Solidity in modo sequenziale, usa interi a 256 bit e misura la computazione tramite il gas. Le chain non-EVM si discostano da questo modello in vari modi:

Macchine virtuali diverse

Chain / ecosistema Macchina virtuale Linguaggio principale Differenza architetturale chiave
Solana SVM (Sealevel) Rust Esecuzione parallela delle transazioni tramite dichiarazione anticipata dell'accesso allo stato
Chain Cosmos CosmWasm / moduli nativi Rust (CosmWasm), Go (moduli) Blockchain specifiche per applicazione con comunicazione cross-chain integrata (IBC)
NEAR WebAssembly (Wasm) Rust, AssemblyScript Esecuzione shardizzata con chiamate cross-shard asincrone
Sui MoveVM Move Modello di stato centrato sugli oggetti che consente l'esecuzione parallela
Aptos MoveVM Move Motore di esecuzione parallela Block-STM
Bittensor Runtime Substrate Rust Coordinamento specifico per l'AI; le subnet come unità di esecuzione

Ogni macchina virtuale fa compromessi diversi. La SVM di Solana richiede che le transazioni dichiarino in anticipo a quale stato accederanno, consentendo al runtime di eseguire in parallelo le transazioni non in conflitto — cosa che la EVM non può fare nativamente. Le chain Cosmos abbandonano completamente il modello di esecuzione condivisa: ogni applicazione ottiene la propria chain con logica personalizzata, collegata alle altre chain tramite il protocollo IBC. Le chain basate su Move (Sui, Aptos) usano un modello di programmazione orientato alle risorse che previene certe classi di bug (come la reentrancy) a livello di linguaggio.

Linguaggi di programmazione diversi

L'ecosistema EVM è dominato da Solidity — un linguaggio progettato specificamente per gli smart contract di Ethereum. Le chain non-EVM usano linguaggi generici o alternative costruite su misura:

  • Rust — usato da Solana (tramite il framework Anchor), Cosmos (tramite CosmWasm), NEAR e le chain basate su Substrate, inclusa Bittensor. Le garanzie di sicurezza della memoria e le prestazioni di Rust lo rendono adatto ai programmi on-chain.
  • Move — sviluppato originariamente presso Facebook/Diem, oggi usato da Sui e Aptos. Move tratta gli asset on-chain come risorse di prima classe che non possono essere duplicate o distrutte accidentalmente, riducendo una categoria di vulnerabilità comuni degli smart contract.
  • Go — usato per lo sviluppo di moduli nativi nelle chain Cosmos SDK. I validator eseguono direttamente binari compilati in Go.
  • AssemblyScript — un linguaggio simile a TypeScript che compila in WebAssembly, usato come linguaggio alternativo per lo sviluppo su NEAR.

Questa diversità di linguaggi significa che gli sviluppatori non possono trasferire direttamente le competenze Solidity alle chain non-EVM. Un progetto che costruisce su Solana ha bisogno di ingegneri Rust; un progetto che costruisce su Sui ha bisogno di ingegneri Move. Il bacino di talenti per ciascun linguaggio influisce sulla rapidità con cui un progetto può costruire e iterare.

Caratteristiche prestazionali diverse

Le chain non-EVM raggiungono spesso profili prestazionali diversi:

  • Esecuzione parallela — Solana, Sui e Aptos eseguono in parallelo le transazioni non in conflitto, il che può offrire un throughput più elevato rispetto al modello di esecuzione sequenziale della EVM.
  • Commissioni più basse e più prevedibili — alcune chain non-EVM hanno strutture di commissioni progettate fin dall'inizio per un throughput elevato, evitando i mercati delle commissioni volatili che le chain EVM possono sperimentare durante la congestione.
  • Modelli di stato personalizzati — le chain non-EVM possono usare modelli di stato ottimizzati per specifici pattern di accesso. Il modello centrato sugli oggetti di Sui, ad esempio, consente la proprietà per oggetto e un'elaborazione parallela che sarebbe complessa da implementare sulla EVM.

Questi vantaggi prestazionali comportano compromessi: ecosistemi di sviluppatori più piccoli, strumenti meno maturi, meno società di audit con competenze pertinenti e minore componibilità con il vasto ecosistema DeFi e di token basato sulla EVM.

Perché è importante per i progetti crypto AI

La scelta della macchina virtuale ha implicazioni pratiche per i progetti blockchain legati all'AI:

  • Flessibilità di esecuzione — le chain non-EVM possono supportare modelli di esecuzione più adatti ai carichi di lavoro di coordinamento AI. Esecuzione parallela, macchine a stati personalizzate e insiemi di istruzioni a basso overhead possono servire meglio le transazioni ad alta frequenza legate all'AI (assegnazioni di task di calcolo, invio di risultati, aggiornamenti dei registri dei modelli).
  • Affinità di linguaggio — le chain basate su Rust si allineano bene con l'infrastruttura AI/ML, poiché gran parte degli strumenti AI (componenti critiche per le prestazioni, coordinamento delle GPU, programmazione di sistema) è scritta in Rust o si interfaccia bene con il codice Rust.
  • Design specifico per applicazione — le appchain Cosmos e le subnet di Bittensor consentono ai progetti AI di costruire logiche di esecuzione personalizzate a livello di chain, senza i vincoli dell'insieme di opcode e del modello di gas della EVM.
  • Compromessi di ecosistema — i progetti non-EVM non possono attingere facilmente al vasto ecosistema EVM di protocolli DeFi, bridge di token e infrastrutture di wallet. I progetti AI su chain non-EVM devono costruire questa infrastruttura da soli, affidarsi a bridge cross-chain o accettare un ecosistema iniziale più piccolo.

Nelle schede progetto DecAIHub, Type: non-EVM comunica al lettore che il progetto non usa Solidity, non può effettuare il deployment su chain compatibili EVM senza riscritture e opera in un ecosistema tecnico diverso.

Dove compare nelle schede progetto DecAIHub

Nelle schede progetto DecAIHub, la designazione non-EVM compare in:

  • Type — non-EVM indica che gli smart contract o la logica on-chain del progetto usano una macchina virtuale diversa dalla EVM. Questo influisce su quali strumenti, linguaggi e standard si applicano.
  • Main chain — viene indicata la specifica chain non-EVM (Solana, Bittensor, una chain Cosmos, Sui, ecc.). Ogni chain ha la propria VM, il proprio linguaggio e il proprio ecosistema.
  • Token standard — le chain non-EVM hanno propri standard di token. Solana usa i token SPL; le chain Cosmos usano denominazioni native o CW-20 (CosmWasm); le chain basate su Move usano risorse coin/fungible-asset. Non sono intercambiabili con ERC-20.
  • Smart contract / logica on-chain — il linguaggio di programmazione e il framework differiscono dai progetti EVM. I programmi Solana sono scritti in Rust (Anchor), i contratti Cosmos in Rust (CosmWasm) o Go, e così via.

Cosa una classificazione non-EVM da sola non dimostra

  • Non-EVM non significa prestazioni migliori. Sebbene alcune chain non-EVM offrano esecuzione parallela o commissioni più basse, le prestazioni dipendono dalla chain specifica, dalla sua infrastruttura di validator e dal carico attuale — non solo dalla scelta della VM.
  • Non-EVM non dimostra sofisticazione tecnica. Scegliere una chain non-EVM è una decisione infrastrutturale. Non indica la qualità della componente AI del progetto, del suo codice o del suo prodotto.
  • Non-EVM non significa che il progetto non possa interagire con le chain EVM. Molti progetti non-EVM usano bridge, oracoli o wrapped token per connettersi con Ethereum e altri ecosistemi EVM. L'interazione cross-chain è possibile; richiede solo infrastruttura aggiuntiva.
  • Una VM diversa non significa garanzie di sicurezza diverse. Bug negli smart contract, errori di logica e rischi di centralizzazione esistono su tutte le chain indipendentemente dalla macchina virtuale. Linguaggi non-EVM come Rust e Move eliminano alcune classi di bug ma ne introducono altre.
  • Un'etichetta non-EVM non spiega perché il progetto ha scelto quella chain. La scelta può essere guidata da esigenze prestazionali, dalle competenze del team di sviluppo, da incentivi di ecosistema o semplicemente da dove il team fondatore ha iniziato. Senza contesto aggiuntivo, l'etichetta da sola è informativa, non valutativa.

Da non confondere con

  • EVM — la EVM è la Ethereum Virtual Machine. Non-EVM si definisce in contrapposizione ad essa: qualsiasi chain che non usa la EVM rientra nella categoria non-EVM.
  • Ethereum — Ethereum è la chain EVM originale. Essere non-EVM significa che la chain non è Ethereum e non usa il motore di esecuzione di Ethereum — ma può comunque interagire con Ethereum tramite bridge o protocolli cross-chain.
  • Solana — Solana è una specifica blockchain non-EVM con la propria macchina virtuale (SVM). "Non-EVM" è una categoria ampia che include Solana, Cosmos, Sui, Aptos, NEAR, Bittensor e molte altre.
  • "Anti-Ethereum" — essere non-EVM non è una presa di posizione contro Ethereum. Molte chain non-EVM coesistono con Ethereum e beneficiano della liquidità collegata tramite bridge. La scelta della VM riflette priorità di design diverse, non un'opposizione ideologica.
  • Incompatibile — le chain non-EVM non possono eseguire nativamente bytecode EVM, ma questo non significa che siano isolate. Bridge cross-chain, protocolli di messaggistica (come IBC, LayerZero, Wormhole) e wrapped token consentono l'interoperabilità tra ecosistemi EVM e non-EVM.

Domande frequenti

Quali sono le chain non-EVM più comuni usate dai progetti crypto AI?

Solana e Bittensor sono tra le chain non-EVM più frequentemente incontrate nello spazio crypto AI monitorato da DecAIHub. L'elevato throughput di Solana e il suo ecosistema basato su Rust attraggono progetti AI che necessitano di un coordinamento on-chain rapido e a basso costo. Bittensor è costruita appositamente per l'AI decentralizzata, con subnet dedicate a specifici compiti AI. Le appchain basate su Cosmos sono un altro pattern, in particolare per progetti che vogliono un ambiente di esecuzione completamente personalizzato con comunicazione cross-chain integrata tramite IBC.

Un progetto non-EVM può effettuare il deployment anche su chain EVM?

Sì, ma richiede una codebase separata. Un progetto scritto in Rust per Solana non può essere distribuito su Ethereum così com'è — dovrebbe essere riscritto in Solidity (o avere un'implementazione Solidity separata). Alcuni progetti mantengono contratti sia su chain EVM sia non-EVM, ma ogni deployment richiede sviluppo, audit e manutenzione indipendenti. I bridge cross-chain possono inoltre consentire ai progetti non-EVM di avere una rappresentazione del token su chain EVM (ad esempio, token SPL wrapped come ERC-20 su Ethereum).

Il non-EVM è migliore per le applicazioni AI?

Non esiste una risposta universale. Le chain non-EVM possono offrire vantaggi per specifici casi d'uso AI — l'esecuzione parallela di Solana si adatta al coordinamento ad alto throughput, l'architettura a subnet di Bittensor è costruita appositamente per gli incentivi AI e le appchain Cosmos consentono logiche di esecuzione completamente personalizzate. Tuttavia, le chain EVM offrono un ecosistema di sviluppatori più grande, strumenti più maturi, liquidità DeFi più profonda e un supporto dei wallet più ampio. La scelta migliore dipende dai requisiti specifici del progetto: quali carichi di lavoro vengono eseguiti on-chain, quali prestazioni servono, quale ecosistema il team preferisce e dove si trovano gli utenti target.

Le chain non-EVM hanno standard di token come ERC-20?

Sì, ma diversi. Solana usa i token SPL. Le chain Cosmos usano denominazioni native o token CW-20 (tramite CosmWasm). Sui e Aptos usano le risorse coin e fungible asset di Move. NEAR usa NEP-141. Ogni standard definisce come i token vengono creati, trasferiti e gestiti su quella chain. Questi standard non sono intercambiabili con ERC-20 — un token creato come SPL su Solana non può essere usato direttamente su una chain EVM senza wrapping o bridging.

Riferimenti esterni

Vedi anche

No comments to display

Back to top