Quadro Normativo

In questa sezione trovi...

Quali sono le principali normative che disciplinano l’uso dello smart contract?
Ad oggi non esistono disposizioni che stabiliscano regole dettagliate in merito all’uso di questo strumento, limitandosi perlopiù a fornire una definizione di carattere generale. Tuttavia la materia è in continua evoluzione e beneficia di un’energica spinta ricevuta durante il periodo pandemico. Analizziamo quindi le principali norme.
Il linguaggio utilizzato durante la disamina sarà volontariamente informale in quanto, come ti è possibile leggere alle sezione “About“, si vuole rispettare l’intento di rappresentare uno strumento utile anche per un pubblico di non giuristi.

Normativa Italiana
Normativa Europera
Paesi Extra Ue

Normativa Italiana

L’ordinamento italiano introduce una definizione di Dlt e Smart Contract con la Legge 12/2019 in conversione al D.L. 135/2018. Nello specifico si tratta dell’articolo 8-ter, composto di soli quattro commi, che di seguito andiamo ad analizzare.

Articolo 8 ter, 1° comma, L. 12/2019:
“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.”

La prima osservazione riguarda l’oggetto della definizione, la norma infatti definisce DLT e nulla dice in merito a blockchain (BC). Come saprai i due termini non sono sinonimi, e le due architetture seppur similari possiedono caratteristiche diverse (in termini assai semplicisti si può dire che tutte le BC sono DLT ma non tutte le DLT sono BC. Se sei veramente interessato alla tematica ti suggerisco di non limitarti al “semplicistico” ma di approfondire l’argomento).
Vediamo quindi di organizzare in modo grafico questo consistente elenco:

Caratteristiche del registro	Azioni possibili con i dati ("sia in chiaro che ulteriormente protetti da crittografia")	Caratteristiche dei Dati
Distribuito	Registrazione	Verificabili da ciascun partecipante
Replicabile	Convalida	Non alterabili
Accessibile simultaneamente	Aggiornamento	Non modificabili
Architetturalmente decentralizzato su basi crittografiche	Archiviazione

Due sono le principali critiche a questo primo comma da parte degli esperti in materia. La prima riguarda la scelta di fornire la definizione di DLT prevedendo dei requisiti di non alterabilità e non modificabilità che sembrerebbero essere garantiti solo da una BC pubblica.
La seconda riguarda la “non modificabilità”, carattere problematico sotto diversi aspetti:

informatico: nemmeno la BC pubblica può assicurare l’immodificabilità in forma assoluta (soglia del 51% dei nodi);
giuridico: possibile conflitto con la normativa GDPR, in particolare con l’art 17, che prevede il diritto ad ottenere la cancellazione dei dati comunicati;
logico: si prevede che il dato debba essere “non modificabile” e “aggiornabile”, caratteri in apparente contrasto tra loro.

Questo primo comma, se da un lato evidenzia la volontà del legislatore di creare una base normativa che permetta alle aziende di investire e sperimentare i possibili utilizzi della tecnologia, dall’altro lascia un significativo margine di incertezza circa quali siano le reti che possano rientrare nella definizione, non specificando se debbano essere public, private, permissionless, permissioned, o quale debba essere l’algoritmo di consenso utilizzato (PoW, PoS, altro).

Passiamo ora alla definizione di Smart Contract.

Articolo 8 ter, 2° comma, L. 12/2019:
“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.”

