Una EVM parallela è un nuovo linguaggio per smart contract?

No. L'obiettivo è di solito eseguire il bytecode EVM esistente e supportare gli strumenti Solidity, cambiando il modo in cui il software dei nodi pianifica e valida internamente le transazioni tra i core del processore.

Due transazioni che toccano lo stesso contratto possono essere eseguite in parallelo?

È possibile, se accedono a storage diversi e il motore può dimostrare o validare l'indipendenza. Condividere solo un indirizzo di contratto non crea sempre un conflitto, ma condividere chiavi di stato spesso sì.

Che cosa succede quando transazioni parallele entrano in conflitto?

Il motore rileva la dipendenza non valida, scarta o ritarda il risultato provvisorio interessato e lo esegue di nuovo rispetto allo stato precedente corretto. Alcuni sistemi tornano all'elaborazione sequenziale in caso di forte contesa.

La compatibilità con EVM parallela garantisce la sicurezza di livello Ethereum?

No. La compatibilità riguarda il comportamento esecutivo. Consenso, distribuzione dei validatori, archiviazione dello stato, bridge, governance, permessi di aggiornamento, finalità e disponibilità dei dati determinano parti separate del modello di sicurezza di una rete.

Che cos'è una EVM parallela e come funziona l'esecuzione parallela?

Una EVM parallela è un'implementazione della Ethereum Virtual Machine o un motore di esecuzione compatibile EVM che elabora transazioni indipendenti in modo concorrente su più core CPU. Le transazioni mantengono comunque un ordine deterministico e devono produrre lo stesso stato finale di un'esecuzione EVM sequenziale valida. La parallelizzazione cambia il modo in cui i nodi calcolano internamente i risultati, non il significato dei contratti Solidity né lo stato contabile ordinato osservato dagli utenti.

Il design affronta un collo di bottiglia esecutivo tipico dell'elaborazione sequenziale a thread singolo. Quando le transazioni toccano account o slot di storage non correlati, un nodo può elaborarle contemporaneamente. Quando entrano in conflitto, il motore deve rilevare la dipendenza, scartare o ritardare un risultato speculativo non valido ed eseguire la transazione interessata rispetto allo stato precedente corretto. Le prestazioni dipendono quindi in larga misura dalla contesa del carico di lavoro e dalla progettazione dello storage.

Che cos'è una EVM parallela?

Una EVM parallela è un ambiente di esecuzione compatibile con Ethereum in grado di elaborare più transazioni indipendenti contemporaneamente, invece di eseguire ogni transazione rigorosamente una dopo l'altra. Mira a preservare i familiari smart contract EVM, gli indirizzi, i formati delle transazioni e gli strumenti per sviluppatori, migliorando al contempo il throughput delle transazioni.

Le implementazioni di EVM parallela possono usare metodi diversi per identificare quali transazioni possono essere eseguite insieme in sicurezza. Alcune rilevano i conflitti durante l'esecuzione, mentre altre analizzano quali parti dello stato della blockchain accederà ogni transazione prima di programmarla. EVM parallela descrive quindi un approccio esecutivo, non uno standard universale, e le reti possono comunque differire per consenso, commissioni, finalità, requisiti hardware e compatibilità con Ethereum.

Come funziona una EVM parallela?

Una EVM parallela funziona assegnando le transazioni di un blocco ordinato a più worker e monitorando lo stato che ogni transazione legge e scrive. Con l'esecuzione ottimistica, i worker presumono inizialmente che le transazioni possano essere eseguite insieme. I loro output restano provvisori finché il motore non verifica che una transazione precedente non abbia modificato un input usato da una successiva. I risultati non in conflitto possono essere confermati secondo l'ordine originale del blocco.

Se una transazione successiva legge dati obsoleti o genera conflitti in scrittura, il suo output provvisorio viene rifiutato e la transazione viene rieseguita dopo che lo stato precedente necessario diventa disponibile. Alcuni motori possono riutilizzare firme, bytecode decodificato, stato in cache o altro lavoro durante la riesecuzione. Un fallback sequenziale preserva i progressi in caso di forte contesa. Ogni validatore deve applicare regole deterministiche di conflitto e commit, così che la programmazione parallela non possa creare root di stato diverse.

Quali sono i principali vantaggi e casi d'uso di una EVM parallela?

I design di EVM parallela sono più efficaci quando un blocco contiene molte transazioni che operano su stato separato. Mirano ad aumentare la capacità di esecuzione dei nodi senza costringere gli sviluppatori Solidity e gli utenti in un ambiente poco familiare.

