Blockchain: dai registri distribuiti e smart contract alla validazione temporale elettronica, il vademecum sulla regolamentazione

Il presente contributo ha come scopo quello di fornire a un neofita della blockchain un kit informativo su questo strumento avanguardistico, illustrandone in maniera sintetica la regolamentazione di base italiana ed europea vigente alla data di pubblicazione.

In questa sede ci limitiamo alla mera normativa civilistica della blockchain come registro distribuito, scevra da ogni applicazione finanziaria, di criptovalute o altro. Al fine di delimitare il perimetro del nostro intervento, di seguito elenchiamo le fonti di cognizione che prenderemo in considerazione:
• Regolamento (UE) 910/2014 del Parlamento e del Consiglio del 23 luglio 2014;
• Decreto Legge n. 135 del 14 dicembre 2018 (c.d. Decreto Semplificazioni);
• Regolamento (UE) 2022/858 del Parlamento e del Consiglio del 30 maggio 2022;
• Decreto Legge n. 25 del 17 marzo 2023 (c.d. Decreto Fintech).

La blockchain è un registro di contabilità condiviso e immutabile che facilita il processo di registrazione delle transazioni e la tracciabilità di beni e servizi in una rete commerciale, fornendo informazioni immediate, condivise e completamente trasparenti , archiviate in un registro immutabile a cui possono accedere solo i membri di rete autorizzati, o chiunque se la blockchain è pubblica (si veda infra).

Una rete blockchain può tracciare ordini, pagamenti, account, produzione e molto altro ancora, con possibilità di visione di tutti i dettagli di una transazione end-to-end , generando così maggiore fiducia. La blockchain è, infatti, il più efficace strumento a oggi esistente per creare affidamento e fiducia tra parti che non si conoscono o si conoscono poco.

A livello normativo, le caratteristiche della blockchain sono definite all’art 8-ter del D.L. n. 135/2018 e agli artt. 41 e 42 del Regolamento UE n. 910/2014.

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” (art. 8-ter, comma 1, D.L. n. 135/2018).

Con la blockchain, in qualità di membro di una rete di soli partecipanti, si può confidare nel fatto che si stanno ricevendo dati accurati e tempestivi e che i propri dati confidenziali saranno condivisi solo con i membri della rete a cui hai specificamente concesso l’accesso. Il consenso sull’accuratezza dei dati è richiesto per tutti i membri della rete e tutte le transazioni convalidate sono immutabili, perché vengono registrate in modo permanente.

Nessuno, nemmeno un amministratore di sistema, può eliminare una transazione, se non in casi e con procedure estremamente particolari.

Ogni volta che avviene una transazione, questa viene registrata come un “blocco” di dati . Queste transazioni rappresentano il movimento di un asset che può essere tangibile (un prodotto) o intangibile (intellettuale). Questo blocco di dati può riportare le informazioni che si desiderano: chi, cosa, quando, dove, quanto e persino termini e condizioni.

Ogni blocco è collegato a quelli che lo precedono e che lo seguono. I blocchi formano una catena di dati man mano che un asset si sposta da un luogo all’altro o cambia il proprietario, attestando l’ora e la sequenza esatte delle transazioni, e collegandosi in modo sicuro tra loro per evitare che uno di essi venga alterato o inserito tra due blocchi esistenti.

Le transazioni sono bloccate tra loro in una catena irreversibile, dove ogni blocco aggiuntivo rafforza la verifica del blocco precedente e quindi dell’intera blockchain. Questo fa sì che la blockchain sia a prova di manomissione, offrendo l’elemento chiave dell’immutabilità, che elimina la possibilità di manomissioni da parte di malintenzionati e crea un registro di transazioni di cui tutti i membri della rete possono fidarsi.

