🇮🇹 "Sviluppo della programmabilità della blockchain"

[lordwotton]

Traduzione italiana di Development of blockchain programmability

Traduzione italiana a cura di Lordwotton di RIOT Stake Pools. Se apprezzi queste traduzioni, per favore valuta di supportare il mio lavoro delegando i tuoi ada a RIOT entra nel nostro gruppo Telegram

---

Sviluppo della programmabilità della blockchain

La prima generazione di blockchain è fondamentalmente solo una rete transazionale, simile a PayPal. Il valore può essere trasferito incondizionatamente solo da Alice a Bob. Il Bitcoin è più comunemente usato per il semplice trasferimento di valore. Tuttavia, esiste la possibilità di scrivere uno script. Cardano ed Ethereum sono piattaforme di contratti intelligenti, quindi è possibile creare servizi bancari alternativi su di esse. Le piattaforme consentono agli sviluppatori di implementare programmi più complessi e di lavorare con gli stati delle applicazioni. Nell’articolo descriveremo le possibilità di programmazione di Bitcoin, Ethereum e Cardano. Inoltre, esamineremo brevemente alcune differenze tra gli smart contract di Ethereum e gli script di Plutus.

Capacità della prima generazione di blockchain

Possiamo includere Bitcoin nella prima generazione di blockchain. Bitcoin ha introdotto il concetto di scarsità digitale. In generale, la blockchain consente di creare una politica monetaria fissa, immutabile o modificabile solo con il consenso della maggioranza. Possono esistere monete digitali (chiamate anche monete native) che non possono essere copiate all’interno del sistema.

Le monete native sono utilizzate come parte del modello di incentivo della rete (ricompensa per coloro che decentralizzano e proteggono la rete), ma questo è irrilevante per questo articolo.

L’esistenza delle monete dipende da una rete distribuita e dalla decentralizzazione.

La rete blockchain può garantire il trasferimento sicuro di monete tra due partecipanti, ad esempio da Alice a Bob, in quanto assicura che le stesse monete non vengano spese due volte di seguito (protezione contro il doppio uso delle monete). In questo modo si preserva la scarsità digitale. Inoltre, garantisce che solo il vero proprietario e nessun altro possa spendere le monete. Nella rete blockchain non è possibile imbrogliare, bloccare un account, impedire a qualcuno di usare la rete o di spendere monete, ecc.

La politica monetaria, la scarsità digitale, l’equità, l’uguaglianza e il trasferimento delle monete sono controllati da tutti i partecipanti al consenso della rete.

In poche parole, la prima generazione di blockchain è in grado di svolgere solo queste funzioni essenziali. La creazione di una politica monetaria fissa e il trasferimento incondizionato di valore digitale tra due partecipanti.

Il trasferimento di valore è incondizionato. La rete blockchain può solo verificare che Alice sia la vera proprietaria delle monete e che sia stata lei a ordinare il trasferimento del valore all’indirizzo di Bob attraverso la transazione. Se la convalida della transazione ha successo, Bob diventa il nuovo proprietario del valore (monete) una volta che la transazione viene inclusa nel nuovo blocco e il blocco viene finalizzato.

Nell’immagine sottostante si può vedere come un nodo Bitcoin verifica una comune transazione. Alice invia BTC a Bob. Il codice sorgente per la verifica delle transazioni è definito nel client Bitcoin. Il nodo verifica, oltre ad altre cose, se la transazione ha una firma digitale valida che dimostra la proprietà dei BTC in entrata, se la transazione spende BTC che sono già stati spesi da un’altra transazione e altre regole di consenso.

La convalida delle transazioni regolari non dipende da programmi di terze parti. Tutta la logica è implementata nel client Bitcoin. Se è necessario fare qualcosa di più complesso della normale convalida, come una firma digitale, è necessario che la logica sia programmata da una terza parte e che il protocollo consenta l’esecuzione del programma.

Sorge spontanea una domanda. Ha senso inviare transazioni in modo condizionato? Ha senso coniare nuovi gettoni che abbiano le stesse o simili proprietà delle monete native, cioè una politica monetaria immutabile? Oppure può essere utile che le politiche monetarie cambino (bruciare e ri-coniare i gettoni)? Ciò richiederebbe la definizione delle regole e la loro convalida in modo decentralizzato.

