È aperto il dibattito sulle implicazioni giuridiche in materia di diritto contrattuale degli smart contract basati su blockchain. Infatti, questi possono essere utilizzati per l’automatico adempimento di prestazioni contrattuali o per la conclusione di contratti in forma di linee di codice: dunque l’idea di fondo è che delle macchine possano rimpiazzare l’uomo, in quanto ritenute più affidabili e incorruttibili. La blockchain, a causa del suo carattere decentralizzato e della sua natura immutabile, avvalorerebbe tale assunto. Per quanto concerne la formazione del contratto, ci si concentra primariamente sullo scambio tra offerta e accettazione, sul tempo di conclusione del contratto, sull’intenzione dei contraenti e sulla forma del contratto. Anche la Direttiva 2000/31/CE sul commercio elettronico e la Direttiva 2011/83/UE in materia di consumatori acquisiscono rilevanza: vediamo perché.
L’uso degli smart contract
Gli smart contracts, a discapito dell’espressione, non sono necessariamente contratti. Uno smart contract di per sé è un codice informatico che, al verificarsi di una specifica condizione, si esegue automaticamente. Questo codice può essere memorizzato ed elaborato su una blockchain e ogni modifica viene registrata nella blockchain. Ogni operazione, in teoria, può essere automatizzata per mezzo di uno smart contract. Ad esempio, un termostato intelligente che regola la temperatura all’interno di una casa secondo le impostazioni prestabilite è uno smart contract.
Pertanto, quando gli smart contract sono utilizzati nel settore contrattuale, si è suggerito di parlare di “smart legal contract”. Ma, anche in quest’ultimo caso, gli smart contract non sono sempre contratti. Infatti, come da definizione giuridica, un contratto è “l’accordo di due o più parti per costituire, regolare o estinguere tra loro un rapporto giuridico patrimoniale” (art. 1321 cc). Quindi, l’accordo tra le parti costituisce il presupposto irrinunciabile per la formazione di un contratto, che viene raggiunto attraverso lo scambio di un’offerta e un’accettazione. Se quest’ultimo scambio avviene on-chain, lo smart contract può essere considerato un contratto, in quanto espressione di quell’accordo. Se, contrariamente, lo smart contract viene caricato sulla blockchain quando l’accordo è già stato raggiunto ed estrinsecato in altra forma, esso diviene un mero mezzo di esecuzione di un contratto tradizionale.
Sulla blockchain, la proposta può essere rappresentata dall’upload di uno smart contract ad opera di un soggetto proponente. In questo caso, lo smart contract, in combinazione con la blockchain, è lo strumento attraverso il quale un utente esprime una volontà contrattuale. L’offerta deve contenere tutti gli elementi di un contratto valido. Altrimenti, non c’è un’offerta, ma un invito a proporre. Un’offerta può essere indirizzata ad uno o più destinatari determinati. In alternativa, può essere indirizzata al pubblico (offerta al pubblico, ex art. 1336 cc). In una blockchain, ciò dipende dalla possibilità di uno o più partecipanti di interagire con lo smart contract. Più specificamente, e da un punto di vista tecnico, se questa possibilità è consentita ad un indirizzo specifico (o wallet, o account), l’offerta è indirizzata a uno specifico partecipante della blockchain. Nel caso opposto, ogni partecipante alla blockchain può inviare transazioni, quindi l’offerta è rivolta ad un destinatario indeterminato. Per quanto riguarda l’accettazione, essa non deve soddisfare alcun requisito specifico, a parte l’accordo dell’accettante su tutti i termini dell’offerta. Pertanto, una volta che l’offerente ha caricato lo smart contract, il destinatario può accettare il contratto firmando una transazione corrispondente con la propria chiave privata e inviarla all’account dello smart contract.
Se la dichiarazione dell’accettante non fa riferimento a tutti i termini dell’offerta o non acconsente ai termini precisi dell’offerta, non si tratta di un’accettazione ma piuttosto di una controproposta. In quest’ultimo caso, la controproposta deve essere seguita da un’accettazione per poter formare un contratto. Qui, il problema è l’immutabilità della tecnologia blockchain. Infatti, il codice dello smart contract non può essere modificato nella blockchain. Di conseguenza, non c’è altra opzione che accettare (o non accettare) l’offerta. L’accettante dovrebbe caricare un nuovo smart contract sulla blockchain. Il caricamento corrisponderebbe a una nuova offerta e l’accettante diverrebbe offerente. L’accettazione può avvenire anche in assenza di una dichiarazione specifica quando è implicita nella condotta dell’accettante. Più precisamente, se l’accettante inizia ad eseguire il contratto, le sue azioni possono essere considerate come una valida accettazione dell’offerta (art. 1327 cc). È richiesto un comportamento inequivocabile dell’accettante che dimostri una chiara accettazione. In blockchain, per esempio, comunicare con lo smart contract attraverso l’invio di un certo ammontare di criptovalute può essere considerato accettazione del contratto.
Tempo di conclusione del contratto
Nei contratti conclusi mediante il mezzo informatico, la proposta e l’accettazione sono inviate o ricevute sotto forma di messaggi di dati per mezzo di indirizzi elettronici. Il contratto si ritiene concluso quando il messaggio elettronico che rappresenta l’accettazione raggiunge il sistema informatico del proponente ed è a questo accessibile, a meno che il proponente non dimostri di non essere stato in grado (senza colpa) di conoscere l’accettazione. Il tempo di conclusione del contratto è così determinato applicando le tradizionali regole del codice civile (art. 1326 cc, mitigato dall’art. 1335 cc) e tenendo presente il principio di equivalenza funzionale (sancito dal Model Law on Electronic Commerce prima, e dalla United Nations Convention on the Use of Electronic Communications in International Contracts, poi).
In blockchain, l’offerta e l’accettazione sono espresse sotto forma di messaggi di dati scambiati utilizzando degli indirizzi elettronici (cioè gli accounts che ogni utente deve creare per partecipare alla blockchain), attraverso una connessione ad Internet. Inoltre, l’offerente e l’accettante non utilizzano un mezzo di comunicazione istantaneo (come il telefono) ma sono assenti e tra l’offerta e l’accettazione passa un certo tempo. Pertanto, non c’è differenza con i contratti conclusi attraverso il mezzo informatico, dove l’offerta e l’accettazione sono inviate da un indirizzo elettronico o ricevute da un indirizzo elettronico sotto forma di messaggi di dati. Per questo motivo, si ritiene che la disciplina contrattuale che sancisce il momento di conclusione del contratto debba essere interpretata allo stesso modo, e il contratto formato on-chain si reputa concluso quando l’indirizzo elettronico dell’offerente riceve l’accettazione, a meno che l’offerente non dimostri di non aver potuto accedere al suo sistema informatico per motivi non dipendenti da sua colpa.
Rimane da stabilire quando l’accettazione si debba intendere accessibile al sistema informatico del proponente in blockchain. Sul punto, si ritiene che l’offerente riceve l’accettazione quando la transazione di accettazione del contratto raggiunge anche il suo nodo dopo essere stata validata. Infatti, le transazioni valide sono replicate in tutti i nodi del network. In caso di accettazione mediante inizio di esecuzione ai sensi dell’art. 1327 cc, il contratto è concluso nel tempo in cui ha avuto inizio l’esecuzione. L’applicazione di quest’ultima norma non pare necessitare di ulteriori interpretazioni nell’ambito degli smart contract basati su blockchain.
L’intenzione dei contraenti
Affinché si formi un contratto, non è sufficiente la coincidenza tra proposta e accettazione, ma occorre che le parti intendano vincolarsi giuridicamente mediante l’accordo. Tale intenzione potrebbe risultare dubbia quando un contratto è espresso con il linguaggio del codice, perché l’uomo medio non è in grado di comprenderlo. Secondo l’opinione prevalente, l’intenzione contrattuale deve essere oggettiva e non soggettiva, nel senso che non ha importanza l’intenzione interna della parte, le sue percezioni o la sua comprensione. Per tutelare l’affidamento della controparte e per preservare l’efficienza e la certezza giuridica dei rapporti contrattuali, l’accordo deve essere inteso dal punto di vista esterno di un osservatore ragionevole. Deve essere effettuata una valutazione obiettiva delle dichiarazioni o del comportamento della parte, tenendo conto delle circostanze del caso e del principio generale di buona fede.
Si presta particolare attenzione all’intenzione contrattuale quando le clausole sono redatte unilateralmente e non negoziate tra le parti, come avviene per i contratti di adesione. Ciò vale anche per i cd “wrap contracts”, contratti di adesione online, le cui tipologie più comuni sono i contratti “click-wrap” e “browse-wrap”. Essi sono presentati e conclusi in un modo non tradizionale. Infatti, in un accordo click-wrap, i termini sono presentati su una pagina web, e l’altra parte deve cliccare su un pulsante virtuale per accettare. In un accordo browse-wrap, i termini sono accessibili tramite collegamenti ipertestuali (“Condizioni di utilizzo”, o “Terms of use”) e l’utente accetta di utilizzare un sito web o di scaricare un contenuto digitale, senza dover cliccare il pulsante di accettazione o intraprendere qualsiasi altra azione positiva. È oggi generalmente riconosciuto che la parte che redige il contratto deve adottare misure ragionevoli per portare all’attenzione dell’altra parte le condizioni contrattuali al momento o antecedentemente alla conclusione del contratto. A questo proposito, i termini devono essere presentati in modo chiaro e comprensibile all’uomo medio.
Chiarito ciò, si ritiene che il solo fatto che il contratto sia espresso in codice informatico non sia sufficiente ad escludere la presenza della volontà della parte di vincolarsi contrattualmente. La parte accettante è tenuta ad informarsi e a comprendere le conseguenze delle proprie azioni prima di accettare l’offerta. Devono invece essere considerate le circostanze che hanno preceduto la conclusione del contratto, e le qualità della parte accettante. Come per i contratti di adesione, i termini contrattuali predisposti sotto forma di linee di codice in blockchain possono essere o accettati in toto o non accettati affatto, a causa dell’immutabilità della blockchain che impedisce di modificarne le condizioni. Il contratto viene redatto unilateralmente. Si osserva inoltre un’analogia con i wrap contracts a causa del modo non tradizionale di esprimere il consenso. Infatti, una volta che l’offerente ha caricato il codice dello smart contract sulla blockchain, il destinatario può accettarlo inviando alcuni dati all’indirizzo dello smart contract (ad esempio, firmando una transazione di accettazione con una chiave privata o trasferendo una certa quantità di criptovalute). Riepilogando, solo una parte redige i termini del contratto, utilizzando un linguaggio non comprensibile (almeno per l’uomo medio), e tali termini sono accettati in modo non tradizionale.
Per queste ragioni, si sostiene che l’offerente debba accompagnare il codice con una versione in linguaggio naturale dei termini, in modo chiaro e comprensibile. Inoltre, l’altra parte dovrebbe avere l’opportunità di capire il momento in cui sta per concludere un contratto, per esempio mediante la predisposizione di un apposito pulsante virtuale di accettazione. A tal fine, anche la distinzione tra contratti B2B e B2C è rilevante. I professionisti hanno di solito più potere contrattuale dei consumatori. Ad esempio, possono avere maggiori possibilità economiche di consultare un esperto in grado di comprendere il linguaggio del codice. Può anche accadere che il contratto venga concluso sulla base di un accordo quadro preesistente che stabilisce l’oggetto principale dei contratti futuri e le modalità della loro conclusione mediante blockchain.
La direttiva sul commercio elettronico e la direttiva sui diritti dei consumatori
La Direttiva 2000/31/CE sul commercio elettronico e la Direttiva 2011/83/UE sui diritti dei consumatori nei contratti a distanza e nei contratti negoziati fuori dei locali commerciali includono alcune regole che si applicano prima o al momento dell’invio di un ordine online. È quindi importante verificare se queste regole sono applicabili anche alla formazione di smart contract basati su tecnologia blockchain. La Direttiva sul commercio elettronico ravvicina alcune disposizioni nazionali sui servizi della società dell’informazione anche per quanto riguarda i contratti elettronici, ossia i contratti conclusi a distanza e per via elettronica (art. 2, par.1, lett a). I “mezzi elettronici” si riferiscono a “[…]apparecchiature elettroniche di elaborazione (…) e di memorizzazione di dati” (considerando 17). Sulla base di queste definizioni, non vi sono pertanto ostacoli all’applicazione della direttiva. Infatti, l’offerente e l’accettante non utilizzano un mezzo di comunicazione istantaneo ma sono assenti e tra l’offerta e l’accettazione intercorre un certo lasso tempo. Inoltre, l’offerente carica uno smart contract e il destinatario accetta il contratto inviando un messaggio di dati al codice dello smart contract. Entrambe le parti utilizzano un’infrastruttura a chiave pubblico/privata e una connessione ad Internet. Un registro elettronico distribuito e decentralizzato (la blockchain) elabora e memorizza il caricamento dell’offerente, la transazione di accettazione e il conseguente cambiamento di stato dello smart contract.
Analogamente, la Direttiva sui diritti dei consumatori si applica ai contratti a distanza, ossia “qualsiasi contratto concluso tra il professionista e il consumatore nel quadro di un regime organizzato di vendita o di prestazione di servizi a distanza senza la presenza fisica e simultanea del professionista e del consumatore, mediante l’uso esclusivo di uno o più mezzi di comunicazione a distanza fino alla conclusione del contratto” (art. 2, par. 1, n. 7). Il considerando 20 include anche gli ordini mediante Internet come mezzi di comunicazione a distanza, e altre disposizioni si riferiscono esplicitamente ai contratti a distanza conclusi per via elettronica (v. art. 8, par. 2 e art. 11, par. 3). Dunque, anche la presente direttiva è applicabile.
Chiarito ciò, entrambe le direttive stabiliscono alcuni obblighi informativi che il prestatore o il professionista devono fornire al destinatario del servizio o al consumatore. L’articolo 10 della Direttiva sul commercio elettronico (attuato in Italia con l’art. 12 del D.Lgs. 70 del 9 aprile 2003) stabilisce che tali obblighi informativi non sono obbligatori nei contratti B2B, mentre quelli stabiliti dalla Direttiva sui diritti dei consumatori (e trasposti all’art. 49 del Codice del Consumo) si riferiscono solo ai contratti B2C. L’articolo 10 della Direttiva sul commercio elettronico stabilisce inoltre che la disposizione non si applica ai contratti conclusi esclusivamente per scambio di posta elettronica o tramite comunicazioni individuali equivalenti. Ci si potrebbe chiedere se la modalità di conclusione di contratti on-chain possa essere considerata una comunicazione individuale equivalente al pari della posta elettronica. A questo proposito, è stato già chiarito che in blockchain l’offerente può indirizzare la sua offerta verso uno (o più) destinatari specifici o verso il pubblico. Nella prima ipotesi, solo gli indirizzi corrispondenti ai destinatari individuati possono interagire con il codice dello smart contract, mentre nella seconda ogni partecipante alla blockchain può inviare messaggi di dati al codice dello smart contract. Quando l’offerente indirizza l’offerta verso uno (o più) destinatari determinati si crede che il contratto sia concluso con una forma di comunicazione individuale equivalente alla posta elettronica. Infatti, il fatto che l’offerente indichi uno (o più) indirizzi specifici significa che ha già identificato il destinatario (o i destinatari) dell’offerta.
Nel caso opposto, il destinatario dell’offerta è indifferente all’offerente, come quando un professionista rende disponibile la sua offerta su un sito web. Pertanto, si presume che quando l’offerente indirizza la sua offerta a uno (o più) destinatari determinati, gli obblighi informativi di cui all’art. 10 della Direttiva sul commercio elettronico non si applicano. Forse, questa forma di comunicazione individuale è più frequente nelle blockchain permissioned perché si tratta di sistemi chiusi con partecipanti noti. Un’altra questione è se questi obblighi informativi possano essere espressi nel linguaggio informatico. Su questo punto, si individuano due ostacoli principali, uno tecnico e uno giuridico. Per quanto riguarda il primo, qualcuno ha osservato che non tutte le condizioni contrattuali sono traducibili in linee di codice. Esistono infatti delle condizioni contrattuali descrittive, non operative, come quelle che determinano la legge o la giurisdizione applicabile. Allo stesso modo, i requisiti informativi richiedono un linguaggio descrittivo. Da un punto di vista giuridico, entrambe le direttive sottolineano l’importanza della trasparenza delle informazioni da fornire. L’art. 5, par. 2, della Direttiva sul commercio elettronico stabilisce che “ogniqualvolta i servizi della società dell’informazione facciano riferimento ai prezzi, questi siano indicati in modo chiaro e inequivocabile”; l’art. 10 della medesima direttiva prevede che le informazioni siano fornite dal prestatore “in modo chiaro, comprensibile e inequivocabile”. L’art. 6 della Direttiva sui diritti dei consumatori stabilisce che il fornitore deve fornire al consumatore le informazioni “in maniera chiara e comprensibile”.
Gli obblighi informativi
Con l’avvento di Internet e lo sviluppo del commercio elettronico, le persone hanno iniziato a condurre i loro affari senza conoscere l’identità della controparte e senza la possibilità di testare direttamente la qualità dei servizi e dei prodotti desiderati. Infatti, Internet è una rete aperta che permette la comunicazione tra sconosciuti, i quali concludono contratti navigando su siti web messi a disposizione dalle aziende o da piattaforme intermediarie mediante icone e pulsanti virtuali che possono disorientarli. Ciò ha determinato una mancanza di fiducia nel commercio elettronico. Per questo motivo, il diritto contrattuale tradizionale è stato affiancato da ulteriori norme per incoraggiare la contrattazione elettronica. Tra queste, gli obblighi informativi stimolano la consapevolezza dell’altra parte circa la rilevanza giuridica delle proprie azioni e il contenuto del contratto. In altre parole, sono volti ad aumentare la fiducia nei contratti elettronici e a distanza. Un livello di protezione più elevato è necessario nei contratti B2C, in cui il consumatore è la parte più debole, e nei contratti conclusi mediante accesso a un sito web perché l’identità dell’offerente è sconosciuta e i termini del contratto sono predisposti unilateralmente. Perciò, secondo la Direttiva sul commercio elettronico, gli obblighi di informazione sono inderogabili nei contratti B2C e applicabili a tutti i contratti non conclusi mediante posta elettronica o altro mezzo di comunicazione individuale equivalente. Quest’ultima modalità di conclusione del contratto è più adatta alle parti che si conoscono già e che sono entrambe coinvolte nel processo di redazione del contratto. Discorrendo circa l’intenzione dei contraenti, è già stato ipotizzato che i contratti legali intelligenti dovrebbero essere forniti anche in linguaggio naturale quando le parti hanno un diverso potere contrattuale (come ad esempio nei contratti B2C), il contratto è redatto unilateralmente e la parte accettante non ha la capacità di comprendere il linguaggio del codice. In questo modo, la parte viene considerata ragionevolmente intenzionata a concludere un contratto. Sulla base del medesimo ragionamento, si ritiene che anche gli obblighi informativi dovrebbero essere predisposti in linguaggio naturale (in modo chiaro, inequivocabile e comprensibile) almeno nei casi in cui gli stessi sono inderogabili, cioè nei contratti B2C e quando la modalità di conclusione on-chain non può essere equiparata ad una comunicazione individuale equivalente.
Infine, poiché gli obblighi informativi hanno lo scopo di rafforzare la fiducia tra le parti, si potrebbe riflettere sulla loro necessità pratica quando i contratti sono conclusi mediante la blockchain, poiché gli smart contract si eseguono da sé senza possibilità di influire sulla loro esecuzione. La parte obbligata non potrebbe cioè controllare il sistema informatico che esegue il contratto in sua vece grazie al carattere immutabile della blockchain. Non ci sarebbe più il bisogno di fidarsi dell’altra parte – che non può evitare l’esecuzione – ma del codice.
Volendo escludere ogni considerazione relativa all’effettiva capacità della tecnologia blockchain di evitare il controllo della parte obbligata sull’esecuzione del contratto, che dovrebbe essere trattata separatamente, gli obblighi informativi non riguardano solo l’identità della parte obbligata o il suo indirizzo geografico di stabilimento – che ne consentono l’identificazione utile in caso di controversia – ma anche i prodotti e i servizi offerti, i prezzi, le fasi tecniche da seguire per la conclusione del contratto, le modalità di accesso ai termini del contratto, i mezzi tecnici per identificare e correggere gli errori di input prima di inoltrare l’ordine, le lingue del contratto, e così via. In breve, gli obblighi informativi cercano di rafforzare la consapevolezza della parte più debole in modo da riequilibrare lo squilibrio negoziale tra le parti e favorire così il commercio elettronico. Pertanto, anche se da un lato la parte potrebbe essere effettivamente più sicura che il contratto venga eseguito grazie alla blockchain, tuttavia tale tecnologia non può rimuovere il rischio della mancata coincidenza tra volontà della parte più svantaggiata e contenuto del contratto.
La ricevuta dell’ordine
L’art. 11 della Direttiva sul commercio elettronico (attuato in Italia con l’art. 13 del D. Lgs. 70 del 9 aprile 2003) stabilisce che, nel caso in cui il destinatario del servizio inoltri il proprio ordine, il prestatore deve accusare ricevuta dell’ordine del destinatario del servizio senza ingiustificato ritardo e per via elettronica. Quest’obbligo non aggiunge nulla alla tradizionale modalità di conclusione del contratto mediante lo scambio tra offerta e accettazione, ma ha lo scopo di dare certezza circa la conclusione del contratto perché il destinatario è lontano e non può sapere con certezza se l’ordine è arrivato a destinazione. L’avviso di ricevimento non è obbligatorio nei contratti tra professionisti e non si applica ai contratti conclusi esclusivamente mediante scambio di posta elettronica o comunicazioni individuali equivalenti. Le ragioni di tali deroghe sono le stesse di quelle relative agli obblighi informativi. In breve, in queste situazioni, la conclusione del contratto è meno rischiosa per il destinatario e quest’ultimo può capire più facilmente se e quando un contratto è stato concluso.
La norma non desta particolari problemi applicativi relativamente al tema che qui interessa. Si potrebbe considerare che il carattere distribuito della blockchain potrebbe contribuire a svolgere la funzione dell’avviso di ricevimento, ossia quella di rilevare la ricezione dell’ordine. Infatti, dopo la validazione, la transazione di accettazione viene replicata nei nodi della blockchain, divenendo visibile anche al mittente. Quindi, la blockchain potrebbe essere utile per provare il ricevimento dell’ordine e la conclusione del contratto.
La forma
Secondo i principi di informalità e di non discriminazione, internazionalmente riconosciuti, nulla osta alla conclusione di contratti nella forma di linee di codice. Quando la legge richiede alcune formalità per la validità dei contratti o per provarne l’esistenza, occorre invece, sulla base del richiamato principio di equivalenza funzionale, stabilire quando lo smart contract può soddisfare la forma scritta. La forma scritta richiede normalmente la firma del contratto, che nei contratti informatici diviene elettronica. Secondo l’art. 3, par. 1, n. 10 del Regolamento e-IDAS (Reg. UE 910/2014) le firme elettroniche sono “dati in forma elettronica, acclusi oppure connessi tramite associazione logica ad altri dati elettronici e utilizzati dal firmatario per firmare”. Il Regolamento disciplina tre tipologie di firma elettronica: la firma elettronica semplice (art. 3, par. 1, n. 10, Reg.), la firma elettronica avanzata (art. 3, par. 1, n. 11, Reg.) e la firma elettronica qualificata (art. 3, par. 1, n. 12, Reg.). Solo quest’ultima firma ha l’effetto equivalente di una firma autografa, mentre per le altre ogni valutazione è lasciata alla discrezionalità del giudice (art. 25, par. 2, Reg.).
Nella blockchain gli utenti firmano le transazioni con le loro chiavi private. Le transazioni sono messaggi di dati scambiati tra gli account degli utenti. Le transazioni di offerta e accettazione dello smart contract, dunque, possono essere considerate almeno come firme elettroniche semplici, poiché sia l’offerente che l’accettante collegano alcuni dati (la chiave privata) ad altri dati (le transazioni) e approvano le informazioni contenute in questi ultimi dati (offerta e accettazione). Le altre operazioni che determinano un cambio di stato dello smart contract e che richiedono la firma di transazioni sono mere firme tecniche. Le firme elettroniche qualificate devono essere create da un dispositivo qualificato per la creazione di firme elettroniche e devono essere basate su un certificato qualificato per le firme elettroniche.
Un dispositivo per la creazione di una firma elettronica qualificata è un software o un hardware configurato utilizzato per creare una firma elettronica che soddisfa i requisiti di cui all’Allegato II del Regolamento (art. 29, par. 1, Reg.). I requisiti dell’Allegato II riguardano essenzialmente la riservatezza e la sicurezza dei dati per la creazione della firma elettronica. Un certificato qualificato per la firma elettronica è un certificato, ossia un attestato che collega i dati di convalida della firma elettronica a una persona fisica e conferma almeno il nome o lo pseudonimo di tale persona (art. 3, par. 1, n. 14, Reg.). Esso è rilasciato da un prestatore di servizi fiduciari qualificato e soddisfa i requisiti di cui All’allegato I del Regolamento (art. 3, par. 1, n. 15, Reg.). Il certificato ha la funzione di collegare la firma a un soggetto identificato. Se il certificato è qualificato, vi è un livello di sicurezza più elevato nel collegamento tra un firmatario e una firma. Un prestatore di servizi fiduciari qualificato è una persona fisica o giuridica che fornisce servizi fiduciari qualificati e riceve lo status qualificato dall’organismo di vigilanza (art. 3, par. 1, n. 20, Reg.).
Nonostante il principio della neutralità tecnologica e l’elaborazione di un elenco di requisiti generici, un elemento essenziale di un certificato è un particolare sistema di firma elettronica, ossia l’infrastruttura a doppia chiave pubblico/privata (PKI), che viene utilizzato anche in blockchain. Tuttavia, il wallet che detiene le chiavi dovrebbe soddisfare alcuni requisiti che garantiscano la riservatezza e la sicurezza dei dati di creazione della firma elettronica, e deve essere presente un certificato rilasciato da un fornitore di servizi fiduciari qualificato che attesti il legame tra le chiavi e una precisa identità. In caso contrario, la firma in blockchain non può ergersi al livello di una firma elettronica qualificata. Una firma elettronica può essere considerata avanzata se soddisfa i seguenti requisiti (ex art. 26 del Regolamento):
- è connessa unicamente al firmatario;
- è idonea ad identificare il firmatario;
- è creata mediante dati per la creazione di una firma elettronica che il firmatario può, con un elevato livello di sicurezza, utilizzare sotto il proprio esclusivo controllo;
- è collegata ai dati sottoscritti in modo da consentire l’identificazione di ogni successiva modifica di tali dati.
Si ritiene che l’uso della PKI nella blockchain soddisfi il primo requisito. La crittografia asimmetrica – cioè la chiave privata e la chiave pubblica che ogni utente detiene per effettuare le transazioni – è resistente all’accesso non autorizzato ai dati, quindi mantiene la riservatezza dei dati. Infatti, nella crittografia asimmetrica, la chiave utilizzata per crittografare i dati è diversa da quella utilizzata per decodificarli. Per questo motivo, la crittografia asimmetrica è più sicura della crittografia simmetrica, perché non è necessario condividere una chiave per decifrare un messaggio. La crittografia asimmetrica permette la verifica da parte del destinatario della provenienza e dell’integrità del messaggio ricevuto. Il mittente cripta i dati con la sua chiave privata e invia sia il messaggio criptato che il suo hash. Il destinatario decifra il messaggio con la chiave pubblica del mittente. Se il risultato è identico all’hash, il destinatario può essere sicuro che il messaggio proviene dal mittente e non è stato modificato da terzi.
Nelle blockchain permissioned, la possibilità di identificare il firmatario potrebbe determinare la soddisfazione del requisito b). Inoltre, le medesime soluzioni potrebbero anche soddisfare il terzo requisito, ad esempio attraverso l’adozione di token OTP o la biometria. Infine, il quarto requisito richiede controlli sull’integrità dei dati firmati anche dopo la sottoscrizione. Si sostiene che la natura immutabile della blockchain (grazie alla distribuzione e al richiamo all’hash del blocco precedente) combinata con l’uso della crittografia asimmetrica possa garantire l’individuazione di eventuali cambiamenti nel tempo. I dati sono collegati ad hash che li rappresentano in modo univoco. Ogni tentativo di manomissione causerebbe il cambiamento dell’hash e dei successivi hash nella catena.
La situazione in Italia
In Italia, il D. Lgs. n. 82 del 7 marzo 2005, o “Codice dell’Amministrazione Digitale” (CAD) considera un documento elettronico in forma scritta quando il firmatario lo firma utilizzando non solo una firma elettronica qualificata, ma anche una firma elettronica avanzata. Inoltre, lo stesso valore è riconosciuto alla firma digitale e ad un documento formato secondo i requisiti stabiliti dall’Agenzia per l’Italia Digitale (AGID) ai sensi dell’art. 71 del CAD, previa identificazione informatica del suo autore, in modo tale da garantire la sua sicurezza, integrità e immodificabilità e, in maniera manifesta e inequivoca, la sia riconducibilità all’autore (art. 20, co. 1-bis, CAD). La firma digitale è una firma elettronica qualificata peculiare dell’ordinamento giuridico italiano, che si avvale della crittografia asimmetrica. La firma elettronica avanzata è considerata equivalente alla firma autografa. Inoltre, l’AGID ha recentemente fissato le linee guida, ai sensi dell’Art. 71 del CAD, per la firma con il Sistema Pubblico per la gestione dell’Identità Digitale di cittadini e imprese (SPID).
La Legge 11 febbraio 2019, n. 12, di conversione del D.L. 14 dicembre 2018, n. 35 (“Decreto Semplificazioni”), all’art. 8-ter, co. 2, stabilisce che gli smart contract soddisfano il requisito della forma scritta previa identificazione informatica delle parti interessate, attraverso un processo avente i requisiti fissati dall’AGID con linee guida. La norma è molto simile all’art. 20, co.1-bis, del CAD nella parte in cui riconosce lo stesso valore legale delle firme autografe ai documenti formati secondo i requisiti stabiliti dall’AGID ai sensi dell’art. art. 71 del CAD. Tuttavia, a differenza dell’art. 20 del CAD, il Decreto Semplificazioni fa genericamente riferimento ad un processo previa identificazione delle parti senza stabilire alcun requisito (la cui determinazione è lasciata all’AGID, che ancora non ha provveduto a pubblicare alcunché). Inoltre, poiché l’articolo non considera le firme elettroniche, ci si chiede se l’AGID possa prevedere anche l’utilizzo di firme digitali, qualificate, o avanzate.
In tutti gli altri casi, l’art. 20, co.1-bis, del CAD prevede che l’idoneità a soddisfare il requisito della forma scritta può essere liberamente valutata dal giudice, in relazione alle sue caratteristiche di sicurezza, integrità e immutabilità. Forse i giudici potrebbero considerare che crittografia asimmetrica, hash e decentralizzazione del database sono idonei a garantire l’integrità e l’immutabilità del documento. La difficoltà maggiore è rappresentata dal fatto che nelle blockchain permissionless le chiavi non sono riconducibili a precise identità, a meno che il collegamento non sia altrimenti deducibile (ad esempio, se l’account viene citato in un documento indubbiamente ascrivibile ad un determinato soggetto).
