Scopri ALPHred è la terza di una serie di innovazioni tecniche introdotte da Alephium. Trovate i precedenti qui (PolW) e qui (sUTXO). Qui esaminiamo cos’è una macchina virtuale, quale funzione svolge nelle blockchain e cosa distingue la VM di Alephium (chiamata Alphred) dalle altre.
traduzione in italiano dell’articolo pubblicato da alephium.org, link a fine articolo.
Che cos’è una VM ?
Una VM (Macchina Virtuale) è un programma software che emula le funzionalità di un computer fisico. Esistono diversi tipi di macchine virtuali e sistemi di virtualizzazione: alcuni consentono alle persone di giocare su una piattaforma su cui non sono stati pensati per essere giocati, e altri di eseguire un sistema operativo Windows su un computer Mac o Linux. Alcuni sono costruiti per eseguire programmi in modo decentralizzato su più macchine.
Un’altra caratteristica utile della VM è che risiede da qualche parte in un luogo simulato, senza influire sull’infrastruttura sottostante se le cose vanno storte. Se una macchina virtuale si arresta in modo anomalo, non è necessario riavviare il computer fisico, ma solo la macchina virtuale.
Le macchine virtuali e il mondo blockchain
Bitcoin ha, per sua natura, una macchina virtuale molto grezza e limitata. La sua programmabilità di base e la mancanza di completezza di Turing consentono ancora a bitcoin di essere efficiente in ciò che fa: mantenere un registro unificato funzionale di indirizzi e saldi su migliaia di nodi. Ma questo è tutto, il “denaro” non ha molto da eseguire, non c’è (quasi) alcuna possibilità di smart contract così com’è, motivo per cui la maggior parte dell’azione delle dApp avviene altrove e nessuna informazione dal mondo esterno può entrare nella rete. Ciò consente un design snello, una rete sicura, ma con funzionalità limitate: è un registro distribuito.
Ma cosa succede se si desidera eseguire calcoli più complicati nello stesso modo decentralizzato in cui opera Bitcoin? Questa è la domanda a cui Vitalik Buterin ha risposto quando ha concepito quello che all’epoca chiamava il «computer del mondo». Ha creato una macchina virtuale gestita come un’unica entità mantenuta da migliaia di nodi fisici connessi che eseguono un client Ethereum. Questa VM ha la capacità di compilare istruzioni complesse da smart contract, e tutte le modifiche create da queste istruzioni vengono registrate sulla blockchain, accessibile a tutti: si tratta di una macchina a stati.
L’esempio mostrato sopra è la Ethereum Virtual Machine (EVM), la prima grande macchina virtuale nel settore blockchain a vedere una maggiore adozione. Gli sviluppatori possono scrivere smart contract in un linguaggio di alto livello e leggibile dall’uomo chiamato Solidity. Quando una transazione utilizza questo codice, il compilatore converte le istruzioni risultanti in bytecode (che è il codice leggibile dalla macchina di basso livello). L’EVM esegue quindi il bytecode e i nodi trasmettono le modifiche (transazioni e blocchi) a tutti gli altri nodi.
Molte blockchain, molte VM
Quando altri progetti blockchain sono emersi dopo Ethereum, avevano due opzioni: sviluppare la propria macchina virtuale (VM) per soddisfare le proprie esigenze o adottare la Ethereum Virtual Machine (EVM) per facilitare l’esecuzione degli stessi smart contract di Ethereum. Fantom e Avalanche hanno scelto quest’ultima opzione e sono compatibili con EVM, mentre Polkadot, Solana e Cosmos hanno deciso di costruire le proprie VM.
Polkadot e Cosmos hanno optato per l’uso di WebAssembly (Wasm). Ciò ha permesso loro di supportare una gamma più ampia di linguaggi di programmazione (ad esempio Rust, Golang e C++), rendendo più facile per gli sviluppatori che già hanno familiarità con questi linguaggi lavorare allo sviluppo di smart contract ed espandere il proprio ecosistema.
Solana, d’altra parte, ha optato per l’infrastruttura del compilatore LLVM e la sua variazione del bytecode Berkeley Packet Filter (BPF). Solana attualmente supporta Rust e C/C++ come linguaggi di programmazione. La scelta di Solana è legata alla sua capacità di eseguire istruzioni native senza bisogno di una pre-compilazione (la traduzione dal codice di alto livello al codice di basso livello). Esegue la compilazione “just in time” nello stesso momento in cui viene eseguito il codice.
Ci sono molte altre VM diverse, come NeoVM, AVM, RSK, FUEL… e puoi trovare un confronto più esteso tra le VM disponibili qui.
La scelta di una VM e del relativo set di strumenti (linguaggio di programmazione, compilatore, ecc…) dipende da ciò che una blockchain sta cercando di realizzare.
Scopri ALPHred
Gli utensili di Alephium: Alphred & Ralph
L’UTXO stateful di Alephium combina UTXO e modello di account e dispone di funzionalità di smart contract. Ha bisogno di una VM per eseguire le istruzioni dello smart contract in un ambiente di runtime completamente diverso rispetto ad altre blockchain con funzionalità di sicurezza e prestazioni avanzate.
Questo ha imposto la decisione di creare una nuova VM, appositamente progettata per sfruttare i punti di forza di sUTXO. Come i nodi completi di Alephium, la VM è scritta in Scala per una maggiore sicurezza e denominata Alphred.
Analogamente all’EVM con Solidity, Alphred ha un linguaggio specifico di dominio chiamato Ralph. Ralph è stato creato appositamente per la blockchain di Alephium per essere estremamente espressivo e facile da usare. È stato appositamente progettato per essere sicuro in base alla progettazione perché sfrutta le funzionalità integrate della macchina virtuale. Questo esula dallo scopo di questo articolo e ci immergeremo in Ralph in particolare in un post successivo.
La combinazione di Ralph (il linguaggio) e Alphred (la macchina virtuale) ha molti vantaggi, di cui alcuni sono descritti qui:
Migliore UX, DevX e sicurezza durante lo spostamento delle risorse
Un sistema di autorizzazione degli asset controlla l’accesso e l’interazione con asset specifici sulla blockchain. Ad esempio, fornirebbe un quadro di riferimento su ciò a cui uno smart contract con cui un utente sta interagendo può accedere nell’account dell’utente: uno specifico NFT, tutti gli NFT, una quantità specifica di token, ecc…
In Ethereum, quando un utente vuole effettuare transazioni diverse da ETH, viene accolto con molteplici approvazioni confuse oltre alla transazione effettiva. Alphred elimina questa complessità e la rende molto semplice per un utente perché l’autorizzazione è definita a livello di funzione, standardizzando tutte le interazioni. Questo aiuta a prevenire errori umani o difetti di progettazione come chiedere agli utenti di approvare una spesa infinita in token.
Design compatibile con MEV
Un meccanismo di base del MEV (Miner Extractable Value) è quello di trovare opportunità di arbitraggio e cercare di estrarre valore dalla produzione di blocchi. I “ricercatori MEV” sono in grado di farlo perché possono speculare sull’ordine delle transazioni scavando nelle mempool. Uno degli incentivi a provarlo è perché questo processo può essere (quasi) privo di rischi: se la transazione proposta non viene eseguita, non c’è alcuna perdita finanziaria ad eccezione della tassa sul gas.
Su Alephium, poiché ogni transazione segue il paradigma Input/Output, un’operazione MEV complessa richiederebbe più transazioni sequenziali. Ciò renderebbe l’operazione più incline alla concorrenza, in quanto altri utenti potrebbero contro-eseguire qualsiasi transazione. Di conseguenza: più concorrenza sul MEV, più rischi per i ricercatori di MEV e, quindi, costi più elevati. Rispetto all’EVM, i ricercatori MEV non possono creare complicate operazioni di arbitraggio in una singola transazione. Possono fare solo la stessa cosa degli utenti normali. Ciò rende il protocollo più resistente contro MEV.
Resistente al prestito flash
Un flash loan raggruppa le transazioni successive all’interno di un blocco con esecuzione condizionale. Richiede l’interazione con diversi smart contract nella stessa transazione per prendere un prestito, utilizzarlo in una dApp e rimborsarlo. Se il rimborso non avviene, nessuna transazione è avvenuta. Questo funziona bene nelle blockchain del modello di account.
Alephium è basato su UTXO, il che significa che il paradigma Input/Output impone che solo l’output possa essere utilizzato dopo che la transazione è stata trasmessa alla rete. Pertanto, un prestito non può essere rimborsato istantaneamente nella stessa transazione. Ciò rende i prestiti flash impossibili per impostazione predefinita.
Progettazione più sicura
È difficile scrivere smart contract sicuri sulla maggior parte delle blockchain, in parte perché i loro linguaggi di programmazione e le loro VM danno agli sviluppatori “troppa libertà”. Quando scrivono codice e si affidano a fonti esterne (come le librerie) per eseguire le verifiche, c’è troppo spazio per gli errori e possono verificarsi bug, spesso critici.
Alphred è dotato di molti controlli e controlli integrati che, pur preservando una grande espressività e facilità d’uso per gli sviluppatori, li aiutano anche a evitare molti degli errori e dei bug più comuni. Ecco alcuni esempi:
Il controllo dell’overflow aritmetico è utile per impedire l’esecuzione di una transazione quando si verifica un overflow della memoria. Permette di individuare il problema prima dell’esecuzione, risparmiando tempo e risorse.
Dispone di un sistema di autorizzazione degli asset creato per fornire una verifica aggiuntiva per determinare che le transazioni di token siano inviate secondo le regole dello smart contract.
Alphred restituisce un’eccezione quando si verifica un errore, fornendo allo sviluppatore una spiegazione migliore dell’errore che si è verificato durante l’esecuzione della transazione.
Il Type System incorporato è in grado di verificare autonomamente il tipo di funzioni e variabili, rendendo il codice meno soggetto a errori. Queste protezioni aiutano a prevenire l’implementazione di smart contract difettosi, consentendo allo sviluppatore di concentrarsi su altre cose.
Eventi contract leggeri/personalizzabili
Ogni volta che qualcuno utilizza uno smart contract, emette eventi di contratto, che sono molto utili per gli sviluppatori e i servizi per monitorare l’attività on-chain. Ad esempio, se un analista vuole capire come viene utilizzato un DEX o quali sono le pool più popolari, può controllare gli eventi contrattuali degli swap o degli swap falliti, ecc… Sulla maggior parte delle catene EVM, questi eventi contrattuali vengono generati automaticamente e memorizzati on-chain per tutti gli smart contract per sempre.
In Alphred gli eventi di contratto sono possibili, attivati di default, e possono essere disabilitati: sono interamente configurabili e opzionali. Se qualcuno è interessato solo agli eventi emessi da un particolare DEX, può semplicemente ascoltarli. Questo dovrebbe portare a un uso più responsabile e mirato e a un minor numero di dati inutili archiviati, perché una catena più leggera è migliore per gli operatori dei nodi e per la decentralizzazione.
Bytecode con leggibilità migliorata
Quando uno sviluppatore scrive uno smart contract, lo fa in un linguaggio di alto livello e leggibile dall’uomo come Solidity o, nel nostro caso, Ralph. Quando un utente interagisce con uno smart contract, questo viene eseguito da un compilatore che interpreterà il codice leggibile dall’uomo (scritto dallo sviluppatore) in bytecode che la VM eseguirà. Il bytecode è solitamente difficile da leggere, il che rende il controllo un’attività goffa e dispendiosa in termini di tempo.
Il bytecode Alphred/Ralph è stato creato pensando alla leggibilità umana, rendendolo più facile da analizzare/verificare senza software aggiuntivo. Ciò è utile quando si eseguono unit test e si verifica il valore restituito di un’istruzione perché rende più efficiente la verifica del codice e il rilevamento tempestivo dei bug.
In conclusione (TL; DR)…
Una macchina virtuale esegue il codice dello smart contract e aggiorna lo stato della blockchain. Ogni blockchain implementa un design di VM mirato al raggiungimento di obiettivi specifici.
Nel caso di Alephium, la combinazione di Alphred (la VM) e Ralph (il linguaggio di programmazione) porta a una maggiore sicurezza attraverso controlli e verifiche integrati, prestazioni eccezionali e caratteristiche uniche (come la resistenza al flash loan) grazie al design UTXO.
Questa è stata solo una breve introduzione alle caratteristiche principali di Alphred. Un prossimo e dettagliato articolo, oltre ad alcuni thread su Twitter, farà più luce su Alphred nelle prossime settimane.
Fonte in Inglese:
Meet ALPHred, a Virtual Machine like no others | by Alephium | Medium