Gli script di Bitcoin consentono di implementare logiche più complesse. È possibile creare transazioni con più firme, transazioni con blocco temporale (il valore può essere speso solo dopo una certa data o altezza di blocco) o transazioni con blocco hash (il valore può essere speso solo rivelando un segreto che corrisponde a un determinato hash).

Lo scripting consente agli utenti di trasferire il valore al canale di stato (Lightning Network) o di definire una condizione per la spesa del valore in modo che la transazione debba essere firmata da un numero definito di partecipanti (ad esempio, due su tre).

Bitcoin può definire le condizioni per spendere BTC.

Lo scripting di Bitcoin è un linguaggio semplice, basato su stack e non Turing-completo, progettato per essere sicuro, deterministico e facile da verificare. Ciò comporta diverse limitazioni importanti per gli sviluppatori.

Lo scripting Bitcoin ha un insieme limitato di codici operativi e tipi di dati, che limita la funzionalità e l’efficienza degli script. Non supporta i loop, la ricorsione o la computazione statica, il che rende impossibile l’implementazione di alcuni algoritmi o protocolli. Inoltre, non ha accesso a dati o eventi esterni, il che limita l’interattività e l’adattabilità degli script. Lo scripting Bitcoin non ha una semantica formale o un sistema di tipi, il che rende difficile ragionare sulla correttezza e sulla sicurezza degli script.

La maggior parte delle transazioni nella rete Bitcoin sono standard. Nel 2021 il numero di transazioni non standard (script) è salito al 10-18% (le analisi differiscono tra loro).

È importante ribadire che il codice sorgente di Bitcoin si occupa del trasferimento dei valori all’interno delle transazioni normali. Nessuna terza parte può intervenire nell’elaborazione delle transazioni normali, poiché tutto è sotto il controllo dei nodi della rete distribuita (più precisamente, sotto il controllo dei pool).

Gli script sono sempre definiti da terzi e non fanno parte del codice sorgente di Bitcoin. Bitcoin è in grado di elaborare gli script tramite un interprete (di cui si parlerà più avanti). Gli script comportano alcuni rischi, in quanto potrebbe esserci un bug nella logica dello script.

Nelle immagini dell’articolo, gli script sono mostrati in rosso. L’interprete e le macchine virtuali sono mostrati in blu.

Chiunque crei una transazione può utilizzare gli script Bitcoin per specificare come i BTC della transazione possono essere spesi in futuro. Gli script Bitcoin vengono distribuiti includendoli negli input e negli output di una transazione. Gli input contengono gli script che sbloccano i BTC dalle transazioni precedenti, mentre gli output contengono gli script che bloccano i BTC per le transazioni future.

Gli script Bitcoin vengono elaborati dai nodi Bitcoin, che convalidano le transazioni. Quando un nodo riceve una transazione, controlla se gli script negli input e negli output sono validi e seguono le regole del consenso. Il nodo esegue gli script utilizzando un interprete basato su stack.

Un interprete basato su stack è un programma che può eseguire un altro programma scritto in un linguaggio speciale (nel caso di Bitcoin, si chiama semplicemente Script). L’interprete è incorporato nel nodo Bitcoin. L’interprete funziona leggendo le istruzioni dello script Bitcoin una per una (da sinistra a destra) ed eseguendo le azioni corrispondenti. Il nodo valuta gli script e, se il risultato finale è vero, la transazione viene accettata. Se il risultato finale è falso, o se c’è un errore o un’eccezione, la transazione viene rifiutata.

L’interprete è presente su ogni nodo Bitcoin. Se è necessario eseguire uno script come parte della convalida, ciò avverrà. Si noti che la convalida delle transazioni avviene in modo decentralizzato.

Nell’immagine sottostante si può vedere come il nodo Bitcoin verifica la transazione di uno script. La transazione contiene uno script (in rosso) con la logica per spendere il valore. Si tratta di una logica fornita da una terza parte. L’interprete di script (in blu) viene utilizzato per la convalida dello script. Il risultato della valutazione dello script determina se il valore sarà speso (cioè se la proprietà del valore passerà a Bob).

