Blockchain nella Pubblica Amministrazione, ecco le condizioni di utilizzo

Nel contesto del digital government, le amministrazioni devono interoperare e cooperare per scambiare informazioni, spesso finalizzate all’esecuzione di un procedimento complesso che ne coinvolge più d’una. In questo contesto può essere ponderato l’uso della blockchain. Vediamo le condizioni che ne rendono utile l’utilizzo

La tecnologia della blockchain si è recentemente affermata come una delle più interessanti novità nell’ambito dei sistemi distribuiti e si discute sempre più delle sue possibili applicazioni nella Pubblica Amministrazione, in quello che una volta veniva chiamato eGovernment e che più recentemente è stato ribattezzato come Digital o Smart Government.

Nell’attuale scenario di digital government, la PA deve occuparsi di interoperabilità, di far parlare i sistemi tra loro tramite API, di partecipare e sostenere il percorso chiaramente indicato nel Piano Triennale da AgID e Team per la Trasformazione Digitale, e della costituzione e diffusione di banche dati di rilevanza nazionale che costituiscono fonti autoritative di informazioni nei domini di riferimento. Le linee guida sul modello di interoperabilità in corso di pubblicazione da parte di AgID e Team Digitale spingono su modelli di interscambio basati sulle tecnologie e i protocolli più avanzati disponibili, che scalano, sono efficienti, interoperano e offrono sicurezza.

E’ in questo contesto che l’utilizzo di blockchain, quale tecnologia in via di affermazione, deve essere ponderata e supportata da obiettive necessità.

Indice degli argomenti

Un modello per classificare gli scenari applicativi

Nel contesto del Digital Government, le amministrazioni devono interoperare e cooperare per scambiare informazioni, spesso finalizzate all’esecuzione di un procedimento complesso che ne coinvolge più di una (ad es., concessione di una qualche licenza/autorizzazione/provvedimento). Questa cooperazione tra amministrazioni può essere condotta principalmente in due modi:

data-oriented, quando l’acquisizione di un dato (informazione) è l’elemento essenziale per cui cooperare, eventualmente anche per ripubblicare (in modalità open) il dato;
process/service-oriented, quando l’espletamento di un processo/procedura/servizio è l’elemento essenziale per cui cooperare.

Qui si parla di cooperazione tra amministrazioni, ma chiaramente ogni amministrazione internamente esegue dei processi al fine di gestire i dati e le sue procedure e il nostro interesse è su cosa avviene alla “frontiera” tra differenti amministrazioni.

Un’altra importante dimensione da considerare è se lo scenario applicativo è tutto intra-amministrazione, ovvero ci sono degli altri soggetti esterni (extra-amministrazione). Nel caso intra-amministrazione, tutti i soggetti sono tra di loro fidati (trusted), non potrebbe essere diversamente, ed addirittura in molti casi è naturale identificarne alcuni che abbiano un ruolo preminente nello scenario applicativo di interesse.

Nel caso extra-amministrazione, può invece avvenire che non vi sia trust nei riguardi di alcuni soggetti esterni alle amministrazioni, e con i quali tuttavia è necessario cooperare. Si noti come, ai fini della classificazione, non si debba considerare l’utente finale (cittadino o impresa) che accede all’informazione e/o richiede il servizio, ma vadano considerati soggetti che devono cooperare per recuperare tale informazione e/o espletare il servizio. Per tornare al parallelo della blockchain, il servizio a cui l’utente finale è interessato è il suo “conto corrente in BTC”, ed a questo non concorre un singolo sistema bancario (del quale avere trust) ma un insieme di soggetti, non mutuamente trusted, che tutti insieme svolgono il ruolo di sistema bancario.

PA, blockchain e trust

La blockchain è un registro distribuito di transazioni gestito su ogni nodo della rete senza la necessità di autorità centrali di controllo e intermediazione. La rete, senza gerarchie di alcuni tipo, per un “miracoloso” insieme di condizioni ed equilibri, riesce a trovare il consenso su quale sia la lista di transazioni accadute nel corso del tempo.

La caratteristica più importante non sta nell’utilizzo della mera struttura dati a blocchi, ma nel fatto che la rete sia aperta o meno, nel fatto che il meccanismo del consenso sia governato da forze indipendenti, spesso in contrapposizione l’una all’altra, che si autoregolano o no, così come nell’esistenza o meno di entità centrali che ne governano il funzionamento. Per questo motivo le blockchain aperte sono decisamente innovative e “game changer”. Se al contrario ci si riduce a blockchain chiuse e regolamentate, le soluzioni conseguenti sono declinabili come una possibile implementazione di un database (o meglio, di uno scambio di dati tra database), scenari questi che possono essere affrontati con tecnologie già mature ed efficienti e facendo riferimento a fonti di trust istituite centralmente. Questo è il caso del contesto inter-amministrazione.

Quando può avere senso usare la blockchain

