In questo articolo esamineremo cosa sono i contratti intelligenti, quali tipologie esistono, ci familiarizzeremo con diverse piattaforme di contratti intelligenti, le loro caratteristiche e discuteremo come funzionano e quali vantaggi possono offrire. Questo materiale sarà molto utile per i lettori che non conoscono bene l'argomento dei contratti intelligenti, ma desiderano avvicinarsi alla sua comprensione.
Contratto tradizionale vs. contratto intelligente
Prima di approfondire i dettagli, esaminiamo un esempio delle differenze tra un contratto tradizionale, redatto su carta, e un contratto intelligente, che è rappresentato in forma digitale.
Come funzionava tutto prima dell'avvento dei contratti smart? Immaginate un gruppo di persone che desidera stabilire alcune regole e condizioni per la distribuzione di beni, e anche certi meccanismi per garantire che questa distribuzione avvenga secondo tali regole e condizioni. Si riunivano, redigevano un documento in cui annotavano i loro dati identificativi, le condizioni e i beni coinvolti, mettevano la data e firmavano. Questo contratto veniva poi certificato da una parte fidata, ad esempio un notaio. Successivamente, queste persone si disperdevano con la loro copia cartacea del contratto e cominciavano a compiere alcune azioni che potevano non corrispondere al contratto stesso, cioè facevano una cosa mentre sulla carta era certificato che dovevano farne un'altra. Come si esce da questa situazione? In effetti, uno dei partecipanti al gruppo doveva prendere questo documento, raccogliere delle prove, portarle in tribunale e cercare di ottenere la corrispondenza tra il contratto e le azioni reali. Spesso, ottenere l'adempimento giusto di questo contratto risulta difficile, il che porta a conseguenze spiacevoli.
Cosa si può dire sui contratti intelligenti? Questi combinano la possibilità di scrivere le condizioni di un contratto con un meccanismo rigoroso per la loro esecuzione. Se le condizioni sono state definite e la transazione o la richiesta corrispondente è stata firmata, dopo l'accettazione di questa richiesta o transazione non sarà più possibile modificare le condizioni o influenzare la loro esecuzione.
È presente un validadore o un'intera rete, insieme a un database che memorizza tutti i contratti intelligenti che sono stati eseguiti in rigorosa sequenza cronologica. È anche importante che questo database contenga tutte le condizioni-triggers per l'esecuzione del contratto intelligente. Inoltre, deve considerare il valore stesso, la cui distribuzione è descritta nel contratto. Se si tratta di una certa valuta digitale, allora questo database deve tenerne conto.
In altre parole, i validatori dei contratti intelligenti devono avere accesso a tutti i dati con cui opera il contratto stesso. Ad esempio, un unico database dovrebbe gestire contemporaneamente valute digitali, saldi degli utenti, transazioni degli utenti e timestamp. Così, nel contratto intelligente, una condizione potrebbe essere il saldo dell'utente in una certa valuta, il trascorrere di un certo tempo o l'avvenuta transazione, ma non di più.
Definizione di contratto intelligente
In generale, la terminologia è stata coniata dal ricercatore Nick Szabo e applicata per la prima volta nel 1994, mentre fu documentata nel 1997 in un articolo che descrive l'idea stessa dei contratti intelligenti.
I contratti intelligenti implicano che viene automatizzata una certa distribuzione di valore, che può dipendere solo dalle condizioni preimpostate. Nella sua forma più semplice, appare come un contratto con condizioni rigorosamente definite, firmato da determinate parti.
I contratti intelligenti sono progettati per ridurre al minimo la fiducia nelle terze parti. A volte viene completamente eliminato il centro decisionale da cui dipende tutto. Inoltre, è più semplice effettuare audit per tali contratti. Ciò è dovuto ad alcune caratteristiche di progettazione di questo sistema, ma il più delle volte, ciò che intendiamo per contratto intelligente è un ambiente decentralizzato con funzioni che consentono a chiunque di analizzare il database e effettuare un audit completo dell'esecuzione dei contratti. In questo modo, si garantisce la protezione contro le modifiche dei dati retroattive, che potrebbero comportare modifiche all'esecuzione del contratto stesso. La digitalizzazione della maggior parte dei processi durante la creazione e l'avvio di un contratto intelligente semplifica spesso la tecnologia e riduce i costi delle loro implementazioni.
Un semplice esempio — servizio Escrow
Esaminiamo un esempio molto semplice. Questo aiuterà a comprendere le funzionalità dei contratti intelligenti e a orientarsi meglio su quando conviene utilizzarli.
È possibile realizzarlo anche utilizzando Bitcoin, sebbene al momento Bitcoin non possa ancora essere considerato una piattaforma adeguata per i contratti intelligenti. Immaginiamo un acquirente e un negozio online. L'acquirente desidera acquistare un monitor in questo negozio. Nel caso più semplice, l'acquirente effettua e invia il pagamento, mentre il negozio online lo accetta, lo conferma e poi spedisce il prodotto. Tuttavia, in questa situazione è necessaria una grande fiducia: l'acquirente deve fidarsi completamente del negozio per l'intero costo del monitor. Poiché il negozio online potrebbe avere una reputazione bassa agli occhi dell'acquirente, c'è il rischio che, per qualche motivo, dopo aver accettato il pagamento, il negozio rifiuti di servire e non spedisca il prodotto all'acquirente. Pertanto, l'acquirente si pone la domanda (e anche il negozio online si pone la stessa domanda) su cosa possa essere applicato in questo caso per minimizzare tali rischi e rendere queste transazioni più sicure.
Nel caso di Bitcoin, è possibile fornire al compratore e al venditore l'opzione di scegliere un intermediario in modo indipendente. Esistono molte persone che si occupano di risolvere controversie. I nostri partecipanti possono scegliere da un elenco generale di mediatori, scegliendo quello di cui si fidano entrambi. Insieme creano un indirizzo multisignature 2 di 3, dove ci sono tre chiavi e sono necessarie due firme di qualsiasi coppia di chiavi per spendere le monete da quell'indirizzo. Una chiave appartiene al compratore, la seconda all'e-commerce e la terza all'intermediario. L'acquirente invierà l'importo necessario per il monitor a questo indirizzo multisignature. Ora, quando il venditore vede che il denaro è bloccato su un indirizzo multisignature per un certo tempo, può inviare il monitor con tranquillità.
Successivamente, l'acquirente riceve il pacco, controlla il prodotto e decide se procedere con l'acquisto finale. Può essere completamente soddisfatto con il servizio fornito e firmare la transazione con la sua chiave, trasferendo le monete da un indirizzo multisig al venditore, oppure potrebbe avere qualche insoddisfazione. In quest'ultimo caso, contatta il mediatore per elaborare una transazione alternativa che redistribuisca le monete in modo diverso.
Supponiamo che il monitor sia arrivato leggermente graffiato e che nel pacco non ci fosse il cavo per collegarlo al computer, nonostante sul sito dell'e-commerce fosse specificato che il cavo avrebbe dovuto essere incluso. In tal caso, l'acquirente raccoglie le prove necessarie per dimostrare al mediatore di essere stato ingannato in questa situazione: fa screenshot del sito, foto della ricevuta della spedizione, foto dei graffi sul monitor e dimostra che il sigillo è stato rotto e il cavo è stato estratto. L'e-commerce, a sua volta, raccoglie le proprie prove e le invia al mediatore.
Il mediatore è interessato a soddisfare sia l'indignazione dell'acquirente che gli interessi del negozio online (più avanti sarà chiaro il motivo). Egli crea una transazione in cui le monete da un indirizzo multisignature vengono distribuite in una certa proporzione tra l'acquirente, il negozio online e il mediatore, poiché trattiene una parte come compenso per il suo lavoro. Supponiamo che il 90% dell'importo totale vada al venditore, il 5% al mediatore e il 5% come compensazione per l'acquirente. Questa transazione viene firmata dal mediatore con la sua chiave, ma non può ancora essere applicata, perché sono necessarie due firme, mentre ne esiste solo una. Tale transazione viene inviata sia all'acquirente che al venditore. Se almeno uno di loro accetta questa proposta di redistribuzione delle monete, la transazione sarà ulteriormente firmata e diffusa nella rete. Per la sua validazione, è sufficiente che uno dei partecipanti all'affare accetti la proposta del mediatore.
È fondamentale scegliere inizialmente un mediatore di fiducia per entrambe le parti. In questo modo, il mediatore agirà indipendentemente dagli interessi di uno o dell'altro e valuterà la situazione in modo obiettivo. Se il mediatore non propone un'opzione di distribuzione delle monete che soddisfi almeno uno dei partecipanti, allora, accordandosi insieme, sia l'acquirente che il negozio online possono trasferire le monete su un nuovo indirizzo multisignature, fornendo entrambe le firme. Il nuovo indirizzo multisignature sarà creato con un altro mediatore, che potrebbe avere maggiore competenza nella questione e offrire una soluzione migliore.
Esempio di una residenza universitaria e di un frigorifero
Esaminiamo un esempio più complesso, che illustra in modo più chiaro le capacità di un contratto intelligente.
Immagina che ci siano tre ragazzi che si sono recentemente trasferiti nella stessa stanza di un dormitorio. Sono tutti e tre interessati ad acquistare un frigorifero da utilizzare insieme. Uno di loro si è offerto di raccogliere la somma necessaria per l'acquisto del frigorifero e di trattare con il venditore. Tuttavia, si conoscono solo da poco tempo e non c'è molta fiducia tra di loro. È evidente che due di loro rischiano di perdere i soldi affidandoli al terzo. Inoltre, devono raggiungere un accordo sulla scelta del venditore.
Possono usare un servizio di escrow, cioè scegliere un mediatore che controlli l'esecuzione dell'affare e risolva eventuali questioni controverse se dovessero sorgere. Così, una volta raggiunto un accordo, redigono un contratto intelligente in cui vengono specificate determinate condizioni.
La prima condizione è che, prima di un certo momento, ad esempio entro una settimana, devono essere effettuati tre pagamenti da indirizzi specifici a un determinato importo sul rispettivo account del contratto intelligente. Se ciò non avviene, il contratto intelligente termina la sua esecuzione e restituisce le monete a tutti i partecipanti. Se invece la condizione è soddisfatta, vengono assegnati i valori degli identificativi del venditore e dell'intermediario, e viene inoltre verificato che tutti i partecipanti siano d'accordo con la scelta del venditore e dell'intermediario. Quando tutte le condizioni sono soddisfatte, i fondi verranno quindi trasferiti agli indirizzi specificati. Questo approccio può proteggere i partecipanti da frodi da qualsiasi parte ed esclude completamente la necessità di fidarsi.
In questo esempio vediamo il principio secondo cui la possibilità di definire passo dopo passo i parametri per l'esecuzione di ciascuna condizione consente di creare sistemi di qualsiasi complessità e profondità di livelli annidati. Inoltre, nel contratto intelligente è possibile definire inizialmente la prima condizione e solo dopo la sua esecuzione impostare i parametri per la successiva condizione. In altre parole, la condizione è formalmente scritta, mentre i parametri per essa possono essere definiti durante il suo funzionamento.
Classificazione dei contratti intelligenti
Per la classificazione è possibile definire diversi gruppi di criteri. Tuttavia, attualmente, sono quattro quelli più pertinenti, dati i progressi tecnologici.
I contratti intelligenti possono essere distinti in base all'ambiente di esecuzione, che può essere centralizzato o decentralizzato. In caso di decentralizzazione, abbiamo molta più indipendenza e resilienza nell'esecuzione dei contratti intelligenti.
Possono anche essere distinti in base al modo in cui vengono impostate e eseguite le condizioni: possono essere programmabili in modo arbitrario, limitati o preimpostati, cioè fortemente tipizzati. Quando esistono solo 4 contratti intelligenti definiti sulla piattaforma dei contratti intelligenti, i parametri per questi possono essere impostati in modo arbitrario. Di conseguenza, è molto più semplice impostarli: selezioniamo il contratto dall'elenco e passiamo i parametri.
In base al modo di attivazione, esistono contratti intelligenti automatizzati, cioè si auto-eseguono al verificarsi di determinate condizioni, e ci sono contratti in cui le condizioni sono definite ma la piattaforma non verifica automaticamente la loro esecuzione; per questo devono essere iniziati separatamente.
Inoltre, i contratti intelligenti si differenziano per livello di privacy. Possono essere completamente aperti, parzialmente aperti o completamente riservati. L'ultima opzione significa che gli osservatori esterni non vedono le condizioni dei contratti intelligenti. Tuttavia, il tema della privacy è molto vasto e sarebbe meglio trattarlo separatamente dall'articolo attuale.
Di seguito approfondiremo i primi tre criteri per chiarire ulteriormente la comprensione dell'argomento attuale.
Smart contract per ambiente di esecuzione
Per ambiente di esecuzione si distinguono piattaforme di smart contract centralizzate e decentralizzate. Nel caso di contratti digitali centralizzati, si utilizza un unico servizio, dove esiste un solo validatore e potrebbe esserci un servizio di backup e ripristino, gestito anch'esso in modo centralizzato. C'è un unico database che memorizza tutte le informazioni necessarie per definire le condizioni dello smart contract e distribuire il valore registrato in quel database del servizio. Un tale servizio centralizzato ha un cliente che stabilisce le condizioni tramite richieste specifiche e utilizza tali contratti. Poiché la piattaforma è centralizzata, i meccanismi di autenticazione potrebbero essere meno affidabili rispetto a quelli delle criptovalute.
Come esempio, si possono prendere i fornitori di servizi di telefonia mobile (diversi operatori mobili). Supponiamo che un determinato operatore gestisca in modo centralizzato il tracciamento del traffico sui propri server, che può essere trasmesso in vari formati, ad esempio: sotto forma di chiamate vocali, invio di SMS, traffico internet mobile e secondo diversi standard, oltre a gestire i saldi degli utenti. Di conseguenza, il fornitore di servizi mobili può stipulare contratti per la registrazione dei servizi forniti e i loro pagamenti con condizioni diverse. In tal caso, è facile stabilire condizioni come “invia un SMS con un certo codice a un certo numero e riceverai queste condizioni di distribuzione del traffico”.
Possiamo portare un altro esempio: le banche tradizionali con funzionalità avanzate di internet banking e contratti molto semplici, come i pagamenti ricorrenti, la conversione automatica dei pagamenti in entrata, l'addebito automatico di una percentuale sul conto indicato, e così via.
Quando si tratta di smart contract con un ambiente di esecuzione decentralizzato, abbiamo un gruppo di validatori. Idealmente, chiunque può diventare validatore. Grazie al protocollo di sincronizzazione del database e al raggiungimento del consenso, abbiamo un database comune che conterrà ora tutte le transazioni con contratti ben definiti, invece di richieste arbitrari, i cui formati cambiano frequentemente e non hanno una specifica aperta. Qui, le transazioni conterranno istruzioni per l'esecuzione del contratto in conformità con una specifica rigorosa. Questa specifica è aperta e, quindi, gli stessi utenti della piattaforma possono effettuare audit e validare gli smart contract. Qui vediamo che le piattaforme decentralizzate superano quelle centralizzate in termini di indipendenza e resilienza, ma il loro design e la loro manutenzione sono molto più complessi.
Smart contract per modalità di definizione ed esecuzione delle condizioni
Analizziamo ora più nel dettaglio come i contratti smart possano differire nel modo in cui vengono definiti e attuati. Ci concentreremo sui contratti smart che sono programmabili in modo arbitrario e completi secondo Turing. Un contratto smart completo secondo Turing consente di definire praticamente qualsiasi algoritmo come condizioni per l'esecuzione del contratto: è possibile specificare cicli, alcune funzioni di calcolo delle probabilità e così via, fino ai propri algoritmi di firma elettronica. In questo caso si parla di una scrittura davvero arbitraria della logica.
Si identificano anche contratti smart arbitrari, ma non completi secondo Turing. Qui rientrano Bitcoin e Litecoin con il loro script. Ciò significa che è possibile utilizzare solo operazioni specifiche in modo arbitrario, ma non è possibile scrivere cicli o algoritmi personalizzati.
Inoltre, ci sono piattaforme di smart contract che implementano smart contract preimpostati. Tra queste ci sono Bitshares e Steemit. Bitshares offre una serie di smart contract per il trading, la gestione degli account e l'amministrazione della piattaforma e dei suoi parametri. Steemit è una piattaforma simile, ma è orientata non all'emissione di token e al trading come Bitshares, ma alla scrittura di blog, ovvero gestisce e archivia contenuti in modo decentralizzato.
Tra i contratti full Turing possiamo includere la piattaforma Ethereum e RootStock, che è ancora in fase di sviluppo. Pertanto, di seguito ci soffermeremo un po' di più sulla piattaforma di smart contract Ethereum.
Smart contract in base al metodo di iniziazione
I contratti smart possono essere suddivisi in almeno due categorie in base al modo in cui vengono attivati: automatizzati e manuali (non automatizzati). I contratti automatizzati si attivano completamente in modo automatico al verificarsi di determinati parametri e condizioni, il che significa che non è necessaria l'invio di ulteriori transazioni o il pagamento di ulteriori commissioni per ciascun successivo compimento. La piattaforma stessa dispone di tutti i dati necessari per calcolare come si concluderà il contratto smart. La logica non è arbitraria, ma predeterminata e tutto ciò è prevedibile. Pertanto, è possibile valutare in anticipo la complessità dell'esecuzione del contratto smart, utilizzare una commissione costante per esso e tutti i processi di esecuzione avvengono in modo più efficiente.
Per i contratti intelligenti programmabili in modo arbitrario, l'esecuzione non è automatizzata. Per avviare un tale contratto intelligente, è necessario creare una nuova transazione ad ogni passo, che invocherà il successivo stadio di esecuzione o il metodo successivo del contratto intelligente, pagando la relativa commissione e attendendo la conferma della transazione. L'esecuzione può concludersi con successo o meno, poiché il codice del contratto intelligente è arbitrario e possono verificarsi eventi imprevedibili come cicli infiniti, mancanza di parametri e argomenti e momenti eccezionali non gestiti, e così via.
Account in Ethereum
Tipi di account Ethereum
Esaminiamo quali possono essere gli account sulla piattaforma Ethereum. Ci sono solo due tipi di account e non ci sono altre opzioni. Il primo tipo è chiamato account utente, il secondo è l'account contratto. Vediamo quali sono le differenze.
L'account utente è gestito solo dalla chiave privata della firma elettronica. Il proprietario dell'account genera la propria coppia di chiavi per la firma elettronica utilizzando l'algoritmo ECDSA (Elliptic Curve Digital Signature Algorithm). Solo le transazioni firmate con questa chiave possono modificare lo stato di questo account.
Per l'account del contratto intelligente è prevista una logica separata. Può essere gestito solo tramite codice di programmazione predefinito, che definisce completamente il comportamento del contratto intelligente: come dispiegherà i propri token in determinate circostanze, l'iniziativa di quale utente porterà a una distribuzione e quali condizioni aggiuntive determineranno la distribuzione dei token. Se alcuni aspetti non sono previsti dagli sviluppatori nel codice, possono sorgere problemi. Ad esempio, un contratto intelligente potrebbe raggiungere uno stato in cui non accetta ulteriori avvii da nessuno degli utenti. In tal caso, i token rimarranno effettivamente congelati, poiché il contratto intelligente non prevede un'uscita da quello stato.
Come vengono creati gli account su Ethereum
Nel caso di un account utente, il proprietario genera autonomamente una coppia di chiavi tramite ECDSA. È importante notare che Ethereum utilizza lo stesso algoritmo e la stessa curva ellittica per la firma elettronica di Bitcoin, ma l'indirizzo viene calcolato in modo leggermente diverso. Non si applica il risultato del doppio hashing come in Bitcoin, ma è previsto un singolo hashing tramite la funzione Keccak con una lunghezza di 256 bit. Dai valori ottenuti vengono troncati i bit inferiori, precisamente 160 bit inferiori del valore di output della funzione hash. Alla fine otteniamo un indirizzo in Ethereum. Infatti, occupa 20 byte.
Si noti che l'identificatore dell'account in Ethereum è codificato in esadecimale senza utilizzare un checksum, a differenza di Bitcoin e di molti altri sistemi, dove l'indirizzo è codificato in un sistema numerico con base 58 con l'aggiunta di un checksum. Ciò significa che è necessario prestare attenzione quando si lavora con gli identificatori degli account in Ethereum: anche un solo errore nell'identificatore porterà garantito alla perdita di monete.
C'è una caratteristica importante e consiste nel fatto che l'account utente a livello di database globale viene creato nel momento in cui riceve il primo pagamento.
Per quanto riguarda la creazione dell'account del contratto intelligente, viene applicato un approccio completamente diverso. Inizialmente, uno degli utenti scrive il codice sorgente del contratto intelligente, dopodiché il codice viene passato attraverso un compilatore specifico per la piattaforma Ethereum, ottenendo il bytecode per la propria macchina virtuale Ethereum. Il bytecode risultante viene inserito in un campo speciale della transazione. Questa viene firmata a nome dell'account del mittente. Successivamente, questa transazione viene diffusa nella rete e pubblica il codice del contratto intelligente. La commissione per la transazione e, di conseguenza, per l'esecuzione del contratto viene detratta dal saldo dell'account del mittente.
Ogni contratto intelligente deve contenere il proprio costruttore. Può essere vuoto o avere del contenuto. Dopo che il costruttore viene eseguito, viene creato un identificatore dell'account del contratto intelligente, che consente di inviare monete, chiamare determinati metodi del contratto intelligente, ecc.
Struttura della transazione Ethereum
Per comprendere meglio, iniziamo a esaminare la struttura della transazione Ethereum e un esempio di codice di smart contract.
Una transazione Ethereum è composta da diversi campi. Il primo di questi, il nonce, è un numero sequenziale della transazione relativo all'account stesso che la distribuisce e ne è l'autore. Questo serve a distinguere le transazioni duplicate, cioè a escludere il caso in cui la stessa transazione venga accettata due volte. Grazie all'uso dell'identificatore, ogni transazione ha un valore hash unico.
Successivamente, troviamo un campo chiamato gas price. Qui viene indicato il prezzo al quale la valuta base Ethereum viene convertita in gas, che viene utilizzato per pagare l'esecuzione dello smart contract e la fornitura delle risorse della macchina virtuale. Cosa significa questo?
Nel Bitcoin, le commissioni vengono pagate direttamente con la valuta di base — il bitcoin stesso. Questo è possibile grazie a un meccanismo semplice di calcolo: paghiamo esattamente in base alla quantità di dati contenuti nella transazione. Nel caso di Ethereum, la situazione è più complessa, poiché è molto difficile fare riferimento alla quantità di dati della transazione. Qui, la transazione può anche contenere codice che verrà eseguito su una macchina virtuale, e ogni operazione della macchina virtuale può avere una complessità diversa. Ci sono anche operazioni che allocano memoria per le variabili. Queste avranno la loro complessità, dalla quale dipenderà il pagamento per ogni operazione.
Il costo di ogni operazione in equivalenti di gas sarà costante. Questo è stato introdotto appositamente per determinare il costo costante di ciascuna operazione. A seconda del carico sulla rete, cambierà il gas price, cioè il coefficiente secondo il quale la valuta di base sarà convertita in questa unità ausiliaria per il pagamento delle commissioni.
C'è un'altra caratteristica delle transazioni in Ethereum: il bytecode contenuto per l'esecuzione nella macchina virtuale verrà eseguito fino a quando non terminerà con un risultato (successo o fallimento) oppure fino a quando non si esauriranno alcune monete riservate per pagare le commissioni. Proprio per evitare situazioni in cui tutte le monete vengano utilizzate per la commissione in caso di errore (ad esempio, se viene avviato un ciclo infinito nella macchina virtuale), esiste il seguente campo — start gas (spesso chiamato limite di gas) — definisce la quantità massima di monete che il mittente è disposto a spendere per eseguire una specifica transazione.
Il campo successivo si chiama destination address. Qui si inserisce l'indirizzo del destinatario delle monete o l'indirizzo di un contratto smart specifico, i cui metodi verranno chiamati. Successivamente, c'è il campo value, dove viene inserito l'importo delle monete che vengono inviate all'indirizzo di destinazione.
Si trova poi un campo interessante chiamato data, dove viene inserita l'intera struttura. Non è un campo separato, ma un'intera struttura che definisce il codice per la macchina virtuale. Qui è possibile inserire dati arbitrari — per questo ci sono regole specifiche.
E l'ultimo campo si chiama signature. Contiene sia la firma elettronica dell'autore di questa transazione, sia la chiave pubblica che verrà utilizzata per verificare questa firma. Dalla chiave pubblica è possibile ottenere l'identificativo dell'account del mittente di questa transazione, identificando in modo univoco l'account del mittente nel sistema stesso. Per quanto riguarda la struttura della transazione, abbiamo chiarito gli aspetti principali.
Esempio di codice di uno smart contract in Solidity
Ora esaminiamo più da vicino il più semplice smart contract tramite un esempio.
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}Sopra è riportato un codice sorgente semplificato, che può mantenere le monete degli utenti e restituirle su richiesta.
Quindi, c'è un contratto intelligente Bank che svolge le seguenti funzioni: accumula criptovalute nel suo bilancio, ovvero, quando una transazione viene confermata e viene implementato questo contratto intelligente, viene creato un nuovo account che può contenere criptovalute nel suo bilancio; ricorda gli utenti e la distribuzione delle criptovalute tra di essi; ha diversi metodi per gestire i bilanci, cioè è possibile ricaricare, prelevare e controllare il bilancio dell'utente.
Esaminiamo ogni riga del codice sorgente. In questo contratto ci sono campi costanti. Uno di essi, di tipo address, si chiama owner. Qui il contratto memorizza l'indirizzo dell'utente che ha creato questo contratto intelligente. Inoltre, c'è una struttura dinamica che conserva le corrispondenze tra gli indirizzi degli utenti e i loro bilanci.
Dopo di ciò, abbiamo il metodo Bank — che porta lo stesso nome del contratto. Pertanto, questo è il suo costruttore. Qui viene assegnato alla variabile owner l'indirizzo di colui che ha pubblicato questo smart contract nella rete. È l'unica operazione che avviene in questo costruttore. In altre parole, msg in questo caso sono proprio quei dati che sono stati trasmessi alla macchina virtuale insieme alla transazione, contenente l'intero codice di questo contratto. Pertanto, msg.sender è l'autore di questa transazione che pubblica questo codice. Sarà lui ad essere il proprietario dello smart contract.
Il metodo deposit permette di inviare tramite transazione una certa quantità di monete al conto del contratto. In questo caso, lo smart contract, ricevendo queste monete, le conserva nel suo saldo, ma registra nella struttura balances chi è stato il mittente di queste monete, per sapere a chi appartengono.
Il metodo successivo si chiama withdraw e accetta un parametro: l'importo di monete che qualcuno desidera prelevare da questa banca. Qui viene effettuata un'asserzione per verificare se ci sono abbastanza monete nel bilancio dell'utente che sta chiamando questo metodo per inviarle. Se ce ne sono a sufficienza, il contratto smart restituisce all'utente la quantità di monete richiesta.
Il passo successivo è il metodo per controllare il bilancio attuale dell'utente. Chi chiama questo metodo verrà utilizzato per ottenere questo bilancio nel contratto smart. È importante notare che il modificatore di questo metodo è view. Questo significa che il metodo stesso non modifica in alcun modo le variabili della sua classe ed è di fatto solo un metodo di lettura. Non viene creata una transazione separata per chiamare questo metodo, non vengono pagate commissioni e tutti i calcoli vengono eseguiti localmente, dopo di che l'utente riceve il risultato.
Il metodo kill è necessario per eliminare lo stato di uno smart contract. Qui è prevista una verifica aggiuntiva per stabilire se l'annotatore di questo metodo è il proprietario del contratto. Se lo è, il contratto si autodistrugge e la funzione di distruzione accetta un parametro: l'identificativo dell'account a cui il contratto invierà tutte le monete rimaste nel suo bilancio. In questo caso, le monete rimanenti verranno automaticamente inviate all'indirizzo del proprietario del contratto.
Come funziona un nodo completo della rete Ethereum?
Esaminiamo schematicamente come viene eseguito tali smart contract sulla piattaforma Ethereum e come funziona un nodo completo della rete.
Un nodo completo della rete Ethereum deve avere almeno quattro moduli.
Il primo, come per qualsiasi protocollo decentralizzato, è il modulo di networking P2P — il modulo di connessione di rete e interazione con altri nodi, dove avviene lo scambio di blocchi, transazioni e informazioni sugli altri nodi. Questo è un componente tradizionale per tutte le criptovalute decentralizzate.
In seguito, abbiamo un modulo per la memorizzazione dei dati della blockchain, elaborazione, selezione del ramo prioritario, aggiunta di blocchi, distacco di blocchi, verifica di questi blocchi, ecc.
Il terzo modulo si chiama EVM (Ethereum Virtual Machine) — e questo è la macchina virtuale, che accetta bytecode dalle transazioni Ethereum. Questo modulo accetta lo stato attuale di un determinato account e applica le modifiche al suo stato sulla base del bytecode ricevuto. La versione della macchina virtuale su ciascun nodo della rete deve essere identica. I calcoli avvengono su ogni nodo di Ethereum in modo assolutamente identico, ma avvengono in modo asincrono: qualcuno verifica e accetta questa transazione prima, eseguendo tutto il codice in essa contenuto, e qualcun altro dopo. Pertanto, quando viene creata una transazione, essa si diffonde nella rete, i nodi la accettano e durante la verifica, esattamente come in Bitcoin, dove viene eseguito il Bitcoin Script, qui viene eseguito il bytecode della macchina virtuale.
Una transazione è considerata confermata se tutto il codice in essa contenuto è stato eseguito, è stato generato un nuovo stato per un determinato account e salvato fino a quando non è chiaro se questa transazione è stata applicata o meno. Se la transazione è stata applicata, allora questo stato è considerato non solo eseguito, ma anche attuale. Esiste un database che memorizza lo stato di ciascun account per ogni nodo della rete. Poiché tutti i calcoli avvengono allo stesso modo e lo stato della blockchain è identico, anche il database contenente gli stati di tutti gli account sarà lo stesso per ogni nodo.
Miti e limitazioni dei contratti intelligenti
Per quanto riguarda le limitazioni esistenti per piattaforme simili a Ethereum con contratti intelligenti, si possono elencare le seguenti:
- esecuzione del codice;
- allocare memoria;
- dati della blockchain;
- inviare pagamenti;
- creare un nuovo contratto;
- chiamare altri contratti.
Esaminiamo i limiti imposti sulla macchina virtuale e, di conseguenza, sfatiamo alcuni miti sui contratti smart. Su una macchina virtuale, che può non essere solo in Ethereum ma anche su piattaforme simili, è possibile eseguire operazioni logiche veramente arbitrarie, cioè scrivere codice che verrà eseguito lì, e si può anche allocare memoria aggiuntiva. Tuttavia, le commissioni vengono pagate separatamente per ogni operazione e per ogni unità di memoria aggiuntiva allocata.
Inoltre, la macchina virtuale può leggere dati dal database della blockchain, al fine di utilizzare questi dati come trigger per l'esecuzione di una certa logica dei contratti smart. La macchina virtuale può creare e inviare transazioni, può creare nuovi contratti e invocare metodi di altri contratti smart già pubblicati nella rete: esistenti, accessibili, ecc.
Il mito più comune è che i contratti intelligenti di Ethereum possano utilizzare informazioni da qualsiasi risorsa online. La verità è che la macchina virtuale non può inviare richieste di rete a risorse informative esterne su Internet, il che significa che non è possibile scrivere un contratto intelligente che distribuisca valore tra gli utenti in base, ad esempio, al tempo atmosferico, al vincitore di un campionato, o in base a eventi che accadono nel mondo esterno, perché tali informazioni non sono disponibili nel database della piattaforma stessa. In altre parole, non ci sono dati al riguardo nella blockchain. Se non ci sono, la macchina virtuale non può utilizzare queste informazioni come trigger.
Svantaggi di Ethereum
Elencando i principali svantaggi, il primo consiste nelle difficoltà legate alla progettazione, sviluppo e test di smart contract su Ethereum (in Ethereum, il linguaggio utilizzato per scrivere smart contract è Solidity). In effetti, la pratica dimostra che una percentuale molto alta di errori è attribuibile al fattore umano. Questo è particolarmente vero anche per gli smart contract Ethereum già scritti, che presentano una complessità media o superiore. Se per smart contract semplici la probabilità di errore è bassa, nei contratti complessi emergono frequentemente errori che portano a furti di fondi, congelamenti o distruzioni non previste degli smart contract, e così via. Ci sono già molti casi noti.
Il secondo svantaggio è che la macchina virtuale stessa non è perfetta, poiché è scritta da esseri umani. Può eseguire comandi arbitrari e qui risiede una vulnerabilità: è possibile configurare in modo specifico un insieme di comandi che porteranno a conseguenze impreviste. È un campo molto complesso, ma ci sono già diverse ricerche che dimostrano che queste vulnerabilità esistono nella versione attuale della rete Ethereum e possono portare al malfunzionamento di molti smart contract.
Un'altra grande difficoltà, che può essere considerata uno svantaggio, è che si può arrivare a stabilire, in modo pratico o tecnico, che se si compila il bytecode del contratto che verrà eseguito sulla macchina virtuale, si può definire un certo ordine specifico delle operazioni. Quando vengono eseguite insieme, queste operazioni sovraccaricano notevolmente la macchina virtuale e la rallentano in modo sproporzionato rispetto alla commissione pagata per l'esecuzione di queste operazioni.
In passato, ci sono stati periodi di sviluppo di Ethereum in cui molte persone che avevano una buona conoscenza del funzionamento della macchina virtuale scoprivano vulnerabilità. In effetti, le transazioni pagavano commissioni molto basse, ma rallentavano notevolmente l'intera rete. Questi problemi sono complessi da risolvere perché, prima di tutto, devono essere determinati, in secondo luogo, bisogna correggere il costo per l'esecuzione di queste operazioni e, in terzo luogo, è necessario effettuare un hard fork, il che significa aggiornare tutti i nodi della rete alla nuova versione del software e poi attivare simultaneamente queste modifiche.
Per quanto riguarda Ethereum, sono stati condotti numerosi studi e accumulata una grande esperienza pratica: sia positiva che negativa, ma rimangono ancora complessità e vulnerabilità con cui dovremo confrontarci in futuro.
Quindi, la parte tematica dell'articolo è conclusa, passiamo alle domande che sorgono abbastanza frequentemente.
Domande frequenti
— Se tutte le parti di un contratto intelligente in vigore vogliono modificare i termini, possono annullare questo contratto intelligente utilizzando la firma multipla e poi creare un nuovo contratto intelligente con i termini aggiornati per la sua esecuzione?
La risposta qui sarà duplice. Perché? Da un lato, il contratto intelligente è impostato una sola volta e non prevede modifiche, dall'altro, può avere una logica predefinita che consente l'adeguamento totale o parziale di alcune condizioni. Quindi, se desideri modificare qualche aspetto del tuo contratto intelligente, devi prevedere in anticipo le condizioni che ti permetteranno di aggiornare tali termini. Pertanto, solo in modo così previdente si può organizzare l'aggiornamento del contratto. Ma anche qui puoi incappare in problemi: commettere un errore e ottenere una vulnerabilità corrispondente. Pertanto, queste cose devono essere progettate e testate molto dettagliatamente e con attenzione.
— E se il mediatore si accordasse con una delle parti partecipanti: escrow o contratto intelligente? È obbligatorio avere un mediatore in un contratto intelligente?
Il mediatore non è necessario in un contratto smart. Può non esserci. Se nel caso di un escrow il mediatore collude con una delle parti, allora sì, questo schema perde rapidamente tutto il suo valore. Per questo motivo, i mediatori vengono scelti in modo tale da essere fidati da tutte le parti coinvolte in questo processo. Di conseguenza, non trasferirai semplicemente monete a un indirizzo multisignature con quel mediatore di cui non ti fidi.
— È possibile trasferire molte criptovalute diverse con una sola transazione Ethereum dal proprio indirizzo a diversi indirizzi di destinazione, ad esempio a indirizzi di scambio dove questi token sono negoziati?
È una domanda interessante e riguarda il modello di transazione di Ethereum e le sue differenze rispetto al modello di Bitcoin. E la differenza è fondamentale. Nel modello di transazione di Ethereum, si trasferiscono semplicemente monete da un indirizzo a un altro, senza resto, ma solo l'importo specifico che hai indicato. In altre parole, non è un modello di uscite non spese (UTXO), ma un modello di conti e bilanci corrispondenti. Teoricamente, è possibile inviare con una singola transazione più token diversi, se si scrive un contrattino intelligente astuto, ma si dovrà comunque effettuare molte transazioni, creare un contratto, quindi trasferirgli token e monete, e infine chiamare il metodo corrispondente. Questo richiede sforzi e tempo, quindi, in pratica, non funziona così e tutti i pagamenti in Ethereum vengono effettuati tramite transazioni separate.
— Uno dei miti sulla piattaforma Ethereum è che non sia possibile descrivere condizioni che dipendono da dati di risorse esterne nel web; come bisogna procedere allora?
La soluzione consiste nel fatto che il contratto smart stesso può prevedere uno o più cosiddetti oracoli fidati, i quali raccolgono dati sulle condizioni del mondo esterno e li trasmettono ai contratti smart attraverso metodi speciali. Il contratto stesso considera veri i dati ricevuti dalle parti fidate. Per maggiore affidabilità, si seleziona semplicemente un gruppo più ampio di oracoli e si minimizza il rischio di collusione tra di loro. Il contratto stesso può ignorare i dati provenienti da oracoli che contraddicono la maggior parte.
Questa tematica è oggetto di una delle lezioni del corso online su Blockchain — “”.
Fonte: habr.com