Analizziamo quindi singolarmente le due frasi che compongono questo comma. Se è una delle prime volte che ti soffermi nella lettura di queste righe, ti renderai conto che c’è abbastanza carne al fuoco.
Cos’è uno SC secondo il legislatore? Un “programma per elaboratore”! Quindi? Codice informatico! Si ma in quale linguaggio? Qualsiasi probabilmente; ma la legge stabilisce un requisito tecnico “opera su tecnologie basate su registri distribuiti”. Cosa significa questo? Che non è sufficiente che il codice informatico sia salvato sull’hard disk delle parti o in una qualsiasi LAN, ma deve esserne fatto il deploy all’interno di una rete DLT che soddisfi i requisiti stabiliti al 1° comma dell’art. 8-ter (che come abbiamo visto poco fa non risulta essere particolarmente chiaro). [Se sei un giurista e non sai cosa sia il deploy, tranquillo, lo vedremo in modo approfondito alla pagina “Nozioni basilari di coding – Smart Contract per la Notarizzazione“, per ora ti basta sapere che si tratta della registrazione del contratto nella rete DLT].
La frase non è terminata però; la norma stabilisce infatti che “l’esecuzione” di questo codice informatico “vincola automaticamente due o più parti sulla base di effetti predefiniti dalle stesse”.
Cosa significa “esecuzione”? Non essendo specificato se sia da intendersi esecuzione in senso giuridico o informatico, sorge un primo problema interpretativo. Se sei un informatico, sappi che nel mondo giuridico un contratto nasce dalla volontà di due o più parti (art. 1321 c.c.) e non dall’esecuzione della prestazione. Per tale ragione la maggior parte della dottrina giuridica suggerisce l’interpretazione informatica del termine, così che lo smart contract possa essere il contratto stesso e non l’esecuzione (giuridica) della volontà espressa in precedenza.
A mio avviso si apre un altro problema, che meglio analizzeremo in fase di scrittura del codice, ossia di quale esecuzione informatica si stia parlando? Se sei un giurista, devi sapere che una volta effettuato il deploy dello smart contract questo riceve subito esecuzione, quanto meno nella parte contenuta nel constructor. Sarà quindi il caso di prestare particolare attenzione in fase di sviluppo del codice per capire quale sia l’esatto momento in cui la parte si sta vincolando, tenendo sempre a mente il contenuto dell’art. 1326 del codice civile (conclusione del contratto).

Possiamo quindi passare alla seconda parte del 2° comma nella quale si dice che gli SCs “soddisfano il requisito della forma scritta previa identificazione informatica delle parti interessate”.
Come deve avvenire l’identificazione per essere valida? Lo stabilisce l’AgID (Agenzia per l’Italia Digitale). Nel momento in cui scrivo, nonostante siano trascorsi circa due anni dalla pubblicazione della L.12/2019, non sono state emanate ancora le linee guida.
Cos’è la forma scritta e perché è importante? Nel mondo giuridico si distinguono diversi tipi di forma, questa può rilevare sia per quanto riguarda la validità dell’atto che l’eventuale prova in giudizio. In assenza di linee guida dell’AgID quale validità può essere attribuita allo SC? Bisogna ritenere che questa sia lasciata al libero apprezzamento del giudice.
Sembra che la disposizione appena vista sia superflua in quanto allo smart contract può essere attribuita la natura di “documento informatico”, ad esso è quindi applicabile quanto disposto dal Codice dell’Amministrazione Digitale(CAD) all’articolo 20 comma 1 bis.
Non mi soffermo in questo momento sulla tematica dell’identificazione alla quale dedicherò una parte specifica; per ora è bene tenere a mente che è una delle principali problematiche da risolvere.

Vediamo infine il contenuto degli ultimi due commi.

Articolo 8 ter, 3° e 4° comma, L. 12/2019:
“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.”

“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 debbono possedere ai fini della produzione degli effetti di cui al comma 3.”

I due commi non presentano particolari problemi interpretativi. Le tecnologie DLT possono essere utilizzate per la “validazione temporale elettronica”, ossia la c.d. “notarizzazione” di documenti. Sappiamo bene che questo tipo di utilizzo è ormai comune e vi sono molti siti che in modo gratuito o meno forniscono questo servizio. Tuttavia osservando quanto disposto dal 4° comma ricadiamo nella stessa casistica evidenziata parlando dello smart contract. Quali sono le reti nelle quali possono essere notarizzati dei documenti? Ethereum si o no? e Algorand? La risposta sarà data dalle future linee guida AgID.