Una condizione per cui può avere senso applicare la blockchain è la mancanza di fiducia verso alcune delle entità che cooperano, e quindi in un contesto extra-amministrazione. Le applicazioni e i casi d’uso che richiedono la blockchain sono quelle per cui deve valere la premessa: non ci si può fidare di niente e di nessuno. La Pubblica Amministrazione, specialmente quella italiana, basata sul modello giuridico di “civil law”, nel momento in cui coopera attraverso le sue emanazioni per offrire informazioni e servizi, gode di trust, non potrebbe essere altrimenti.

È possibile che una Pubblica Amministrazione sia coinvolta come soggetto in un sistema che usi blockchain aperte (caso extra-amministrazione), o che voglia, attraverso progetti sperimentali, individuare dei casi d’uso fortemente innovativi. In ogni caso, deve essere evidente che la Pubblica Amministrazione è fonte di trust per definizione, e quindi deve promuovere con cautela l’utilizzo di una soluzione che parte dalla premessa che non ci si può fidare di essa stessa; eventualmente la mancanza di trust deve essere verso gli altri soggetti a lei esterni.

Un’altra condizione che può rendere utile l’impiego di un meccanismo per gli smart contract basato su blockchain è l’effettiva necessità di tracciare lunghe catene di contratti in cui l’input di uno smart contract rappresenta l’output di un altro smart contract e così via. Ad esempio, questo è il caso delle coreografie di processi/servizi^{^[1]}, in cui, nonostante l’uso di soluzioni ad hoc sia sempre possibile, l’utilizzo di soluzioni open source basate su smart contract può velocizzare il processo di sviluppo.

Infine, vogliamo introdurre il seguente diagramma di flusso^{^[2]}, che può aiutare nella scelta:

Il diagramma mostra in modo compatto quali sono i criteri i requisiti che dovrebbero guidare il progetto di un’architettura da basare o meno su blockchain.

Blockchain e Bitcoin

Per introdurre il funzionamento della blockchain, è utile fare riferimento alla sua applicazione più popolare, i Bitcoin (BTC), al fine di estrarne le componenti fondamentali, per poi vedere come esse si applicano al concetto più generale di smart contract (una transazione monetaria in BTC può essere considerata un caso specifico di smart contract).

Alla base dei Bitcoin c’è il concetto di ledger (libro mastro). In questo libro mastro sono indicati per ognuno degli utenti (identificati dalla loro chiave pubblica) la quantità di BTC posseduti. Una copia del libro mastro è conservata da ognuno dei nodi che compongono la rete Bitcoin. Uno degli aspetti fondamentali della rete Bitcoin, come per un qualsivoglia database distribuito (e replicato), è il mantenimento della coerenza tra le diverse copie del libro mastro.
Al fine di inviare BTC ad un utente B, un utente A diffonde un messaggio alla rete in cui si richiede di decrementare il suo totale di una certa quantità ed accreditarlo sul record dell’utente B. Ogni nodo della rete che riceve questo messaggio aggiorna la sua copia ed invia il messaggio ad altri nodi conosciuti che fanno in sequenza lo stesso. La differenza principale tra la rete Bitcoin ed una rete bancaria tradizionale è quindi la mancanza di fiducia (trust), poiché i nodi della rete fanno capo ad entità sconosciute. Al fine di mantenere la sicurezza e la riservatezza, quindi si fa uso di complesse funzioni matematiche che proteggono ogni aspetto del sistema.
Per accertarsi dell’autenticità della richiesta dell’utente A, quest’ultimo applica una firma digitale alla richiesta che certifica il fatto che essa non sia stata manomessa e provenga da A (che la firma utilizzando la sua chiave privata). Il messaggio contiene inoltre riferimenti alle transazioni passate che certificano il possesso della quantità di BTC trasferita. Queste transazioni, dette input, hanno come destinatario l’utente A e sono firmate da altri utenti che hanno inviato ad A i BTC. Si noti che il libro mastro contiene tutte le singole transazioni avvenute sulla rete Bitcoin, ma in realtà non contiene i totali, che possono solo essere calcolati a partire dalle transazioni. Le transazioni utilizzate (spese) come input non possono più essere riutilizzate. Questo meccanismo non protegge completamente dalla possibilità di double spending, poiché i messaggi devono attraversare tutta la rete Bitcoin e possono farlo attraverso percorsi differenti. Per eliminare completamente il problema, si fa affidamento al meccanismo basato sui blocchi ordinati (da cui il nome blockchain, da non confondere con la transaction chain ottenuta tramite gli input alle transazioni).
Ogni nodo della rete mantiene un insieme di transazioni ricevute e le inserisce in un blocco che viene diffuso sulla rete insieme al riferimento al blocco precedente. Poiché nodi multipli possono creare e diffondere blocchi in maniera concorrente sulla rete, si utilizza un meccanismo tramite il quale i nodi (detti miner) sulla rete devono risolvere un complesso gioco matematico (l’inversione di una funzione hash) al fine di dichiarare un blocco come valido (confermando quindi le transazioni contenute in esso). La risoluzione di questo gioco (proof-of-work) è molto costosa dal punto di vista computazionale (e quindi dal punto di vista dei consumi energetici) e viene ricompensato in BTC. Questo spiega anche come i BTC vengano introdotti nella rete e spiega come la validità di una transazione non sia immediata ma richieda il tempo necessario a risolvere diversi blocchi. Il consenso si riesce a trovare anche assumendo che una significativa parte dei membri della rete – ma non la maggioranza – voglia cercare di violare le regole. Il supporto alla mancanza di trust viene però pagato in una rete Bitcoin con l’elevato tempo (più di 10 minuti) necessari a considerare una transazione valida.