Ethereum è la prima piattaforma blockchain Turing-completa

Ethereum è la prima piattaforma decentralizzata che supporta un linguaggio di programmazione Turing-completo e di uso generale chiamato Solidity. Solidity può essere utilizzato per scrivere contratti intelligenti per qualsiasi tipo di logica o funzionalità. I contratti intelligenti sono programmi autoesecutivi che vengono eseguiti sulla blockchain di Ethereum e possono interagire con altri contratti intelligenti, utenti o fonti di dati esterne.

Una delle caratteristiche di Ethereum è che consente agli utenti di creare token personalizzati tramite gli smart contract. I token sono beni digitali che possono rappresentare qualsiasi cosa di valore, come valute, oggetti da collezione o diritti. La prima generazione di blockchain prevedeva solo monete native. Né il protocollo né gli script consentivano la creazione e il trasferimento di token personalizzati.

Ethereum ha reso possibile la scrittura di applicazioni complesse in grado di funzionare con le monete native e con tutta una serie di altri token. Grazie a Ethereum è nata l’industria della DeFi.

Ethereum EVM è la macchina virtuale di Ethereum, che è l’ambiente di esecuzione dei contratti intelligenti sulla rete Ethereum. La EVM è una macchina virtuale isolata, Turing-completa e basata su stack, in grado di eseguire istruzioni bytecode generate da linguaggi di programmazione di alto livello come Solidity. L’EVM può accedere e manipolare i dati memorizzati sulla blockchain, come i saldi dei conti, lo stato dei contratti o gli input e gli output delle transazioni. L’EVM applica anche le regole di consenso e il sistema di gas della rete, che limitano le risorse di calcolo e di archiviazione utilizzate dagli smart contract.

Una delle differenze tra Bitcoin ed Ethereum in termini di operazioni complesse è che le transazioni di Ethereum non contengono uno smart contract con la logica di spesa, ma solo un riferimento allo smart contract.

Gli smart contract sono memorizzati sulla blockchain di Ethereum. Gli smart contract vengono distribuiti sulla blockchain inviando un tipo speciale di transazione che contiene il bytecode e i parametri del costruttore dello smart contract. La transazione crea un nuovo indirizzo sulla rete che rappresenta lo smart contract. Il bytecode e lo stato dello smart contract sono memorizzati nella blockchain sotto questo indirizzo.

Per invocare uno smart contract, un utente può inviare un altro tipo di transazione che fa riferimento all’indirizzo dello smart contract e fornisce alcuni parametri, come il valore, il limite del gas, il prezzo del gas, i dati o la chiamata di funzione. La transazione attiverà l’esecuzione del codice dello smart contract da parte dei nodi della rete, utilizzando la macchina virtuale di Ethereum (EVM).

Gli script Bitcoin sono stateless, mentre gli smart contract Ethereum possono mantenere uno stato nel libro mastro. Ciò significa che gli script Bitcoin non hanno memoria o memorizzazione di transazioni o eventi precedenti e possono operare solo sui dati forniti dalla transazione corrente. Gli smart contract di Ethereum, invece, possono avere uno stato persistente che viene memorizzato sulla blockchain e può essere aggiornato o consultato dal codice dello smart contract.

L’assenza di stato degli script Bitcoin è una scelta progettuale che mira a garantire la sicurezza, il determinismo e la semplicità della rete Bitcoin. Non avendo uno stato, gli script Bitcoin evitano i problemi di corruzione, incoerenza o manipolazione dello stato che possono derivare da attori malintenzionati o da guasti della rete.

La statualità degli smart contract di Ethereum è una scelta progettuale che mira a consentire una maggiore espressività, funzionalità e interattività della rete Ethereum. Avendo uno stato, gli smart contract di Ethereum possono implementare logiche e funzionalità complesse e dinamiche per le transazioni, come la creazione di token, l’esecuzione di calcoli o l’interazione con altri smart contract. Gli smart contract di Ethereum consentono anche una maggiore interattività e adattabilità, in quanto possono utilizzare oracoli e trigger per accedere e reagire a informazioni esterne alla catena, come i feed dei prezzi, i timestamp o gli input degli utenti.

