La definizione di regole conformi a quelle comunitarie per la validazione temporale degli smart contract nell’ambito di tecnologie blockchain non è ovvia. In questo articolo proveremo a proporre una ipotesi di percorso che comporta scelte innovative. Ci sono infatti alcune opzioni valide per raggiungere l’obiettivo previsto dalla normativa primaria e comunitaria per la validazione temporale elettronica basata sui registri distribuiti (in inglese Distributed Ledger Technology – DLT).
Indice degli argomenti
L’articolo 8-ter
La conversione in legge, con modificazioni, del decreto legge 14 dicembre 2018, n. 135 recante disposizioni urgenti in materia di sostegno e semplificazione per le imprese e per la pubblica amministrazione è stata pubblicata sulla Gazzetta Ufficiale n. 12 del 12 febbraio 2019.
Le nuove regole primarie in tema di DLT, smart contract e validazione temporale elettronica sono contenute nell’articolo 8-ter che, per comodità, si riporta di seguito.
Art. 8-ter. (Tecnologie basate su registri distribuiti e smart contract)
1. Si definiscono « tecnologie basate su registri distribuiti » le tecnologie e i protocolli informatici che usano un registro condiviso, distribuito, replicabile, accessibile simultaneamente, architetturalmente decentralizzato su basi crittografiche, tali da consentire la registrazione, la convalida, l’aggiornamento e l’archiviazione di dati sia in chiaro che ulteriormente protetti da crittografia verificabili da ciascun partecipante, non alterabili e non modificabili.
2. Si definisce « smart contract » un programma per elaboratore che opera su tecnologie basate su registri distribuiti e la cui esecuzione vincola automaticamente due o più parti sulla base di effetti predefiniti dalle stesse. 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.
3. 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 (UE) n. 910/2014 del Parlamento europeo e del Consiglio, del 23 luglio 2014.
4. Entro novanta giorni dalla data di entrata in vigore della legge di conversione del presente decreto, l’Agenzia per l’Italia digitale individua gli standard tecnici che le tecnologie basate su registri distribuiti devono possedere al fine della produzione degli effetti di cui al comma 3.
Validazione temporale elettronica
In questa sede si propongono delle ipotesi realizzative per quanto stabilito nel comma 3 in materia di validazione temporale elettronica.
Il regolamento al quale fa riferimento la legge italiana è il ben noto eIDAS e quindi andiamo subito ad analizzare cosa si stabilisce nell’articolo 41 di questo regolamento.
Nel regolamento eIDAS la validazione temporale elettronica è definita come “dati in forma elettronica che collegano altri dati in forma elettronica a una particolare ora e data, così da provare che questi ultimi esistevano in quel momento”.
La definizione totalmente neutra sul piano tecnologico è certamente un vantaggio notevole perché consente di fare scelte vincolate solo ai principi normativi.
I requisiti per la validazione temporale elettronica qualificata
Peraltro solo la validazione temporale elettronica qualificata gode della presunzione di accuratezza della data e dell’ora che indica e di integrità dei dati ai quali tale data e ora sono associate (articolo 41, comma 2 del regolamento eiDAS). Considerando il rango normativo comunitario, superiore a quello nazionale è opportuno che AgID chiarisca nei previsti provvedimenti a suo carico il contesto di riferimento.
Nel caso si scelga di operare con fattispecie qualificate, si deve applicare l’articolo 42 del regolamento eIDAS che stabilisce i requisiti per la validazione temporale elettronica qualificata.
Il requisito cruciale da applicare è quello che la validazione temporale qualificata si basa su una fonte accurata di misurazione del tempo collegata al tempo universale coordinato ed è apposta mediante una firma elettronica avanzata o sigillata con un sigillo elettronico avanzato del prestatore di servizi fiduciari qualificato o mediante un metodo equivalente.
A questo punto è indispensabile comprendere come collocare questi requisiti nelle architetture dei registri distribuiti.
Il blocktime
Possiamo utilizzare il concetto scientifico/filosofico di blocktime (Melanie Swan, 2016).
Il blocktime è definito come intervallo temporale atteso tra due blocchi consecutivi, o “regime temporale di registri crittografici e smart contract; il tempo è specificato in unità basate sulla approvazione temporale dei blocchi e non minuti o ore come il tempo umano o variabili come ‘il parco chiude con il buio’ “.
La definizione è molto affascinante, condivisibile e perfettamente contestuale al fatto che i registri distribuiti sono composti da blocchi ed il tempo è collegato al metodo di consenso che viene applicato sulla base della tipologia di registri distribuiti che si stanno utilizzando.
In particolare, il blocktime di due grosse reti blockchain, Bitcoin e Ethereum, sono rispettivamente di circa 10 minuti e 17 secondi.
Questi due numeri sono il risultato del tempo necessario alla verifica e propagazione del nuovo blocco in tutta la rete.
Diventa quindi applicabile un modello di DLT che utilizzi la prova di lavoro (Proof of Work) o altri meccanismi di consenso per validare la transazione.
Ovviamente non possiamo considerare un tempo preciso al secondo per il calcolo e previsione di blocchi futuri visti gli oneri standard di validazione e propagazione dell’informazione sul sistema dei registri distribuiti, però è ovviamente possibile certificare le marche temporali precise dei blocchi già elaborati e propagati, in quanto ogni blocco contiene un campo dati “time” riportante il maniera accurata il momento di generazione esempio il “time” del Genesis Block di Bitcoin è 1231006505 in Unix Time .
Creazione di un timestamp su blockchain Bitcoin
L’operazione di creazione di un timestamp su blockchain Bitcoin, per esempio, calcola l’hash SHA256 dei dati originali da validare, vi concatena una stringa randomica “nonce” lunga 128 bit per mantenere la privacy e ricalcola l’hash SHA256, spedendo questo valore unico a servizi di server specifici di calendario, questo genera un primo file .ots, ma esso risulta ancora incompleto perché non contiene il record del DLT.
Una volta che questo hash viene inserito in una transazione e viene quindi messo nel DLT, il file .ots viene aggiornato con il riferimento al blocco in cui la transazione viene inserita.
In fase di verifica l’utente necessita sia il file originale che il file .OTS per verificare il timestamping effettuato precedentemente, operazione effettuabile anche in assenza di terze parti in caso l’utente abbia un nodo Bitcoin aggiornato in esecuzione in locale.Un metodo noto flessibile e gestibile in ogni architettura è quello che propone open timestamps.
Gestione runtime e esecuzione di uno smart contract
Stesso ragionamento per gli smart contract che sono nati nell’ambito di tipologie di applicazioni decentralizzate con un’impronta di “capacità computazionale distribuita”.
Gli smart contract sono stati sviluppati e si sono evoluti nell’ambito di Ethereum.
Uno smart contract opera mediante la “trasposizione” in algoritmo e conseguente codice informatico di un contratto. In questo modo si verificano automaticamente le condizioni definite e il loro avverarsi. Ne seguono azioni o disposizioni per eseguirle dopo ogni passaggio di verifica delle condizioni predette. In pratica lo smart contract è uno script che applica sia le clausole concordate sia gli scenari nei quali devono verificarsi. Poi si esegue in modo automatico nel momento in cui i dati reali relativi a quanto in esame corrispondono a condizioni e clausole concordate.
Quindi per la gestione runtime dell’esecuzione dello smart contract risulta cruciale un sistema di temporizzazione cadenzato dalla generazione dei blocchi, i quali non contengono soltanto transazioni ma anche gli stati di una macchina virtuale decentralizzata (EVM) che si occupa dell’allocazione delle risorse di calcolo e dell’esecuzione stessa.
Validazione temporale elettronica di uno smart contract
A parte Ethereum sono numerosi i DLT che possono elaborare smart contracts. Quindi la validazione temporale elettronica deve essere individuata negli specifici meccanismi realizzati che comunque saranno basati sempre basandosi su una transazione che dovrà essere inserita nel DLT, e che quindi dovrà passare per tutto il meccanismo di code di attesa e di fee di transazione. Il tempo necessario per questa operazione è prevedibile statisticamente ma non costituisce una misura certa di tempo.
I meccanismi utilizzano la rete dei Bitcoin come notaio temporale quindi il tempo di validazione è elevato o costoso (mediamente decine di minuti).
Trovando dei processi di sviluppo appositi che tengano conto delle problematiche legate al blocktime è possibile utilizzare un DLT permissionless per la marcatura temporale, considerando che le caratteristiche richieste citate nella direttiva comunitaria sono pienamente rispettate una volta gestita adeguatamente la variabile costituita dal tempo di generazione dei blocchi.
Qualificare sistemi di DLT permissioned (ad accesso controllato) non è impossibile anzi è una scelta più semplice e richiede meno sforzi organizzativi da parte di AgID e Accredia rispetto a una dei DLT permissionless.
L’enorme vantaggio è che questa validazione qualificata è riconosciuta nel mercato interno comunitario, ma quanto tutto questo risulta davvero diverso da un ente fiduciario centralizzato di terze parti?
Partecipa alla community