Abbiamo visto come la normativa italiana non fornisca una disciplina dettagliata ma ponga le basi affinché si cominci a sperimentare portando alla luce le criticità delle quali il diritto dovrà occuparsi. L’unica certezza che abbiamo è che per la legge italiana non esiste lo “smart legal contract” ma lo “smart contract”. In questo modo si crea una sovrapposizione tra termine informatico e giuridico, per distinguere quindi il codice puramente informatico da quello con rilevanza giuridica saremo costretti a parlare del primo come smart contract informatico e del secondo come smart contract; all’opposto un’informatico parlerà del primo come “smart contract” e del secondo come “smart legal contract”. Infine dobbiamo tenere a mente che uno smart contract registrato sulla DLT “sbagliata” potrebbe non essere considerato valido giuridicamente.

Normativa Europea

L’Unione Europea è un grande promotore dello sviluppo delle tecnologie blockchain e smart contract; negli ultimi anni la principale iniziativa è stata Horizon 2020, programma attivo dal 2013 che avrebbe movimentato più di 300 milioni di euro in questo settore.
Ad oggi dal lato europeo non abbiamo alcuna normativa volta a disciplinare gli SCs.
Le principali fonti non-normative in merito alla tematica, per ora, possono ridursi a:

il noto documento “How blockchain technology could change our lives” pubblicato nel 2017 dall’European Parliament Research Service;
i molti report pubblicati dall’EU Blockchain Observatory & Forum, organismo istituito dalla Commissione Europea per accelerare lo sviluppo di queste tecnologie.

Dal lato normativo, seppur non direttamente rivolte a disciplinare gli SCs, dobbiamo tenere in forte considerazione:

Caro informatico, come saprai ci sono tanti tipi di normative diverse, alcune gerarchicamente più forti rispetto ad altre. In ambito europeo possono essere prodotti una pluralità di atti, tra questi vi sono regolamenti, direttive e decisioni, che vengono classificati come atti legislativi e quindi con effetti vincolanti per gli stati membri. Per ora ti basta tenere a mente che: i regolamenti sono destinati a tutti gli stati membri (incluse persone giuridiche e fisiche) e sono immediatamente applicati e vincolanti in tutte le parti; le direttive possono essere destinate a tutti o solo alcuni stati membri e hanno efficacia vincolante per quanto riguarda gli obiettivi da conseguire; in pratica obbligano lo stato a conformarsi entro un certo limite di tempo (possono essere immediatamente applicabili solo in circostanze particolari), attraverso una propria norma interna.
Se sei interessato a conoscere il funzionamento delle fonti europee di consiglio la lettura di questo articolo “L’ABC del diritto dell’Unione europea” .

In questa sezione non farò una disamina delle norme ma una breve spiegazione del contenuto e di come influiscano nella realizzazione dello smart contract. Affronteremo in modo maggiormente diretto e pragmatico il contenuto nella sezione “Sviluppare uno Smart Contract” per capire se sia possibile, e in quale modo, rendere lo smart contract compliant alla normativa vigente.

Il motivo per il quale cito la direttiva AML/CFT, anche se non disciplina l’utilizzo dello smart contract, è che fornisce una definizione di valute virtuali e tratta gli obblighi dei soggetti che operano in ambito di cambio con valute legali.
Alcuni sostenevano che la criptovaluta sarebbe potuta essere una sorta di contante della rete, una moneta scambiabile in modo totalmente anonimo. Ora chiunque abbia mai acquistato criptovaluta sa che deve necessariamente (se vuole essere sicuro di ricevere qualcosa) passare attraverso un servizio di exchange che richiederà delle formalità pari a quelle richieste per l’apertura di un tradizionale conto in banca.
Nel settembre 2020 la Commissione europea ha inoltre pubblicato una bozza di Regolamento dedicata ai mercati di cripto-attività; seppur ancora in forma di bozza rappresenta un forte segnale di avvicinamento ad una normativa europea che disciplini la materia. Per ora ti segnalo semplicemente che all’articolo 3 viene proposta una distinzione in diverse tipologie di tokens, argomento sul quale torneremo in seguito.