Nell’immagine sottostante si può vedere una transazione Ethereum in cui Alice invia un valore (token) a Bob. Trattandosi di token personalizzati, è necessario utilizzare uno smart contract. Alice inserisce un riferimento allo smart contract nella transazione. La macchina virtuale di Ethereum trova lo smart contract nella blockchain (compreso il suo stato attuale) ed esegue l’operazione richiesta.

Vediamo alcune differenze tra Solidy ed EVM rispetto a Bitcoin Script e a un interprete basato su stack.

Solidity offre una maggiore espressività. Solidity è un linguaggio di programmazione di alto livello, orientato agli oggetti e Turing-completo, in grado di implementare logiche e funzionalità complesse e flessibili per i contratti intelligenti.

Il codice Solidity viene compilato in istruzioni bytecode che vengono eseguite dall’EVM. Il codice Bitcoin Script è direttamente incorporato negli input e negli output delle transazioni e interpretato dai nodi della rete.

Il codice Solidity può accedere e reagire a dati o eventi esterni, come oracoli, trigger o input dell’utente, utilizzando vari meccanismi come chiamate di funzione, eventi o modificatori. L’elevata interattività con il mondo circostante consente di replicare i servizi bancari tradizionali. Il codice Bitcoin Script non può accedere o rispondere a dati o eventi esterni e può operare solo sui dati forniti dalla transazione stessa.

Solidity ed EVM possono offrire maggiore espressività ed eleganza rispetto a Bitcoin Script, in quanto possono utilizzare varie funzionalità come loop, ricorsione, stateful computation, funzioni di ordine superiore o valutazione pigra. Ethereum può offrire maggiore sicurezza e affidabilità rispetto a Bitcoin Script, in quanto gli smart contract possono utilizzare la verifica formale e i test per garantire la correttezza e la sicurezza degli smart contract (sono disponibili vari strumenti e framework).

La maggiore espressività e statualità può richiedere più abilità e attenzione rispetto a Bitcoin Script per la scrittura e l’esecuzione degli smart contract, in quanto possono comportare una maggiore complessità e potenziali insidie.

L’esecuzione dei contratti intelligenti può comportare costi maggiori rispetto a Bitcoin Script, in quanto possono consumare più gas per le risorse di calcolo e di archiviazione sulla rete. Ethereum può avere più problemi di scalabilità rispetto all’elaborazione di Bitcoin Script, in quanto l’esecuzione di contratti intelligenti può generare una maggiore congestione e latenza della rete a causa della loro maggiore richiesta di risorse.

La maggior parte delle transazioni di Ethereum è legata all’esecuzione di contratti intelligenti. DeFi, NFT e stablecoin sono settori rilevanti della blockchain che aprono nuove possibilità. Ethereum ha superato il Bitcoin per numero di utenti attivi e transazioni.

Cardano ha script nativi e script Plutus

Cardano è una piattaforma di smart contract simile a Ethereum, ma con molte differenze. Gli script su Cardano possono essere eseguiti in due modi: script nativi e script Plutus.

Gli script nativi sono semplici script che possono essere utilizzati per bloccare i fondi, coniare token o delegare le monete ADA. Sono scritti in un formato simile a JSON e possono essere interpretati direttamente dalle regole del ledger di Cardano. Pertanto, gli script nativi non richiedono strumenti speciali o macchine virtuali per la loro convalida.

Gli script nativi sono un modo per implementare una transazione con più firme. Sono utilizzati nei certificati di delega. Un certificato di delega è un tipo di transazione che consente a un partecipante di delegare le proprie monete ADA a una stake pool.

Nell’immagine sottostante è possibile vedere una transazione con uno script nativo. Si noti che il nodo Cardano non ha bisogno di alcuna macchina virtuale o interprete per eseguire lo script (a differenza di Bitcoin ed Ethereum). Vengono eseguiti in modo nativo. Alice può inviare una transazione con un certificato di delega in cui delega ADA al pool di Bob. In alternativa, può essere una transazione che contiene uno script di conio. I token saranno coniati all’indirizzo di Bob (emittente dei token).

Esistono due modi per includere uno script nativo in una transazione:

