La blockchain (assieme ai cosiddetti registri distribuiti – DLT) è un algoritmo tecnico a tutti gli effetti riconducibile a un database di nuova generazione. La consapevolezza di questa caratteristica apre la strada a nuovi scenari per l’utilizzo di questa tecnologia in progetti di e-democracy. Un’esperienza in questo ambito è stata fatta dal Comune di Napoli. Analizziamo la situazione.
Le tappe importanti nella storia dei database
Dal punto di vista ingegneristico la storia dei database è costellata di momenti importanti: dalla nascita dei moderni calcolatori ad oggi, possono identificarsi tre grandi rivoluzioni: la prima, durante gli anni ‘50-’70, guidata dalla nascita e dalla successiva diffusione del computer elettronico e delle schede perforate; la seconda, durante gli anni ‘70-2000, che ha visto l’egemonia del modello relazionale[1]; l’ ultima, nell’era attuale della Terza Piattaforma, in cui dominano i social network massivi, l’ultraconnettività mobile, i miliardi di dispositivi in rete con l’IoT; la società digitale vede dunque l’emergere di una nuova generazione di database, in qualche caso come estensione, in altri in dichiarata opposizione al modello relazionale, ma in ogni modo rispondenti alle nuove esigenze : da un lato, l’elaborazione di enormi insiemi di dati, i cosiddetti bigdata[2], dall’altro l’affidabilità, la resilienza dei sistemi e l’anonimato.
In questo quadro evolutivo che coinvolge la fenomenologia del concetto di database e, dietro la spinta dirompente dell’ambiente legato alle transazioni di moneta virtuale, nasce e si sviluppa la tecnologia blockchain. L’aumento della dimensione e l’utilizzo massivo delle applicazioni richiede il passaggio dall’architettura client-server ad un’architettura distribuita e la suddivisione della base dati su diversi server. Si sviluppano quindi due diverse tipologie di database di nuova generazione: da un lato, in un contesto di ultraconnettività come quello dei primi anni 2000, grosse realtà OTT, ad esempio Google, iniziano ad abbandonare il modello puramente relazionale per sviluppare “in casa” un ecosistema “ad hoc”, in grado di gestire in modo performante gli enormi insiemi di dati rilasciati dalle applicazioni massive e dai miliardi di connessioni di rete, attraverso una modalità di elaborazione ottimizzata (perché costruita su misura) e ad alta velocità.
Il progetto open source Hadoop (adottato da Facebook) si ispira proprio all’architettura pionieristica disegnata dagli sviluppatori del colosso americano Google: i server distribuiti (cluster) condividono un file system dedicato GFS (HDFS in Hadoop), uno strato software di elaborazione parallela e distribuita, Map Reduce (o Yarn in Hadoop) e un database NoSQL, ridondante e resiliente[3].
Database tradizionale e blockchain, il confronto
Dall’altro lato, grazie alla spinta del mondo emergente delle criptovalute e per risolvere tutta una serie di altri problemi, legati in primo luogo all’anonimato delle transazioni e alla costruzione di un meccanismo robusto volto ad una memorizzazione affidabile e resiliente, inizia a svilupparsi e a crescere il complesso ecosistema della blockchain. Dal punto di vista della progettazione di un’applicazione dunque, di fronte alle sfide della Terza piattaforma, oggi è possibile scegliere fra i database noSql che, nel nome dell’elaborazione di un’enorme massa di dati, sacrificano la consistenza del sistema e le tecnologie DLT, le quali rinunciano all’elaborazione massiva, lasciando il dato off-chain per puntare sull’affidabilità della registrazione non del dato in chiaro ma di una sua impronta pseudonima, l’hash.
Rispetto ad un database tradizionale inoltre, la piattaforma peer to peer rappresentata dalla blockchain, supera il problema del Single Point of Failure e appare un sistema intrinsecamente resiliente perché distribuito, in cui ogni nodo detiene una copia completa, replicata del database e ha interesse a non compromettere la fonte stessa della sua remunerazione. Un sistema del genere può fare a meno del concetto del Trust Service Provider (cioè dell’entità detentrice o “allocatrice” della versione autentica delle informazioni) perché è l’algoritmo stesso, per come è costruito (almeno nelle due versioni più diffuse di Bitcoin ed Ethereum), ad essere in grado di discriminare, in maniera automatizzata e definitiva, qual è l’informazione attendibile e come tale suscettibile di essere registrata nei blocchi.
Da queste caratteristiche emerge il grande interesse che le implementazioni blockchain, nate nel mondo delle transazioni virtuali, hanno suscitato tra gli esperti del settore sia in ambito data protection (visto il diffuso utilizzo dei dati pseudonimi a basso impatto), sia per affrontare alcune istanze di e-democracy, nel contesto ormai consolidato di cittadinanza digitale.
E-democracy e blockchain tra passato presente e futuro
Sotto il profilo normativo, il nostro paese possiede una regolamentazione sui DLT piuttosto controversa, ardita sotto certi aspetti, specie se si fa riferimento alla recente posizione della Commissione Europea sul Report del Blockchain Observatory, rilasciato il 27 settembre 2019. La Commissione infatti, ritiene di dover condizionare l’attribuzione della caratteristica di firma elettronica qualificata ai sensi del Regolamento eIDAS, nel caso delle firme e dei “sigilli” elettronici tramite blockchain, all’esistenza dei TSP, quelle stesse entità che, per definizione, sono escluse e superate dall’architettura distribuita.
Mentre dunque la Commissione Europea sembra porre un freno al riconoscimento della validità alle firme elettroniche e alle marche su blockchain, la normativa italiana, all’articolo 8 ter del D.Lgs. 135/2018 dispone che, in primo luogo, “gli smart contract soddisfano il requisito della forma scritta previa identificazione informatica delle parti interessate, attraverso un processo avente i requisiti fissati dall’Agenzia per l’Italia digitale con linee guida da adottare entro novanta giorni dalla data di entrata in vigore della legge di conversione del presente decreto” e, in secondo luogo, che “la memorizzazione di un documento informatico attraverso l’uso di tecnologie basate su registri distribuiti produce gli effetti giuridici della validazione temporale elettronica di cui all’articolo 41 del regolamento eiDAS”.
Da questo quadro si evince che il Legislatore italiano, diversamente dalla Commissione europea, subordina il valore probatorio a requisiti tecnici individuati da linee guida (non ancora emesse) di Agid e non anche alla presenza di eventuali Enti Certificatori, che costituirebbero certamente una contraddizione in termini, almeno in architetture permissionless. I requisiti di anonimato e di decentralizzazione del sistema blockchain dunque, se da un lato sembrano costituire un ostacolo per il riconoscimento del valore probatorio di un potenziale output, dall’altro rappresentano una soluzione innovativa alle sfide della Protezione dei Dati Personali e, soprattutto, della e-democracy.
Il caso del Comune di Napoli
Un’implementazione tutta italiana, realizzata da un eterogeneo team di volontari, il Team eVoting Napoli (due giuriste, due ingegneri software, un architetto funzionario del Comune di Napoli con vasta esperienza nella task force elettorale del Comune e un matematico esperto di sistemi paralleli e distribuiti) in seguito ad una delibera del Comune di Napoli, la numero n. 465 del 05/10/2018, che istituiva un gruppo di lavoro allo scopo di elaborare e proporre obiettivi legati alla tecnologia blockchain, rappresenta un paradigma innovativo di superamento delle problematiche connesse all’e-voting, rese palesi dalle esperienze dei precursori esteri, tra tutte, quelle del Cantone di Zug (Svizzera) e in Estonia in particolare.
La caratteristica innovativa del sistema di Napoli è che utilizza una blockchain permissionless (Ethereum) ma lo fa non attraverso il voto a distanza (il che genererebbe problematiche conosciute, in primo luogo sull’affidabilità dei client e in secondo luogo sul voto di scambio) ma direttamente nel seggio, scindendo con una chiara scelta progettuale e metodologica, il momento dell’identificazione (lasciata al Presidente del Seggio) dal momento dell’esercizio effettivo della preferenza elettorale e della registrazione in blockchain. Ciò permette di realizzare un meccanismo di gestione delle preferenze completamente anonimizzato, perché il soggetto votante, una volta che sia entrato in cabina ad esercitare il suo diritto di voto, non è in alcun modo riconducibile alla preferenza espressa, che è l’unico dato memorizzato dal sistema. In questo modo il voto elettronico non a distanza, ma rigorosamente segreto, diventa non solo costituzionalmente legittimo ai sensi art. 48, ma anche (di fatto) immutabile perché appoggiato non su blockchain permissioned, soggette, come minimo, alla vulnerabilità legata all’unico nodo autorevole per rilasciare le autorizzazioni, ma su blockchain anonima, permissionless e consolidata come quella di Ethereum.
Un’ulteriore garanzia è inoltre legata al fatto che lo spoglio può essere fatto, sempre attraverso blockchain, attraverso una lettura dei dati pubblici assolutamente trasparenti. Certo, Il tema dell’hardware preesistente nelle sedi del seggio dove si innestano le votazioni tramite blockchain è certamente delicato. Andranno sicuramente predisposti dei “requisiti di applicabilità” dell’infrastruttura applicativa basata sui client blockchain, che dovrà necessariamente fare i conti con sistemi operativi, reti e con il software preinstallato sulle macchine che le ospiteranno. Sarà auspicabile dunque adottare procedure robuste di “security by design” soprattutto sul server che, in qualità di elemento essenziale di tutto il sistema, dovrà essere configurato in luogo idoneo, da personale preparato e, una volta blindato grazie alla tecnologia del container, trasportato nel luogo del seggio.
Le caratteristiche del sistema
Se si analizza l’architettura del sistema[4] si evince un aspetto fondamentale: esistono due web application, ognuna gestita da un server LAMP stack (Linux, Apache, MySQL e PHP) e incubate in container Docker[5] che lavora su sistema operativo Linux Ubuntu, utilizzate rispettivamente, la prima per virtualizzare il seggio (e la dashboard del Presidente di Sezione), la seconda per simulare lo spoglio elettorale. Entrambe utilizzano blockchain come sistema di registrazione e memorizzazione affidabile delle informazioni di voto, cioè come un database, un database di nuova generazione.
L’implementazione di Napoli inoltre, con uno stratagemma non da poco, cioè creando una pipeline, una piccola area di memoria (l’urna virtuale) in cui accumulare un certo numero di preferenze prima della transazione di registrazione riesce a migliorare le garanzie sull’anonimato e anche ad abbassarne i costi[6]; problema, quello economico, che per lungo tempo ha allontanato le sperimentazioni dei progetti di e-voting dai contesti permissionless consolidati in grado, come tali, di generare fiducia (per l’elevato numero di nodi che rende improbabile il rischio di compromissione dovuto alla detenzione del 51% dell’hashing power) ma, appunto, suscettibili di incidere notevolmente sul budget.
Conclusione
Per proporre uno spunto di riflessione a conclusione di questo contributo, è proprio grazie ad una soluzione tutta italiana che è possibile enucleare idee ed elementi innovativi utili a superare i limiti di approcci preesistenti (si pensi al problema della sicurezza del nodo afferente all’Autorità di identificazione in contesti permissioned) e a percorrere prospettive promettenti di sviluppi futuri della tecnologia: la blockchain, se considerata attraverso un punto di vista di autentica neutralità tecnologica, come “database di nuova generazione”, è la nuova frontiera della partecipazione e della e-democracy.
Il voto infatti non è riconducibile all’elettore, e quindi non reca alcun danno alla persona e al processo democratico; proprio la natura permissionless del sistema garantisce il rispetto della segretezza, della trasparenza e dell’immutabilità (laddove una blockchain permissioned, al contrario, introdurrebbe i concetti di “Fiducia” e “Autorità” all’interno di un contesto nato proprio per superarli e che anzi, con l’aggiunta degli stessi, perderebbe di credibilità); non esiste un’autorità centrale in grado di censurare o alterare il contenuto; la natura aperta della piattaforma consente infine di verificare pubblicamente l’integrità del sistema di voto.
Note
- Il modello relazionale, sostituendo il puntatore ad una struttura di livello fisico con il principio del riferimento in base al valore (in cui il legame tra gli schemi si fonda sulla uguaglianza dei valori di certi attributi), si presenta sulla scena come il modello vincente, in grado di realizzare sia l’indipendenza logica (attraverso il DBMS) sia l’indipendenza fisica dalle strutture destinate all’effettiva memorizzazione: non importa dove è fisicamente collocato il record, esso potrà essere raggiunto attraverso le operazioni di join sugli attributi in comune delle tabelle, dichiarati foreign keys, chiavi esterne, in grado di consentire la navigazione. ↑
- Il termine bigdata non si riferisce solo alla dimensione quantitativa della risorsa informativa, ma anche al suo effetto: disporre di un così grande patrimonio conoscitivo, anche in forma di dati grezzi, provenienti dalle fonti più disparate (IoT, multimedia, social network ecc), consente non solo di migliorare l’analisi dal punto di vista descrittivo ma, attraverso tecniche di machine learning, di effettuare ipotesi di tipo predittivo. ↑
- Il teorema di CAP , dal canto suo, fornisce la base teorica ai sostenitori della corrente NoSql: in un sistema distribuito è impossibile ottenere contemporaneamente i tre requisiti indispensabili dell’architettura dell’applicazione:
- Disponibilità: in caso di crash di un nodo, il sistema deve continuare ad essere operativo (resilienza);
- Tolleranza delle partizioni, principio in base al quale, qualora si verifichi l’interruzione della connessione di rete tra due nodi, l’intero database deve continuare ad eseguire le operazioni
- La consistenza, in base a cui ogni utente deve avere, allo stesso istante, la stessa “versione” dei dati contenuti nella base informativa.
Da ciò l’abbandono del modello relazionale, e della proprietà della consistenza, a vantaggio delle prime due, e solo in via residuale della cosiddetta “consistenza eventuale”. Non è raro infatti collegarsi ad Amazon con due dispositivi diversi e vedere prezzi diversi nel carello. ↑
- Si ringrazia il Team eVoting Napoli per la descrizione tecnica dell’implementazione; ↑
- Un contenitore docker è un’unità di software che “impacchetta” una funzionalità del codice e tutte le sue dipendenze in modo che l’applicazione venga eseguita in modo rapido e scalabile da un sistema di elaborazione ad un altro. ↑
- Per gentile concessione del Gruppo di Volontari dell’implementazione di Napoli, ecco i dati dei test: Dai test preliminari effettuati possiamo dire che una normale transazione scrive circa 250byte di dati in blockchain. Il consumo totale stimato in gas della transazione sarà di circa 35000 unità. Fissando il prezzo del gas 10Gwei, per emulare una condizione di leggero sovraccarico della mainnet. Il costo totale sarà quindi di 0 . 00035008 ETH. Per semplicità di calcolo e per dare unmargine maggiore al set di dati, si può arrotondare il costo della tx a 0,0004ETH. Ciò vuol dire che spendendo 1ETH possiamo inviare 2500 transazioni. Se valutiamo il tutto in euro (1ETH=152€ al 25/09/2019) si può affermare che una singola transazione costa circa 6,08 centesimi di euro(0,0608 euro). Considerando ora l’architettura del sistema e immaginando circa 200000 transazioni generate nelle 61552 sezioni durante una sessione referendaria a livello nazionale, possiamo facilmente calcolare che il costo totale sarebbe di 80ETH, 12160€ circa. Considerando che le votazioni del 2013 sono costate in media circa 6000€ a sezione (389 milioni a livello nazionale), di cui circa 3600€ solo per le spese organizzative di ogni singola sezione, la cifra stimata per le transazioni totali a livello nazionale ha un impatto minimo sul budget generale. ↑