Per quanto riguarda il regolamento eIDAS, dobbiamo prestare particolare attenzione al ruolo che può giocare in tema di smart contracts.
Un contratto è l’accordo di due o più parti per costituire, regolare o estinguere tra loro un rapporto giuridico patrimoniale (art. 1321 c.c.). È fondamentale che la volontà manifestata sia riconducibile ad uno specifico soggetto, e con questo non intendo necessariamente nome e cognome, ma un’indicazione univoca che mi permetta di distinguere quella manifestazione di volontà da una qualsiasi altra. Non essendo ancora presenti linee guida AgID, in merito all’identificazione su protocolli BC e DLT possiamo solo fare affidamento sulla lettura dell’eIDAS che, nonostante non contenga disposizioni specifiche per gli smart contracts, tratta l’identificazione elettronica quindi qualsiasi tipo di identificazione che avviene in modo non analogico.

Per quanto concerne la normativa GDPR il mondo giuridico ha sollevato fin dall’inizio alcuni dubbi circa la compatibilità con l’impiego di tecnologie BC e DLT.
Vediamo quindi:

quando si applica la normativa
quali sono gli elementi di conflitto
quali caratteristiche sono conciliabili con la normativa.

L’ambito di applicabilità della normativa è stabilito dall’articolo 3 del regolamento:

Articolo 3, Reg. UE 2016/679:
1. Il presente regolamento si applica al trattamento dei dati personali effettuato nell'ambito delle attività di uno stabilimento da parte di un titolare del trattamento o di un responsabile del trattamento nell'Unione, indipendentemente dal fatto che il trattamento sia effettuato o meno nell'Unione.

2. Il presente regolamento si applica al trattamento dei dati personali di interessati che si trovano nell'Unione, effettuato da un titolare del trattamento o da un responsabile del trattamento che non è stabilito nell'Unione, quando le attività di trattamento riguardano:
a) l'offerta di beni o la prestazione di servizi ai suddetti interessati nell'Unione, indipendentemente dall'obbligatorietà di un pagamento dell'interessato; oppure
b) il monitoraggio del loro comportamento nella misura in cui tale comportamento ha luogo all'interno dell'Unione.

3. Il presente regolamento si applica al trattamento dei dati personali effettuato da un titolare del trattamento che non è stabilito nell'Unione, ma in un luogo soggetto al diritto di uno Stato membro in virtù del diritto internazionale pubblico.

Emerge subito che in tema di estensione territoriale la portata sia decisamente ampia, non richiedendo necessariamente che il titolare del trattamento o il responsabile del trattamento sia stabilito nell’Unione.

La norma definisce alcuni importanti termini, essenziali per comprendere se il suo ambito di applicazione influisca nella programmazione dei nostri smart contracts. Primo importante termine è quello di “dato personale”.

Articolo 4, punto 1, Regolamento (UE) 2016/679:
«dato personale»: qualsiasi informazione riguardante una persona fisica identificata o identificabile («interessato»); si considera identificabile la persona fisica che può essere identificata, direttamente o indirettamente, con particolare riferimento a un identificativo come il nome, un numero di identificazione, dati relativi all'ubicazione, un identificativo online o a uno o più elementi caratteristici della sua identità fisica, fisiologica, genetica, psichica, economica, culturale o sociale;

