Il mondo della finanza decentralizzata sta crescendo rapidamente. Negli ultimi tre anni, il valore totale bloccato – un parametro che misura la quantità di denaro gestita complessivamente dai protocolli DeFi – è passato da 10 miliardi di dollari a poco più di 50 miliardi. Nel pieno del bull market, è stato raggiunto un picco di ben 180 miliardi.

Valore totale bloccato nella DeFi, dal 2019 a oggi. Fonte: DefiLlama

Ma il dato che tutti ignorano è che nel 2022 gli utenti hanno perso oltre 2,8 miliardi di dollari a causa di attacchi hacker ed exploit; nel 2021, tale cifra aveva superato i 10 miliardi di dollari. Il problema è il seguente: gli attuali linguaggi di programmazione per smart contract non forniscono funzioni adeguate per la creazione e la gestione di asset. Affinché la DeFi diventi realmente alla portata di tutti, i linguaggi di programmazione dovrebbero fornire funzionalità orientate agli asset per rendere lo sviluppo di smart contract più sicuro e intuitivo.

Gli attuali linguaggi di programmazione non possiedono il concetto di "asset"

Fra le soluzioni che potrebbero contribuire a ridurre i problemi della DeFi vi è la revisione del codice: consentire a entità di terze parti di esaminare il codice sorgente del proprio smart contract può evidenziare falle nella sicurezza. Dei dieci maggiori hack nella storia della DeFi, nove non avevano superato alcuna revisione. Ma investire un maggior numero di risorse nella risoluzione di questo problema sarebbe come potenziare il motore di un'automobile con le ruote quadrate: è vero, la sua velocità aumenterebbe... ma vi è un problema fondamentale alla base.

I linguaggi di programmazione utilizzati oggi per la DeFi, come Solidity, non possiedono il concetto di "asset." Gli asset come token e NFT esistono solo come variabile (numeri che possono cambiare) in uno smart contract. In altre parole, i fattori che definiscono il comportamento di una variabile – ad esempio "può essere spesa soltanto una volta", "vi può accedere soltanto un utente autorizzato", oppure "in una transazione, la somma fra fondi in entrata e uscita dovrebbe essere sempre pari a zero" – devono essere implementati dallo sviluppatore da zero, per ogni singolo smart contract.

Con l'aumentare della complessità degli smart contract, aumenta anche il numero di revisioni necessarie per garantire che il servizio sia sicuro. Ma gli esseri umani sono fallaci, commettono errori e introducono bug nel codice. E a volte a causa di questi bug la gente perde un sacco di soldi.

Un esempio su tutti: Compound, uno dei protocolli più importanti del settore DeFi, ha subito un attacco hacker nel 2021 che ha causato il furto di 80 milioni di dollari. Perché? Lo smart contract conteneva un ">" invece di un ">=".

Effetto a catena

Affinché gli smart contract possano interagire tra loro, come ad esempio un utente che scambia un token con un altro, vengono inviati messaggi a ciascun contratto per aggiornare le loro variabili interne.

Il risultato è un complesso gioco di equilibri. La garanzia che tutte le interazioni con gli smart contract siano gestite correttamente ricade interamente sugli sviluppatori. Dal momento che non vi sono misure di sicurezza innate in Solidity e nella Ethereum Virtual Machine (EVM), gli sviluppatori devono progettare e implementare in maniera autonoma le protezioni e le convalide necessarie.

Pertanto, gli sviluppatori della DeFi passano quasi tutto il proprio tempo ad assicurarsi che il loro codice sia sicuro. Lo smart contract viene controllato più volte, al punto che alcuni sviluppatori riferiscono di dedicare fino al 90% del loro tempo a test e revisioni, e soltanto il 10% alla creazione di nuove funzionalità.

Ma se gli sviluppatori sprecano così tanto tempo cercando di rendere il proprio codice sicuro, come ha fatto la DeFi a crescere così rapidamente? Perché nel settore vi è una fortissima domanda per forme di denaro programmabili, auto-sovrane, permissionless e automatizzate, nonostante le sfide e i rischi che queste presentano oggigiorno. 

Immaginate quanto gli sviluppatori potrebbero innovare, se potessero concentrare la loro produttività sulle funzionalità e non sulla sicurezza. Un'innovazione tale da permette alla DeFi – un settore da "appena" 50 miliardi di dollari – di sfidare il mondo della finanza tradizionale, che attualmente muove quasi 500.000 miliardi.

Asset totali delle istituzioni finanziarie globali, dal 2002 al 2020. Fonte: Statista

Innovazione e sicurezza

Il modo migliore per rendere la DeFi sia innovativa che sicura è migliorare i linguaggi di programmazione: offrire agli sviluppatori un modo semplice per creare e interagire con gli asset, nonché rendere tali asset e il loro comportamento una caratteristica nativa. Ogni asset dovrebbe sempre comportarsi in modo prevedibile e in linea con principi finanziari sensati.

In un paradigma di programmazione orientato agli asset, creare nuovi token dovrebbe essere semplice tanto quanto richiamare una funzione nativa. Perché la piattaforma saprebbe cos'è un asset: -initial_supply_fungible(1000) creerebbe un token fungibile con una fornitura fissa di 1000, mentre funzioni come -take e -put penderebbero token da una parte e li sposterebbero altrove.

Invece di costringere gli sviluppatori a ideare logiche complesse e aggiornare costantemente liste di variabili, con tutti gli errori che ne derivano, nella programmazione orientata agli asset le operazioni basilari della DeFi sarebbero funzioni native del linguaggio stesso. I token non possono pertanto essere perduti o rubati, perché la programmazione orientata agli asset garantisce l'impossibilità di tali eventi.

È così che otterremo contemporaneamente innovazione e sicurezza nella DeFi. Ed è così che cambieremo la percezione del grande pubblico, da "la DeFi è un luogo poco sicuro" a "e lì che voglio mettere i miei risparmi."

Ben Far è responsabile delle partnership di RDX Works, core developer del protocollo Radix. Prima di RDX Works, ha ricoperto posizioni manageriali presso PwC e Deloitte, dove ha assistito i clienti in questioni relative alla governance, alla revisione contabile, alla gestione del rischio e alla regolamentazione della tecnologia finanziaria. Ha conseguito una laurea in geografia ed economia e un master in mapping software e analisi presso l'Università di Leeds.