Smart Contract
Una delle funzionalità più apprezzate delle Blockchain è la possibilità di scrivere degli Smart Contract [5]. Uno Smart Contract non è altro che un blocco, all’interno della Blockchain, che può essere utilizzato per creare delle applicazioni decentralizzate.
Questo blocco eredita alcune caratteristiche proprie di un account standard e le automatizza tramite l’associazione a un programma in grado di reagire agli eventi ricevuti.
Esistono varie implementazioni di Blockchain che permettono la scrittura di uno Smart Contract. Quella che andremo a vedere oggi è l’implementazione propria di Ethereum, probabilmente la forma più diffusa di Smart Contract esistente.
Per capire però il funzionamento di uno Smart Contract, occorre fare un passo indietro e focalizzarci sugli account Ethereum e su come funzionano.
Gli account
Il concetto di account è abbastanza semplice: rappresenta un indirizzo univoco che identifica una posizione all’interno della Blockchain e ha un bilancio che può variare in base a transazioni che vengono ricevute o disposte.
È possibile autorizzare una transazione utilizzando la chiave privata associata all’account. Tale chiave ne identifica la proprietà e la possibilità di effettuare movimenti. Alla luce di questo, le principali caratteristiche di un account sono:
- avere un bilancio;
- Inviare e ricevere transazioni;
- possedere una chiave privata;
- non avere codice associato.
Si intuisce subito che questo tipo di account deve essere gestito da una persona o, alla peggio, può essere utilizzato da un programma esterno alla Blockchain. La garanzia è data solo dal possesso di una chiave.
Facendo un esempio: se Matteo volesse inviare 5 ETH a Caterina, dovrà possedere la chiave privata del proprio account e chiedere alla rete Ethereum l’invio degli ETH.
Le caratteristiche degli Smart Contract
Per evitare che il controllo di quando effettuare una transazione sia sempre a carico di una persona, o sia esterno alla Blockchain, all’interno di Ethereum è presente un altro tipo di account, accanto a quelli standard. Si tratta appunto degli account di tipo Smart Contract.
Questo tipo di account ha delle caratteristiche leggermente diverse:
- hanno un bilancio, come gli account standard;
- possono inviare e ricevere transazioni, come gli account standard;
- non hanno una chiave privata di gestione dell’account;
- hanno del codice che risponde ad alcuni aventi che ricevono;
- hanno un proprio stato interno che può essere alterato;
- possono eseguire altri Smart Contract;
- hanno un costo computazionale.
Con gli Smart Contract, quindi, il controllo di quanto avviene nell’account viene spostato dall’esterno all’interno della Blockchain.
Ereditarietà ed eventuali problemi
Dato che il codice dello Smart Contract è interno alla Blockchain, ne eredita una caratteristica importante data dall’immutabilità.
Questo è un aspetto che ha dei pro e dei contro, ma principalmente garantisce che non ci siano alterazioni “malevole” di quanto scritto nel codice nel momento della creazione. Per intenderci: non è possibile alterarne la struttura in nessun modo.
Chiaramente questo aspetto ha anche dei risvolti negativi come la permanenza di bug, nel caso ci fossero [2].
Trasparenza e linearità
Mantenere un bilancio permette a uno Smart Contract di ricevere valuta, ma allo stesso tempo di inviarne in modo programmatico.
Immaginiamo, ad esempio, la creazione di uno Smart Contract per la gestione dei dividendi di un’azienda, dove ogni socio riceva in automatico la propria quota.
La gestione della divisione verrebbe fatta dall’evento di ricezione della transazione in ingresso, che andrebbe a dividere l’importo in parti uguali (immaginando soci con quote equivalenti).
Questo tipo di approccio permette di avere trasparenza e incorruttibilità, aspetto che molte volte la natura umana non ci permette di avere.
Esempi di Smart Contract
Per cogliere meglio la differenza fra un approccio con o senza Smart Contract, possiamo fare un raffronto con un caso ipotetico.
Immaginiamo di avere un’azienda dove devono essere pagati degli operai: viene destinata una cifra ai pagamenti, tutti i pagamenti dovrebbero essere identici, ma a causa della disonestà di un dipendente, la cifra non viene divisa equamente fra i dipendenti, ma in parti disuguali.
Questo è possibile a causa della catena di fiducia fra persone e al mancato controllo da parte della persona che dovrebbe controllare le operazioni.
Immaginiamo ora se tutto il processo fosse delegato a uno Smart Contract destinato ai pagamenti. Questo Smart Contract riceverebbe la somma da dividere e si occuperebbe di ripartire in ugual maniera l’importo, senza la possibilità che un umano possa modificare o alterare il flusso che aziendalmente era stato deciso.
Inalterabilità del flusso economico
Questo cambiamento di processo ha dei pro e dei contro, ma uno dei vantaggi è che azzera la possibilità di alterare il flusso economico di scambio dei processi, azzerando alcuni aspetti umani come la corruttibilità, oltre a rendere assolutamente trasparente il processo col quale i flussi monetari vengono distribuiti.
Oltre a questo, ricordiamoci che uno Smart Contract, per sua natura, è immutabile, quindi garantisce anche che nessuno possa modificalo, ad esempio, per variare quanto è stato deciso nel momento della sua creazione.
Rispetto a qualsiasi altro software la differenza è notevole, dato che azzera la possibilità di “hackeraggio”: capiamo perfettamente che questo non sia il termine più corretto se inteso nella sua originaria e più etica accezione, ma credo che usare l’imbastardimento del termine ormai passato nel linguaggio comune possa rendere bene l’idea che intendo spiegare.
Pensate anche alla differenza con un account standard nel quale le transazioni sono effettuate tramite una chiave privata; pensate a tutte le volte in cui questa chiave viene trasmessa o utilizzata o semplicemente memorizzata in un supporto elettronico.
Tutte quelle volte, se qualcuno fosse così abile da riuscire ad acquisirla, potrebbe fare transazioni a nostro nome. Con lo Smart Contract quanto esce dall’account è controllato dal codice al suo interno: non esiste una chiave che, in possesso della persona sbagliata, possa estrarre valuta da quel tipo di account.
Ora che sono chiare le differenze fra un account standard e uno Smart Contract, vediamo come poterne realizzare uno.
Il linguaggio Solidity
Quando sono nati gli Smart Contract, dopo averne delineate le caratteristiche, è stato scelto di non basarsi su un linguaggio esistente, ma di realizzarne uno nuovo chiamato Solidity [6].
Solidity è un linguaggio di programmazione abbastanza semplice basato su una sintassi che ricorda linguaggi come JavaScript, Java, C e C++, pur mantenendo una propria identità.
I programmi Solidity funzionano all’interno della Virtual Machine di Ethereum (EVM) e il costo per la loro esecuzione viene calcolato in GAS. Più è complesso e articolato il vostro programma più avrà bisogno di elaborazione e di GAS per poter essere eseguito.
L’aspetto interessante di Solidity è che, nonostante sia un linguaggio molto verticale, è fiorito un sottobosco di tool come debugger, Virtual Machine, Code Analyzer e così via. Potete trovare una lista molto interessante di tali strumenti su EVM AwesomeList [1].
Altri linguaggi per Smart Contract
In realtà Solidity non è il solo linguaggio col cui è possibile scrivere uno Smart Contract ma, per diffusione e storicità, è sicuramente il primo da imparare.
Al momento, le alternative più diffuse rispetto a Solidity sono:
- Vyper: un linguaggio con controllo di overflow, unità numeriche, ma senza loop infiniti. Lo scopo di Vyper è quello di rendere più semplice la creazione di Smart Contract rispetto a Solidity.
- Flint: anche in questo caso l’approccio è quello di migliorare l’approccio di Solidity [3].
- LLLL: un compilatore implementato in Isabelle/HOL.
- HAseembly-evm, Bamboo e altri [4].
Uno dei motivi che hanno permesso la nascita di queste alternative è dato dal fatto che Solidity viene eseguito in una Virtual Machine. In teoria, qualsiasi linguaggio capace di produrre codice per questa Virtual Machine è in grado di creare degli Smart Contract.
In futuro non mi meraviglierebbe trovare un compilatore “Java” in grado di produrre codice compatibile con la EVM.
Perché una nuova Virtual Machine?
Da programmatori Java ci si potrebbe però chiedere: “Perché implementare l’ennesima Virtual Machine e non utilizzare quella Java, ormai stabile e largamente diffusa?”.
Il motivo è abbastanza semplice: il design Java non è adeguato alle funzionalità richieste dagli Smart Contract. La sua programmazione risale a parecchi anni fa e non teneva conto di alcuni aspetti che potrebbero rivelarsi critici all’interno della EVM e che riportiamo di seguito.
- Le classi Java possono avere metodi in grado di raggiungere i 64k di bytecode. Potrebbe anche sembrare poco, ma in un sistema dove è importante salvare spazio, avere così tanto bytecode è controproducente. Per chi ha iniziato a programmare negli anni Ottanta, 64k di memoria rappresentano ancora un mondo enorme dove poter scrivere un intero programma. All’interno di quello spazio, per anni, sono stati eseguiti programmi molto più grandi di un metodo Java: per questo motivo occorreva progettare del bytecode più compatto.
- Le JVM sono piene di funzionalità non necessarie in Ethereum, principalmente tutto il blocco delle funzionalità di I/O: la EVM è progettata per avere un alto livello di isolamento e impedire qualsiasi comunicazione fra il programma ospitato e la macchina che deve eseguirlo. Non c’è una protezione a livello di permessi: semplicemente non si può fare.
- È assente una resistenza ai DDOS e ai loop infiniti, aspetto che andava salvaguardato in una rete distribuita.
- Non ha una licenza adeguata a quella utilizzata dal progetto Ethereum.
- Non era possibile gestire un costo di computazione del programma, per stabilire quanto fosse costosa l’elaborazione di un blocco di codice.
Gli strumenti
Come tutti i linguaggi che si rispettino, Solidity ha numerosi tool di contorno, uno di quelli maggiormente diffusi è Remix [7]: un IDE web-based dove poter scrivere Smart Contract.
Oltre a questo, sono disponibili numerose estensioni che permettono di scrivere codice Solidity anche nei più diffusi IDE: IntelliJ, Visual Studio, Atom e così via.
Conclusioni
Con questo articolo della serie su Blockchain abbiamo voluto introdurre il concetto di Smart Contract, capirne i pro e i contro e capire con quale linguaggio è possibile scriverne uno.
In alcuni prossimi articoli vedremo in dettaglio gli strumenti qui accennati, e scriveremo il nostro primo Smart Contract, lo proveremo e lo aggiungeremo alla rete Ethereum.
Fino ad allora vi consiglio l’approfondimento tematico tramite i link di riferimento di questo articolo.
Matteo Baccan è un informatico per passione.
Si occupa di sviluppo e architetture software da quando 64k erano sufficienti per qualsiasi tipo di applicazione.
Al momento gestisce team di programmatori e sviluppa progetti mission critical per alcune aziende italiane e internazionali.
Parte del suo lavoro è consultabile sul sito http://www.baccan.it