Le reti blockchain possono essere:
a) pubbliche
Una blockchain pubblica è una rete a cui chiunque può accedere e partecipare, come ad esempio Bitcoin.
Gli inconvenienti potrebbero includere la necessità di una notevole potenza di calcolo, poca o nessuna privacy a tutela delle transazioni e scarsa sicurezza (anche se a contrariis si argomenta che più una blockchain è pubblica più è sicura, almeno per certi versi). Queste sono considerazioni importanti per i casi d’ uso aziendali della blockchain.
b) private
Una rete blockchain privata, similmente a una rete blockchain pubblica, è una rete peer-to-peer decentralizzata. Tuttavia, una singola organizzazione governa la rete, controllando chi è autorizzato a partecipare, eseguire un protocollo di consenso e mantenere il registro condiviso.
Una blockchain privata può essere protetta da un firewall aziendale e addirittura essere gestita in hosting on-premise (da remoto).
c) con autorizzazioni
Le attività di business che impostano una blockchain privata generalmente creano una rete blockchain basata su autorizzazioni.
In questo caso si pongono dei limiti relativamente a chi è autorizzato a partecipare alla rete e a quali transazioni può partecipare (i partecipanti devono ottenere un invito o un permesso per partecipare).
Anche le reti blockchain pubbliche possono essere basate su autorizzazioni.
d) consortili
Più organizzazioni possono condividere le responsabilità della gestione di una blockchain. Queste organizzazioni pre-selezionate stabiliranno chi può inoltrare transazioni o accedere ai dati.
Una blockchain consortile è la soluzione ideale per il business in quanto tutti i partecipanti devono essere autorizzati e hanno una responsabilità condivisa per la blockchain.

Per agevolare le transazioni, un set di regole chiamate smart contract (contratto intelligente) viene memorizzato come codice crittografico sulla blockchain.

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” (art. 8-ter, comma 2, D.L. n. 135/2018).

Un contratto intelligente può definire, quindi, le condizioni per i trasferimenti di obbligazioni aziendali, includere le condizioni per l’assicurazione di viaggio da pagare e molto altro ancora, con soddisfazione del requisito della forma scritta per mezzo dell’identificazione informatica delle parti interessate.

Per inquadrare bene il concetto di smart contract è interessante notare che il nome non corrisponde alla sostanza, in quanto essi non sono né intelligenti né contratti veri e propri (almeno da un punto di vista giuridico). Lo stesso Vitalik Buterin, fondatore di Ethereum, si è pentito di aver dato tale definizione e ne ha proposto una differente di “permanent scripts”, sicuramente più aderente alla realtà ma dallo scarsissimo seguito tra il pubblico ormai abituato all’altra.

Ai sensi dell’art. art. 8-ter, comma 3, D.L. n. 135/2018, 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’art. 41 del Regolamento (UE) n. 910/2014.

Nello specifico:
1. alla validazione temporanea elettronica non possono essere negati gli effetti giuridici e l’ammissibilità come prova in procedimenti giudiziali per il solo motivo della sua forma elettronica o perché non soddisfa i requisiti della validazione temporanea elettronica qualificata;
2. una 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; e
3. una validazione temporale elettronica rilasciata in uno Stato membro è riconosciuta quale validazione temporale elettronica qualificata in tutti gli Stati membri.

A norma dell’art. 42 dello stesso regolamento, una validazione temporale elettronica qualificata soddisfa i seguenti requisiti:
1. collega la data e l’ora ai dati in modo da escludere ragionevolmente la possibilità di modifiche non rilevabili dei dati;
2. si basa su una fonte accurata di misurazione del tempo collegata al tempo universale coordinato; e
3. è apposta mediante una firma elettronica avanzata o sigillata con un sigillo elettronico avanzato del prestatore di servizi fiduciari qualificato o mediante un metodo equivalente.

Il 7 maggio 2020 l’Agenzia per l’Italia Digitale (AGID) ha emanato, ai sensi dell’art. 71 del codice dell’amministrazione digitale (“CAD”), le linee guida relative alle best practice di secure design per le architetture basate su registri distribuiti, in conformità ai principi di “Secure/Privacy by Design” (le “Linee Guida”).

Lo scopo delle Linee Guida è l’analisi dei processi, metodi e modelli concernenti la progettazione di applicazioni software sicure, fornendo indicazioni agli attori del settore durante la fase di progettazione e creazione del software, per la modellazione delle minacce e per l’individuazione preventiva di potenziali azioni e procedure volte alla mitigazione delle stesse in conformità con il principio di Secure/privacy by Design .

Nel contesto delle indicazioni contenute nelle Linee Guida, l’AGID ha redatto un apposito paragrafo (nello specifico il paragrafo numero 1.1.1.3 delle Linee Guida) concernente i registri distribuiti (DLT ) o, come specificato nel documento, le tecnologie “più notoriamente [denominate] Blockchain”. Con riferimento alla definizione di DLT, e in aggiunta alla definizione introdotta ai sensi dell’art. 8-ter comma 3 del D.L. n. 135/2018, le Linee Guida specificano che le DLT “sono sistemi informatici che gestiscono dati, transazioni o codici eseguibili (Smart Contracts) in modo il più possibile indipendente da un’autorità centrale attraverso l’utilizzo di data storage distribuito in correlazione con processi crittografici e sistemi decisionali decentralizzati”.

