🇮🇹 "Plutus: cosa c'è da sapere"

:it: Traduzione italiana di “Plutus: what you need to know” scritto da Lars Brunjes nel blog IOHK

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 :pray: entra nel nostro gruppo Telegram


Plutus: cosa c’è da sapere

Gli sviluppatori si stanno preparando per l’arrivo dei contratti intelligenti Cardano, abilitati da Plutus e dall’aggiornamento del protocollo Alonzo

img

Nel nostro precedente post sul blog, abbiamo discusso di Alonzo - il nostro nome dato all’aggiornamento del protocollo che introdurrà il supporto ai contratti intelligenti su Cardano. Alonzo stabilirà l’infrastruttura e aggiungerà strumenti per lo sviluppo funzionale di smart contract utilizzando Plutus.

La piattaforma Plutus fornisce un linguaggio nativo di contratti intelligenti per la blockchain di Cardano. Per capire e diventare abili in Plutus, si devono capire tre concetti:

  • Il modello UTXO esteso (EUTXO)
  • Plutus Core - la parte “on-chain” di Plutus
  • Il Plutus Application Framework (PAF) - la parte ‘off-chain’ di Plutus che permette l’interazione con i contratti intelligenti.

I contratti Plutus consistono di parti che girano sulla blockchain (codice on-chain) e parti che girano sulla macchina di un utente (codice off-chain o client). Sia il codice on-chain che quello off-chain sono scritti in Haskell, e i contratti smart di Plutus sono effettivamente programmi Haskell. Il codice off-chain può essere scritto usando PAF e questo codice viene poi compilato dal GHC (Glasgow Haskell Compiler), mentre il codice on-chain (scritto usando il Plutus Core) viene compilato dal compilatore Plutus.

È fondamentale capire la relazione tra questi concetti di Plutus e la funzionalità nativa dei token per vedere come la loro interazione trasforma quest’ultima in una caratteristica più utile e potente.

Il modello UTXO esteso

Cardano (come Bitcoin) utilizza il modello contabile di transazione non spesa (U) (TX) uscita (O). Nel modello UTXO, una transazione ha input e output, dove gli input sono output non spesi da transazioni precedenti. Non appena un output viene usato come input in una transazione, diventa speso e non può più essere usato. L’output è specificato da un indirizzo (una chiave pubblica o un hash di chiave pubblica) e un valore (che consiste in un importo ada e, facoltativamente, importi aggiuntivi di token nativi). L’indirizzo di un output determina quali transazioni sono autorizzate a “sbloccare” l’output e usarlo come input. Una transazione deve essere firmata dal proprietario della chiave privata corrispondente all’indirizzo. Pensate ad un indirizzo come ad una ‘serratura’ che può essere ‘sbloccata’ solo dalla giusta ‘chiave’ - la firma corretta.

Il modello EUTXO estende questo modello in due direzioni:

  • Generalizza il concetto di “indirizzo” usando l’analogia serratura-chiave. Invece di limitare le serrature alle chiavi pubbliche e le chiavi alle firme, gli indirizzi nel modello EUTXO possono contenere una logica arbitraria sotto forma di script. Per esempio, quando un nodo convalida una transazione, il nodo determina se la transazione è autorizzata o meno ad usare un certo output come input. La transazione cercherĂ  lo script fornito dall’indirizzo dell’output e lo eseguirĂ  se la transazione può usare l’output come input.
  • La seconda differenza tra UTXO e EUTXO è che le uscite possono trasportare dati (quasi) arbitrari oltre a un indirizzo e un valore. Questo rende gli script molto piĂš potenti permettendo loro di trasportare lo stato.

Quando si convalida un indirizzo, lo script accede ai dati trasportati dall’uscita, alla transazione che viene convalidata e ad alcuni dati aggiuntivi chiamati redentori (redeemers), che la transazione fornisce per ogni ingresso. Cercando tutte queste informazioni, lo script ha abbastanza contesto per dare una risposta “sì” o “no” in quelle che possono essere situazioni e casi d’uso molto complessi.

Per riassumere, EUTXO estende il modello UTXO permettendo agli indirizzi di uscita di contenere una logica complessa per decidere quali transazioni possono sbloccarli, e aggiungendo dati personalizzati a tutte le uscite.

Il modello EUTXO offre vantaggi unici rispetto ad altri modelli di contabilità. Il successo o il fallimento della convalida della transazione dipende solo dalla transazione stessa e dai suoi input, e non da qualsiasi altra cosa sulla blockchain. Di conseguenza, la validità di una transazione può essere controllata fuori dalla catena, prima che la transazione sia inviata alla blockchain. Una transazione può ancora fallire se qualche altra transazione consuma simultaneamente un input che la transazione si aspetta, ma se tutti gli input sono ancora presenti, la transazione è garantita per avere successo.

Questo contrasta con un modello basato sull’account (come usato da Ethereum), dove una transazione può fallire a metà dell’esecuzione dello script. Questo non può mai accadere in EUTXO. Inoltre, i costi di esecuzione delle transazioni possono essere determinati fuori dalla catena prima della trasmissione - un’altra caratteristica impossibile su Ethereum.

Infine, a causa della natura “locale” della convalida delle transazioni, è possibile un alto grado di parallelismo: un nodo potrebbe, in linea di principio, convalidare le transazioni in parallelo, se queste transazioni non cercano di consumare lo stesso input. Questo è ottimo sia per l’efficienza che per il ragionamento, semplificando l’analisi dei possibili risultati e dimostrando che “nulla di male” può accadere. Potete approfondire il modello EUTXO nel post del blog precedente.

Plutus Core

Per implementare il modello EUTXO, è necessario definire chiaramente i termini script e dati. Gli script richiedono un linguaggio di scripting definito e ben specificato, ed è anche importante definire il tipo di dati che sono collegati agli output e usati come redattori.