• In primo luogo, incorporando lo script come dato nella transazione. Ciò significa che lo script fa parte dei dati della transazione e può essere visto da chiunque controlli la transazione. Questo metodo è adatto a script brevi e semplici o che devono essere modificati frequentemente.

• In secondo luogo, la memorizzazione dello script sulla blockchain tramite una transazione e il riferimento al suo hash. Lo script viene memorizzato come output sulla blockchain e può essere identificato tramite il suo hash univoco. L’output deve avere un indirizzo che deriva dall’hash dello script e deve avere un valore di almeno 1 ADA per garantire che non venga potato dalla rete. Questo metodo è adatto a script lunghi e complessi o che devono essere fissi e immutabili.

È possibile fare riferimento allo script nativo memorizzato sulla blockchain per molte volte di seguito. Finché l’output dello script non viene speso da un’altra transazione, può essere utilizzato come input per più transazioni che utilizzano lo stesso script.

Nell’immagine sottostante si può vedere un caso simile a quello descritto sopra, con la differenza che la transazione fa riferimento a uno script nativo memorizzato nella blockchain attraverso un hash.

Gli script nativi sono per lo più logici on-chain, poiché sono incorporati nella transazione o memorizzati sulla blockchain. Tuttavia, possono anche avere una logica off-chain, come la generazione di transazioni che utilizzano script nativi come input o output. Ad esempio, è possibile utilizzare JavaScript, Python o Java per creare applicazioni che generano transazioni che utilizzano script nativi.

Ora diamo un’occhiata più da vicino agli script Plutus.

Gli script Plutus sono script più complessi ed espressivi che possono implementare una logica arbitraria e interagire con altri smart contract. Sono scritti in Plutus (linguaggio simile a Haskell), un linguaggio di programmazione funzionale, e compilati in Plutus Core, un linguaggio di basso livello che gira sulla macchina virtuale di Cardano (CVM).

Una delle caratteristiche principali dello scripting su Cardano è la separazione tra codice on-chain e codice off-chain (la logica del programma).

La logica on-chain è la logica che viene eseguita sulla blockchain e convalida le transazioni che coinvolgono gli smart contract. La logica on-chain è scritta in Plutus Core ed eseguita dalla macchina virtuale di Cardano. La logica on-chain è immutabile e trasparente, il che significa che non può essere modificata o nascosta una volta distribuita sulla blockchain.

La logica off-chain è la logica che viene eseguita al di fuori della blockchain e gestisce i requisiti e le interazioni dell’applicazione smart contract. La logica off-chain è scritta in Haskell, un linguaggio di alto livello che può utilizzare il Plutus Application Framework (PAF) per accedere a servizi quali nodi, portafogli, oracoli, ecc. Tuttavia, è possibile utilizzare anche altri linguaggi di programmazione di alto livello (JavaScript, Python o Java).

La logica off-chain è mutabile e privata, il che significa che può essere aggiornata o modificata senza influenzare la logica on-chain o richiedere un hard fork.

Gli script Plutus sono contratti intelligenti che utilizzano sia la logica on-chain che quella off-chain. La parte on-chain di uno script Plutus è chiamata script validatore, che decide se una transazione che spende un output è autorizzata a farlo. Il codice on-chain, come suggerisce il nome, è convalidato da tutti i nodi della rete Cardano. La parte off-chain di uno script Plutus è chiamata Plutus application backend (PAB), che genera transazioni conformi alle regole dello script validatore.

La separazione tra codice on-chain e codice off-chain è utile per diversi motivi. In primo luogo, consente agli sviluppatori di scrivere contratti intelligenti in un linguaggio di alto livello come Haskell, Java, Python JavaScript, più facile da leggere, scrivere e testare rispetto a linguaggi di basso livello come Plutus Core o Solidity. In secondo luogo, riduce le dimensioni e i costi delle transazioni che eseguono i contratti intelligenti, in quanto solo il codice on-chain essenziale è incluso nella transazione. In terzo luogo, migliora la sicurezza e la scalabilità dei contratti intelligenti, poiché il codice off-chain può essere aggiornato e modificato senza influenzare il codice on-chain o richiedere un hard fork.