L’ambito di applicazione delle prescrizioni contenute nel documento è esteso alle più svariate applicazioni della tecnologia, ad esempio:

1. sistemi di identità digitale (Self Sovereign Identity);
2. sistemi di certificazione garantita di dati e certificazioni (Verifiable Claims);
3. creazione e gestione di nuovi mercati digitali (vedi i mercati peer to peer di scambio energetico) fino alla creazione e gestione di nuove entità (vedi ad esempio le DAO/DAC Distributed Autonomous Organizations/Corporations).

Preliminarmente, quindi, l’AGID ha ritenuto fondamentale analizzare i profili di integrità, disponibilità e riservatezza dei dati memorizzati in una DLT

• Con riferimento all’integrità dei dati, le Linee Guida specificano che “uno dei fattori fondamentali che assicurano tale caratteristica in una DLT è la struttura a blocchi concatenati attraverso la funzione di hash”. Tuttavia, l’AGID avverte gli operatori che tale caratteristica connaturata alle DLT “di per sé non basterebbe se non fosse affiancata da un adeguato algoritmo di consenso che garantisca l’immediata evidenza di una qualsivoglia modifica di questa struttura in confronto a strutture uguali esistenti nei vari nodi componenti la DLT”.

In altre parole, le Linee Guide riconoscono che la struttura a blocchi delle DLT “amplifica la sicurezza della funzionalità di hash attraverso la concatenazione dei dati”, ovverosia che “la modifica di un blocco in posizione <n> implicherebbe la conseguente modifica di tutti i blocchi successivi fino alla testa della catena”, ma raccomandano agli operatori di settore di considerare quale “fattore critico relativamente all’integrità dei dati […] quello dato dall’algoritmo di consenso”. Pertanto, in relazione alla sicurezza di tali algoritmi, le Linee Guida suggeriscono agli operatori di rispettare le indicazioni fornite nel documento stesso in relazione all’applicazione del principio c.d. “ Secure by Design ”.

• In relazione alla disponibilità dei dati di una DLT, le Linee Guida prescrivono che “è intrinsecamente garantita dall’infrastruttura sottostante: difatti ogni nodo di una DLT (a meno di nodi specifici, normalmente chiamati “light nodes”) detiene una intera copia della struttura dati e quindi l’indisponibilità degli stessi si potrebbe avere solo nel caso in cui tutti i nodi fossero allo stesso istante inattivi”. Pertanto, se da un lato “attacchi che mirino ad un eventuale centro non avrebbero senso in una struttura decentralizzata”, dall’altro un possibile attacco sulla disponibilità dei dati “dovrebbe essere mirato all’intera infrastruttura e quindi avere ad esempio come obiettivo il software di base, al fine di rendere indisponibili le informazioni negandone l’accesso attraverso la modifica della modalità con cui tutti i nodi operano”.

• Rispetto alla riservatezza dei dati, l’AGID ha riconosciuto che varia ampiamente a seconda della specifica tecnologia utilizzata, ad esempio “alcune DLT sono intrinsecamente trasparenti (vedi bitcoin) in quanto chiunque ha accesso a tutte le transazioni fatte da qualsivoglia partecipante e la confidenzialità è demandata all’anonimità dei partecipanti che vengono identificati da un indirizzo generico”.

In tali applicazioni della tecnologia, sarebbe tuttavia più corretto ritenere che le transazioni e i relativi dati siano pseudo-anonimi poiché dall’analisi delle ripetute attività di un indirizzo è possibile risalire all’identità del soggetto persona fisica ovvero giuridica. Invece, alcune DLT con caratteristiche differenti, ovverosia maggiormente orientate all’anonimità dei partecipanti e delle transazioni (ad esempio “Zcash” o “Monero”), comportano che per “un osservatore esterno è praticamente impossibile risalire agli attori parte di una qualsiasi transazione proprio per le tecnologie utilizzate” (ad esempio “ring transactios”, una caratteristica concernente la blockchain Monero).

Pertanto, e “in qualsiasi caso”, le Linee Guida raccomandano agli sviluppatori di tecnologie DLT di “provvedere ad una adeguata gestione della riservatezza dei dati in modo disgiunto dalla gestione dell’infrastruttura: il livello di riservatezza da implementare sarà come al solito legato alla tipologia dei dati e le metodologie le stesse applicate a qualsiasi altra tipologia di data storage”.