1. Più core possono elaborare lavoro indipendente. Trasferimenti e chiamate a contratti che toccano account o slot di storage diversi possono essere eseguiti simultaneamente, sfruttando l'hardware moderno dei validatori in modo più completo rispetto a un singolo thread di esecuzione.

2. Le applicazioni EVM possono mantenere strumenti familiari. Le reti compatibili possono supportare contratti Solidity, wallet in stile Ethereum, interfacce JSON-RPC e framework di sviluppo, pur cambiando l'esecuzione sotto il livello applicativo.

3. Le applicazioni ad alto volume ottengono più spazio di esecuzione. Pagamenti, giochi, exchange e applicazioni social con stato distribuito possono elaborare blocchi più grandi quando le loro transazioni creano relativamente pochi conflitti di stato condiviso.

4. L'ottimizzazione può restare trasparente per i contratti. I motori ottimistici come Monad confermano i risultati come se le transazioni fossero eseguite in sequenza, così gli sviluppatori non devono dividere manualmente i contratti ordinari solo per attivare la concorrenza.

Quali sono esempi di motori di esecuzione parallela?

I progetti usano l'esecuzione parallela con macchine virtuali e modelli di stato diversi. I sistemi non EVM restano riferimenti utili perché diverse tecniche di concorrenza ottimistica sono state sviluppate o implementate prima al di fuori dell'EVM.

Monad: EVM parallela ottimistica. Monad esegue transazioni compatibili con Ethereum in modo concorrente, monitora i loro input e riesegue una transazione quando un risultato confermato in precedenza ha modificato i dati che utilizzava.
Sei: motore di parallelizzazione. Sei utilizza il controllo di concorrenza ottimistica, set di accesso stimati, esecuzione basata su worker, rilevamento dei conflitti, rielaborazione deterministica e un fallback sequenziale attorno al suo ambiente EVM.
Aptos Block-STM. Block-STM è un motore di esecuzione parallela basato sulla memoria transazionale software e sullo stato multi-versione, che dimostra un'esecuzione ottimistica trasparente per transazioni blockchain ordinate.
Solana Sealevel. Solana non è una EVM, ma il suo runtime dimostra un modello diverso in cui le transazioni dichiarano l'accesso agli account, così il lavoro non in conflitto può essere programmato in parallelo.

Quali sono i limiti e i rischi di una EVM parallela?

L'esecuzione parallela non può eliminare le dipendenze inerenti allo stato dell'applicazione. Aggiunge inoltre complessità di scheduling, validazione, caching, database e riesecuzione che deve essere implementata in modo coerente tra i nodi.

1. Lo stato conteso riduce i guadagni di velocità. Le transazioni che interagiscono con lo stesso pool di liquidità, contatore globale, valore dell'oracolo o slot di contratto popolare possono entrare in conflitto e richiedere serializzazione o esecuzione ripetuta.

2. La speculazione può sprecare calcolo. Un worker ottimistico può completare una transazione usando input obsoleti solo per scartare il risultato, aumentando il lavoro di CPU e memoria quando i tassi di conflitto sono elevati.

3. La complessità implementativa amplia la superficie dei bug. Scheduler, storage multi-versione, rilevamento dei conflitti, caching e logica di commit devono riprodurre esattamente la semantica EVM attraverso revert, contabilità del gas, chiamate e casi limite.

4. I benchmark possono non rappresentare carichi di lavoro reali. Il throughput di punta da trasferimenti indipendenti può sovrastimare le prestazioni per applicazioni in cui molti utenti competono per modificare un piccolo insieme di posizioni di storage condivise.

5. Una capacità maggiore può aumentare i requisiti dei nodi. Le reti devono bilanciare CPU, memoria, larghezza di banda dello storage, progettazione del database e crescita dello stato, affinché gli obiettivi di prestazioni non rendano impraticabile la validazione indipendente.

Una EVM parallela cambia i risultati degli smart contract?

Una EVM parallela implementata correttamente non cambia il risultato finale definito dall'ordine delle transazioni della rete. Il lavoro parallelo è provvisorio e il motore conferma o riesegue le transazioni affinché lo stato finale corrisponda alla semantica sequenziale richiesta. Gli utenti possono sperimentare una capacità maggiore o una congestione inferiore, ma i contratti dovrebbero comunque osservare gli stessi effetti ordinati. Questa garanzia rende la gestione deterministica dei conflitti più importante della semplice esecuzione di molti thread.