La separazione tra codice on-chain e codice off-chain è utile per creare applicazioni di smart contract flessibili e robuste. Utilizzando strumenti come Plutus Application Framework (PAF) e Plutus Application Backend (PAB), gli sviluppatori possono facilmente creare e distribuire le loro applicazioni di smart contract localmente o in un ambiente di produzione live.

Gli script Plutus possono far parte delle transazioni come input o output, a seconda di come vengono utilizzati. Esistono due tipi principali di script Plutus: gli script di validazione e le politiche di conio (script di conio).

Gli script del validatore sono utilizzati per bloccare i fondi in un indirizzo di script e convalidare la spesa di tali fondi. L’output del validatore è un valore booleano (Vero significa che il valore può essere sbloccato/speso). Il validatore non è in grado di compiere un’azione, come chiamare un altro script o inviare dei token da qualche parte. Il validatore approva o rifiuta solo lo sblocco dei fondi all’indirizzo dello script.

Uno script del validatore può essere incorporato nella transazione come Datum o memorizzato sulla blockchain e referenziato dal suo hash. È simile agli script nativi. Il vantaggio di memorizzare lo script sulla blockchain è che riduce le dimensioni della transazione e le commissioni, ma rende anche lo script pubblico e immutabile.

Le politiche di conio sono utilizzate per controllare la creazione e la distruzione dei token personalizzati. Una politica di conio può essere memorizzata solo sulla blockchain e referenziata dal suo hash. Ciò garantisce che la politica di conio sia unica e coerente per tutti i token dello stesso tipo.

L’hash dello script è l’ID della politica dei token nativi che lo script conia. Quando si dispone di token con un particolare ID di politica, si può essere certi che i token sono stati coniati dallo script (politica di conio) che corrisponde all’ID di politica.

Gli script del validatore hanno una maggiore flessibilità, mentre le politiche di conio hanno una maggiore coerenza.

Quando lo script del validatore deve essere eseguito, gli vengono passate queste tre informazioni come argomenti:

• Datum: è un dato collegato all’UTxO che lo script sta bloccando. In genere viene utilizzato per trasportare lo stato (stato dell’applicazione).
• Redentore: è un dato collegato all’input di spesa. In genere viene utilizzato per fornire input allo script da parte di chi spende (dati di input che possono sbloccare fondi attraverso lo script).
• Contesto: È un dato che rappresenta informazioni sulla transazione di spesa. Viene utilizzato per fare affermazioni sul modo in cui viene inviato l’output.

Datum: è un dato opzionale. Il dato è sempre memorizzato accanto all’UTXO. Possono esserci più UTXO a un indirizzo, quindi possono esserci anche più Datum. Tutti i Datum all’indirizzo sono uguali. Nessun dato specifico serve come stato globale dello script. Tutti gli UTXO all’indirizzo sono indipendenti e il loro sblocco viene convalidato separatamente dallo script.

Nell’immagine sottostante è possibile vedere lo smart contract Cardano composto da logica off-chain (backend) e logica on-chain. Un’applicazione può utilizzare la logica off-chain per creare transazioni con script e lo stesso backend per creare transazioni di spesa. Bob ha creato la transazione con uno script. Contiene lo script Plutus (validatore) e anche l’UTxO che è bloccato attraverso il validatore (lo script). Un UTxO può contenere un Datum, ovvero un dato che può essere utilizzato per memorizzare lo stato del contratto. Alice vuole sbloccare l’UTxO. Per spendere l’UTxO, nella parte off-chain dello smart contract deve essere creata una transazione di spesa che può contenere un Redeemer. Il Redeemer è l’input per lo script Plutus, che decide se la transazione di spesa è valida o meno.

La logica applicativa definita nel backend consente a Bob di bloccare il valore e ad Alice di sbloccarlo. La prima transazione blocca i fondi all’indirizzo dello script e la seconda attiva l’esecuzione dello script per sbloccare i fondi.

Si noti che nel caso di una transazione di script (la transazione di Bob), la freccia dal lato sinistro del backend conduce direttamente alla transazione nella parte destra dell’immagine. Ciò significa che lo script Plutus non viene eseguito quando la transazione viene regolata. Lo script del validatore blocca i fondi all’indirizzo dello script e l’esecuzione viene attivata da una transazione di spesa (la transazione di Alice). Ecco perché la freccia conduce dalla transazione di spesa alla macchina virtuale Cardano.