• Con specifico riferimento alla sicurezza delle DLT, le Linee Guida analizzano alcuni elementi che compongono la tecnologia per fornire alcune indicazioni operative concernenti lo sviluppo. A tal proposito, il documento dell’AGID prende in considerazione le seguenti caratteristiche delle DLT:
1. rete infrastrutturale peer-to-peer;
2. struttura dati (concatenazione di blocchi);
3. algoritmi di consenso (es. PoW, PoS, etc); e
4. smart contract e logiche dinamiche (e.g. token, DAC/DAO, etc.).

Riguardo l’infrastruttura, l’AGID ritiene che un possibile attacco di “ Distributed Denial of Service ” potrebbe provenire “dall’utilizzo di wallet/accounts per generare grandi numeri di transazioni al fine di rallentare la rete . Un evento del genere, anche se non rappresentante un attacco, è avvenuto nella rete Ethereum all’apparire dello smart contract CryptoKitties: questo smart contract ha raggiunto volumi superiori al 10% dell’intero volume di transazioni della rete, causando un indesiderato rallentamento dell’intera rete”.

• Relativamente alla struttura dati, le Linee Guida correlano il tema con le caratteristiche e il funzionamento dell’algoritmo di consenso, poiché quest’ultimo determina i requisiti per l’introduzione di nuove transazioni (ovverosia dati) nei blocchi della catena di una DLT. Pertanto, l’AGID ha ritenuto opportuno analizzare le due tematiche in modo congiunto.

Per quel che riguarda l’analisi di un algoritmo di consenso, le Linee Guida evidenziano l’applicabilità del teorema CAP, ovverosia che “è impossibile per una DLT garantire contemporaneamente più di due dei seguenti elementi:
1. consistenza : una DLT è consistente quando i fork sono evitati, caratteristica detta anche “finalizzazione del consenso”. In pratica i nodi devono tutti avere la stessa copia del ledger nello stesso momento;
2. disponibilità : una DLT è disponibile se le transazioni generate dai client sono gestite e quindi “committed” (cioè aggiunte alla catena di blocchi); e/o
3. tolleranza alle partizioni : quando una partizione della rete avviene, i nodi autoritativi sono divisi in gruppi disgiunti affinché i nodi di un gruppo non possono comunicare con i nodi di un altro gruppo”.

Considerato che l’algoritmo di consenso è un costrutto sviluppato dal singolo operatore, la responsabilità in relazione alle proprietà summenzionate, e, quindi, il funzionamento della DLT, è in capo allo sviluppatore che decide “quali caratteristiche siano fondamentali per lo specifico caso d’uso”.

Infine, le Linee Guida illustrano alcuni attacchi di cui possono essere vittime le DLT.

Il Regolamento (UE) 2022/858 (“ Regolamento DLT ”) del Parlamento e del Consiglio del 30 maggio 2022, pubblicato nella Gazzetta Ufficiale dell’Unione europea del 2 giugno 2022 istituisce un regime pilota per le infrastrutture di mercato basate sulla tecnologia a registro distribuito (quindi, blockchain), al fine di regolare gli operatori di piattaforme DLT.

Il Regolamento DLT si applica a decorrere dal 23 marzo 2023, fatta eccezione per:
a) gli articoli (i) 8, paragrafo 5, (ii) 9, paragrafo 5, (iii) 10, paragrafo 6, e (iv) 17, che si applicano a decorrere dal 22 giugno 2022; e
b) ’articolo 16, che si applica a decorrere dal 4 luglio 2021.

Il Regolamento DLT si applica solo alle cripto-attività che si qualificano come strumenti finanziari ai sensi della Direttiva (UE) 2014/65 .

La negoziazione di altre cripto-attività è quindi esclusa dall’ambito di applicazione del Regolamento DLT.

Tale atto di recente approvazione introduce una specifica regolamentazione per le infrastrutture di mercato basate su DLT, tra le quali vi rientrano:
• sistemi multilaterali di negoziazione DLT (MTF DLT), intesi come sistemi multilaterali di negoziazione che ammettono alla negoziazione solo “strumenti finanziari DTL” ;
• sistemi di regolamento DLT (SS DLT), ossia i sistemi di regolamento per le operazioni in strumenti finanziari DLT; e
• sistemi di negoziazione e regolamento DLT (TSS DLT), ricomprendenti i soggetti che offrono al contempo servizi di MTF DLT e DLT SS.