Sicuramente è possibile evitare l’inserimento di nomi e identificativi all’interno di uno SC, limitandosi all’utilizzo di codici hash e degli address degli account.
Cosi facendo sono al riparo dall’applicazione del GDPR? La risposta deve essere negativa, in quanto seppur pseudonimizzato, anche la chiave pubblica di un account è un dato personale.
Sono altresì importanti, ai fini di comprendere l’ambito di applicazione del regolamento, la definizione di dato “pseudonimizzato” e di dato “anonimo”. Infatti solo se si dovesse trattare quest’ultimo tipo di informazione il GDPR non troverebbe applicazione. Di seguito quindi una parte del Considerando n.21 e dell’articolo 4 punto n.5.

Considerando n.21, Reg. UE 2016/679
I principi di protezione dei dati non dovrebbero pertanto applicarsi a informazioni anonime, vale a dire informazioni che non si riferiscono a una persona fisica identificata o identificabile o a dati personali resi sufficientemente anonimi da impedire o da non consentire più l'identificazione dell'interessato. Il presente regolamento non si applica pertanto al trattamento di tali informazioni anonime, anche per finalità statistiche o di ricerca.

Articolo 4, punto 5, Reg. UE 2016/679
«pseudonimizzazione»: il trattamento dei dati personali in modo tale che i dati personali non possano più essere attribuiti a un interessato specifico senza l'utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente e soggette a misure tecniche e organizzative intese a garantire che tali dati personali non siano attribuiti a una persona fisica identificata o identificabile.

Come si può agilmente dedurre dalle righe che precedono, operare con uno smart contract su blockchain non può corrispondere all’uso di dati anonimi ma pseudonimizzati, quindi deve trovare applicazione la disciplina del regolamento GDPR.

Assodato quindi che si applica la normativa, quali sono i principali punti di attrito con essa?
La normativa è stata pensata per una struttura verticale nella quale vi è un soggetto che raccoglie e utilizza i dati degli utenti per determinate finalità, anche servendosi di strutture informatiche fornite da esterni. Una rete decentralizzata e distribuita è una struttura prettamente orizzontale e difficilmente coordinabile con il principio di accountability contenuto nella normativa. Accountability è essenzialmente un sinonimo di “responsabilità” e si sostanzia nel rispetto dei principi indicati all’articolo 5 comma 1 del regolamento e nella capacità del titolare di dimostrare di averli rispettati. La protezione del dato non riguarda infatti solo il momento della violazione dello stesso ma l’intera gestione del dato dalle fasi di raccolta ed archiviazione.
Una prima difficoltà riguarda la possibilità di individuare le figure che l’articolo 4 al punto n.7 e n.8 definisce come titolare del trattamento e responsabile del trattamento: “«titolare del trattamento»: la persona fisica o giuridica, l’autorità pubblica, il servizio o altro organismo che, singolarmente o insieme ad altri, determina le finalità e i mezzi del trattamento di dati personali” e “«responsabile del trattamento»: la persona fisica o giuridica, l’autorità pubblica, il servizio o altro organismo che tratta dati personali per conto del titolare del trattamento; “.
L’individuazione di una figura simile potrebbe risultare decisamente problematica se si pensa ad una blockchain pubblica, più agevole potrebbe essere in blockchain private permissioned o in DLT.
In dottrina ci sono stati diversi tentativi di ricostruire uno schema di responsabilità ma ad oggi non si può dire che sia stato trovato un modello unanimemente riconosciuto (“Fonti per approfondire“: Gambino, Bomprezzi (2019), Razzini (2018), Giuliano (2018)).

Ulteriori profili problematici possono essere individuati in merito alla conservazione, rettifica e cancellazione dei dati.
Particolarmente significativi sono i seguenti articoli:

Articolo 5, par. 1, lett. e, Reg. UE 2016/679
"...i dati personali sono conservati in una forma che consenta l'identificazione degli interessati per un arco di tempo non superiore al conseguimento delle finalità per le quali sono trattati."
Articolo 16 comma 1 Reg. UE 2016/679
"L'interessato ha il diritto di ottenere dal titolare del trattamento la rettifica dei dati personali inesatti che lo riguardano senza ingiustificato ritardo."
Articolo 17 Reg. UE 2016/679
"...il diritto di ottenere dal titolare del trattamento la cancellazione dei dati personali che lo riguardano…"

