Source: https://www.andig.it/chi-siamo/comitato-editoriale/10-saggi/18-voto-elettronico-rilievi-giuridici-e-tecnici-teorizzazione-di-un-modello-sperimentale-di-votazione-mediante-uso-della-tecnologia-blockchain
Timestamp: 2020-07-09 21:28:19+00:00
Document Index: 42089703

Matched Legal Cases: ['art. 5', 'art 5', 'art. 38', 'art. 48', 'sentenza ', 'art. 48', 'art. 25', 'art. 21', 'sentenza ']

Voto elettronico: rilievi giuridici e tecnici. Teorizzazione di un modello sperimentale di votazione mediante uso della tecnologia Blockchain - ANDIG
1. Panoramica sulle esperienze più importanti di voto elettronico in Italia
1.1. Elezioni politiche del 2006
In occasione del referendum consultivo in Lombardia, indetto dal Consiglio Regionale e tenutosi il 22 ottobre 2017, si sono accesi dibattiti riguardanti la modalità di espletamento del voto, essendo l’intera votazione avvenuta per tramite di apparecchiature elettroniche. Tale circostanza è di relativa novità per l’Italia, difatti una delle ultime istanze di scrutinio elettronico in ambito politico-amministrativo risale al 2006 in occasione delle elezioni politiche e ha visto interessate ben quattro regioni (Lazio, Liguria, Puglia e Sardegna). Al tempo la votazione avveniva mediante un software closed source installato su terminali presso i seggi; successivamente i dati dei voti così espressi venivano trasmessi, mediante supporti USB, presso strutture centrali del Dipartimento dell’Innovazione e le Tecnologie della Presidenza del Consiglio. I molteplici passaggi di dati costituivano vulnerabilità al tempo insoverchiabili, esponendo la segretezza e sicurezza del voto ad attacchi a livello software, sfruttando eventuali debolezze del programma per la votazione, e a livello hardware, tramite contraffazione degli stessi supporti USB; infine, la possibilità esclusiva da parte del governo di decifrare i dati raccolti dalle votazioni presta il fianco ad eventuali manipolazioni non altrimenti verificabili dai votanti.[1]
1.2. Referendum per l’autonomia della Regione Lombardia del 22 ottobre 2017
La legge 3/2015[2] della Regione Lombardia prevede il ricorso al voto elettronico in occasione dei referendum consultivi, primo passo verso una giusta informatizzazione di tali procedure. La materia non ha goduto di attenzione da parte delle istituzioni; l’unica proposta di legge per la disciplina del voto elettronico è stata presentata il 15 marzo 2013 dall’on. Pisicchio: “Delega al Governo per l'introduzione di un sistema elettronico di votazione per lo svolgimento delle elezioni e dei referendum, nonché disciplina della sottoscrizione per via telematica delle liste elettorali, delle candidature e delle richieste di referendum”, mai discussa dalla Commissione Affari Costituzionali).[3] Alla luce della inerzia del legislatore, molta attenzione si è concentrata su questa votazione, e, in ossequio alla correttezza ideologica scevra da considerazioni politiche, si procederà ad un’analisi tecnica, logica e circostanziata del sistema di espressione e raccolta dei voti adottato per il referendum, nonché sui soggetti attivi protagonisti di tale evento.
2. Analisi tecnica e giuridica della procedura di votazione esperita in occasione del referendum – vicende contingenti di interesse
2.1. Punti di rilevanza della procedura
Si può introdurre l’analisi asserendo che la procedura che ha avuto luogo il 22 ottobre non è stata eccessivamente dissimile da quella già sperimentata dieci anni or sono. Senza soffermarci sull’intero iter, ampliamente descritto dal regolamento regionale 3/2016[4] della Regione Lombardia, vale la pena sottolineare che è prevista, per ogni voto elettronico espresso, la stampa di una relativa scheda riportante indicazione della scelta compiuta, senza possibilità per gli scrutinatori di far risalire il voto elettronico o relativa stampa al soggetto votante. Tali voti cartacei vengono infine confrontati con il report riepilogativo emesso direttamente dall’apparecchio elettronico contenente i voti espressi e, «nel caso di mancata corrispondenza, il Presidente deve dare in ogni caso prevalenza ai risultati riportati sul report riepilogativo, dandone atto nel verbale.» (Art. 12 comma 4; la prevalenza di un sistema di memorizzazione del voto sull’altro è coerente con quanto stabilito dalle linee guida sulla trasparenza delle votazioni elettroniche[5] del Consiglio d’Europa). Le macchine per le votazioni sono per ragioni precauzionali non connesse a Internet, dunque, al termine delle operazioni di voto, le memorie criptate dei terminali su cui è avvenuta la votazione, contenenti i voti espressi, vengono trasferite fisicamente presso la segreteria del comune per essere riversate nel sistema informativo elettorale regionale.
2.2. Gestione della trasparenza e libera consultabilità del codice sorgente di programmi adoperati dalla Pubblica amministrazione
Il primo aspetto critico, nell’ambito di una votazione elettronica, riguarda il bilanciamento tra sicurezza e trasparenza. Una disposizione di estrema rilevanza è riportata all’art. 5 delle suddette linee guida: «La componente software dell’apparecchio elettronico deve avere un codice sorgente verificabile». Difatti, l’analisi del codice sorgente permette di comprendere in profondo il funzionamento del relativo programma, dato fondamentale per poter assicurare uno svolgimento della votazione libero da manipolazioni. La verifica del codice sorgente del software per la votazione, di proprietà della società Smartmatic Corp., da parte della società Emaze S.p.A. datata 06/10/2017[6], si è incentrata sui seguenti punti: 1) Anonimato del votante, 2) Unicità del voto, 3) Integrità dei dati elettorali, 4) Correttezza del conteggio del risultato elettorale; ha avuto esito positivo, e, tramite la procedura di hashing, è stata data certezza che i software forniti alla regione e oggetto della verifica fossero quelli utilizzati durante la votazione del 22 ottobre.
Dunque, la verifica del codice è stata operata da una parte terza, seppur selezionata dalla stessa Regione. Della struttura del codice e di come questo operi, tuttavia, non sono stati resi pubblici i dettagli: la certezza della non compromissione del codice sussiste fintanto che sussiste la fiducia nel soggetto incaricato di fornire i programmi per la votazione e nel soggetto incaricato della verifica.
L’associazione Hermes Center per la trasparenza e i diritti umani digitali ha dunque richiesto alla regione Lombardia accesso a: 1) Registri informatici di voto, 2) Test di sicurezza informatica e 3) Report delle richieste Helpdesk eseguite dalla società BVTech S.p.A.;[7] in risposta è stata ricevuta la documentazione priva delle «parti secretate in quanto contenenti dati relativi a codici sorgente e informazioni coperte da proprietà intellettuale nonché dati attinenti alla sicurezza». Tale esito parzialmente negativo della istanza di accesso civico F.O.I.A. è legittimo sulla base dell’art 5-bis del d. lgs 33/2013 introdotto dal d. lgs 97/2016, il quale prevede l’esclusione e la limitazione all'accesso civico di informazioni per evitare un pregiudizio concreto alla tutela di uno degli interessi pubblici inerenti alla sicurezza pubblica, nazionale e all’ordine pubblico; categorie tanto generali da legittimare qualsivoglia diniego di accesso a informazioni della pubblica amministrazione, seppur in contrasto con l’obbligo di massima trasparenza delle succitate linee guida5.
Il mancato accesso a tali informazioni non deve suscitare dubbi sulla legittimità del software della Smartmatic, né tanto meno sulla buona fede della Emaze, incaricata di verificare i codici sorgente, dacché la pubblicazione di questi potrebbe concretamente mettere a rischio la sicurezza della votazione. Tuttavia, al netto delle misure cautelari particolari adottate per garantire la sicurezza dei dati (crittografia, operazioni totalmente offline), il sistema di votazione presenta dei vulnera di rilevante portata.
Innanzitutto, è condivisibile la censura compiuta dal presidente della Hermes Center, il quale ha definito la politica della Smartmatic «security by obscurity»; ossia, è posta a garanzia della sicurezza dei programmi la segretezza degli stessi. Difatti, il paradigma closed source è nato non solo per evitare copie contraffatte dei programmi, ma anche per tutelare gli utenti da vulnerabilità che potevano essere scoperte mediante una attenta analisi del codice. Per quanto questa strategia possa essere condivisibile per applicazioni di uso privato, essa dimostra la sua intera debolezza se adottata in contesti di Pubblico interesse: non è infatti in gioco la mera tutela dell’utente, bensì lo stesso ordine pubblico-nazionale, e non è accettabile un grado di sicurezza e trasparenza che non sia il massimo raggiungibile dalle attuali tecnologie. Nel caso di questa votazione, la certezza della sicurezza del sistema è riposta nelle mani della società che controlla il codice, senza che vi sia possibilità di corroborare le loro analisi con altre affini. Tale situazione è di certo deprecabile, dacché il voto elettronico deve sopprimere il rischio di manipolazioni dei risultati cui la votazione cartacea è prona, tramite semplificazione e automatizzazione delle procedure di scrutinio, senza prestare il fianco a nuove e ulteriori forme di manipolazione dei risultati delle votazioni, che verranno successivamente analizzate.
2.3. Vulnerabilità del sistema di votazione adottato – profili di illegittimità
Il più grande rischio per la procedura di votazione elettronica sperimentata il 22 ottobre è senza dubbio la molteplicità di passaggi dei voti prima della elaborazione finale e pubblicazione; innanzitutto, il passaggio dei dati da supporti di memoria allo stato solido (SSD) alla segreteria del comune. Quali sono, ad esempio, le misure precauzionali nel caso tutt'altro che improbabile di corruzione/smarrimento di una o più memorie?
Ipotizzando lo scenario per cui di ogni memoria esiste una relativa copia, caso non contemplato dallo svolgimento attuale della votazione, ma che potrebbe essere adottato per future votazioni con lo stesso modello, oltre l’ovvia considerazione che anche il backup può essere soggetto allo smarrimento o degradazione dei dati, dovrebbe essere implementato un meccanismo per evitare di immettere nei database due volte gli stessi dati. E ciò può avvenire solamente mediante il riconoscimento univoco della memoria al terminale assegnatogli, così permettendo al computer nel quale vengono riversati i dati di accettare solo una volta dati derivanti da una data memoria (o relativo backup); si configurano, tuttavia, profili di violazione del principio di segretezza del voto, essendo disposizione fondamentale la non riconducibilità del voto espresso al terminale usato per votare.
Difatti, considerando per ipotesi che su un terminale di un seggio sia stato espresso un solo voto, se la memoria removibile associata a tale terminale venisse smarrita o i dati risultassero corrotti, deve essere possibile rintracciare la relativa memoria di backup. Ciò può avvenire o tramite tabelle che associano coppie di memorie sulla base dei codici seriali, o tramite codici identificativi installati a livello software sulle memorie, che rispondono tuttavia allo stesso principio. In tal caso le memorie o coppie di memorie debbono poter essere identificabili tra loro e con il terminale presso cui è avvenuta la votazione, per scongiurare il rischio di smarrimento doloso di una memoria primaria per sostituirla con una di backup contraffatta riportante dati diversi. Dunque non vi è modo per assicurare la certezza di inserire il dato genuino derivante dallo specifico terminale senza associare ex post la memoria a quest’ultimo e, dunque, senza esporre a potenziale identificazione il singolo soggetto votante della precedente ipotesi, e la memoria su cui giace la sua preferenza. Traslitterando in uno scenario tradizionale, sarebbe come identificare il soggetto e la scheda su cui ha votato; anche senza necessariamente svelare il suo voto, tale ipotesi non è contemplabile alla luce dei valori costituzionali a tutela del diritto di voto, in particolare quello della segretezza.
Eliminando dall’ipotesi la copia di backup della memoria, unico modo per tutelare le memorie da eventuali perdite di dati è mantenere una copia dei dati sul terminale, ed è la soluzione contemplata dalla votazione del 22 ottobre. Tuttavia, in tal modo il problema non viene risolto, bensì spostato su un altro livello. La memoria corrotta o smarrita deve poter essere identificabile in riferimento al terminale assegnatogli in modo da poter estrarre i dati su un’altra memoria, e riproponendo tutti i rilievi di non opportunità già esposti che tale identificazione reca. Volendo analizzare gli eventi della votazione, oltre 200 terminali non hanno provveduto a memorizzare i dati sulle rispettive memorie removibili, e dunque si è dovuto far ricorso ai backup.
Una soluzione al problema della potenziale l’identificazione del singolo terminale in rapporto al soggetto votante potrebbe essere la raccolta dei dati di ogni seggio su una unica memoria poi da depositare nella segreteria del comune, in sostituzione dell’attualmente previsto deposito di tutte le singole memorie. In tal modo, verrebbe ridimensionato il rischio di smarrimento/corruzione di una delle diverse singole memorie, senza tuttavia eliminarlo. Difatti, in caso di smarrimento o corruzione dei dati, si applicheranno in identico modo i rilievi già esaminati.
Purtroppo, tali ipotesi non sono meri esercizi accademici: secondo il segretario del PD a Milano Pietro Bussolati, vi è stato un malfunzionamento del 4% dei supporti di memoria a disposizione, prontamente sostituiti, senza che però siano state fornite ulteriori notizie su come tale sostituzione sia avvenuta, su quale sia stata la sorte delle unità che avevano già raccolto i voti, e su quale siano stati i provvedimenti presi a tutela della segretezza dei voti espressi in relazione all’identificazione dei soggetti votanti. La scarsa affidabilità dei supporti di memoria removibili è già stata sperimentata in passato dalla Smartmatic: nell’ambito delle elezioni del maggio 2016 nelle Filippine, il parlamentare e avvocato Glenn Chong ha denunciato la presenza di almeno una scheda SD (supporto di memoria) contraffatta[8] e l’autorevole editoriale Manila Times ha espresso dubbi inequivocabili sulla risibile sicurezza adottata per tale votazione, alzando sospetti su eventuali cambi di schede di memoria adoperate nella votazione, con supporti di memoria preparati ad hoc.[9]
3. L’identità della società Smartmatic
A tal punto, non si può non scendere nell’analisi della condotta della società Smartmatic, pur sottolineando l’intento non polemico di tale analisi, bensì di riprova della inefficienza e inaffidabilità del sistema asseritamente inoppugnabile di tale società, considerata leader nel settore.
La Smartmatic Corp. è diventata celebre per il suo coinvolgimento nel referendum dell’agosto 2004 in Venezuela. Wikileaks, sito di divulgazione di materiale coperto da segreto, ha pubblicato nel 2006 un documento[10] che suggerisce una collusione tra la società incaricata di gestire il voto elettronico (la stessa Smartmatic) e il governo Venezuelano. La successiva espansione della società Smartmatic, mediante acquisizione della società americana Sequoia Voting System, ha suscitato sospetti tra le autorità preposte statunitensi:[11] in occasione della votazione del 2006 nella Contea di Cook e Chicago, polemiche su eventuali intromissioni di agenti esterni alla votazione,[12] suffragate dall’invio dei risultati della votazione presso un computer centrale localizzato in Venezuela sono risultate nella dichiarazione da parte della Commissione degli Stati Uniti per gli Investimenti Esteri di possibili legami della società Smartmatic con il governo Venezuelano.
L’hacker italiano Matteo Flora il 17 ottobre ha dichiarato di aver fatto breccia presso le fonti aperte e liberamente consultabili della Smartmatic, ottenendo «svariati gigabyte di software, certificati, istruzioni relative a parti di software del voto, pezzi di codice, macchine virtuali e password, nomi utenti e chiavi di autenticazione di possibili amministratori del sistema».[13] Dopo aver avvisato l’autorità CERT-PA, tale accesso è stato inibito.
3.2. Modello di voto elettronico adottato dalla Smartmatic
Procedendo con l’analisi, la società Smartmatic adopera dispositivi elettronici a registrazione diretta o DRE (Direct Recording Eletronic) nell’ambito di una votazione presidiata, ovverosia presso un seggio elettorale. Tali dispositivi simulano elettronicamente una scheda per l’espressione della preferenza, possono essere adoperati online o offline e possono prevedere o meno la possibilità di stampare la controparte cartacea del voto. Questo sistema permette uno scrutinio elettronico incredibilmente più veloce, essendo lo spoglio compiuto elettronicamente, recando problematiche di non indifferente portata, e non risolvendo quelle legate alla votazione cartacea.
3.3. Rilievi di criticità tecnico-giuridiche
Primo problema derivante dall’adozione di tale modello è una sostanziale perdita di trasparenza, essendo le fasi del processo secretate e materialmente non analizzabili; vi è perdita di sicurezza, dovendo essere costretti a fidarsi dei soggetti incaricati di gestire le apparecchiature elettroniche mediante il quale il voto materialmente viene registrato; conseguente perdita del controllo pubblico, ossia da parte di agenti esterni a quelli direttamente coinvolti nelle operazioni di voto; perdita della facoltà di poter effettuare il riconteggio dei voti digitali (l’inserimento dei voti nel database è definitivo, e compiuto una sola volta), se non mediante una controparte cartacea (cosiddetto sistema VVPAT, Voter Verified Paper Audit Trail), che peraltro non ha nessun valore in questa votazione.
A tal proposito, è doveroso riportare una delle prime espressioni giurisprudenziali europee in merito al voto elettronico. Nel 2009 il Tribunale costituzionale tedesco (BVerfG, 2 BvC 3/07) ha ribadito che il Parlamento federale è eletto «a suffragio universale, diretto, libero, uguale e segreto», e che «la pubblicità del voto è la condizione essenziale per la formazione di una volontà politica democratica. Essa assicura la conformità all’ordinamento e il controllo delle procedure di voto e crea pertanto un presupposto basilare per la motivata fiducia dei cittadini nel corretto svolgimento delle votazioni»; perciò «tutti i passaggi essenziali di un’elezione sono soggetti a un possibile controllo pubblico a meno che altri interessi costituzionali (Verfassungsrechtliche Belange) giustifichino un’eccezione» (par. 106 e 111 della sentenza).[14] Il Tribunale continua, in rapporto al voto per corrispondenza, sottolineando come la restrizione di pubblicità derivante dal voto per corrispondenza sia necessaria per assicurare l’esercizio del diritto di voto a coloro che non possono esercitarlo nelle forme comuni; al contempo, precisa che tali restrizioni risultano ingiustificate nell’ambito del voto elettronico, essendo l’esercizio del diritto nella sua forma tradizionale capace di garantire in maniera più efficiente la genuinità del voto sancita dall’art. 38 della Legge fond. (corrispettivo dell’art. 48 della Cost. italiana). Dunque, l’implementazione del voto elettronico deve garantire standard di tutela del diritto di voto più elevati o almeno pari al sistema tradizionale.
Seppur tale sentenza rimane estranea all’ordinamento italiano, vi è comunanza dei principi su cui questa si fonda: «Il voto è personale ed eguale, libero e segreto.» statuisce l’art. 48 della Costituzione; altresì, l’art. 25 del Patto Internazionale relativo ai Diritti Civili e Politici, adottato dall’Assemblea generale delle Nazioni Unite il 16 dicembre 1966[15], ratificato dall’Italia con la legge 881/1977, recita: «Ogni cittadino ha il diritto [...] di votare e di essere eletto, nel corso di elezioni periodiche, veritiere, effettuate a suffragio universale ed eguale, ed a voto segreto, che garantiscano la libera espressione della volontà degli elettori.»; riprende la medesima impostazione di pensiero l’art. 21 della Dichiarazione Universale dei Diritti dell’Uomo: «La volontà popolare è il fondamento dell'autorità del governo; tale volontà deve essere espressa attraverso periodiche e veritiere elezioni, effettuate a suffragio universale ed eguale, ed a voto segreto, o secondo una procedura equivalente di libera votazione.».
Tali principi non sono mera espressione della natura democratica della Costituzione Italiana o di fonti sovranazionali, ma riflettono quello che è uno dei cardini più antichi su cui si fonda l’intero modello politico-statuale occidentale; ordunque, i mezzi che la Repubblica mette a disposizione dei cittadini per l’esercizio del diritto di voto non devono essere banalmente ispirati ai principi della personalità, uguaglianza, libertà e segretezza del voto, bensì debbono sviluppare questi valori in una forma tale da darne piena e compiuta espressione, senza ammettere limitazioni di sorta. A fronte della forza cogente di tali precetti, occorre riformulare ex novo il paradigma di votazione elettronica adottato negli ultimi anni in Italia, aderendo maggiormente ai valori Costituzionali ed Europei in tale materia.
Prima di procedere all’analisi di un differente sistema di votazione elettronica, presumibilmente più sicuro, bisogna sottolineare come l’approccio analogico a un sistema prettamente digitale ha cagionato l’insieme di problematiche finora trattate. Difatti, prendendo come modello il sistema di proprietà della Smartmatic, considerata tra le società leader del settore, si può facilmente evincere che la frammentazione e commistione della componente umana in un processo prettamente digitale ha apportato solo l’incertezza dell’errore inconsapevole (o del doloso sabotaggio) in un algoritmo che per definizione non può sbagliare. Molte schede non hanno registrato voti a causa della mancata disattivazione della modalità test da parte dei soggetti deputati a farlo;[16] il trasferimento fisico delle memorie in un luogo differente da quello in cui il voto è stato espresso, derivante dal rifiuto di adoperare la rete Internet, strumento più potente e privilegiato in tale ambito, riflette non solo una paura di attacchi informatici esterni ai terminali, di certo non scongiurati con il modello da loro effettivamente adottato, ma una sfiducia nello stesso medium informatico da loro prescelto; costringendosi a ricorrere a pratiche anacronistiche, i supporti di memoria sono stati trattati alla stregua di schede cartacee, da raccogliere per poter essere poi conteggiate elettronicamente. Tale approccio obsoleto alla tecnologia non può che cagionare le problematiche finora sperimentate o teorizzate, perciò è necessario adoperare tutti i mezzi oggi disponibili per teorizzare un sistema capace di garantire una votazione elettronica più sicura, più trasparente e più segreta.
4. La blockchain in Bitcoin
4.1. Introduzione, definizione
Attualmente, l’avanguardia nell’ambito della sicurezza informatica è la tecnologia blockchain. È necessario, per affrontare con contezza il modello che si accinge a teorizzare, stabilire con chiarezza struttura, potenzialità, limiti e attuali applicazioni di tale tecnologia.
La blockchain è un registro che raccoglie informazioni relative a transazioni, ordinate cronologicamente, e raccolte in unità dette blocchi; da qui il nome blockchain, che letteralmente è tradotto catena di blocchi. Tale registro (ledger) è condiviso, distribuito e decentralizzato: materialmente la blockchain si trova nella sua interezza su più dispositivi contemporaneamente, nonostante ciò è considerata come singola; infine, non vi è una blockchain di riferimento, ovvero centrale, cui gli altri registri si adeguano, bensì vengono registrati i cambiamenti validi di ogni blockchain della rete.
Le transazioni avvengono mediante l’utilizzo di una coppia di chiavi (keys), una pubblica e una privata. Ogni utente della blockchain innanzitutto genera tramite il client della blockchain una chiave privata e una pubblica. Di norma la chiave pubblica viene utilizzata per criptare, e quella privata per decriptare, in tal modo si ha la certezza che nessuno se non il destinatario, titolare della chiave privata, può accedere ai dati decriptati. Se invece si usa la chiave privata per criptare e quella pubblica per decriptare, si certifica che un particolare soggetto, detentore della chiave privata, ha inviato i dati: tale è la cosiddetta firma digitale.
4.2. I Bitcoin
La prima e più celebre applicazione della tecnologia blockchain è quella di registro delle transazioni della criptovaluta (o token, letteralmente gettone) Bitcoin. I Bitcoin non esistono come dati a sé stanti, ma meramente come valori di cui la blockchain tiene memoria. Risulta necessario, per la trattazione della blockchain, delineare i tratti fondamentali della tecnologia Bitcoin.
Ogni detentore di Bitcoin possiede un indirizzo pubblico (wallet address), derivato dall’hashing della chiave pubblica prima citata. L’hashing è una pratica crittografica che assegna a dei dati di dimensione arbitraria una stringa binaria di dimensione fissa; peculiarità del procedimento è la impossibilità di procedere a ritroso: conoscendo un hash non si può risalire ai dati originari. L’indirizzo ricavato tramite hashing potrebbe per collisione coincidere con uno già esistente, essendo la stringa hash finita in grandezza. In questo caso due soggetti avrebbero accesso agli stessi fondi; tuttavia, tale probabilità è tanto minima da non essere al momento considerata un rischio o vulnerabilità nella rete Bitcoin, tanto che si usa dire nell’ambiente «È più probabile che la Terra venga distrutta entro i prossimi 5 secondi che una collisione avvenga nei prossimi 1000 anni».
Dunque si può procedere ad analizzare il cuore della blockchain, ovvero la struttura delle transazioni. Esistono diversi tipi di transazioni. Si provvederà a delineare le caratteristiche principali delle più comuni.
4.3. Transazione Pay-To-PubKeyHash (P2PKH)
La transazione P2PKH è la transazione mediante il quale un soggetto A trasferisce a un soggetto B la disponibilità unità di Bitcoin, dacché è già stato precisato che non viene trasferita materialmente la moneta, bensì la possibilità di spenderla.
Il grafico sulla sinistra indica nel vettore vin due input, corrispondenti a fondi disponibili ricevuti da soggetti terzi, pronti per essere spesi. Gli output compresi nel vettore vout fanno invece riferimento a ciascuno dei relativi input e contengono informazioni sull’indirizzo di uno o più destinatari. Dunque viene precisata la provenienza dei bitcoin di cui si trasferisce la disponibilità, e il destinatario di tale trasferimento.
Nel momento in cui il soggetto A invia i soldi, viene creato un nuovo input CTxIn (riquadro sulla destra) con uno script (ScriptSig) contenente la firma digitale della transazione da cui vengono prelevate le somme e la chiave pubblica di A. Tale chiave pubblica consente a B di decodificare la transazione ricevuta accertando che il soggetto che invia la somma è il vero proprietario di questa; difatti, in tal modo vi è la possibilità di controllare l’autenticità della firma digitale e di conseguenza la catena di proprietà delle transazioni. L’ulteriore campo prevout fa riferimento all’hash della precedente transazione, dove n invece si riferisce all’output specifico della stessa.
Sostanzialmente A firma l’assegno ricevuto per poi girarlo tramite la seconda parte dello script.
Viene altresì creato un output CtxOut con uno script (ScriptPubKey) contenente nValue, che precisa l’ammontare da inviare a B e l’hash della chiave pubblica di B, ossia l’indirizzo Bitcoin, o wallet address, sul quale riceverà il pagamento. Così il procedimento è concluso, la transazione è avvenuta.
Nel momento in cui B decide di inviare a propria volta i fondi così ricevuti, dovrà fornire nello ScriptSig della nuova transazione la propria chiave pubblica (il cui hash deve coincidere con l’indirizzo fornito nello ScriptPubKey della transazione da cui attinge), hash della precedente transazione e la relativa quantità ricevuta.
La particolarità di questa transazione è che A firma lo ScriptSig, che è relativo alle transazioni da cui si attinge, ma non lo ScriptPubKey, che invece indica a chi è indirizzato il pagamento e la relativa somma.
4.4. Double-spending e attacco del 51%
Ipotizzando l’esistenza di un soggetto C che volesse rubare (ergo avere la capacità di spendere) i soldi destinati a B, questi dovrebbe modificare lo ScriptPubKey della transazione di A inserendo il proprio indirizzo. Affinché ciò possa avvenire lecitamente, lo ScriptSig della nuova transazione di C (C che spende i fondi giunti da A) deve riportare una chiave pubblica il cui hash sia esattamente quello contenuto in ScriptPubKey, altrimenti la transazione verrebbe rigettata dalla rete. C dovrebbe creare a questo punto una nuova transazione fasulla da inserire all’estremità della blockchain, e far in modo che questa venga validata. Di norma la transazione valida è quella avvenuta per prima, tuttavia il processo di validazione delle transazioni prevede che ad ogni livello della catena possa esistere un solo blocco valido. C dovrebbe poter possede il 51% della potenza di calcolo della rete per forzare la validazione della propria transazione fasulla, o altrimenti falsificare l’intera blockchain. A tal proposito bisogna sottolineare che le transazioni vengono controllate e validate dai cosiddetti miners. Uno dei problemi teorici risolti dalla blockchain è quello del double-spending, ossia della doppia spesa delle medesime unità di bitcoin: tutte le transazioni e blocchi vengono ordinati cronologicamente, e risulta valido l’ente primo dal punto vista cronologico.
4.5. Protocollo Proof-Of-Work
A quelli già visti si aggiunge un ulteriore sistema di protezione, teorizzato per affrontare il Problema dei Generali Bizantini[17], che comporta la concreta impossibilità da parte di uno o più nodi manomessi di alterare l’intera rete. La soluzione a tale problema si è avuta tramite l’implementazione del protocollo Proof-Of-Work,[18] adottato dai miners, derivante dal sistema antispam Hashcash. La rete bitcoin è strutturata in modo da fornire un blocco di transazioni valido ogni 10 minuti, calibrando la difficoltà delle operazioni di risoluzione del problema in modo da farla coincidere con tale intervallo temporale. Semplificando con un esempio: un soggetto che intenda alterare una transazione, magari intestando il proprio indirizzo come destinatario dei fondi, dovrà alterare tutti i blocchi precedenti, essendo le transazioni concatenate da un punto di vista logico, altrimenti la transazione verrebbe semplicemente rifiutata dalla rete. Noi sappiamo che per creare un blocco (valido o contraffatto che sia) ci vogliono all’incirca 10 minuti, e ciò rende impraticabile tale forma di attacco; durante il lasso di tempo necessario per alterare tutta la blockchain altri blocchi validi verranno scoperti e aggiunti, e il falsificatore non potrà mai compiere la sua operazione in tempo. Ipotizzando invece la falsificazione del blocco più recente di una catena, dunque, facendo in modo che esistano due blocchi derivanti dallo stesso blocco precedente, il falsificatore dovrebbe possedere oltre il 50% della potenza computazionale della rete (la potenza è detta hashrate e si esprime in hash al secondo) per far in modo che la blockchain che si basa sul blocco contraffatto prosegua. Difatti, la rete è strutturata in modo che la blockchain più lunga, ovverosia con il valore di difficoltà maggiore sia quella su cui tutti i nodi si orientino, dunque non basterà creare molti blocchi con difficoltà bassissima per fare passare tutti i nodi su tale biforcazione della blockchain. Il fenomeno dei blocchi orfani è un evento raro che si verifica quando due miners forniscono due soluzioni valide contemporaneamente: nel giro di pochi blocchi solo una delle estremità della biforcazione continuerà, essendo matematicamente una destinata ad essere più lunga dell’altra.
Coloro che svolgono le operazioni Proof-of-Work sono i miners, che fungono da motore del sistema, svolgendo operazioni di hashing di tutte le transazioni (creando un merkle root di tutte le transazioni) comprese nel blocco, insieme con l’hash del blocco precedente.[19] In questo modo si crea una catena per cui non può essere falsificata una singola transazione. Il regime di consensus dei nodi alla base della rete e il sistema proof work rende la rete massimamente affidabile e resiliente ad attacchi esterni. Per i miners è prevista una ricompensa per ogni blocco trovato, la transazione che aggiudica a un soggetto tali ricompense è dette transazione coinbase.
4.6. Transazione Coinbase
La differenza tra la transazione P2PKH e coinbase è la stessa che figura tra l’acquisto a titolo originario e quello a titolo derivativo. Nella transazione coinbase i bitcoin vengono creati: la loro struttura comprende negli input un valore casuale che può essere utilizzato dai miners come nonce,18 e il valore null nel campo prevout, non essendoci una transazione precedente cui far riferimento. La ricompensa per blocco trovato diminuisce con il passare del tempo, essendo il limite massimo di Bitcoin generabili 21 milioni.
5. Modello di voto elettronico mediante blockchain
5.1. Modelli preesistenti di votazione tramite blockchain, principi su cui si basa il modello oggetto di trattazione
Conclusa la breve ma necessaria spiegazione sul meccanismo di funzionamento della blockchain, si può procedere a delineare il modello di votazione oggetto di trattazione. È doveroso riferire la presenza di preesistenti modelli di voto con blockchain, che tuttavia o si affidano totalmente a soggetti terzi, la cui bontà è verificabile entro determinati limiti, come nel modello Follow My Vote[20], o implementano la tecnologia blockchain in maniera parziale, rendendone vana la portata innovativa, quale il sistema sperimentale TIVI[21] della stessa Smartmatic.
Al contrario il modello dovrà: essere idoneo per essere utilizzato per votazioni di matrice pubblicistica (politiche, amministrative, referendum) a livello nazionale regionale e comunale, di conseguenza totalmente indipendente da soggetti terzi; essere ispirato alla massima trasparenza possibile in ogni suo aspetto, purtuttavia rendendo totalmente impossibile per il singolo soggetto votante rintracciare il proprio voto; infine, essere più sicuro dei precedenti modelli di voto.
5.2. Codice sorgente pubblico, blockchain privata
Il codice sorgente di tutti i componenti del prototipo debbono essere open source. La circostanza che il funzionamento intrinseco dei programmi sarà di dominio pubblico non compromette la sicurezza globale della rete, in quanto il sistema sarà strutturato in maniera tale da rendere impraticabile ogni attacco dall’esterno sul funzionamento dei programmi.
La blockchain deve essere privata. Ciò significa che possono essere nodi completi, ossia capaci di validare le transazioni, esclusivamente quelli autorizzati da un preesistente nodo detenente una posizione di autorità, ovvero da un gruppo di nodi già autorizzati (consortium blockchain). La decentralizzazione è interna tra tutti i nodi, ma comporterà una chiusura nei confronti di enti esterni. Dunque, anche possedendo i codici sorgenti di blockchain, client utilizzati per effettuare materialmente la votazione e programmi che trasmettono la votazione dal terminale preposto al nodo, non sarà possibile dall’esterno poter interferire decidendo arbitrariamente di diventare un nodo della rete.[22] Essendo solo determinati soggetti (i nodi), coloro in possesso della blockchain, questa non sarà analizzabile se non direttamente dai terminali sui cui copia di questa è conservata. Al termine della votazione viene consentito automaticamente il libero accesso da parte di tutti alla blockchain, cosicché ognuno possa controllare anche autonomamente i risultati della votazione. Ogni blocco deve contenere anche indicazione specifica del nodo che l’ha scoperto, in modo da poter confrontare gli estremi del nodo (che in questo prototipo coincide con il miner) con i log files (registri di eventi) generati automaticamente dai nodi, i quali devono essere autonomamente caricati online senza necessità di intervento umano. I nodi devono essere dotati di batterie e generatore di emergenza per affrontare ogni eventuale asperità, i relativi monitor devono essere ripresi e trasmessi in diretta online, in modo da garantire massima trasparenza. I tecnici incaricati di preparare i nodi prima del nodo non possono essere gli stessi che presteranno assistenza durante lo svolgimento della votazione, che a loro volta dovranno essere soggetti diversi da quelli incaricati di terminare le operazioni dei nodi. La componente umana, per ovvi motivi, non è totalmente eliminabile, ma deve essere gestita in modo da garantire la massima trasparenza e sicurezza.
5.3. Ipotesi oggetto di trattazione e struttura organizzativa della rete: nodi, verifica dei voti, terminali e client
A tal punto, bisogna specificare il complesso di elementi fisici che costituiscono l’essenza della rete. Si prenderà in ipotesi il caso di un referendum su base nazionale con un quesito per il quale è prevista una scelta di Sì/No. Un nodo per Comune è ben più che sufficiente per affrontare il flusso di dati, tuttavia per esigenze di ridondanza e sicurezza potranno essere disposti due nodi per Comune.[23] I nodi, previamente autorizzati ad essere tali da un nodo centrale, ospiteranno l’intera blockchain e valideranno le transazioni mediante un sistema Proof-Of-Work. I nodi consistono materialmente in computer dislocati presso i municipi. Nei seggi elettorali vi saranno solo dei terminali che non ospiteranno la blockchain ma collegati ai nodi che la ospitano, e su cui verranno effettuate materialmente le votazioni tramite un apposito client.
5.4. Capacità di votare
Primamente, deve essere verificata la possibilità del soggetto di votare. Il modello teorizzato presuppone l’uso di una tessera elettorale elettronica dotata di chip criptato, contenente un numero univoco di identificazione, usato, insieme ad un valore casuale, per creare una coppia di chiavi. Tali non devono essere visualizzabili e conoscibili dal soggetto che esperisce la procedura di voto, per ragioni di sicurezza. Con una normale tessera elettorale si potranno senza problemi prendere misure precauzionali per far in modo che un soggetto possa compiere una sola votazione, senza tuttavia porsi al riparo da abusi di eventuali membri del seggio elettorale, che potrebbero compiere votazioni multiple approfittando del loro ruolo di vigilanti. Seppur telecamere e forze dell’ordine possono fungere da deterrente a tali condotte criminali, un sistema più raffinato dovrebbe impedire ab origine la possibilità che possano essere espressi liberamente voti non riferiti a soggetti votanti. Ciò può avvenire solamente per uso della tessera elettorale elettronica, tramite una automazione della procedura di verifica della disponibilità e capacità di votare.
5.5. Controllo
Come già detto, la coppia di chiavi può essere generata a partire da un valore arbitrario utilizzato come seed. Adoperando una stringa unica contenuta in ogni tessera elettorale elettronica (ipotesi ad hoc), è possibile generare una coppia di chiavi esclusivamente riferite al soggetto votante. In tal modo, il client per il voto verificherà che lo stesso seed è già stato adoperato per generare una coppia di chiavi da cui è partita una transazione (voto) valida e, dunque, impedirà di generare ulteriori coppie dallo stesso seed. Facendo in modo che al seed venga aggiunto un valore casuale,[24] un soggetto non potrà risalire alla coppia di chiavi generata solamente conoscendo il seed: deve poter conoscere anche il valore casuale aggiunto, che deve non essere memorizzato nei terminali adoperati per votare.
Le ipotesi si basano sull’assunto secondo il quale il soggetto votante non deve poter visualizzare le informazioni relative alle sue chiavi e al suo indirizzo; dunque, l’interfaccia del client che gestirà le materiali operazioni di voto dovrà essere strutturata in modo da secretare tali dati.
5.6. Confusione della cronologia delle transazioni e conclusione delle operazioni di voto
La blockchain è un registro contenente transazioni ordinate cronologicamente. La possibilità di associare una transazione ad un soggetto per via dell’ora precisa in cui questa è avvenuta è un rischio che deve poter essere superato da questo modello, per poter essere funzionale e, a tal proposito, è previsto un meccanismo di miscelazione dell’ordine delle transazioni. Nel momento in cui un voto viene espresso, il sistema verifica la astratta idoneità e validità della transazione, senza tuttavia inserirla, lasciandola in sospeso. Quando tre[25] transazioni potenzialmente valide (in quanto non ancora inserite) sono avvenute su uno stesso terminale, o complessivamente sull’insieme di terminali del seggio, il sistema in maniera casuale prevede quale delle tre transazioni inserire: tale transazione avverrà regolarmente, mentre le altre resteranno in sospeso. Conclusa l’operazione di voto, il client provvederà a memorizzare sulla tessera elettorale elettronica l’avvenuto esercizio del diritto e a distruggere la coppia di chiavi relativa alla transazione inserita tra le tre, liberando la schermata in modo da permettere la fruizione della macchina da parte degli altri soggetti.
Finite le operazioni di votazione, ergo al raggiungimento di una determinata ora trigger, i terminali provvederanno a inviare le rimanenti due votazioni idonee non inserite nel sistema, dando così termine ufficiale alle operazioni di voto. Appena scoperto il blocco contenente le ultime transazioni,[26] automaticamente i nodi renderanno pubblica la propria blockchain, permettendo a tutti di controllare i risultati della votazione. Secondo questo modello, l’ordine cronologico delle transazioni viene totalmente rimescolato, creando un ulteriore strato di sicurezza. Del resto, la blockchain richiede solamente che le transazioni siano in ordine cronologico, non necessariamente secondo un dato ordine.
5.7. Modelli di blockchain utilizzabili:
Tuttora esistono moltissimi tipi di blockchain, ognuno con delle sue particolarità. Si provvederà ad illustrare i due tipi che maggiormente risultano adeguati per il modello oggetto di trattazione.
5.7.1. Modello a indirizzi multipli e token singolo
Ipotizzando l’oggetto delle transazioni sia una criptovaluta sulla falsariga di Bitcoin, queste devono avvenire con unità non divisibili della valuta[27] e senza commissioni (fee),[28] per assicurare innanzitutto l’integrità del risultato e per semplificare la consultazione (se 100 persone hanno votato per il Sì, sull’indirizzo pubblico relativo al Sì, da tutti consultabile online, apparirà una riserva di 100 unità, corrispondenti a quelle spese per votare). Il risultato viene conteggiato tenendo conto delle singole transazioni avvenute verso quell’indirizzo, accertando che nessun soggetto abbia inviato più unità verso un singolo indirizzo (se un indirizzo ricevesse 60 voti e risultassero 40 transazioni, ciò significherebbe che soggetti hanno illegittimamente votato più volte). In condizioni di regolarità, verificare semplicemente l’ammontare di unità detenuto da un dato indirizzo può dare uno specchio accurato dei risultati delle elezioni.
Un soggetto, una volta accreditato della unità di valuta da spendere per votare, deve poter scegliere di terminare l’operazione di voto senza spenderla. In tal modo, le unità non spese equivarranno a schede bianche, ma verrà altresì registrata la sua partecipazione alla votazione sulla scheda elettorale elettronica.
5.7.2. Modello a singolo indirizzo e token multipli
Una blockchain può ospitare anche una pluralità di token, permettendo di associare ciascun token alla relativa scelta da esprimere. Dunque, coesisteranno nell’ipotesi formulata due token A e B, rispettivamente associati alle opzioni Sì e No. L’indirizzo del votante, nel momento in cui egli avrà confermato la propria scelta, verrà accreditato, tramite transazione coinbase, di una unità del relativo token, che verrà immediatamente trasferita all’indirizzo assegnato al quesito oggetto di votazione. Ferme restando le precauzioni sulla indivisibilità dell’unità di qualsivoglia token e sull’assenza di fee, i risultati della votazione potranno essere verificati controllando le quantità differenti di token spesi versi l’indirizzo destinatario delle votazioni.
Deve essere previsto, in questo modello, un token e un indirizzo per le schede bianche, mediante il quale l’elettore non esprime alcuna preferenza.
In entrambi casi, le operazioni di accredito e spesa verso l’indirizzo scelto debbono avvenire in background, anche mentre si procede anche con altre votazioni.
5.8. Opzionale – Indirizzo furtivo per il mittente
Le transazioni devono essere distinguibili l’una dall’altra, ma non riferibili al singolo soggetto votante. A tal proposito è di ispirazione il modello adottato dalla criptovaluta Monero. In Monero le transazioni vengono firmate mediante un protocollo chiamato Ring Signature,[29] il quale rompendo il nesso tra output e input in una transazione renderà irrintracciabile il mittente. Dunque, potranno figurare come mittenti soggetti che invece non lo sono, e, per quanto tale meccanismo sia idoneo in un circuito il cui unico scopo è la totale irrintracciabilità, sarebbe deleterio in un sistema in cui deve essere ben chiara la cronologia di transazioni di ogni indirizzo. Le transazioni vengono ricevute da stealth address,[30] i quali consistono in indirizzi utilizzabili una sola volta, il cui scopo è nascondere l’identità del destinatario. Allo stesso modo, nel modello teorizzato deve essere ben identificabile l’indirizzo ricevente, essendo questo coincidente con una scelta del quesito o con il quesito stesso, a seconda del tipo di blockchain adottata. Il meccanismo dello stealth address, se invece mutuato sull’indirizzo mittente, renderebbe irrintracciabile la transazione (sulla blockchain deve apparire l’indirizzo stealth come mittente affinché la portata precauzionale di tale misura sia effettiva). Tale misura comporta un guadagno di sicurezza su un lato critico, ossia la impossibilità da parte del votante di conoscere il proprio indirizzo, ma, dato che uno stealth address per sua natura può essere utilizzato solo una volta, si perderebbe la certezza che da un indirizzo non siano stati inviati più voti, essendo creato un nuovo stealth address per transazione.
Una costruzione attenta dell’interfaccia del client dovrebbe essere in grado scongiurare la possibilità da parte del votante di conoscere il proprio indirizzo, dunque, l’apporto dello stealth address deve considerarsi come mera caratterista da poter integrare come extrema ratio.
Al termine della votazione, una volta che la blockchain è stata resa pubblica, tramite appositi programmi chiamati blockchain explorer sarà possibile consultare la blockchain e verificare, contando le transazioni verso determinati indirizzi, il numero dei votanti, e quanti voti assegnati a nessun soggetto. Il modello ha cercato di porre rimedio in maniera efficace a quelle che sono non vulnerabilità, bensì caratteristiche della tecnologia blockchain, tramite coordinamento del sistema di votazione con la titolarità esclusiva di una tessera elettorale elettronica. Il sistema sarebbe stato teorizzabile anche senza uso di tessere elettorali elettroniche, ma a scapito non solo della sicurezza stessa del modello, ma anche della sua semplicità e chiarezza. In tal modo, invece, è garantito innanzitutto uno standard di sicurezza più elevato non solo del voto elettronico finora sperimentato in Italia, ma anche del modello tradizionale con schede cartacee. Ciò è possibile grazie ad un sapiente uso delle ultime tecnologie, coordinato con il totale rispetto dei precetti Costituzionali ed Europei in materia di diritto di voto, dacché l’avvento degli strumenti informatici deve permettere una tutela più efficace e pregnante di tali principi, quando al contrario si assiste al sacrificio degli stessi in nome di una ingiustificata primazia dell’evoluzione tecnologica, sicché è il diritto che risulta essere asservito alla tecnologia, e non il contrario.
[1] Fu prevista la raccolta di voti omologhi cartacei, ma tali schede erano prese in custodia dalla Prefettura e non utilizzabili come riscontro per i risultati della votazione elettronica.
[2] http://normelombardia.consiglio.regione.lombardia.it/NormeLombardia/Accessibile/main.aspx?exp_coll=lr002015022300003&view=showdoc&iddoc=lr002015022300003&selnode=lr002015022300003
[3] http://www.camera.it/leg17/126?tab=1&leg=17&idDocumento=185
[4] http://www.anci.lombardia.it/documenti/6860-Regolamento%20Regionale%20n.%203%20del%2010%20febbraio%202016.pdf
[5] https://rm.coe.int/168059bdf6
[6] http://www.regione.lombardia.it/wps/wcm/connect/a12fdd40-a5c5-4cba-be5a-aabae7c4e8bb/Regione-Lombardia-Code-Review-SW-Voto-Sintesi-Executive-2017_10_06.pdf?MOD=AJPERES&CACHEID=a12fdd40-a5c5-4cba-be5a-aabae7c4e8bb
[7] La BVTech è società incaricata di gestire le operazioni di supporto tecnico e informatico durante le operazioni di voto. La richiesta è stata così sintetizzata «Al fine di rendersi conto delle effettive dinamiche operative di esecuzione della commessa, nonché delle problematiche affrontate e della efficienza operativa complessiva, abbiamo richiesto il registro di tutte le richieste di assistenza ricevute dalla società BVTech SpA, sub-fornitore della SmartMatic per erogare servizi di HelpDesk ai tecnici e digital assistant prima e durante le operazioni di voto.» (https://www.hermescenter.org/le-richieste-foia-sul-voto-elettronico-lombardia-2017). I registri delle richieste di assistenza, difatti, permettono di capire quali siano state precisamente le problematiche sperimentate durante le operazioni di voto.
[8] http://www.manilatimes.net/election-machines-tampered/307497/
[9] http://www.manilatimes.net/filipino-people-helpless-untrustworthiness-comelec/307702/
[10] https://wikileaks.org/plusd/cables/06CARACAS2063_a.html
[11] http://www.nytimes.com/2006/10/29/washington/29ballot.html
[12] http://articles.chicagotribune.com/2006-04-08/news/0604080149_1_sequoia-voting-systems-smartmatic-jack-blaine
[13] http://mgpf.it/2017/10/20/referendum-autonomia-lombardia-hacker.html
[14] Traduzione degli stralci della sentenza ripresi da “Finalità e problemi del voto elettronico: le prospettive della sua attuazione in Italia” (A. Gratteri)
[15] https://www.admin.ch/opc/it/classified-compilation/19660262/201608310000/0.103.2.pdf
[16] Roberto Maroni, Presidente della Regione Lombardia, durante la conferenza stampa successiva alla conclusione delle operazioni di voto
[17] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/The-Byzantine-Generals-Problem.pdf
[18] https://www.mail-archive.com/Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo./msg09997.html
[19] Il Block Header contiene, oltre l’hash del blocco precedente e merkle tree, l’indicazione della versione di Bitcoin utilizzata e un valore casuale detto nonce, incrementato durante l’operazione di hashing compiuta dai miner.
[20] https://followmyvote.com/
[21] http://www.smartmatic.com/fileadmin/user_upload/TIVI_FAQ.pdf
[22] L’attacco del 51% può essere portato a termine solo disponendo di più del 50% della potenza computazionale della rete. In uno scenario normale chiunque può validare transazioni e dunque essere parte della potenza computazionale della rete. In una blockchain privata, soltanto alcuni soggetti determinati potranno essere nodi verificatori, dunque viene escluso il rischio che soggetti esterni possano validare transazioni fasulle per modificare i risultati della votazione.
[23] Una struttura per cui i nodi comunali vengono autorizzati dai rispettivi nodi provinciali, che vengono autorizzati a loro volta da quelli regionali, potrebbe sembrare a primo impatto la più coerente e sicura, ma in realtà non fa che inflazionare il sistema con intermediari non necessari, aumentando il rischio che una regione, magari contraria ad un referendum, provveda ad autorizzare nodi non contemplati per preparare un attacco del 51%.
[24] Ad esempio un valore salt, assimilabile al valore casuale nonce di cui già si è discorso
[25] In teoria, è adatto allo scopo un qualunque numero n pari o superiore a due, ma già il tre può creare combinazioni così complesse da rendere irrintracciabile il mittente tramite analisi dei timestamps (data e ora) delle transazioni.
[26] Per precauzione, può essere indicato anche un blocco più distante da quello contenente le transazioni finali. Una volta che la transazione è inserita in un blocco è considerata irreversibile, tuttavia per ragioni precauzionali si considera una transazione totalmente irreversibile solo dopo sei blocchi; data la distanza di dieci minuti tra un blocco e l’altro questo lasso di tempo equivale a un’ora. La blockchain di Ethereum, più moderna e versatile di Bitcoin, prevede un termine di dodici transazioni per avere la massima certezza, che corrispondo all’incirca a tre minuti. In questo modello tuttavia, essendo il rischio di un attacco del 51% bloccato ab origine dalla natura privata della blockchain, la transazione può considerarsi definitiva nel momento in cui il sistema la ritiene idonea ad essere inviata. Essendo i blocchi scoperti a intervalli regolari, può essere prevista la pubblicazione della blockchain anche al mero raggiungimento di una determinata altezza della blockchain, coincidente con il termine delle operazioni di voto.
[27] Le transazioni in Bitcoin avvengono anche per frazioni dell’unità fino all’ottava cifra decimale. È sì ipotizzabile un client mediante il quale la transazione solo per l’importo predefinito di “1”, ma essendo un modello pseudo bitcoin, dovrebbe poter essere possibile inviare solo numeri interi positivi.
[28] Al di sopra di una soglia minima, su ogni transazione viene pagata una commissione, che poi viene accreditata al miner che scopre il blocco in cui tale transazione è contenuta. Non essendoci all’interno di questo modello l’intento di incentivare i miners ad essere onesti tramite emolumenti pecuniari per il servizio svolto, decade la ragion d’essere di tale meccanismo.
[29] Letteralmente “Firma ad anello” https://getmonero.org/resources/moneropedia/ringsignatures.html
[30] Letteralmente “Indirizzi furtivi” https://getmonero.org/resources/moneropedia/stealthaddress.html