Blockchain e smart contract vanno normati con precisione per evitare i rischi connessi alle loro caratteristiche: per esempio costi elevati per l’una, natura trustless degli altri, possibilità di attacchi ai danni di entrambi con ripercussioni sugli utenti. La normativa attuale sembra essere tuttavia incompleta, nonostante le novità introdotte a febbraio 2019 con il Decreto Semplificazioni.
Questi strumenti tecnologici nel prossimo futuro potranno avere larga applicazione in molti campi: anche per questo motivo necessitano di una regolamentazione ragionata ed articolata. L’art. 8-ter del Decreto Semplificazioni che definisce giuridicamente queste tecnologie, costituisce sicuramente un incentivo all’introduzione delle nuove tecnologie nei processi di e-Government, ma occorre evitare che sulla spinta di un entusiasmo collettivo sull’argomento ci si concentri più sulle soluzioni che sui problemi. I quali, come i rischi, ovviamente non mancano.
Un quadro normativo incompleto
La legge di conversione del Decreto Semplificazione (Legge 11 febbraio 2019 di conversione del D.L. 14 dicembre 2018 n. 135) ha introdotto l’art. 8-ter, recante la rubrica “Tecnologie basate su registri distribuiti e smart contract”. Il comma 1 contiene la definizione di tecnologie basate su registri distribuiti, il comma 2 contiene la definizione di smart contract, il comma 3 detta una particolare disposizione in materia di validazione temporale. Infine il comma 4 del citato articolo assegna all’Agid il compito di individuare gli standard tecnici che le piattaforme di cui al comma 1 devono adottare per costituire validazione temporale opponibile ai terzi.
L’art. 8-ter si limita a contenere delle definizioni, che normalmente costituiscono solo l’inizio di un provvedimento normativo diretto a regolare le fattispecie che ne costituiscono oggetto. Qui invece le definizioni costituiscono l’inizio e la fine dell’intervento del legislatore, per cui sembra lecito attendersi in futuro ulteriori norme precettive.
I volti e i rischi della blockchain
Tralasciando qui ogni considerazione sulla formulazione letterale della definizione di blockchain, la prima considerazione è che le blockchain aperte o permissionless (come Bitcoin o Ethereum) si sottraggono ad ogni forma di regolamentazione o autorità, mentre, d’altro canto, l’utilizzo di registri distribuiti quando unica è la governance ha solo l’effetto di aumentare i costi di gestione della piattaforma. In questo ultimo caso, un database tradizionale si rivela più efficiente ed economico.
La blockchain giustifica i suoi costi soltanto quando è utilizzata da più soggetti che, in assenza di una terza parte fidata, decidono di condividere un registro che ognuno alimenta autonomamente, secondo regole proprie, ma che nessuno può alterare. Le blockchain private o permissioned hanno quindi campi di applicazione ben precisi e limitati e per essi va attentamente valutata la convenienza in base al costo (di realizzazione, manutenzione e gestione) e alle prestazioni rispetto a soluzioni basate su altre tecnologie.
Smart contract, né smart né contract
Passando invece all’analisi del secondo comma, dopo 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 norma prosegue disponendo 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”.
Sembra fin troppo ovvio che il modello preso in considerazione sia quello di Ethereum, piattaforma blockchain su cui operano smart contract aventi ad oggetto token digitali, che possono rappresentare ogni tipo di asset. Il legislatore, forse ingannato da una traduzione letterale della locuzione smart contract, arriva a considerarli forma scritta, purché sia possibile identificare le parti. Ma a ben vedere gli smart contract non sono smart e tanto meno contract e attribuire loro il valore di cui all’articolo 2702 del codice civile (che norma l’efficacia della scrittura privata) sembra davvero troppo.
Non sono contract perché a differenza di un vero contratto non sono scritti in linguaggio naturale ma in un linguaggio formale codificato. Si tratta appunto di software (“programma”, come dice la norma): puro codice che, al ricorrere di determinate condizioni, esegue le prestazioni previste senza la collaborazione delle parti. Ancora, gli smart contract non sono contratti perché possono solo sostituire la parte esecutiva di un contratto, certamente non tutta la parte semantico-descrittiva con le pattuizioni collaterali. Non sono smart: la parola sembrerebbe implicare che essi siano intelligenti. In realtà, non lo sono affatto. Ciò che li fa considerare smart è il fatto di essere trustless, cioè di consentire la contrattazione tra soggetti che non si fidano gli uni degli altri senza l’intervento di intermediari, eliminando l’inadempimento contrattuale e quindi anche il ricorso ai giudici. In realtà, hanno il difetto esattamente opposto. Infatti, al ricorrere delle condizioni previste, eseguono inevitabilmente le prestazioni contrattuali, anche eventualmente contro l’intenzione originaria delle parti.
Il compito del legislatore
La vicenda TheDAO, in cui un baco nel software ha consentito la sottrazione di svariati milioni dai fondi investiti, riassume tutti i limiti della tecnologia degli smart contract.
Quello che dunque ci si attende da un legislatore che voglia regolare gli smart contract non è quindi una frettolosa equiparazione alla forma scritta, che lascia poi ai giudici l’onere di risolvere le controversie che un semplice errore nella programmazione può causare. Occorre definire ambiti di applicazione, ruoli e responsabilità.