Ai sensi dell’articolo 3, gli strumenti finanziari DLT sono ammessi alla negoziazione su un’infrastruttura di mercato DLT o registrati in un’infrastruttura di mercato DLT soltanto se, al momento dell’ammissione alla negoziazione o della registrazione in un registro distribuito, consistono in:
a) azioni il cui emittente ha una capitalizzazione di mercato o una capitalizzazione di mercato provvisoria inferiore a Euro 500 milioni ;
b) obbligazioni, altre forme di debito cartolarizzato (comprese le ricevute di deposito in relazione a tali titoli), o strumenti del mercato monetario, con un’entità di emissione inferiore a 1 miliardo di Euro , esclusi quelli che incorporano uno strumento derivato o che incorporano una struttura che rende difficile per il cliente comprendere il rischio correlato; o
c) quote di organismi di investimento collettivo di cui all’articolo 25, paragrafo 4, lettera a), punto iv), della direttiva 2014/65/UE, il cui valore di mercato delle attività gestite è inferiore a Euro 500 milioni .

Sono escluse dal calcolo della soglia di cui alla lettera b), le obbligazioni societarie emesse da emittenti la cui capitalizzazione di mercato non supera i 200 milioni di Euro al momento della loro emissione.

Autorizzazioni specifiche per gestire MFT DLT, SS DLT E TSS DLT sono espressamente previste agli articoli 8, 9 e 10.

Particolare attenzione desta il paragrafo 4 dell’articolo 7, in base al quale «i gestori delle infrastrutture di mercato DLT garantiscono che tutti i dispositivi informatici e cibernetici relativi all’uso della loro tecnologia a registro distribuito siano proporzionati alla natura, alla portata e alla complessità delle loro attività. Tali dispositivi assicurano la continuità e la costante trasparenza, disponibilità, affidabilità e sicurezza dei loro servizi e delle loro attività, compresa l’affidabilità degli smart contract utilizzati nell’infrastruttura di mercato DLT. Tali dispositivi garantiscono inoltre l’integrità, la sicurezza e la riservatezza di tutti i dati memorizzati dai gestori in questione, nonché che tali dati siano disponibili e accessibili».

I gestori devono disporre, inoltre, di procedure specifiche di gestione del rischio operativo per i rischi derivanti dall’uso della tecnologia a registro distribuito e delle cripto-attività.

Risulta chiaro come l’affidabilità delle piattaforme DLT passerà, inevitabilmente, dalla cybersicurezza degli smart contract .

Lo scorso 18 marzo è entrato in vigore il decreto legge n. 25 del 17 marzo 2023 (pubblicato in Gazzetta Ufficiale n. 65 del 17 marzo 2023, convertito con modificazioni dalla L. 10 maggio 2023, n. 52), recante disposizioni urgenti in materia di emissione e di circolazione di strumenti finanziari in forma digitale secondo quanto disposto dal regolamento (UE) 2022/858.

Per mezzo di tale intervento, il legislatore italiano ha introdotto nel proprio ordinamento le norme necessarie circa l’emissione di azioni e obbligazioni “ tokenizzate ”.

Nel dettaglio, Il decreto ha modificato il decreto legislativo 24 febbraio 1998, n. 58 (il “TUF”, Testo Unico della Finanza), specificando che la nozione di “strumenti finanziari” ricomprende gli strumenti emessi mediante DLT.

Le disposizioni si applicano a diverse categorie di strumenti finanziari e prevede l’emissione, la negoziazione e il regolamento di transazioni di titoli sotto forma di token .

In particolare, il decreto sembra volto a rispondere, tra l’altro, alle seguenti finalità :
• adeguare la regolamentazione finanziaria al fine di consentire l’utilizzo di nuove tecnologie;
• rendere le infrastrutture di mercato DLT interoperabili con quelle del sistema finanziario tradizionale; e
• permettere alle PMI di emettere strumenti di debito direttamente su blockchain.

Il decreto prevede che i registri per l’emissione di strumenti finanziari digitali possano essere detenuti unicamente da soggetti autorizzati a gestire un certo tipo di protocollo, quali:
a. banche, imprese di investimento e gestori di mercati;
b. intermediari finanziari iscritti all’albo di cui all’art. 106 del Testo Unico Bancario, istituti di pagamento, IMEL, gestori di FIA o OICVM e imprese di assicurazione o riassicurazione;
c. altri emittenti non finanziari in relazione esclusivamente a strumenti digitali di propria emissione;
d. altri soggetti individuati con regolamento dalla Consob.

Con riferimento ai soggetti di cui sopra alle lettere c. e d., lo svolgimento di tale attività è destinato esclusivamente a società che hanno determinate caratteristiche ed una specifica forma giuridica .

Fonte: Il Sole 24ORE