Per completare il quadro, si aggiunga come la risoluzione del problema matematico diventi sempre più costosa al crescere della grandezza del libro mastro (che ricordiamo contiene tutte le transazioni effettuate) e questo riduce i margini di profitto (in BTC) dei miner.

Bitcoin rappresenta solo un esempio del mondo delle criptovalute che possono differenziarsi dal comportamento descritto per diverse caratteristiche che, per esempio, riducono il tempo di conferma di una transazione.
Le transazioni in criptovaluta possono essere considerate come dei semplici esempi di contratto in cui la precondizione alla validità del contratto è l’effettivo possesso, ad esempio, dei BTC scambiati che viene provato da transazioni. Si può immaginare come questo concetto possa essere esteso a qualunque forma di contratto in cui il meccanismo basato su blockchain si occupa di verificare le precondizioni del contratto a catena (ad esempio, le precondizioni di un contratto possono essere il risultato di contratti precedenti le cui condizioni vanno esse stesse verificate, e così via). Si parla in questo caso di smart contract. Questa accezione generale è quella utilizzata, ad esempio, dalla piattaforma Ethereum. Altre piattaforme, anche commerciali, specifiche per determinati casi di studio, possono introdurre limitazioni sulla tipologia di smart contract supportati. Grande impatto sta avendo l’iniziativa open source Hyperledger, a cui fanno partecipano diverse aziende leader dell’ICT.

A seconda dei permessi dei singoli nodi all’interno della rete, le blockchain possono essere classificate come segue:

Permission-less blockchain: si tratta di una blockchain in cui non c’è bisogno di autorizzazioni particolari per scrivere. È il caso della rete Bitcoin.
Public permissioned blockchain: si tratta di blockchain in cui tutti possono verificare lo stato delle transazioni (e degli smart contract).
Private permissioned blockchain: si tratta di blockchain in cui soltanto alcuni attori/nodi possono leggere lo stato delle transazioni.

Da quanto descritto, emergono i seguenti aspetti peculiari:

Di fatto la blockchain è una base di dati, non molto efficiente in termini computazionali e di semplicità di accesso all’informazione a valore aggiunto.
L’informazione è distribuita e replicata tra più nodi; in generale, l’informazione viene distribuita tra più nodi per motivi di tolleranza ai guasti, bilanciamento del carico nell’accesso/aggiornamento dei dati, ecc.; ma, nel caso della blockchain, questo viene fatto principalmente per motivi di assenza di fiducia (trust) tra i nodi che devono scambiarsi un bene (la criptovaluta) e/o informazioni.
L’informazione di interesse (a valore aggiunto) deve essere il risultato di una catena di trasformazioni/cambiamenti di stato, che concatenati insieme rappresentano qualcosa di significativo per l’utente. Ad es., nel caso dei BTC, è il totale BTC che un utente possiede la vera informazione di interesse, non soltanto le singole transazioni che hanno coinvolto l’utente. La ricostruzione dell’informazione a partire dalla catena di transazioni è, per la natura stessa della blockchain, costosa, in quanto implica (nel peggiore dei casi) lo scorrimento dell’intero libro mastro ed il calcolo dell’ultimo stato valido (a partire appunto dalle singole transazioni). Per iniziare ad introdurre degli esempi relativi alla Pubblica Amministrazioni, di un cittadino interessa, nella maggior parte degli scenari applicativi, conoscere la sua attuale residenza, più che la storia di tutti i cambi di residenza che lo hanno visto coinvolto.

Cf. Jan Mendling, Ingo Weber, Wil M. P. van der Aalst, Jan vom Brocke, Cristina Cabanillas, Florian Daniel, Søren Debois, Claudio Di Ciccio, Marlon Dumas, Schahram Dustdar, Avigdor Gal, Luciano García-Bañuelos, Guido Governatori, Richard Hull, Marcello La Rosa, Henrik Leopold, Frank Leymann, Jan Recker, Manfred Reichert, Hajo A. Reijers, Stefanie Rinderle-Ma, Andreas Solti, Michael Rosemann, Stefan Schulte, Munindar P. Singh, Tijs Slaats, Mark Staples, Barbara Weber, Matthias Weidlich, Mathias Weske, Xiwei Xu, Liming Zhu: Blockchains for Business Process Management. Challenges and Opportunities. ACM Trans. Management Inf. Syst. 9(1): 4:1-4:16 (2018). Una versione online su: http://www.infosys.tuwien.ac.at/Staff/sd/papers/Zeitschriftenartikel_2018_S_Dustdar_Blockchains.pdf ↑
Cf. Karl Wüst, Arthur Gervais: Do you need a Blockchain? IACR Cryptology ePrint Archive 2017: 375 (2017) ↑