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 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
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.