In questi due articoli tratterò di finanza decentralizzata e delle applicazioni che vertono su questo nuovo approccio che sta avendo grande successo nel mondo della blockchain, oltre ad analizzare alcune sfide che riguardano la sicurezza informatica.
Il contenuto è tratto dal mio intervento al Cyber Security Virtual Conference di cui è disponibile il video completo.
Solitamente siamo abituati a interagire da un punto di vista finanziario con altri utenti attraverso un intermediario centralizzato, come ad esempio nel caso di transazioni di trasferimenti di liquidi (bonifici, acquisto o compravendita di azioni e/o di polizze assicurative).
Questo intermediario consente di mantenere alcune proprietà della comunità finanziaria e, in particolare, di mantenere l’integrità del sistema. Non sarebbe possibile creare, ad esempio, nuovi asset se questo non fosse esplicitamente permesso dalla comunità, così come non è possibile spendere più denaro di quanto ne venga effettivamente posseduto.
Nel modello tradizionale queste caratteristiche e funzionalità del sistema finanziario vengono garantite, appunto, da una serie di intermediari centralizzati.
Normalmente l’intermediario finanziario è concepito come una terza parte fidata che garantisce tutte quelle proprietà elencate precedentemente.
Nella finanza decentralizzata e, quindi, nelle relative applicazioni, questi intermediari vengono a mancare.
In un approccio di finanza decentralizzata il sistema finanziario è intrinsecamente integro, oltre a garantire altre proprietà minori; ma la proprietà fondamentale del sistema finanziario è che deve essere integro. Un sistema finanziario praticamente decentralizzato, quindi senza entità centrali che garantiscano questa proprietà, è strutturato in maniera tale da essere automaticamente garantito rispetto alla proprietà fondamentale dell’integrità.
Questo come avviene?
Eliminando gli utenti super partes. Gli utenti fanno parte della stessa comunità e hanno tutti lo stesso ruolo, sono quindi attori del sistema finanziario. Essi eseguono una complicata coreografia, un complesso protocollo con delle proprietà crittografiche ben definite, le quali garantiscono che nessuno possa “barare” o compromettere l’integrità del sistema.
Non parliamo di una novità degli ultimi mesi, ma di qualcosa che ormai esiste da molti anni: la blockchain.
Ci sono diversi tipi di blockchain, ma tutti garantiscono l’integrità del sistema attraverso questo complicato protocollo che i vari attori del sistema finanziario eseguono.
Partendo dai conti di risparmio che consentono di ottenere, ad esempio, un tasso di interesse sui risparmi che vengono depositati all’interno di un’applicazione di finanza decentralizzata, che consentono di prestare e di prendere in prestito (per qualsiasi ragione) denaro o asset, o di acquistare polizze assicurative; e in questo senso possiamo estendere il campo a mondi eterogenei, come i prodotti derivati delle assicurazioni finanziarie su asset primari sottostanti, ad esempio il prezzo del petrolio.
Altre applicazioni riguardano invece aspetti di tassazione e di accounting.
Nel mondo della finanza decentralizzata possono essere concepite, quindi, numerosissime applicazioni. Queste applicazioni non si comportano da “isole”, ma sono collegabili tra loro: la blockchain rappresenta il sostrato su cui poggiano tali applicazioni ed è il canale di comunicazione che esse possono sfruttare per comunicare tra loro, creando un sistema finanziario complesso, slegato da uno specifico ambito applicativo.
Ciò già ci fa intravedere alcuni problemi, non di sicurezza informatica (o perlomeno non direttamente) ma legati all’interoperabilità tra queste applicazioni. Disponiamo comunque di alcuni progetti che tendono a rendere queste applicazioni interoperabili, creando infine un ecosistema complesso.
Queste applicazioni – che nella sostanza sono applicazioni decentralizzate, o dApp – funzionano su una blockchain e consentono le operazioni sopracitate (prendere denaro, prestare denaro, acquistare polizze, ecc.).
Le transazioni che avvengono attraverso queste applicazioni decentralizzate si basano sul concetto di smart contract.
Lo smart contract rappresenta l’insieme delle regole che gli attori devono seguire in un’applicazione finanziaria di tipo decentralizzato; e la blockchain è lo strumento che consente di applicare queste regole, definite all’interno degli smart contract.
Come detto, gli smart contract – che appunto rappresentano la base di questa applicazione decentralizzate – possono poi comunicare tra loro e realizzano un sistema finanziario complesso.
Riassumendo, i punti fondamentali sono il concetto di applicazione decentralizzata o dApp, di blockchain e di smart contract.
Questa slide riporta uno dei principali siti che si occupa di finanza decentralizzata (aggiornato al 10 maggio 2021) e ci mostra gli ambiti applicativi in cui le applicazioni di finanza decentralizzata si stanno muovendo.
Possiamo notare l’alto numero di queste applicazioni, segno che questo nuovo approccio sta avendo un certo tipo di successo: vedremo poi, col tempo, se sarà consolidato.
Per spiegare più nel dettaglio come funzionano le applicazioni di finanza decentralizzata e quindi arrivare agli aspetti di sicurezza, ho preso in esame quello che viene chiamato il Compound Protocol, un progetto che riguarda la creazione di uno smart contract, che definisce alcune regole standard per realizzare tutta una serie di applicazioni di finanza decentralizzata.
Facciamo ora riferimento a un particolare tipo di applicazione della finanza decentralizzata, che è quella di consentire di prestare e di prendere in prestito denaro (inteso sempre in termini di asset, di criptovalute, quindi di token e così via).
Compound Protocol funziona in maniera molto semplice: chi vuole prestare o vuole prendere in prestito del denaro deve innanzitutto immobilizzare una serie di asset, la cui lista è ben definita. Questi asset vengono inseriti all’interno di uno smart contract, che li gestisce.
Una volta che gli asset sono stati immobilizzati all’interno dello smart contract è possibile prestare questi asset (e quindi ottenere un tasso di interesse), oppure è possibile utilizzarli come collateral: ovvero come garanzia di prestiti su altri asset: ad esempio, potrei immobilizzare una certa quantità di Bitcoin all’interno di uno smart contract che realizza il Compound Protocol e ottenere così un certo numero di Ethereum, sulla base di un tasso di cambio che viene definito secondo precise regole.
Tipicamente lo smart contract che realizza il compound protocol prende questi tassi di cambio come elementi esogeni: il mercato di Bitcoin/Ethereum fluttua nel tempo e, quindi, il Compound Protocol deve sapere in ogni istante quale sia il tasso di cambio tra questi due asset. Si tratta di variabili esogene che devono essere ricavate dall’esterno: questo, come vedremo, rappresenta un problema di sicurezza.
Non mi riferisco qui nello specifico a dApp di finanza decentralizzata, ma alle dApp in generale. Come già detto, alla base di un’applicazione finanziaria c’è lo smart contract.
Lo smart contract è la parte che appare in verde in questa figura ed è staccato rispetto alle altre due parti, che si trovano sopra; da una parte troviamo il wallet che rappresenta l’utente e nella parte a destra, invece, l’applicazione stessa. Lo smart contract è separato.
Questo è un concetto importante: lo smart contract, in qualche maniera, vive di vita propria. Viene scritto lo smart contract – che codifica le regole con cui gli attori si scambiano transazioni tramite questa applicazione di finanza decentralizzata – e, una volta che lo smart contract è stato creato sulla blockchain, il creatore se ne “spossessa” tornando ad essere, come tutti gli altri, un membro della comunità.
Ne deriva che lo smart contract e le regole che sono codificate all’interno dello stesso verranno obbligatoriamente applicate: ciò certifica che le regole definite nello smart contract verranno applicate e non potranno essere mai derogate. Questa applicazione è effettuata dalla blockchain.
Quando lo smart contract viene inserito sulla blockchain, abbiamo una garanzia quasi assoluta che le regole che si trovano all’interno dello smart contract verranno attuate.
Lo smart contract è dunque un elemento con cui interagiscono sia l’utente sia la dApp. I due attori si fidano dello smart contract, quindi delle regole che sono applicate dalla blockchain per quello specifico smart contract, e interagiscono tra loro.
Ciò avviene, da un lato, nella parte destra, dove abbiamo la dApp e “la parte tradizionale”. Successivamente vediamo gli strati che ci aspetteremmo da una qualsiasi applicazione: troviamo ad esempio l’applicazione web, una parte di back-end, che gestisce tutta una serie di operazioni (database, altri tipi di sistemi di storage, sistemi di comunicazione ecc.) e anche alcuni token crittografici, che servono alla parte di back-end della dApp per interagire con lo smart contract, ad esempio per autenticare le proprie transazioni.
Saliamo nello stack: abbiamo un’API che può essere sfruttata da un’applicazione web o da un’app mobile. Quindi l’utente si connette alla dApp, esattamente come se dovesse connettersi a un qualsiasi sito web, e comincia a interagire con essa attraverso un’interfaccia di front-end, che può essere implementata con una qualsiasi tipo di tecnologia di front-end, ad esempio Javascript; la dApp, quindi la parte di front-end, comunica con l’utente sia attraverso un canale tradizionale (che è quello del browser, quindi dell’interfaccia che il browser reindirizza in termini di HTML), sia “dietro le quinte”, con il wallet dell’utente.
Il browser mette dunque a disposizione della dApp un’interfaccia per connettersi al wallet dell’utente. E lo fa perché l’utente – ad esempio nel caso del compound protocol – decide di immobilizzare degli asset che si trovano nel suo wallet all’interno dello smart contract.
Chiaramente non è l’utente a fare quest’operazione in maniera diretta ma l’applicazione, la dApp centralizzata che, attraverso il codice JavaScript, interagisce con il wallet dell’utente e gli comunica di trasferire gli asset dal wallet allo smart contract.
Si tratta di un’operazione critica, sensibile, dato che si stanno movimentando asset che sono gestiti dall’utente: per quest’ultimo potrebbero esserci, infatti, degli impatti diretti a livello finanziario.
Normalmente quello che succede è che tra il wallet di un utente e l’applicazione decentralizzate si stabilisce una relazione di trust. Infatti quando si apre un’applicazione di finanza decentralizzata avendo, ad esempio, un plugin che gestisce il wallet (e.g. Metamask), si aprirà una finestra di Metamask chiedendo una conferma per connettere il mio wallet con l’applicazione di finanza decentralizzata. Confermando dico al mio plugin che mi fido di quella dApp, dandogli il permesso di assolvere alle sue richieste.
Ovviamente Metamask ha tutta una serie di ulteriori controlli, in particolare per il trasferimento degli asset; ma richiede sempre la conferma da parte dell’utente, stabilendo questa relazione di trust.
Questo è quindi il funzionamento di una dApp: e possiamo notare, da subito, alcune criticità.
Lo smart contract è qui nella slide rappresentato da un arbitro, perché definisce le regole del gioco e le fa applicare ai vari attori: in questo caso, la dApp e l’utente.
Chiaramente le dApp di per sé non esistono: esse sono i nodi della rete blockchain, in particolare della rete Ethereum. Prendono il codice dello smart contract e garantiscono che tutte le transazioni che vengono inviate sulla blockchain e che servono quello smart contract siano valide. Semplicemente, seguono le regole definite all’interno dello smart contract.
Lo smart contract è un arbitro incorruttibile. Nessuno, neanche il creatore stesso dello smart contract, può derogare alle norme che sono definite all’interno dello stesso; normalmente il creatore dello smart contract si riserva un ruolo “diverso” rispetto a quello degli altri utenti, ma si tratta comunque di un ruolo definito nelle regole dello smart contract.
Non si tratta, quindi, di una deroga a queste regole: il creatore si ritaglia alcune norme speciali poiché è prevista la possibilità di effettuare operazioni di tipo privilegiato, ma questo non intacca il carattere di incorruttibilità dello smart contract.
L’altra caratteristica dello smart contract è l’immutabilità. Una volta inserito lo smart contract all’interno della rete blockchain, nessuno – neanche il creatore – può cambiare il codice, perché cambiare il codice di uno smart contract in un certo momento può rappresentare una violazione dell’integrità del sistema, ossia il bene primario che la blockchain garantisce.
Vedremo come questa immutabilità possa determinare alcuni problemi, che hanno dei riflessi anche dal punto di vista della sicurezza informatica.
Altro importante aspetto legato agli smart contract che realizzano applicazioni di finanza decentralizzata sono i due standard ERC-20 e ERC-721, definiti all’interno della blockchain Ethereum e che realizzano due tipologie di token crittografici.
L’ERC-20 è un token fungibile, assimilabile al denaro contante. Due banconote da 20€, ad esempio, sono pienamente fungibili tra loro: posso scambiarle e il sistema rimane assolutamente neutro. Spesso i contratti di finanza decentralizzata basano il proprio funzionamento sullo standard ERC-20.
Prendiamo ad esempio il Compound Protocol: lo smart contract definisce di poter impiegare un Compound Protocol (per esempio Ethereum, Bitcoin o altri tipi di token) e può farlo perché il Compound protocol è compatibile con lo standard ERC-20. È quindi possibile creare un nuovo token di tipo ERC-20 e avere ottime caratteristiche di compatibilità con applicazioni di finanza decentralizzata, perché spesso queste applicazioni utilizzano lo standard ERC-20 come un layer di astrazione rispetto allo specifico token. A volte le applicazioni di finanza decentralizzata implementano esse stesse dei token ERC-20, per esempio il Compound Protocol: quando si immobilizzano nel Compound Protocol degli asset di tipo crittografico, vengono restituiti un po’ di token di tipo ERC-20 che servono ad altri scopi all’interno del Compound Protocol.
L’altro tipo di token, che talvolta viene realizzato dagli smart contract in generale e dagli smart contract di finanza decentralizzata in particolare, sono gli ERC-721, che realizzano invece token non fungibili. I token non fungibili sono i contratti relativi alla proprietà, ad esempio gli atti di proprietà di beni immobili.
Restando a questo esempio, due case non sono tra loro fungibili: un appartamento da 200 m² non è fungibile con un altro da 100 m², infatti l’atto di proprietà identifica un immobile ben preciso, che non è fungibile rispetto ad altri immobili. Quindi l’ERC-721 incrementa un altro tipo di standard, astrattamente un altro tipo di token, sebbene non fungibile.
Gli NFT hanno avuto recentemente un certo successo mediatico perché esistono aste che mettono in vendita i diritti di proprietà su opere digitali attraverso non fungible tokens di Ethereum: ciò ha causato un certo hype all’interno della finanza generalizzata.
Nel prossimo articolo esporrò i problemi di sicurezza associati allo Smart Contract.
Il contenuto è tratto dal mio intervento al Cyber Security Virtual Conference di cui è disponibile il video completo.
A cura di Cristiano Paris, Consigliere di AIEA – Capitolo di Milano di ISACA
Arrestato a Parigi il CEO di Telegram: cosa significa in termini di responsabilità delle piattaforme…
Introduzione In un contesto in cui la digitalizzazione sta crescendo costantemente, è importante sapere come…
Casi come Cellebrite Ufed v. Signal pongono in luce come la cybersecurity sia un fattore…
I Big Data stanno cambiando le regole del commercio online. Finalmente le aziende possono comprendere…
Dal punto di vista tecnico-operativo, le indagini di digital forensics vengono svolte utilizzando specifici strumenti…
Nell’ambito dell’email security esistono diversi protocolli volti a garantire l'autenticità, l'integrità e la riservatezza delle…