È qui che entra in gioco Plutus Core. Plutus Core è il linguaggio di scripting usato da Cardano. È un semplice linguaggio funzionale simile ad Haskell, e un ampio sottoinsieme di Haskell può essere usato per scrivere script Plutus Core. Come autore di un contratto non scrivi alcun Plutus Core. Tutti i programmi Plutus Core sono generati da un plugin compilatore Haskell.

Questi script saranno eseguiti dai nodi durante la convalida delle transazioni ‘live’ sulla catena. Essi bloccheranno gli UTXO sotto forma di script di validazione o come politiche di conio, che controllano il conio e la creazione di token nativi (vedi sotto).

I dati Redeemer sono un semplice tipo di dati (algebrico) che può essere definito facilmente in Haskell, che è un altro motivo per cui Haskell è una buona opzione per scrivere script Plutus Core. In pratica, uno sviluppatore di smart contract scriverà script di validazione in Haskell, che saranno poi compilati automaticamente in Plutus Core.

Le librerie Haskell appropriate semplificano la scrittura di tale logica di validazione fornendo tipi di dati fondamentali per l’ispezione delle transazioni durante la validazione, e offrendo molte funzioni di aiuto e astrazioni di livello superiore, permettendo agli autori di contratti di concentrarsi sulla logica di business e non doversi preoccupare di troppi dettagli di basso livello.

Il Plutus Application Framework (PAF)

Lo stato on-chain degli script validatori può essere modificato solo dalle transazioni che spendono e producono l’output degli script. Quando si scrive un’applicazione Plutus, dobbiamo considerare non solo la parte on-chain dell’applicazione (gli script Plutus Core) ma anche la parte off-chain che costruisce e sottomette le transazioni.

Il codice off-chain è scritto in Haskell, proprio come il codice on-chain. In questo modo abbiamo solo bisogno di scrivere la logica di business una volta. Poi possiamo usarlo nello script del validatore e nel codice che costruisce le transazioni che eseguono lo script del validatore.

Molte applicazioni hanno bisogno di guardare l’insieme UTXO per cambiamenti a particolari indirizzi, quindi se scriviamo il nostro contratto come una macchina a stati, abbiamo bisogno di tracciare l’uscita non spesa che rappresenta lo stato attuale della macchina e aggiornare il nostro stato locale quando lo stato on-chain cambia. Allo stesso modo, molte app hanno bisogno di comunicare con il backend del portafoglio per accedere alla criptovaluta che stanno usando per le transazioni.

Il PAF fornisce un facile accesso ai servizi che sono comunemente usati dalle applicazioni Plutus. Le applicazioni distribuite utilizzando le librerie del framework possono essere eseguite sul backend dell’applicazione Plutus, che fornisce il supporto runtime per l’accesso alla blockchain e altri aspetti come la persistenza, la registrazione e il monitoraggio. Le applicazioni scritte sopra il PAF forniscono automaticamente un’interfaccia HTTP e WebSocket che può essere utilizzata per interagire con l’applicazione dal browser web.

Token nativi

I token nativi sono diventati disponibili su Cardano con l’hard fork di Mary di febbraio. Qualsiasi utente può creare i propri token, e i token possono essere inviati e ricevuti liberamente, proprio come ada. Ogni token nativo è dotato di una propria politica di conio, che determina le condizioni in cui i token possono essere coniati e bruciati.

Al momento, queste politiche di conio consistono in combinazioni di semplici regole che specificano firme e timelocks. Per esempio, una politica può dichiarare che solo le transazioni che sono firmate da due firme su cinque possibili sono permesse per coniare o bruciare i token. Un’altra politica può permettere il conio solo prima o dopo una specifica fascia oraria.

Per quanto potenti siano questi blocchi di base, non coprono ogni uso concepibile. E’, per esempio, possibile, ma scomodo, modellare gettoni non fungibili (NFT) usando queste semplici politiche. Questo potrebbe essere fatto usando un timelock per coniare un NFT, limitando l’operazione di conio ad uno specifico punto temporale. Se solo un token viene coniato prima che quel punto temporale sia raggiunto, il token è tecnicamente non fungibile (perché ce n’è solo uno). Ma per verificare questo, non è sufficiente controllare la politica di conio. Avremmo bisogno di guardare la storia del conio del token per assicurarci che sia stato coniato solo una volta.

Con l’implementazione di Plutus, gli utenti saranno in grado di scrivere politiche di conio utilizzando il nucleo di Plutus. Durante il conio o la masterizzazione, lo script della policy di Plutus Core verrà eseguito nel contesto della transazione di conio o masterizzazione, e lo script dovrà approvare o proibire l’azione. Questo accelererà ulteriormente la crescita degli NFT su Cardano, consentendo la creazione di politiche di conio molto più complesse, e permettendo la creazione di NFT in un modo trustless.

Alonzo verrà gradualmente distribuito alla rete principale attraverso diversi testnet, così i nostri partner e i pionieri di Plutus saranno in grado di testare Plutus Core scrivendo applicazioni su Cardano per tutto maggio e giugno prima di un congelamento del codice. Questo sarà anche il periodo di garanzia di qualità e test di accettazione degli utenti da parte degli exchange per garantire che la piattaforma sia completamente pronta al momento dell’aggiornamento della mainnet di Alonzo. Se sei uno sviluppatore e vuoi saperne di più su Plutus, considera la possibilità di unirti a una futura coorte di pionieri. In alternativa, dai un’occhiata ai repository GitHub di Plutus e partecipa alle discussioni su Plutus al Cardano Forum.

Vorrei ringraziare Jann MĂźller per ulteriori input e contributi a questo post del blog.