Il carattere immutabile dei dati registrati su blockchain potrebbe costituire un problema. In merito all’articolo 5, si potrebbe però sostenere che tale tipo di conservazione sia necessaria al funzionamento dell’architettura e quindi al “conseguimento delle finalità”. In merito all’articolo 16 e 17 la difficoltà è dovuta al fatto che, seppur sia possibile all’utente richiedere l’inserimento di un dato aggiornato, trattandosi di una struttura append-only, questo può avvenire unicamente come una nuova registrazione senza ottenere la cancellazione del dato già esistente.
In merito allo smart contract questo adempimento risulta essere meno problematico, riguardando unicamente la registrazione dell’esercizio delle functions e degli events eventualmente emessi.
Caro giurista, se non sai cosa sia functions ed events non ti preoccupare, nella sezione “Sviluppare uno smart contract” li tratteremo concretamente. Per ora ti è sufficiente sapere che le functions sono lo strumento che permette di interagire direttamente con lo smart contract, mentre gli events sono una sorta di report che può essere emesso, contestualmente all’esercizio della function, per rendere disponibili una pluralità di informazioni.

Meritevole di attenzione è anche il Capo V del Regolamento UE che tratta il trasferimento dei dati verso paesi terzi. Medesime considerazioni di prima possono essere ripetute; gli aspetti maggiormente problematici sono da individuare nell’utilizzo delle reti blockchain pubbliche, per le quali chiunque può creare un full node, e contenere quindi i dati che vengono registrati all’interno della BC. Una prima soluzione potrebbe essere trovata nel ritenere che la copia dei dati, necessaria ai fini del corretto funzionamento del protocollo, non sia un effettivo trasferimento; una seconda è sostenere che si applichi l’articolo 49 del GDPR “deroghe in specifiche situazioni” rendendo così necessario l’inserimento di una specifica dichiarazione di consapevolezza da parte dell’utente circa il possibile trasferimento del dato in paesi terzi.

Alcune caratteristiche proprie di queste tecnologie sono pienamente conciliabili con la normativa GDPR. Prima tra tutte è la pseudonimizzazione dei dati, è infatti la stessa normativa a invitare a farne uso (vedi ad esempio Considerando n.28, n.29, n.78), come saprai infatti il funzionamento del protocollo blockchain prevede l’utilizzo di codici hash e crittografia a doppia chiave. Questo comporta che non vi siano ostacoli nel rispettare i principi di Data protection by design and protection by default dovendo chiaramente prestare attenzione al modo in cui si sviluppa il proprio smart contract.

Seppur quanto appena analizzato pone diversi interrogativi ancora irrisolti, il crescente numero di stati che prevede una normativa per blockchain e smart contract lascia immaginare che una soluzione sarà presto trovata.

“Blockchain and the GDPR” report pubblicato da The European Union Blockchain Observatory & Forum – Lyons, Courcelas, Timsit, (2018) p.17

Paesi Extra-Ue

Come fino ad ora è emerso non esistono delle norme di portata internazionale che regolano il funzionamento e il riconoscimento dello strumento dello smart contract.
L’International Organisation for Standardization (che sicuramente ti è nota per lo standard ISO 27037 in materia di digital evidence) nel luglio 2020 pubblica ISO 22739:2020, un documento che contiene una definizione di tutte le terminologie di maggior rilievo in ambito blockchain and distributed ledger technologies. Tra queste figura anche lo smart contract il quale viene definito al punto 3.72.

3.72 smart contract
"computer program stored in a DLT system (3.30) wherein the outcome of any execution of the program is recorded on the distributed ledger (3.22)

Note 1 to entry: A smart contract can represent terms in a contract in law and create a legally enforceable obligation under the legislation of an applicable jurisdiction."

