L'Autorità Garante della Concorrenza e del Mercato, in data 26 luglio, ha autorizzato con condizioni…
Commento in materia di Blockchain e Smart contract alla luce del nuovo Decreto Semplificazioni
Breve commento alla legge 11 febbraio 2019, n. 12, di conversione 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
di
Chantal Bomprezzi
Introduzione
È dell’11 febbraio scorso la legge n. 12 di conversione 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.
La legge, che al suo interno contiene la disciplina di argomenti eterogenei, ha attirato l’attenzione della cronaca per l’aggiunta di un articolo 8-ter rubricato “Tecnologie basate su registri distribuiti e smart contract”, il quale provvede a definire le tecnologie basate su registri distribuiti e gli smart contracts, ed a conferirvi alcuni effetti giuridici.
Trattasi di un tema particolarmente in voga a partire dagli ultimi anni, legato ai cospicui e costantemente crescenti investimenti in blockchain – un particolare tipo di tecnologia basata su registro distribuito – e nelle sue svariate applicazioni, dalle criptovalute agli smart contracts.
A fronte di tale successo, l’Unione europea si è mobilitata per intraprendere un percorso volto all’approfondimento della tecnologia al fine di pervenire ad un’opportuna sua regolamentazione. Si rammenta, in particolare, l’istituzione ad opera della Commissione europea, nel febbraio 2018, di un Osservatorio e Forum Blockchain europeo, la firma, in data 10 aprile 2018, di una Dichiarazione volta ad avviare una Partnership sulla Blockchain da parte di un consistente numero di Stati membri (a cui se ne sono poi aggiunti molti altri, tra cui da ultimo l’Italia il 27 settembre 2018) e la Risoluzione del Parlamento europeo del 3 ottobre 2018 sulle tecnologie di registro distribuito e blockchain.
L’Italia non è rimasta indietro e, dopo un iniziale stralcio della disposizione dal decreto, con un emendamento a firma dei senatori del Movimento 5 Stelle Patuanelli, Santillo e Grassi, la norma è stata reintrodotta con alcune modifiche e con l’aggiunta di un comma sugli smart contracts. Segue un breve commento dell’art. 8-ter.
La definizione di “tecnologie basate su registri distribuiti”
Il comma 1 dell’art. 8-ter fornisce una definizione di “tecnologie basate su registri distribuiti” alla stregua di “tecnologie e 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”.
La definizione rimanda evidentemente alle cd “distributed ledger technologies” (o DLT), che si contrappongono alle classiche architetture client-server. Mentre nelle seconde le voci del registro sono detenute centralmente, le DLT prevedono la loro replica in una serie di devices, denominati “nodi”, che si sincronizzano periodicamente. L’aggiornamento dei dati ivi inclusi, in assenza di un unico centro di gestione, avviene secondo regole predeterminate, o “meccanismi di consenso condiviso”. Le DLT assicurano una maggiore resistenza a manipolazioni esterne rispetto a sistemi centralizzati.
La blockchain rientra tra le DLT. Essa si contraddistingue per il fatto che i dati vengono raggruppati e memorizzati in “blocchi”, tra loro collegati (o meglio, concatenati, da cui il termine “blockchain”, che sta per “catena di blocchi”) mediante richiamo dell’hash (una stringa alfanumerica in grado di contraddistinguere univocamente dati elettronici, costituendone l’impronta digitale) del blocco precedente nel blocco successivo. Con questa modalità la blockchain viene detta immutabile, poiché la modifica dell’hash di un blocco causerebbe quella dei blocchi conseguenti, rendendo l’operazione di ricalcolo degli hash da modificare eccessivamente dispendiosa da un punto di vista tecnico.
La blockchain è dunque un “append-only ledger”, ovvero un registro che consente unicamente l’aggiunta di nuovi dati che, una volta registrati, non sono in teoria più modificabili o eliminabili e, per questa ragione, è ritenuta essere in grado di garantire meglio un adeguato coordinamento tra i nodi e la difesa dall’eventuale comportamento malevolo di uno o alcuni di essi.
Fatta questa doverosa premessa, non è chiaro che cosa il legislatore intenda con “non alterabili e non modificabili”. Certamente, come detto, i sistemi distribuiti posso in astratto assicurare un più alto livello di sicurezza rispetto a quelli tradizionali, dunque l’espressione potrebbe riferirsi ad una tendenziale incorruttibilità. D’altra parte, inalterabilità ed immodificabilità evocano le peculiarità della blockchain rispetto agli altri registri distribuiti, tant’è vero che i primi commenti alla norma danno conto del tentativo del Governo italiano di fornire una definizione di blockchain. L’intento si spiegherebbe alla luce del profondo interesse che la blockchain sta riscuotendo a livello mondiale, tanto da spingere alcuni Stati a tentare di delineare giuridicamente il fenomeno.
Se così fosse, ci sarebbe un’errata sovrapposizione tra DLT, da una parte, e blockchain, dall’altra, posto che se è corretta l’affermazione secondo cui tutte le blockchain sono DLT, lo stesso non si può dire al contrario.
Indipendentemente da ciò, si ritiene rischioso mettere in risalto inalterabilità e immodificabilità; oltre alla rapidità che caratterizza l’evoluzione tecnologica, infatti, a quanto consta, la blockchain è solo unilateralmente immodificabile, poiché il raggiungimento del controllo sulla maggioranza dei nodi consentirebbe l’apporto di cambiamenti (sul punto, comunque, c’è un acceso dibattito, considerata la novità della tecnologia, i molteplici meccanismi di raggiungimento del consenso e le differenze tra blockchain permissionless, permissioned o ibride). Al momento dato, sarebbe forse stato più opportuno limitarsi ad una descrizione tecnica. Inalterabilità e immodificabilità paiono infine non collidere con l’aggiornamento dei dati (verosimilmente da ritenersi come aggiornamento del sistema all’aggiunta di nuovi dati).
Inoltre, la verificabilità dei dati da parte di ciascun partecipante pare limitare la definizione alle blockchain permissionless, in cui l’accesso e la visione della catena è consentito per tutti i nodi (seppur usualmente i dati non sono in chiaro ma protetti da crittografia), mentre si sarebbe potuto meglio esplicitare il significato di “verifica” e di “partecipante”.
La definizione di “smart contract”
Il comma 2 esordisce con la definizione di “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”. La locuzione “smart contract” richiama alla mente il contratto, tenuto conto anche del riferimento all’“esecuzione”, a “due o più parti” ed all’uso del verbo “vincola”. Ciò è confermato nel prosieguo del testo, che, al ricorrere di certi presupposti, riconosce allo smart contract l’efficacia della “forma scritta”.
L’espressione è normalmente accostata alla blockchain, di cui rappresenta una delle applicazioni più complesse ed evolute, e sta ad indicare la possibilità di includere e far processare in blockchain un software capace di eseguire in automatico determinate operazioni sulla base di funzioni predefinite al ricorrere di condizioni specifiche, secondo la logica del “se x, allora y”; conseguentemente, se il codice è la traduzione in linguaggio macchina di condizioni contrattuali, si parla di “smart contract” (“contratto intelligente”).
Il teorico degli “smart contract” fu l’informatico Nick Szabo, che in uno scritto omonimo risalente al 1994 elaborava l’idea della trasposizione direttamente nel software di clausole contrattuali, capace di eseguirsi automaticamente senza possibilità di intervento umano. La ritenuta immutabilità di blockchain avrebbe contribuito a rendere praticabile ciò che in precedenza era stato solamente immaginato, posto che l’impossibilità di modificare o eliminare i dati registrati in blockchain impedirebbe di fermare l’esecuzione dello smart contract o di modificarne i contenuti.
Per questa ragione storica, quando ci si riferisce allo “smart contract” è immediato l’accostamento con la blockchain e con il contratto, perdendo di vista ciò che lo smart contract è di per sé, ovvero un programma per elaboratore che può essere utilizzato non solo per la redazione di contratti intelligenti, ma in innumerevoli casi: basti pensare all’automatizzazione di un processo aziendale o di un procedimento amministrativo, o ad un semplice termostato intelligente in grado di accendersi o spegnersi a seconda delle istruzioni date; lo smart contract può anche eseguire, in tutto o in parte, le condizioni di un contratto classico, o determinare la conclusione di un contratto seguendo parametri prestabiliti.
Lo smart contract, inoltre, può esistere indipendentemente dalla blockchain o da qualsiasi registro distribuito, meri sistemi informatici su cui lo smart contract può essere eseguito (dove eseguire, in termini tecnici, significa elaborare le istruzioni di un programma informatico).
Nonostante si tratti di una proposizione infelice e fuorviante, dunque, il legislatore avrebbe forse fatto meglio a non limitare le funzionalità dello smart contract, in quanto “programma per elaboratore”, al contratto; lo smart contract è un programma per elaboratore che può operare su tecnologie basate su registri distribuiti e che può rappresentare la forma di un contratto a cui due o più parti si vincolano. Se si fosse voluto, invece, utilizzare l’espressione “smart contract” solo nell’ambito contrattuale, abbandonando del tutto la confusione dettata dall’utilizzo del lemma “contract” in altri settori non a rilevanza giuridica o a diversa rilevanza giuridica, si sarebbe potuto discorrere di “smart contract” come di un “contratto espresso nella forma di un programma per elaboratore e capace di auto-eseguirsi”.
Anche l’affermazione secondo cui “l’esecuzione dello smart contract vincola automaticamente due o più parti” appare ingannevole: se con “esecuzione” si intende l’esecuzione del contratto, è inopportuno sancire che le parti si vincolano (rectius si obbligano) nel momento in cui il contratto è eseguito, in ragione del principio consensualistico per cui il contratto si perfeziona con il consenso (tranne alcune eccezioni); se viceversa l’esecuzione è propria del programma per elaboratore (con il significato che acquisisce nel linguaggio informatico) il verbo “vincola” allude probabilmente all’immutabilità della blockchain, che impedirebbe l’inadempimento del contratto o la perdita di effetti del medesimo.
Mettendo da parte ogni considerazione sull’effettiva immutabilità della blockchain (e non di ogni tecnologia basata su registri distribuiti, come esplicitato dalla norma), che necessiterebbe di un parere più squisitamente tecnico, appare azzardato far dipendere dalla macchina le vicende contrattuali delle parti: piuttosto, l’informatica dovrebbe poter rappresentare il mezzo tramite cui le parti eseguono il contratto a cui esse stesse si sono vincolate, con tutti i benefici che possono derivarne, senza mettere da parte il principio dell’autonomia contrattuale. Non un programma per elaboratore che vincola le parti contraenti, quanto un programma per elaboratore che agisce a supporto delle parti contraenti. Il discorso potrebbe aprire a considerazioni ed interrogativi di carattere etico prima ancora che giuridico, circa il ruolo di macchine sempre più intelligenti nel rapporto con l’uomo.
Senza contare che il concepimento di un contratto direttamente in forma di codice informatico è ancora poco praticato, posto che sarebbe incomprensibile ai più; tant’è vero che le sperimentazioni avviate prevedono l’uso di smart contracts per l’esecuzione di (parte) delle condizioni di un contratto situato altrove. La diffusione di contratti di tal fatta potrà avvenire nel prossimo futuro, in cui, con il progredire degli studi sull’intelligenza artificiale, potrà essere usuale che le macchine concludano contratti comunicando tra loro, o saranno in grado di processare direttamente il linguaggio giuridico naturale (che è notoriamente e appositamente soggetto ad ambiguità, e necessiterebbe di un’attività interpretativa della macchina).
Efficacia probatoria dello smart contract
Il comma 2 prosegue statuendo che “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”. La disposizione sostanzialmente ricalca l’art. 20, co.1-bis, del Codice dell’amministrazione digitale (CAD), che nella sua ultima versione ha previsto che il documento informatico soddisfa il requisito della forma scritta ed ha l’efficacia prevista dall’art. 2702 c.c. non solo se formato con firma elettronica digitale, altro tipo di firma elettronica qualificata o firma elettronica avanzata, ma anche qualora venga formato mediante un processo avente i requisiti fissati dall’Agenzia per l’Italia digitale (AgID) mediante regole tecniche, che garantisca integrità e immodificabilità del documento ed il collegamento manifesto ed inequivoco con il suo autore, il quale va dunque previamente identificato.
Ciò premesso, pare che la norma, nata evidentemente per stimolare gli investimenti sulle tecnologie basate su registri distribuiti, possa risultare superflua o limitare l’innovazione. Non si intuisce, infatti, la ragione per cui ci sia limitati a riconoscere il valore di forma scritta ai soli smart contracts creati mediante un processo di attribuzione della paternità specifico per le DLT, quando sarebbe stato sufficiente richiamare l’art. 20 co. 1 bis del CAD. Si potrebbe, infatti, determinare l’efficacia di forma scritta dello smart contract per via interpretativa, sulla base delle norme vigenti. Anzitutto includendo lo smart contract tra i documenti informatici, ai sensi dell’art. 1, par. 1, lett. p) del CAD e dell’art. 3, par.1, n. 35 del Regolamento (UE) n. 910/2014 (eIDAS); in secondo luogo, conferendo tale valore unicamente ai documenti informatici firmati con firma avanzata o qualificata o prodotti mediante processi conformi a quanto dettato da AgID. Si crea così un conflitto interpretativo, dovendosi dedurre che il requisito della forma scritta debba essere negato nei casi coperti dall’art. 20, co 1-bis del CAD, con conseguente rimessione alla libera valutazione del giudice.
Ciò si pone in conflitto anche con il principio di neutralità tecnologica, essendo drasticamente ridotte per le DLT le ipotesi di soddisfacimento del requisito della forma scritta rispetto a tutte le altre tecnologie utilizzate, per le quali rimarrebbero operanti le regole generali.
La formulazione si deve forse al tentativo di sostenere la diffusione delle DLT nonostante si tratti di tecnologie giovani e ancora poco collaudate; come si è sopra accennato, ci sono ancora dubbi sulla effettiva capacità di garantire integrità e immodificabilità dei dati, e nelle blockchain pubbliche i soggetti non sono pre-identificati, per cui probabilmente si è voluto evitare un prevedibile assoggettamento alla discrezionalità del giudice (chiamato a verificare paternità del documento e sua sicurezza, integrità e immodificabilità) conferendo certezza giuridica agli smart contract su DLT.
Se così fosse, pur dovendosi riconoscere il merito di aver voluto favorire l’innovazione tecnologica, si stenta a pensare che l’AgID possa anticipare i tempi di un processo che dovrebbe essere affrontato in un’ottica quantomeno europea e auspicabilmente internazionale, con l’elaborazione di standard condivisi e di sistemi interoperabili. Oltre al fatto che si tratterebbe di una soluzione rischiosa, per i motivi sopra enunciati, destinata a produrre un effetto addirittura inverso a quello presumibilmente sperato.
Rimarrebbero poi esclusi i documenti informatici rappresentativi di atti giuridici che non siano anche contratti.
Documento informatico e validazione temporale elettronica
Il comma 3 sancisce l’efficacia giuridica della validazione temporale elettronica derivante dalla memorizzazione di documenti informatici mediante uso di tecnologie basate su registri distribuiti.
La validazione temporale elettronica, secondo la definizione dell’art. 3, par. 1, n. 33 del Regolamento eIDAS consente di accostare data e ora a dati in forma elettronica ad opera di altri dati in forma elettronica, al fine di provare l’esistenza dei medesimi in un determinato momento. Sinonimo di validazione temporale è l’utilizzo dell’espressione “marca temporale” (o “timestamp”), che normalmente viene effettuata mediante funzioni di “hash” in grado di generare un’impronta digitale univoca dei dati da validare.
Hash e timestamp sono concetti ricorrenti nelle DLT, per cui è ragionevole che il legislatore abbia voluto evidenziare l’idoneità di queste tecnologie a validare temporalmente dati in forma elettronica, con possibilità di impiego nei campi più svariati (ad esempio, il diritto d’autore). In particolare, la caratteristica concatenazione di hash propria della blockchain risulta utile ai fini della tracciabilità, ovvero nella possibilità di mantenere la cronologia consequenziale delle transazioni, rendendola oggetto di molteplici casi d’uso (ad esempio i registri immobiliari).
Nel menzionare la validazione temporale elettronica, il comma 3 rimanda all’art. 41 del Regolamento eIDAS, che disciplina gli effetti giuridici sia della validazione temporale elettronica semplice, che di quella qualificata. La differenza non è di poco conto: la validazione temporale elettronica qualificata, infatti, gode della presunzione di accuratezza della data e dell’ora indicate e dell’integrità dei dati a cui data ed ora sono associate, mentre per la validazione temporale elettronica non qualificata tale valutazione è rimessa al libero apprezzamento del giudice; la validazione temporale elettronica qualificata ricade sotto il principio del mutuo riconoscimento, essendo da considerarsi tale in tutti gli Stati membri.
Non è del tutto chiaro se il legislatore abbia voluto riferirsi alla validazione temporale elettronica qualificata, avendo richiamato solo l’art. 41 del Regolamento eIDAS e non l’articolo 3, par. 1, n. 33 o 34, in cui vengono definite, rispettivamente, la validazione temporale elettronica e la validazione temporale elettronica qualificata. Da una parte, il comma 3 si limita a parlare di validazione temporale, senza aggiungere l’aggettivo qualificata; dall’altra, l’affidamento ad AgID dell’individuazione di specifici standard tecnici ad opera del successivo comma 4, pare debba essere ricollegato al rispetto dei requisiti prescritti all’art. 42 del Regolamento affinché la validazione temporale sia qualificata.
Presumibilmente, si sono volute indicare entrambe: in assenza dei requisiti di cui all’art. 42 del Regolamento (e del rispetto degli standard tecnici fissati da AgID), si parlerà di validazione elettronica non qualificata, i cui effetti saranno rimessi alla valutazione del giudice.
Ciò che si critica è la doverosità del rispetto degli standard tecnici per la produzione degli effetti di cui all’articolo 41, che si desume dalla formulazione del quarto comma, a mente del quale l’AgID è tenuta ad individuare gli standard tecnici che le tecnologie basate su registri distribuiti “debbono possedere ai fini della produzione degli effetti di cui al comma 3”. Nel caso di validazione temporale elettronica non qualificata (anche se, come già precisato, non pare questa l’intenzione del legislatore), ciò si porrebbe in contrasto con la stessa definizione di validazione temporale e con l’art. 41, par. 1, del Regolamento eIDAS, volti ad evitare che possa essere preclusa a priori qualsiasi validità giuridica o rilevanza probatoria a strumenti elettronici di assegnazione di data ed ora, e provocherebbe una chiusura, e non un’apertura, del mercato verso soluzioni innovative e meno rigide di validazione temporale.
Nell’ipotesi di validazione temporale qualificata, parimenti, gli standard dovrebbero porsi come utile metro di misura circa il possesso dei requisiti richiesti dall’art. 42 del Regolamento eIDAS, non sostituirsi ad essi; in caso contrario, la disposizione si porrebbe in contrasto con l’articolo 42 del Regolamento e non stimolerebbe l’avanzamento della tecnologia utilizzata per la validazione temporale. Dubbi sussistono inoltre sulla necessità di standard specifici per le DLT, in luogo delle norme tecniche sulla validazione temporale già esistenti.
Infine, gli effetti giuridici della validazione temporale elettronica attraverso l’uso di tecnologie basate su registri distribuiti sono limitati alla memorizzazione di documenti informatici, senza considerare che la validazione temporale consente il collegamento di una particolare ora e data genericamente a “dati in forma elettronica”, siano essi documenti informatici, firme elettroniche o sigilli elettronici.
Considerazioni conclusive
Con la presente norma il legislatore ha chiaramente voluto stimolare l’innovazione e rendere il territorio italiano “blockchain-friendly”, definendo DLT e smart contracts e prevedendo precisi effetti giuridici, cercando di evitare valutazioni discrezionali in favore della certezza giuridica.
Emergono, tuttavia, dei profili critici – che si è cercato di illustrare in questo breve scritto – che si possono riassumere in tre punti fondamentali: l’imprecisione delle definizioni; la superfluità di alcune norme a fronte dell’applicabilità del regime giuridico attuale; il rischio di frenare, piuttosto che accompagnare, lo sviluppo delle applicazioni che adottano tali tecnologie.
La spiegazione andrebbe forse ricercata nella fretta di fornire, o quantomeno abbozzare, un quadro giuridico in materia. Sul punto, però, non pare che l’Italia possa essere tacciata di impreparazione o ritardo rispetto al resto d’Europa; seppure sia stata l’ultimo Stato membro ad aver aderito alla Dichiarazione sull’istituzione di una Partnership europea (con ritardi giustificabili in ragione della fine della legislatura), il MISE ha già provveduto a dotarsi di un gruppo di esperti per l’elaborazione di una strategia nazionale, nello stesso periodo in cui un’altra grande potenza europea come la Germania ha avviato un processo di consultazione popolare sulle modalità di sfruttamento del potenziale della tecnologia blockchain prima di presentare la propria strategia.
Per il resto, Paesi come la stessa Germania, la Francia e Malta stanno facendo piccoli passi nel riconoscimento della tecnologia blockchain per determinate applicazioni, in particolare quella delle valute virtuali (che è anche stata la prima a diffondersi con l’invenzione di Bitcoin): così la Germania, che ha chiarito la differente natura delle valute virtuali a seconda della finalità dello scambio (come strumento di pagamento tra privati alla stregua di monete complementari, o di strumenti finanziari se utilizzati per investimenti), prevedendo l’assoggettamento di coloro che svolgano servizi di intermediazione ad esse collegati a preventiva autorizzazione come gli altri intermediari finanziari; o Malta, che in particolare con il Virtual Financial Asset Act ha istituito un regime normativo per le ICOs ed altri servizi collegati alle criptovalute.
La Francia, invece, con due distinte Ordinanze – Ordonnance n. 2016-520 du 28 avril 2016 relative aux bons de caisse e Ordonnance n° 2017-1674 du 8 décembre 2017 relative à l’utilisation d’un dispositif d’enregistrement électronique partagé pour la représentation et la transmission de titres financiers – ha consentito il ricorso alla tecnologia blockchain per i minibons e per la registrazione ed il trasferimento di titoli finanziari non quotati come sistema alternativo rispetto alla tradizionale registrazione in libri contabili e societari, e con eguali effetti giuridici.
Nell’ambito delle valute virtuali, anche l’Italia vanta un primato; con il D.lgs. 90/2017 sull’antiriciclaggio, infatti, il legislatore è intervenuto in anticipo rispetto a quello europeo, assoggettando i cambiavalute al rispetto degli obblighi antiriciclaggio (l’Unione europea è intervenuta poi con la Direttiva 2018/843, detta V Direttiva AML, estendendo i medesimi obblighi anche ai prestatori di servizi di portafoglio digitale).
In sintesi, come anche auspicato nella Risoluzione del Parlamento europeo del 3 ottobre 2018, è importante adottare un approccio globale in materia di definizione delle norme giuridiche, in cui si tenga conto sia della necessità di certezza giuridica che di approfondire a dovere tecnologie ancora giovani. Improvvisi passi in avanti, soprattutto se non adeguatamente accompagnati dall’armonizzazione con il panorama giuridico europeo ed italiano vigente, rischiano di produrre risultati insperati, o non significativi.
L’istituzione del gruppo di esperti sulla blockchain potrebbe essere un buon punto di partenza per eventuali ritocchi alla norma.
Consulta:
Articoli correlati
