“A vending machine is a very ancient kind of smart contract, supposedly going all the way back to coin-operated holy water dispensers in Ptolemaic Egypt.” Nick Szabo
Gli Smart Contract sono dei “programmi” informatici che semplificano e agevolano l’esecuzione di un contratto tra le parti. Questi sono in grado di eseguire in maniera imparziale e automatica le clausole riportate sul contratto aumentandone così la sicurezza e riducendo i costi nella negoziazione dei contratti.
Le attuali implementazioni sono basate sui sistemi di blockchain. Questi approcci hanno dei problemi strutturali che andranno risolti nel prossimo futuro. La loro risoluzione aprirà la strada al pieno sviluppo delle potenzialità di questa tecnologia.
Gli Smart Contract potrebbero essere una risorsa molto importante nella gestione dei documenti presenti nel procedimento amministrativo della PA per le loro caratteristiche di sicurezza e trasparenza, per quanto allo stato attuale dell’arte gli stessi Smart Contract risultano avere dei problemi legati alla struttura pubblica e decentralizzata della blockchain, nel tempo stesso punto di forza e di debolezza della stessa.
Gli Smart Contract sono dei programmi informatici con algoritmi connessi che utilizzano dei dati per la loro esecuzione.
E’ da notare come sia i dati presi in input dallo Smart Contract come i dati che provengono dal suo output insieme al suo codice sorgente siano memorizzati tutti su blockchain: in sintesi un registro pubblico (ledger), accessibile senza alcuna forma di intermediazione e non censurabile.
Queste caratteristiche portano alla presenza di alcune criticità cruciali nell’applicazione nel settore della PA, analizzate in dettaglio di seguito.
Per quanto riguarda i dati pubblici è necessario ed importante tutelare la loro natura pubblica. Contemporaneamente è altrettanto determinante salvaguardare la tutela della privacy, ovvero la natura confidenziale, delle informazioni trattate. Queste caratteristiche, tanto importanti quanto opposte, mal si conciliano con lo stato attuale dello sviluppo tecnologico degli Smart Contracts su Blockchain rendendone l’utilizzo, ad oggi, complesso e costoso.
Una soluzione, in evoluzione, proposta dagli esperti è la cifratura dei dati inseriti su Blockchain, approccio che sembra apparentemente in contrasto con il principio base di questa tecnologia.
Se fosse già applicabile questa opzione operativa dobbiamo, comunque, prendere in considerazione la circostanza che gli Smart Contract, codice informatico eseguito e salvato su blockchain e per questo pure esso pubblico, dovrebbero integrare un servizio di criptazione e decriptazione automatica per poter rielaborare il dato salvato in forma protetta.
Questo passaggio non adeguatamente integrato nel sistema (oggi ancora non lo è) esporrebbe la cifratura a vulnerabilità, basate sul Reverse Engineering a causa del codice sorgente pubblico e salvato in chiaro degli Smart Contract.
Il risultato di questo processo porta a ricavare il dato originale in chiaro con tutti i problemi di tutela della privacy che ne derivano.
Come ultima opzione gli esperti valutano l’utilizzo di sistemi basati su sidechain, ma questi sono ancora in via di sviluppo. Sinteticamente, le sidechain sono delle blockchain private, collegate in parte ad una blockchain pubblica.
Nell’informatica le funzioni operative sono individuate dall’acronimo CRUD con il quale si intendono le quattro funzioni base nella gestione dei dati persistenti:
C: create – creazione del dato
R: read – lettura del dato
U: update – modifica del dato
D: delete – cancellazione del dato
Avendo compreso la natura funzionale di base della blockchain (la immodificabilità del dato registrato nella catena di blocchi), risulta lampante come le operazioni al punto C – create ed al punto R – read, si integrino perfettamente nella peculiare struttura dati “certificata” in cui stiamo operando.
Allo stesso tempo è altrettanto chiaro come il punto U: update ed il punto D: delete siano in aperto contrasto con la natura immutabile e persistente dei dati salvati su blockchain.
In questo contesto, la blockchain enfatizza il valore delle due prime proprietà C e R, salvando i dati in maniera immutabile così da tracciarne e certificarne l’utilizzo.
All’opposto le funzioni U e D, che sono totalmente assenti sulla blockchain, ne rendono impossibile la correzione dei dati e la loro cancellazione. Questo evidente limite va in aperto contrasto con la necessità della PA di aggiornare, modificare e cancellare i dati in maniera fluida.
La concreta e quotidiana applicazione della normativa, obbligatoria per quanto concerne la pubblica amministrazione, ha dato vita ad una tipologia particolare di contratti detti Contratti Incompleti. I Contratti Incompleti, con una definizione non tecnica e semplicistica utile ai fini di questa trattazione, sono strutturati per lasciare delle parti in bianco che saranno poi compilate dai contraenti data l’impossibilità di poter prevedere ex ante tutte le possibili sfaccettature del reale. Questa natura mutevole e flessibile dei contratti incompleti è necessaria e da affermare come prassi anche nella PA.
Così ragionando risulta chiaro e lampante come questa tipologia di contratto e la sua natura mutevole e fluida possa essere difficilmente imbrigliabile nel codice predeterminato e non soggetto a modifica di uno Smart Contract.
Data l’impossibilità pratica di prevedere, e quindi codificare, tutti i possibili esiti ed applicazioni dello Smart Contract nell’uso quotidiano della PA, risulta lampante come una rigidità del genere sia in aperto contrasto con la fluidità tanto utile quanto necessaria alla PA nella gestione dei contratti incompleti.
Questo fino a quando non sia definito in modo univoco, in sede algoritmica, lo specifico procedimento amministrativo.
In questo scenario gli algoritmi di consenso consentono la sicurezza digitale attraverso l’esecuzione decentralizzata degli Smart Contract. I linguaggi di programmazione di questi ultimi sono caratterizzati da un diverso grado di Turing completeness (il grado computazionale fa riferimento alla macchina di Turing completa).
Turing-Incompleto
I linguaggi di scripting su rete Bitcoin sono un esempio di linguaggi Turing-incompleto, in quanto al fine di garantire un elevatissimo livello di sicurezza i suoi Smart Contract sono molto basilari e si occupano di inviare e ricevere Bitcoin al verificarsi di semplici istruzioni condizionali.
Questo genere di linguaggio non riesce a garantire le capacità computazionali necessarie per molte casistiche richieste dalla PA.
Turing-Completo
Altri linguaggi di scripting, quali quelli sviluppati per rete Ethereum, sono oggi definiti quasi-Turing-complete in quanto, con poche eccezioni, hanno la capacità di garantire la risoluzione del codice eseguito sulla loro macchina virtuale e di farlo in tempi finiti.
Il meccanismo alla base di queste ulteriori garanzie presenti sulla rete Ethereum è basato sul Gas, unità di misura del costo di esecuzione delle singole operazioni fatte da uno Smart Contract.
Il concetto di Gas (dal termine anglosassone di carburante) è stato introdotto per evitare che errori presenti all’interno dei Contratti portassero a esecuzioni perpetue, consumando così le risorse del network senza scopo.
La elevata libertà ed espressività nel linguaggio usato su rete Ethereum hanno causato la creazione di Smart Contract in cui sono stati scoperti successivamente dei bug. Il caso più famoso è quello di The DAO: un errore dovuto a un “side effect” generato dal linguaggio ancora immaturo ha portato al furto di circa 40 milioni di dollari. Errori del genere sarebbero troppo rischiosi nella PA in termini di costi, tempistiche di risoluzione del problema e di sicurezza dei dati. In casi estremi, si potrebbe arrivare al completo blocco della macchina burocratica della PA.
Costi della Blockchain e difficoltà di integrazione
Quando si considera il costo di un progetto legato all’ambiente blockchain, spesso viene sottovalutato un parametro fondamentale dato ormai per scontato nell’informatica tradizionale: il costo di memorizzazione dei dati, particolarmente oneroso in questo campo. A questo si aggiunge un costo sui generis dovuto alla potenza computazionale necessaria all’esecuzione degli Smart Contract.
Nel caso della rete Ethereum, il costo computazionale di uno Smart Contract è misurato sulla base della somma dei costi unitari delle singole operazioni.
L’unità di misura utilizzata che quantifica questo costo è chiamata Gas, con il relativo corrispettivo finanziario in Gwei (i Gwei sono utilizzati nelle transazioni di Ethereum per assegnare il valore al GAS da pagare per favorire la transazione stessa).
Smart Contract lunghi e complessi, con numerosi cicli, possono arrivare a consumare enormi quantità di Gas (dell’ordine di grandezza di milioni) per poterli eseguire. Il costo del Gas, inoltre, non è una costante ma può essere modificato in maniera arbitraria alzandone il prezzo per avere maggiore priorità sulla sua esecuzione. Da questo consegue che le operazioni al secondo che possono essere portate a termine dal network Ethereum sono limitate. Tutto ciò rende l’esecuzione prioritaria del codice un bene scarso e quindi costoso.
Il costo di storage di dati su Blockchain Ethereum è perfino più elevato: un kilobyte di dati costa 640000 Gas (4 USD), un megabyte circa mille volte tanto, ossia 4000 USD, al cambio attuale ETH/USD di circa 210 usd per ETH.
Essendo un settore nuovo, risulta ancora difficile trovare figure professionali con le competenze necessarie a programmare Smart Contract in modo sicuro e ottimizzato, il che spesso porta ad elevati costi per lo sviluppo di progetto anche per applicazioni relativamente semplici.
In fase di integrazione tra il lato Blockchain e l’applicativo tradizionale è frequente incontrare difficoltà legate all’assenza di interfacce stabili di sviluppo, molte delle quali ancora in stadi immaturi, o di test.
Una possibile implementazione: le DAICO
Nel mondo della blockchain hanno preso piede delle emissioni di nuove criptovalute, finanziate in maniera decentralizzata tramite delle raccolte fondi simili al crowdfunding dette ICO, ovvero Initial Coin Offering. Queste sono solitamente volte alla raccolta di capitali per finanziare i più disparati progetti su blockchain.
Il limite di questi progetti è dato dal fatto che l’investitore, una volta trasferiti i propri fondi, non ha nessuna garanzia sull’esecuzione del progetto in cui ha investito come non ha nessun modo per riavere indietro la somma versata laddove fosse insoddisfatto del lavoro svolto dal team.
Per ovviare a questo problema, nel gennaio di quest’anno il capo sviluppatore e fondatore di Ethereum Vitalik Buterin ha proposto una soluzione che punta a rendere le ICO più sicure coinvolgendo maggiormente gli investitori nel processo di sviluppo del progetto: le DAICO. In una DAICO, nel caso in cui i partecipanti non fossero soddisfatti dei progressi compiuti dal team, saranno gli stessi investitori a votare per ottenere un rimborso dei contributi.
I progetti che implementano un sistema DAICO richiedono un buon livello di trasparenza da parte del team, garantendo la nascita di un prodotto effettivamente utilizzabile, oppure il rimborso dei fondi agli stessi investitori.
Questa stessa logica, può essere utilizzata nell’ambito della PA per i finanziamenti pubblici destinati ai Progetti esecutivi. Questo avviene subordinando lo sblocco dei fondi in maniera graduale al raggiungimento di determinati obiettivi o impieghi del capitale, che rispecchino quanto previsto precedentemente nei progetti anche in un percorso di cooperazione dei finanziatori pubblici e privati.
In questo contesto, i limiti precedentemente incontrati nell’applicazione degli Smart Contract risultano facilmente superabili perché da una parte è un bene che l’impiego dei fondi utilizzati sia un dato pubblico e quindi salvato in chiaro su blockchain e nel contempo è anche importante che i nomi ed i dati dei singoli finanziatori siano altrettanto accessibili e verificabili dal pubblico. Inoltre il meccanismo fallace dei contratti incompleti su blockchain sarebbe sostituito da un efficace metodo basato su democrazia diretta, ovvero tramite voto dei singoli finanziatori direttamente proporzionale al contributo versato. Tutto ciò garantirebbe una completa trasparenza dei finanziamenti, dei finanziatori e la possibilità concreta di revoca del capitale versato nel caso in cui i partiti non rispettassero gli accordi presi con i finanziatori.
Questo modello è applicabile anche al finanziamento pubblico dei Partiti Politici.
Per applicazioni degli Smart Contract in un procedimento amministrativo anche di bassa complessità bisogna ancora attendere una maturazione del sistema algoritmico accontentandosi, per il momento, di sperimentare in scenari praticabili.