In questo articolo esamineremo cosa sono i contratti intelligenti, quali tipi esistono, ci familiarizzeremo con le diverse piattaforme di contratti intelligenti, le loro peculiarità e discuteremo come sono strutturati e quali vantaggi possono offrire. Questo materiale sarà molto utile per i lettori che non conoscono a sufficienza il tema dei contratti intelligenti, ma che desiderano avvicinarsi alla sua comprensione.
Contratto tradizionale vs. contratto intelligente
Prima di approfondire i dettagli, analizziamo un esempio delle differenze tra un contratto tradizionale, che è redatto su carta, e un contratto intelligente, che è rappresentato in forma digitale.
Come funzionava prima dell'emergere dei contratti intelligenti? Immagina un gruppo di persone che desiderano stabilire alcune regole e condizioni per la distribuzione di beni, nonché un meccanismo specifico per garantire l'esecuzione di tale distribuzione secondo le regole e condizioni stabilite. Si radunavano, redigevano un documento in cui annotavano i propri dati identificativi, le condizioni, i beni coinvolti, inserivano la data e firmavano. Questo contratto veniva anche certificato da una parte fidata, come un notaio. Successivamente, queste persone si separavano con la propria copia cartacea del contratto e iniziavano a compiere azioni che potevano non corrispondere al contratto stesso, ossia facevano una cosa, mentre sulla carta era attestato che dovevano farne un'altra. E come risolvere questa situazione? In effetti, uno dei partecipanti al gruppo doveva prendere quel documento, raccogliere delle prove, portarle in tribunale e richiedere la corrispondenza tra il contratto e le azioni effettive. Spesso è difficile ottenere un'adeguata esecuzione di questo contratto, il che porta a conseguenze spiacevoli.
Cosa si può dunque dire sui contratti intelligenti? Essi riuniscono in sé la possibilità di redigere le condizioni del contratto e un meccanismo per la loro rigorosa esecuzione. Se le condizioni sono state definite e è stata firmata la transazione o la richiesta corrispondente, allora, dopo l'accettazione di questa richiesta o transazione, non è più possibile modificare le condizioni o influire sulla loro esecuzione.
C'è un singolo validatore o un'intera rete, così come un database che memorizza tutti i contratti intelligenti che sono stati eseguiti in una rigorosa sequenza cronologica. È anche importante che questo database contenga tutte le condizioni trigger necessarie per l'esecuzione del contratto intelligente. Inoltre, dovrebbe tenere conto del valore in questione, la cui distribuzione è descritta nel contratto. Se riguarda una certa valuta digitale, allora questo database deve considerarlo.
In altre parole, i validatori dei contratti intelligenti devono avere accesso a tutti i dati con cui opera il contratto intelligente. Ad esempio, un'unica base di dati dovrebbe essere utilizzata per registrare simultaneamente valute digitali, saldi degli utenti, transazioni degli utenti e timestamp. Quindi, nel contratto intelligente, una condizione potrebbe essere il saldo di un utente in una certa valuta, il verificarsi di un certo tempo o il fatto che sia stata effettuata una certa transazione, e non di più.
Definizione di contratto intelligente
In generale, la terminologia stessa è stata coniata dal ricercatore Nick Szabo e applicata per la prima volta nel 1994, ed è stata documentata nel 1997 in un articolo che descrive l'idea stessa dei contratti intelligenti.
I contratti intelligenti implicano che venga eseguita una certa automazione nella distribuzione del valore, che può dipendere solo dalle condizioni preimpostate. Nel caso più semplice, si presenta come un contratto con condizioni rigorosamente definite, firmato da determinati soggetti.
I contratti intelligenti sono progettati per minimizzare la fiducia nei terzi. A volte viene completamente escluso un centro decisionale dal quale dipende tutto. Inoltre, per tali contratti è più semplice effettuare audit. Questo è il risultato di alcune caratteristiche di progettazione di tale sistema, ma più spesso comprendiamo sotto contratto intelligente un ambiente decentralizzato e la presenza di funzioni che consentono a chiunque di analizzare il database e condurre un audit completo dell'esecuzione dei contratti. Ciò garantisce così la protezione da modifiche ai dati retroattive che potrebbero comportare cambiamenti nell'esecuzione del contratto stesso. La digitalizzazione della maggior parte dei processi durante la creazione e l'avviamento di un contratto intelligente semplifica spesso la tecnologia e i costi per la loro realizzazione.
Esempio semplice — servizio Escrow
Esaminiamo un esempio molto semplice. Questo ci aiuterà a comprendere le funzionalità dei contratti smart e a orientarsi meglio su quando utilizzarli.
Può essere realizzato anche utilizzando Bitcoin, anche se ora Bitcoin è ancora difficile da considerare una vera piattaforma per contratti smart. Quindi, abbiamo 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, conferma e poi spedisce il prodotto. Tuttavia, in questa situazione c'è una necessità di grande fiducia: l'acquirente deve fidarsi del negozio online per l'intero importo del monitor. Poiché il negozio online potrebbe avere una reputazione bassa agli occhi dell'acquirente, c'è il rischio che per qualche motivo, dopo aver ricevuto il pagamento, il negozio si rifiuti di servire e non invii il prodotto all'acquirente. Pertanto, l'acquirente si pone la domanda (e il negozio online si pone la stessa domanda) su cosa sia possibile applicare in questo caso per minimizzare tali rischi e rendere le transazioni di questo tipo più affidabili.
Nel caso di Bitcoin, è possibile dare all'acquirente e al venditore la possibilità di scegliere un mediatore in modo indipendente l'uno dall'altro. Ci sono molte persone che si occupano di risolvere questioni controverse. I nostri partecipanti possono scegliere un mediatore da un elenco generale, 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 questo indirizzo. Una chiave apparterrà all'acquirente, la seconda al negozio online e la terza al mediatore. E su questo indirizzo multisignature l'acquirente invierà l'importo necessario per pagare il monitor. Ora, quando il venditore vede che i soldi sono bloccati per un certo periodo su un indirizzo multisignature, che dipende da lui, può inviare il monitor senza esitazione.
Successivamente, l'acquirente riceve il pacco, esamina il prodotto e decide se completare l'acquisto. Può essere completamente soddisfatto del servizio fornito e firmare la transazione con la propria chiave, trasferendo le monete all'acquirente dall'indirizzo multisignature, oppure può essere insoddisfatto. In quest'ultimo caso, contatta il mediatore per redigere una transazione alternativa che distribuirebbe diversamente queste monete.
Immaginiamo che il monitor sia arrivato con qualche graffio e non ci fosse il cavo per collegarlo al computer, anche se sul sito dell'ecommerce era specificato che il cavo doveva essere incluso. L'acquirente quindi raccoglie le prove necessarie per dimostrare al mediatore di essere stato ingannato: fa screenshot del sito, fotografa la ricevuta dell'ordine, scatta una foto dei graffi sul monitor e mostra che il sigillo è stato rotto e il cavo è stato rimosso. L'ecommerce, 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 dell'ecommerce (sarà chiaro più avanti il motivo). Redige una transazione in cui le monete dall'indirizzo multisignature verranno spese in una certa proporzione tra l'acquirente, l'ecommerce e il mediatore, poiché quest'ultimo si prende una parte come compenso per il suo lavoro. Supponiamo che il 90% dell'intero importo vada al venditore, il 5% al mediatore e il 5% come indennizzo per l'acquirente. Questa transazione viene firmata dal mediatore con la sua chiave, ma non può ancora essere applicata, poiché sono necessarie due firme e al momento ce n'è solo una. La transazione viene inviata sia all'acquirente che al venditore. Se almeno uno di loro sarà soddisfatto di questa opzione di ridistribuzione 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.
È importante scegliere inizialmente un mediatore di cui entrambi i partecipanti si fidino. In questo caso, agirà indipendentemente dagli interessi di uno o dell'altro e valuterà obiettivamente la situazione. Se il mediatore non offre un'opzione di distribuzione delle monete che soddisfi almeno uno dei partecipanti, allora, concordando insieme, sia l'acquirente che il negozio online possono trasferire le monete su un nuovo indirizzo multisignature, firmando entrambi. Il nuovo indirizzo multisignature sarà creato con un altro mediatore, che potrebbe essere più competente nella questione e offrire una soluzione migliore.
Esempio con un dormitorio e un frigorifero
Esaminiamo un esempio più complesso che illustra più chiaramente le possibilità del contratto smart.
Immaginiamo che ci siano tre ragazzi che si sono recentemente trasferiti in una stanza in un dormitorio. Tutti e tre sono interessati a comprare un frigorifero per la loro stanza, che utilizzeranno insieme. Uno di loro si è offerto di raccogliere la somma necessaria per l'acquisto del frigorifero e di trattare con il venditore. Tuttavia, si sono conosciuti da poco tempo e non c'è abbastanza fiducia tra loro. È evidente che due di loro rischiano, dando soldi al terzo. Inoltre, devono raggiungere un accordo sulla scelta del venditore.
Possono utilizzare un servizio di escrow, cioè scegliere un mediatore che controlli l'esecuzione dell'affare e gestisca eventuali controversie, se dovessero sorgere. Allora, concordando, redigono un contratto smart e scrivono in esso determinate condizioni.
La prima condizione è che, entro un certo periodo, ad esempio una settimana, sul relativo account del contratto intelligente debbano essere ricevuti tre pagamenti da indirizzi specifici per un importo definito. Se ciò non avviene, il contratto intelligente interrompe la sua esecuzione e restituisce le monete a tutti i partecipanti. Se la condizione è soddisfatta, vengono definiti i valori degli identificatori del venditore e del mediatore, e viene verificato che tutti i partecipanti siano d'accordo con la scelta di venditore e mediatore. Quando tutte le condizioni saranno soddisfatte, i fondi saranno trasferiti agli indirizzi indicati. Questo approccio può proteggere i partecipanti dalle frodi da qualsiasi parte e in generale elimina la necessità di fiducia.
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, all'inizio nel contratto intelligente è possibile definire la prima condizione, e solo dopo la sua esecuzione si possono definire i parametri per la condizione successiva. In altre parole, formalmente la condizione è scritta, ma i parametri per essa possono essere definiti durante il suo funzionamento.
Classificazione dei contratti intelligenti
Per la classificazione possono essere definiti diversi gruppi di criteri. Tuttavia, attualmente, sono rilevanti quattro di essi.
I contratti intelligenti possono essere distinti in base all'ambiente di esecuzione, che può essere centralizzato o decentralizzato. In caso di decentralizzazione, abbiamo una maggiore indipendenza e resilienza durante l'esecuzione dei contratti intelligenti.
Possono anche essere distinti in base al processo di definizione ed esecuzione delle condizioni: possono essere programmabili arbitrariamente, limitati o preimpostati, cioè strettamente tipizzati. Quando sulla piattaforma dei contratti intelligenti esistono solo 4 contratti intelligenti specifici, i parametri per essi possono essere definiti in modo arbitrario. Di conseguenza, definirli è molto più semplice: scegliamo il contratto dall'elenco e trasferiamo i parametri.
In base al metodo di attivazione, ci sono contratti intelligenti automatizzati, ovvero si auto-eseguono al verificarsi di determinate condizioni, e ci sono contratti in cui le condizioni sono definite, ma la piattaforma non verifica automaticamente il loro adempimento, richiedendo una separate attivazione.
Inoltre, i contratti intelligenti si differenziano per livello di privacy. Possono essere completamente aperti, parzialmente aperti o completamente riservati. Quest'ultimo significa che gli osservatori esterni non vedono le condizioni dei contratti intelligenti. Tuttavia, il tema della privacy è molto ampio e sarebbe meglio considerarlo separatamente dall'articolo attuale.
Di seguito approfondiremo i primi tre criteri per chiarire meglio la comprensione dell'argomento attuale.
Contratti intelligenti per ambiente di esecuzione
Per quanto riguarda l'ambiente di esecuzione, si distinguono piattaforme di contratti intelligenti centralizzate e decentralizzate. Nel caso di contratti digitali centralizzati, viene utilizzato un unico servizio, dove esiste un solo validatore e può esserci un servizio di backup e ripristino gestito in modo centralizzato. C'è un'unica banca dati che memorizza tutte le informazioni necessarie per definire le condizioni del contratto intelligente e per la distribuzione del valore che viene registrato in questa stessa banca dati del servizio. Questo servizio centralizzato ha un cliente che, attraverso richieste specifiche, definisce le condizioni e utilizza tali contratti. Poiché la piattaforma è centralizzata, i meccanismi di autenticazione possono essere meno affidabili rispetto alle criptovalute.
Come esempio, possiamo considerare i fornitori di servizi di telefonia mobile (diversi operatori mobile). 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 in diversi standard, nonché monitorare i fondi sui bilanci degli utenti. Di conseguenza, il fornitore di servizi di telefonia mobile può redigere contratti per la registrazione dei servizi offerti e il loro pagamento con diverse condizioni. In tal caso, è facile stabilire condizioni del tipo "invia un SMS con un determinato codice a un certo numero e riceverai determinate condizioni per la distribuzione del traffico".
Possiamo fornire un altro esempio: le banche tradizionali con funzionalità avanzate di internet banking e contratti molto semplici, come pagamenti ricorrenti, conversione automatica dei pagamenti in ingresso, detrazione automatica di una percentuale su un conto specificato, ecc.
Se parliamo di smart contract con un ambiente di esecuzione decentralizzato, allora abbiamo un gruppo di validatori. In un caso ideale, chiunque può diventare un validatore. Grazie al protocollo di sincronizzazione del database e al raggiungimento del consenso, abbiamo un database comune che ora memorizzerà tutte le transazioni con contratti rigorosamente descritti, e non alcune richieste condizionali i cui formati cambiano frequentemente e non esiste una specifica aperta. Qui, le transazioni conterranno istruzioni per l'esecuzione del contratto in base a una specifica rigorosa. Questa specifica è aperta e, pertanto, gli stessi utenti della piattaforma possono eseguire audit e convalidare gli smart contract. Qui vediamo che le piattaforme decentralizzate superano quelle centralizzate in termini di indipendenza e resilienza, ma la loro progettazione e manutenzione sono molto più complesse.
Smart contract in base al modo di definire ed eseguire le condizioni
Adesso analizziamo in dettaglio come gli smart contract possano differire in base al modo di definire ed eseguire le condizioni. Qui poniamo attenzione sugli smart contract che sono programmati in modo arbitrario e completi secondo Turing. Un smart contract completo secondo Turing consente di definire praticamente qualsiasi algoritmo come condizione per l'esecuzione del contratto: scrivere cicli, funzioni di calcolo delle probabilità e simili, fino ai propri algoritmi di firma elettronica. In questo caso, si intende davvero una scrittura arbitraria della logica.
Si distinguono anche smart contract arbitrari, ma non completi secondo Turing. Qui possiamo includere Bitcoin e Litecoin con il loro script. Si intende che è possibile utilizzare solo determinate operazioni in ordine arbitrario, ma non è possibile scrivere cicli e propri algoritmi.
Inoltre, ci sono piattaforme di smart contract che implementano smart contract preimpostati. Tra queste possiamo considerare Bitshares e Steemit. Bitshares dispone di una serie di smart contract per il trading, la gestione degli account, la gestione della piattaforma stessa e delle sue impostazioni. Steemit è una piattaforma simile, ma è orientata non all'emissione di token e al trading, come Bitshares, ma alla scrittura di blog, ovvero memorizza e elabora contenuti in modo decentralizzato.
Ai contratti completi Turing-completi possiamo ascrivere la piattaforma Ethereum e RootStock, che è ancora in fase di sviluppo. Pertanto, approfondiremo un po' di più sulla piattaforma di smart contract Ethereum.
Smart contract per metodo di attivazione
In base al metodo di attivazione, gli smart contract possono essere suddivisi in almeno due gruppi: automatizzati e manuali (non automatizzati). Gli automatizzati sono caratterizzati dal fatto che, al verificarsi di tutti i parametri noti e delle condizioni, lo smart contract viene completamente eseguito automaticamente, quindi non richiede l'invio di transazioni aggiuntive e di spese di commissione aggiuntive per ogni successivo completamento. La piattaforma stessa dispone di tutti i dati necessari per calcolare in che modo lo smart contract si concluderà. La logica non è arbitraria, ma predefinita e tutto ciò è prevedibile. In altre parole, è possibile stimare in anticipo la complessità dell'esecuzione dello smart contract, utilizzare una commissione costante per esso e tutti i processi legati alla sua esecuzione avvengono in modo più efficiente.
Per gli smart contract programmabili in modo arbitrario, l'esecuzione non è automatizzata. Per avviare uno di questi smart contract, in pratica, ad ogni passaggio è necessario creare una nuova transazione che invocherà la successiva fase di esecuzione o il successivo metodo dello smart contract, pagare la commissione corrispondente e attendere la conferma della transazione. L'esecuzione può concludersi con successo o meno, poiché il codice dello smart contract è arbitrario e possono sorgere problemi imprevedibili, come un ciclo infinito, la mancanza di alcuni parametri e argomenti, situazioni eccezionali non gestite, ecc.
Account in Ethereum
Tipi di account Ethereum
Esaminiamo quali possono essere gli account sulla piattaforma Ethereum. Esistono solo due tipi di account e non ci sono altre opzioni. Il primo tipo si chiama account utente, il secondo - account contratto. Vediamo in cosa differiscono.
L'account dell'utente è gestito esclusivamente dalla sua chiave privata di firma elettronica. Il proprietario dell'account genera la sua 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 attraverso un codice di programma predefinito, che definisce completamente il comportamento del contratto intelligente: come gestirà le sue monete in determinate circostanze, su iniziativa di quale utente e quali ulteriori condizioni devono essere soddisfatte affinché queste monete vengano distribuite. Se alcuni aspetti non sono previsti dagli sviluppatori nel codice del programma, possono sorgere problemi. Ad esempio, un contratto intelligente può raggiungere uno stato specifico in cui non accetta l'inizio di ulteriori esecuzioni da nessun utente. In tal caso, le monete si trovano di fatto bloccate, poiché il contratto intelligente non prevede un'uscita da questo stato.
Come vengono creati gli account in Ethereum
Nel caso dell'account utente, il proprietario genera autonomamente una coppia di chiavi secondo ECDSA. È importante notare che Ethereum utilizza lo stesso algoritmo per la firma elettronica e la stessa curva ellittica di Bitcoin, ma l'indirizzo viene calcolato in modo leggermente diverso. Qui non si applica il risultato del doppio hashing, come in Bitcoin, ma è previsto un singolo hashing con la funzione Keccak di lunghezza 256 bit. Dai valori ottenuti vengono scartati i bit inferiori, precisamente i 160 bit inferiori del valore di output della funzione hash. Alla fine otteniamo un indirizzo in Ethereum. Di fatto occupa 20 byte.
È importante notare che l'identificatore dell'account in Ethereum è codificato in hex senza l'uso di un checksum, a differenza di Bitcoin e molti altri sistemi, dove l'indirizzo è codificato in una base 58 con l'aggiunta di un checksum. Ciò significa che è necessario essere cauti quando si utilizzano identificatori degli account in Ethereum: anche un piccolo errore nell'identificatore porterà sicuramente alla perdita di monete.
C'è una caratteristica importante e consiste nel fatto che l'account dell'utente a livello di database generale viene creato nel momento in cui accetta il primo pagamento in entrata.
Per quanto riguarda la creazione dell'account di un contratto intelligente, si applica 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 ottenuto viene inserito in un campo speciale della transazione. Questa viene firmata a nome dell'account dell'iniziatore. Successivamente, questa transazione viene diffusa nella rete e pubblica il codice del contratto intelligente. La commissione per l'esecuzione della transazione e, di conseguenza, per l'esecuzione del contratto viene addebitata dal saldo dell'account dell'iniziatore.
Ogni contratto intelligente contiene necessariamente il suo costruttore (di quel contratto). Può essere vuoto o avere un contenuto. Una volta che il costruttore è eseguito, viene creato un identificatore dell'account del contratto intelligente, utilizzando il quale è possibile inviare monete, chiamare metodi specifici del contratto intelligente, ecc.
Struttura della transazione Ethereum
Per maggiore chiarezza, procederemo a esaminare la struttura della transazione Ethereum e un esempio di codice di un contratto intelligente.
La transazione Ethereum è composta da diversi campi. Il primo di essi è nonce, che è un certo numero sequenziale della transazione rispetto all'account stesso che la diffonde ed è il suo autore. Questo è necessario per distinguere le transazioni duplicate, cioè escludere il caso in cui la stessa transazione venga accettata due volte. Grazie all'uso dell'identificatore, ogni transazione ha un valore hash unico.
Segue quindi un campo come gas price. Qui viene indicato il prezzo al quale la valuta di base Ethereum viene convertita in gas, utilizzato per pagare l'esecuzione dei contratti intelligenti e l'allocazione delle risorse della macchina virtuale. Cosa significa questo?
In Bitcoin, le commissioni sono pagate direttamente con la valuta di base — il bitcoin stesso. Questo è possibile grazie a un meccanismo semplice di calcolo: si paga rigorosamente il volume dei dati che contiene la transazione. In Ethereum, la situazione è più complessa, poiché basarsi sul volume dei dati della transazione è molto difficile. Qui, la transazione può anche contenere codice sorgente che verrà eseguito sulla macchina virtuale, e ogni operazione della macchina virtuale può avere una complessità diversa. Ci sono anche operazioni che allocano memoria per variabili. Esse avranno la propria complessità, da cui dipenderà il pagamento per ogni operazione.
Il costo di ciascuna operazione in equivalente gas sarà costante. Viene introdotto specificamente per determinare il costo costante di ogni operazione. A seconda del carico della rete, varierà il gas price, ovvero il coefficiente secondo il quale la valuta di base verrà convertita in questa unità ausiliaria per il pagamento delle commissioni.
C'è un'ulteriore caratteristica della transazione in Ethereum: il codice byte che contiene per l'esecuzione nella macchina virtuale sarà eseguito fino a quando non si conclude con un risultato (successo o fallimento) oppure fino a quando non termina una certa quantità di monete assegnate per il pagamento delle commissioni. Proprio per evitare situazioni in cui dal conto del mittente vengono spesi tutti i soldi per le commissioni a causa di un errore (ad esempio, in caso di un ciclo infinito avviato nella macchina virtuale), esiste il seguente campo — start gas (spesso chiamato gas limit) — definisce il volume massimo di monete che il mittente è disposto a spendere per eseguire una determinata transazione.
Il campo successivo viene chiamato destination address. Qui si inserisce l'indirizzo del destinatario delle monete o l'indirizzo di un contratto intelligente specifico, i cui metodi saranno chiamati. Dopo di esso si trova il campo value, dove si inserisce l'importo delle monete che vengono inviate all'indirizzo di destinazione.
Successivamente, c'è un campo interessante chiamato data, in cui si inserisce un'intera struttura. Non è un campo separato, ma un'intera struttura in cui viene definito il codice per la macchina virtuale. Qui si possono inserire dati arbitrari — a questo scopo esistono regole specifiche.
E l'ultimo campo si chiama signature. Contiene sia la firma elettronica dell'autore di questa transazione, sia la chiave pubblica con cui verrà verificata questa firma. Dalla chiave pubblica è possibile ricavare l'identificatore dell'account del mittente di questa transazione, ovvero identificare in modo univoco l'account del mittente all'interno del sistema. Abbiamo chiarito gli aspetti fondamentali della struttura della transazione.
Esempio di codice di smart contract in Solidity
Esaminiamo ora 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, in grado di trattenere le monete degli utenti e restituirle su richiesta.
Quindi, c'è uno smart contract Bank, che esegue le seguenti funzioni: accumula monete sul proprio saldo, cioè al momento della conferma della transazione e della creazione di questo smart contract viene creato un nuovo account che può contenere monete sul proprio saldo; ricorda gli utenti e la distribuzione delle monete tra di essi; ha vari metodi per gestire i saldi, ossia è possibile effettuare ricariche, prelievi e controllare il saldo dell'utente.
Esaminiamo ciascuna 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 smart contract. Inoltre, c'è una struttura dinamica che conserva le corrispondenze tra gli indirizzi degli utenti e i saldi.
Dopo di ciò segue il metodo Bank — ha lo stesso nome del contratto. Pertanto, è il suo costruttore. Qui viene assegnato alla variabile owner l'indirizzo di chi ha collocato questo smart contract nella rete. È l'unica cosa che accade in questo costruttore. Cioè, msg in questo caso sono proprio i dati che sono stati inviati alla macchina virtuale insieme alla transazione che contiene tutto il codice di questo contratto. Pertanto, msg.sender è l'autore di questa transazione, che pubblica questo codice. Sarà lui il proprietario dello smart contract.
Il metodo deposit consente di trasferire un certo numero di monete all'account del contratto tramite una transazione. In questo caso, il contratto smart, ricevendo queste monete, le mantiene nel suo saldo, ma registra nella struttura balances chi è stato l'emittente di queste monete, per sapere a chi appartengono.
Il metodo successivo si chiama withdraw e accetta un parametro: l'importo delle monete che qualcuno desidera prelevare da questa banca. Qui viene verificato se ci sono abbastanza monete nel saldo dell'utente che chiama questo metodo per poterle inviare. Se ce ne sono a sufficienza, il contratto smart restituisce allo chiamante l'importo di monete richiesto.
Successivamente c'è il metodo per controllare il saldo attuale dell'utente. Colui che chiama questo metodo verrà utilizzato per ottenere questo saldo dal contratto smart. Va notato che il modificatore di questo metodo è view. Ciò significa che il metodo non modifica le variabili della sua classe e in effetti è solo un metodo di lettura. Non viene creata una transazione separata per chiamare questo metodo, non si paga alcuna commissione e tutti i calcoli vengono eseguiti localmente, dopo di che l'utente riceve il risultato.
Il metodo kill è necessario per distruggere lo stato del contratto smart. Qui viene inserita una verifica aggiuntiva per determinare se l'autore di questo metodo è il proprietario del contratto. Se lo è, il contratto si autodistrugge e la funzione di distruzione accetta un parametro: l'identificatore dell'account al quale il contratto invierà tutte le monete rimaste nel suo saldo. 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 avviene l'esecuzione di tali contratti smart 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, informazioni su altri nodi. Questo è un componente tradizionale per tutte le criptovalute decentralizzate.
Inoltre, abbiamo un modulo per la memorizzazione dei dati blockchain, elaborazione, selezione del ramo prioritario, aggiunta di blocchi, disconnessione di blocchi, verifica di questi blocchi, ecc.
Il terzo modulo si chiama EVM (Ethereum Virtual Machine) — è macchina virtuale, che accetta il bytecode dalla transazione Ethereum. Questo modulo accetta lo stato attuale di un determinato account e apporta modifiche al suo stato in base al bytecode ricevuto. La versione della macchina virtuale su ciascun nodo della rete deve essere la stessa. I calcoli avvengono su ciascun nodo Ethereum in modo assolutamente identico, ma si svolgono in modo asincrono: qualcuno verifica e accetta questa transazione prima, cioè esegue tutto il codice contenuto, mentre qualcun altro lo fa dopo. Di conseguenza, quando viene creata una transazione, questa si diffonde nella rete, i nodi l'accettano e nel momento della verifica, esattamente come in Bitcoin viene eseguito il Bitcoin Script, qui viene eseguito il bytecode della macchina virtuale.
Una transazione è considerata verificata se tutto il codice contenuto è stato eseguito, è stato generato un nuovo stato di un determinato account e memorizzato 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 già attuale. Esiste un database che memorizza lo stato di ogni account per ciascun nodo della rete. Poiché tutti i calcoli avvengono in modo identico e lo stato della blockchain è lo stesso, anche il database che contiene gli stati di tutti gli account sarà identico per ciascun nodo.
Miti e limitazioni dei contratti smart
Per quanto riguarda le limitazioni che esistono per contratti smart simili a piattaforme Ethereum, si possono citare i seguenti aspetti:
- esecuzione del codice;
- allocare memoria;
- dati della blockchain;
- inviare pagamenti;
- creare un nuovo contratto;
- chiamare altri contratti.
Esaminiamo le limitazioni imposte sulla macchina virtuale e, di conseguenza, sfatiamo alcuni miti sui contratti intelligenti. Su una macchina virtuale, che può trovarsi non solo in Ethereum, ma anche in piattaforme simili, è possibile eseguire operazioni logiche veramente arbitrarie, ovvero scrivere codice che verrà eseguito lì; è inoltre possibile allocare memoria aggiuntiva. Tuttavia, la commissione viene pagata separatamente per ogni operazione e per ogni unità di memoria aggiuntiva allocata.
Inoltre, la macchina virtuale può leggere dati dal database della blockchain per utilizzare tali dati come trigger per eseguire logiche specifiche dei contratti intelligenti. La macchina virtuale può creare e inviare transazioni, può creare nuovi contratti e chiamare metodi di altri contratti intelligenti già pubblicati in rete: esistono, sono accessibili, ecc.
Il mito più comune è che i contratti intelligenti di Ethereum possano utilizzare informazioni da qualsiasi risorsa online nelle loro condizioni. La verità è che la macchina virtuale non può inviare richieste di rete a una risorsa informativa esterna su Internet, quindi non è possibile scrivere un contratto intelligente che distribuisca valore tra gli utenti in base, per esempio, a che tempo fa fuori, a chi ha vinto un certo campionato, o in base a qualsiasi altro evento accaduto nel mondo esterno, perché queste informazioni non sono presenti nel database della piattaforma stessa. In altre parole, nel blockchain non ci sono informazioni a riguardo. Se non compaiono lì, la macchina virtuale non può utilizzare questi dati come trigger.
Svantaggi di Ethereum
Elenco delle principali problematiche. Il primo svantaggio è che ci sono alcune difficoltà nella progettazione, nello sviluppo e nel collaudo dei contratti intelligenti su Ethereum (in Ethereum, il linguaggio di programmazione utilizzato per scrivere contratti intelligenti è Solidity). Infatti, la pratica dimostra che un'alta percentuale di tutti gli errori è attribuibile al fattore umano. Ciò è particolarmente rilevante anche per i contratti intelligenti di Ethereum già scritti, che presentano una complessità media o superiore. Se per i contratti intelligenti semplici la probabilità di errore è bassa, nei contratti complessi si verificano frequentemente errori che causano furti di fondi, congelamento di risorse, distruzione inattesa dei contratti intelligenti, ecc. Sono già noti molti casi di questo tipo.
Il secondo svantaggio è che stesso la macchina virtuale non è perfetta, poiché anche essa è scritta da persone. Può eseguire comandi arbitrari e qui risiede la vulnerabilità: è possibile configurare in un certo modo una serie di comandi che porteranno a conseguenze impreviste. Questo è un campo molto complesso, ma sono già stati condotti diversi studi che dimostrano che queste vulnerabilità sono presenti nella versione attuale della rete Ethereum e possono portare al fallimento di molte operazioni dei contratti intelligenti.
Un'altra grande difficoltà, che può essere considerata un difetto. Essa consiste nel fatto che, se si compila il bytecode del contratto che verrà eseguito sulla macchina virtuale, è possibile determinare un certo ordine specifico delle operazioni. L'esecuzione complessiva di queste operazioni caricherà molto la macchina virtuale e la rallenterà in modo sproporzionato rispetto alla commissione pagata per l'esecuzione di queste operazioni.
In passato ci fu un periodo di sviluppo di Ethereum in cui molti ragazzi, che capivano a fondo il funzionamento della macchina virtuale, trovavano vulnerabilità. Di fatto, le transazioni pagavano una commissione molto piccola, ma rallentavano notevolmente il funzionamento dell'intera rete. Questi problemi sono molto difficili da risolvere, poiché bisogna, innanzitutto, determinarli, in secondo luogo, correggere il prezzo per l'esecuzione di queste operazioni e, infine, effettuare un hard fork, 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 molti studi e acquisito una grande esperienza pratica: sia positiva che negativa, tuttavia restano complessità e vulnerabilità con cui bisognerà ancora affrontare in qualche modo.
Quindi, la parte tematica dell'articolo è conclusa, passiamo alle domande che sorgono abbastanza frequentemente.
Domande frequenti
— Se tutte le parti di un contratto smart attivo vogliono modificare le condizioni, possono annullare questo contratto smart tramite firma multipla e poi creare un nuovo contratto smart con le condizioni aggiornate per la sua esecuzione?
Qui la risposta sarà duplice. Perché? Perché, da un lato, il contratto smart è una volta definito e non prevede ulteriori modifiche, mentre, dall'altro, può avere una logica prestabilita che prevede la modifica totale o parziale di alcune condizioni. Cioè, se vuoi cambiare qualcosa nel tuo contratto smart, devi prima definire le condizioni secondo cui puoi aggiornare tali condizioni. Di conseguenza, solo in questo modo oculato si può organizzare l'aggiornamento del contratto. Ma anche qui si possono incontrare delle difficoltà: commettere un errore e ottenere una vulnerabilità corrispondente. Pertanto, queste cose devono essere progettate e testate molto attentamente e in modo dettagliato.
— E se il mediatore colludesse con una delle parti partecipanti: escrow o contratto smart? È obbligatorio avere un mediatore in un contratto smart?
Il mediatore non è obbligatorio in un contratto intelligente. Potrebbe non esserci. Se nel caso di escrow il mediatore collude con una delle parti, allora sì, questo schema perde rapidamente tutto il suo valore. Pertanto, i mediatori vengono scelti in modo tale che tutte le parti coinvolte in questo processo si fidino di loro contemporaneamente. Di conseguenza, non trasferirai semplicemente monete su un indirizzo multisignature con quel mediatore a cui non ti fidi.
— È possibile trasferire in un'unica transazione Ethereum molti token diversi dal proprio indirizzo a diversi indirizzi di destinazione, ad esempio indirizzi di scambio dove vengono scambiati questi token?
Questa è una buona domanda e riguarda il modello di transazioni Ethereum e la sua differenza rispetto al modello Bitcoin. E questa differenza è fondamentale. Se nel modello di transazione Ethereum trasferisci semplicemente monete, queste vengono trasferite solo da un indirizzo a un altro, senza resto, solo un importo specifico che hai indicato. In altre parole, non è un modello di output non speso (UTXO), ma un modello proprio degli account e dei relativi saldi. Teoricamente, è possibile inviare più token diversi in un'unica transazione, se scrivi un contratto intelligente ingegnoso, ma è comunque necessario effettuare molte transazioni, creare il contratto, poi trasferirgli token e monete, e poi chiamare il metodo corrispondente. Questo richiede sforzi e tempo, di conseguenza, nella pratica non funziona così e tutti i pagamenti in Ethereum vengono effettuati in transazioni separate.
— Uno dei miti sulla piattaforma Ethereum è che non sia possibile descrivere condizioni che dipendano dai dati di una risorsa internet esterna, quindi come procedere?
La soluzione consiste nel fatto che il contratto intelligente può prevedere uno o più cosiddetti oracoli fidati, che raccolgono dati sulla situazione nel mondo esterno e li trasferiscono nei contratti intelligenti tramite metodi speciali. Il contratto stesso considera veri i dati ricevuti da parti fidate. Per una maggiore affidabilità, viene semplicemente scelta un'ampia gruppo di oracoli per minimizzare il rischio di collusione. Il contratto stesso può non tenere conto dei dati provenienti da oracoli che contraddicono la maggioranza.
Questo tema è trattato in una delle lezioni del corso online su Blockchain — “”.
Fonte: habr.com
