Nel precedente articolo abbiamo iniziato ad esplorare come alcune verità legate agli smart contract, questi contratti intelligenti che però lo sono solo di nome ma non di fatto, nascondano dei problemi che non sempre vengono visti in superfice.

Come già anticipato nella prima parte, quanto segue non è un attacco ad Ethereum o agli smart contract, ma lo scopo di questi due articoli è semplicemente quello di spiegare concetti tecnici in maniera semplice.

Smart contract Ethereum VS smart contract Bitcoin

“Antagonisti” da sempre, le due blockchain principali di questo settore hanno entrambe la possibilità di sviluppare smart contract ma con peculiarità diverse.

Ricapitolando, abbiamo visto che:

Quindi da una parte abbiamo degli smart contract con cui possiamo fare molte cose ma che richiedono una complessità di programmazione alta da cui ne deriva un grado di sicurezza inferiore, e sto parlando degli smart contract di Ethereum, mentre dall’altro lato abbiamo degli smart contract più sicuri, in quanto non Turing-complete, con cui si possono fare meno cose con una complessità minore.

Se dunque Bitcoin ha preferito non sceglier un linguaggio non Turing-complete per tutelarsi, Ethereum ha cercato in qualche modo di farlo facendo gravare sulle spalle dei programmatori la responsabilità della sicurezza, infatti quest’ultimi devono assicurarsi che quello che scrivono poi sia quello che vogliono che lo smart contract esegua.

Gli smart contract non sono contratti nel vero senso della parola

Lasciare la responsabilità agli sviluppatori di assicurarsi che i contratti siano sicuri, può sembrare una buona idea, ma tutto sommato questo comporta delle conseguenze che potremmo definire in parte “”centralizzanti””.

Mi spiego meglio.

Ethereum è stato lanciato con l’idea che “il codice è legge”.

Ovvero una volta lanciato un contratto su Ethereum questo è la massima autorità e nessuno può annullarlo.

Con questa idea di fondo, si cercava di responsabilizzare gli sviluppatori, chiarendogli bene che sono soli, nel senso che se avessero sbagliato a scrivere uno smart contract, loro sono gli unici responsabili ma…questa condizione non è più stata vera quando è avvenuto il noto attacco DAO.

Cercherò di riassumerti brevemente quanto accadde.

DAO è stato un progetto che ha raccolto circa 150 milioni di dollari in ETH, quando un ether valeva appena 20$. Questo permetteva agli utenti di depositare denaro e ottenere dei rendimenti su di essi. Tutto sommato lo smart contract non è stato scritto ad hoc, il codice conteneva delle falle, e qualcuno ha trovato il modo di prendere i fondi.

A quel punto la governance di Ethereum, ovvero tutti i nodi della rete che possono esprimere il proprio consenso hanno deciso tramite un hard fork di ripristinare tutto il mal tolto nelle casse del DAO e salvare così sviluppatori ed investitori.

Possiamo sicuramente definire la persona che ha prosciugato il DAO un hacker, ma se ci pensiamo bene e ragionassimo come se lo smart contract fosse un vero contratto, si tratta di qualcuno che in funzione di quello che c’era scritto nel contratto ha trovato un modo per trarne vantaggio.

Spero di non essermi ingarbugliato troppo con questo concetto e che sia chiaro perchè è veramente una sottile ma importante differenza.

Dal caso DAO, naque poi Ethereum Classic che ha mantenuto invece le vecchie regole dove “il codice è legge” senza quindi ridare i fondi al contratto.

Da quel momento gli sviluppatori hanno iniziato a evitare la proprietà di completezza di Turing di Ethereum per gli smart contract, proprio perchè questi si sono rivelati difficili da proteggere, infatti gli standard più noti ed utilizzati come ERC20 e ERC721, possono essere scritti facendo a meno di tale proprietà.

Gli smart contract sono validi solo per beni digitali

Ecco un altra verità sugli smart contract, ne discutevo proprio qualche giorno fa in merito alla possibilità di tokenizzare un asset come l’oro.

Facciamo un esempio prendendo come riferimento il settore immobiliare.

Tizio è proprietario di un immobile che è in vendita e Caio vuole acquistarlo, un semplice smart contract è in grado di provare la transazione di acquisto e passare la proprietà della casa.

Utilizzando una piattaforma come Ethereum, che è decentralizzata, questo fa sorgere un problema definito “Oracle problem”.

Infatti in un contesto decentralizzato gli smart contract hanno senso solo se esiste un legame definito tra la versione digitale (tokenizzata) e la versione fisica del bene.

Quindi ogni volta che la proprietà del token cambia anche la propietà del bene fisico deve variare.

Oracle problem, consiste proprio nella difficoltà del mondo digitale di conoscere il mondo fisico.

Quando Tizio trasferità la sua casa a Caio, lo smart contract deve essere informato dell’avvenuta esecuzione del trasferimento, in tal senso esistono più modi per dare allo smart contract questo input ma tutti si basano sul riporre fiducia in una terza parte che verifica l’evento nel mondo fisico, perdendo così un caposaldo delle caratteristiche della blockchain decentralizzata ovvero quella di essere “trustless”.

La casa si rifletterà in un token non fungibile.

La prima cosa che dovrà fare Caio è assicurarsi che quel token rappresenti proprio quella proprietà e che questo sia in possesso di Tizio, per farlo Caio dovrà affidarsi ad un “oracolo” che gli confermi che quel token rappresenta quell’immobile e che è di proprietà di Tizio.

Pensiamo sempre ad altri casi, se il token viene rubato? La casa appartiene al ladro? E se viene smarrito? Non è più vendibile? Sarà possibile creare un nuovo token per quella casa? Se si, chi lo potrà creare?

Esiste dunque un problema, al momento irrisolvibile, nel collegare un bene digitale a un bene fisico, che si tratti della frutta made in Italy del tuo supermercato di fiducia, di un’auto, di una casa o qualsiasi altra cosa, il tutto sempre in un contesto decentralizzato al 100%.

Detto questo uno smart contract per essere veramente efficace deve funzionare senza un oracolo e l’unico modo è che la proprietà del bene non abbia alcuna dipendenza esterna alla piattaforma su cui viene eseguito il contratto.

Conclusione

Mi auguro che d’ora in avanti anche grazie a questi due articoli la tua considerazione degli smart contract sia più consapevole.

Con questo non voglio dire che gli smart contract siano inutili ma semplicemente che spesso dietro questa parola c’è un idea che non tiene conto di molte variabili, che come abbiamo visto sono numerose.

Spero di esser riuscito nell’intento di comunicare informazioni tecniche in maniera semplice e come sempre per qualsiasi domanda o dubbio lascia pure un commento sotto questo articolo e ti risponderò quanto prima.