La logica off-chain può generare transazioni di script che bloccano i fondi in un indirizzo di script e richiedono uno specifico valore Redeemer per sbloccarli. Ad esempio, Bob può utilizzare la logica off-chain per creare una transazione script che blocca 10 ADA in un indirizzo script e richiede il valore Redeemer “Hello” per sbloccarli. Bob può quindi inviare l’indirizzo di script e il valore Redeemer ad Alice, che può utilizzare la logica off-chain per creare una transazione di spesa che fornisce il valore Redeemer corretto e spende i 10 ADA dall’indirizzo di script.

La logica off-chain può utilizzare il Plutus Application Backend (PAB) per gestire e gestire i requisiti dell’istanza di applicazione durante il suo ciclo di vita. Il PAB funge da intermediario tra le applicazioni Plutus, il nodo, il backend del portafoglio e gli utenti finali. Il PAB contribuisce anche alla creazione delle transazioni che eseguono gli script Plutus sulla blockchain.

Gli script Plutus sono stateless, nel senso che non hanno accesso ad alcuna memoria persistente o variabile globale. Tuttavia, possono utilizzare una tecnica chiamata state threading per simulare un comportamento statico passando dati tra diverse istanze di script. Lo stato viene memorizzato come un Datum collegato a un’uscita di script, a cui può accedere il successivo input di script che spende quell’uscita. Il dato può essere qualsiasi tipo di dato arbitrario che lo script può codificare e decodificare.

Il threading dello stato consente agli script Plutus di implementare logiche e interazioni complesse, come macchine a stati, oracoli e schemi a firma multipla. Tuttavia, richiede anche un’attenta progettazione e coordinamento per garantire che lo stato sia aggiornato in modo corretto e coerente. Ad esempio, uno script potrebbe dover verificare che lo stato non sia stato modificato da un’altra transazione dall’ultima volta che vi si è acceduto, o che lo stato rientri in un intervallo di valori valido.

Gli script di Plutus sono più espressivi degli script di Bitcoin e degli smart contract di Ethereum. Haskell è un linguaggio di programmazione funzionale che può implementare una logica arbitraria e interagire con altri smart contract. Il backend può essere implementato in qualsiasi linguaggio di alto livello. Anche Solidity può implementare una logica complessa e interagire con altri smart contract, ma presenta alcune limitazioni e svantaggi rispetto ad Haskell. Ad esempio, Solidity presenta un rischio maggiore di bug e vulnerabilità a causa dello stato mutabile e dei dettagli di basso livello. Solidity ha anche un costo di esecuzione più elevato a causa del suo modello a gas, che limita la complessità e la scalabilità delle applicazioni di smart contract su Ethereum.

Haskell è un linguaggio che supporta la verifica formale, poiché ha una sintassi chiara e precisa, un sistema di tipi forte e statico e una semantica pura e deterministica. Haskell dispone anche di librerie e strumenti che possono aiutare nella verifica formale, come QuickCheck, LiquidHaskell e Coq.

Se si osservano i tipi di transazioni in un periodo di tempo più lungo, si noterà che le transazioni con uno script sono circa due volte più numerose di quelle comuni. Cardano ha risorse native. Se gli utenti vogliono inviare token tra loro, non c’è bisogno di usare uno script. Pertanto, la quantità di transazioni comuni è relativamente alta rispetto a Ethereum (è sempre necessario utilizzare uno smart contract per trasferire asset).

Conclusione

Il Bitcoin non ha e non avrà le stesse capacità di Cardano o Ethereum. Gli script di Bitcoin sono molto semplici e non permettono di creare la logica complessa necessaria per creare un servizio finanziario alternativo. Ordinals, Inscriptions e BRC-20 sono tecnologie che non hanno il potenziale per superare le capacità delle piattaforme SC. Il protocollo Bitcoin fondamentalmente si limita a scrivere dati sulla blockchain senza alcuna validazione del contenuto. Non è prevista l’esecuzione di programmi di terze parti.

Nell’articolo ci siamo concentrati principalmente sulla descrizione delle opzioni di programmabilità e non troppo sul confronto. Lo esamineremo la prossima volta.