Sono stati inoltre pubblicati due technical reports, ISO/TR 23244 e ISO/TR 23455, intitolati rispettivamente “Blockchain and distributed ledger technologies – Privacy and personally identifiable information protection considerations” e “Blockchain and distributed ledger technologies – Overview of and interactions between smart contracts in blockchain and distributed ledger technology systems”.

Coming Soon: ricognizione degli ordinamenti stranieri che integrano una normativa per DLT, BC e SC, e disamina degli elementi comuni e distintivi.

Fonti per approfondire

Normativa Italiana

Bomprezzi, C. (2019). Commento in materia di Blockchain e Smart contract alla luce del nuovo Decreto Semplificazioni, Diritto Mercato Tecnologia.

Finocchiaro, G. (2018). Il contratto nell’era dell’intelligenza artificiale. Rivista trimestrale di diritto e procedura civile, (2), 441-460.

Galli M., Garotti, L. (2019). Blockchain e smart contract: le novità previste dal Decreto semplificazioni, il Quotidiano Giuridico.

Giuliano, M. (2018). La “block chain” e gli “smart contracts” nell’innovazione del diritto nel terzo millennio. Il Diritto dell’informazione e dell’informatica, (6), 989-1039.

Manente M. (2019). L. 12/2019 – Smart contract e tecnologie basate su registri distribuiti – prime note, Consiglio Nazionale del Notariato.

Nicotra, M. (2019). L’Italia prova a normare gli smart contract, ecco come: pro e contro, documenti digitali, Agenda Digitale. Agendadigitale.eu

Rinaldi, G. (2019). Smart contract: meccanizzazione del contratto nel paradigma della blockchain, Academia.edu

Normativa Europea

Alagna, I. M., Pacelli, G. G. (2017). Il giurista informatico: “Digital Single Market” e approccio olistico. Ciberspazio e diritto, (2), 261-288.

Bomprezzi, C. (2019). Commento in materia di Blockchain e Smart contract alla luce del nuovo Decreto Semplificazioni, Diritto Mercato Tecnologia.

Cappiello, B. (2019). Cepet Leges In Legibus. Cryptoasset And Cryptocurrencies Private International Law And Regulatory Issues From The Perspective Of Eu And Its Member States. Diritto del commercio internazionale, (3), 561.

Finocchiaro, G. (2018). Il contratto nell’era dell’intelligenza artificiale. Rivista trimestrale di diritto e procedura civile, (2), 441-460.

Gambino, A. M., Bomprezzi, C. (2019). “Blockchain” e protezione dei dati personali. Il Diritto dell’informazione e dell’informatica, (3), 619-646.

Giuliano, M. (2018). La “block chain” e gli “smart contracts” nell’innovazione del diritto nel terzo millennio. Il Diritto dell’informazione e dell’informatica, (6), 989-1039.

Lyons, T., Courcelas, L., Timsit, K. (2018). Blockchain and the GDPR, the European Union Blockchain Observatory and Forum.

Palladino, A. (2019). L’equilibrio perduto della blockchain tra platform revolution e GDPR compliance. Rivista di diritto dei media, (2), 144-158.

Piatti, L. (2018). “Blockchain”, decentralizzazione e “privacy”: un nuovo approccio del diritto. Ciberspazio e Diritto, (1-2), 179-196.

Rampone, F. (2018). I dati personali in ambiente “blockchain” tra anonimato e pseudoanonimato. Ciberspazio e Diritto, (3), 457-478.

Razzini, A. (2018). “Blockchain” e protezione dei dati personali alla luce del Regolamento europeo. Ciberspazio e Diritto, (1-2), 197-208.

Rühl G. (2019). The Law Applicable to Smart Contracts, or Much Ado About Nothing? Oxford business Law blog.

Solenne, V. (2019). Smart Contracts, P&S Legal. https://www.pandslegal.it/tecnologie-ict/smartcontracts/