- Dagli automi finiti agli smart contract
Il termine “smart contract” viene coniato per la prima volta nel 1996 da Nick Szabo (Nick Szabo, Smart Contracts: Building Blocks for Digital Markets, 1996) e quindi ancor prima dell’introduzione della blockchain.
L’idea originaria era che una serie di clausole potevano essere incorporate nell’hardware e nel software con cui ci relazioniamo, in modo da rendere gravoso l’inadempimento. Partendo dal funzionamento degli automi finiti (ossia dei circuiti che realizzano le espressioni booleane) Szabo proponeva l’introduzione di contratti da agganciare ai diritti di proprietà di beni digitali, regolati automaticamente proprio dai contratti, in modo da ridurre le ipotesi di inadempimento e ridurre i rischi per le parti.
L’autore suggeriva anche l’uso di tecniche crittografiche e di firme elettroniche per rendere sicure le transazioni nonché riconducibili ai soggetti che le ponevano in essere.
Quando si utilizza il termine smart contract usualmente si fa riferimento a due principali categorie concettuali:
- La prima è riferita agli aspetti operativi, con riferimento agli agenti software che tipicamente, ma non necessariamente, sono attestati su una blockchain. In questo caso la parola contratti è utilizzata in relazione alla capacità che questi agenti software hanno di eseguire automaticamente alcune azioni inerenti ad obbligazioni e diritti e possono controllare determinati asset su un registro condiviso;
- La seconda categoria è riferita a come gli smart contract possono essere espressi e realizzati tramite il software. Questo comporta l’analisi di come possono essere redatti i contratti e come il linguaggio legale possa essere interpretato.
Lo sforzo interpretativo che oggi siamo chiamati a compiere con l’utilizzo della blockchain è quello di riuscire a sintetizzare le due categorie, riuscendo a costruire contratti che siano automatizzabili ed eseguibili da un computer, ma al contempo protetti dalla disciplina normativa che potrebbe andare a colmare quelle parti di accordo che non sono automaticamente eseguite all’interno della blockchain.
Ed infatti, sulla scorta di quella che oggi è la prassi contrattuale, appare evidente la difficoltà di poter presentare innanzi ad un tribunale un contratto che sia redatto unicamente sulla base di un linguaggio di programmazione. Ciò sia per l’impossibilità da parte del giudice di poter immediatamente comprenderne il significato, sia in quanto, in termini strettamente giuridici, in verità non tutte le clausole di un contratto possono essere facilmente tradotte in tali linguaggio, in quanto contengono formule sintattiche e semantiche complesse che non si limitano a prevedere l’esecuzione di una certa azione al verificarsi di un determinato evento.
La ricerca di strumenti che possano condurre ad un’interpretazione e redazione uniforme dei contratti inizia, in verità, già dal 1956 e percorre un cammino in cui, di volta in volta, cerca di servirsi degli strumenti della logica (calcolo proposizionale, logica simbolica, calcolo modale).
Oggi sono presenti varie proposte che si concentrano prevalentemente nella formalizzazione di soluzioni per riuscire ad adeguare le complessità del linguaggio giuridico alle esigenze di una interpretazione “automatica” da parte di un computer (CommonAccord, Legalese, Monax’s Dual integration ed i Ricardian Contract).
In particolare nel 1990 erano stati proposti i Ricardian Contracts, che potremmo considerare i veri e propri predecessori degli smart contract così come intesi nel contesto blockchain, ossia dei design pattern volti ad individuare le intenzioni delle parti prima dell’esecuzione del contratto. Questo attraverso la creazione di apposite classi (attraverso un linguaggio Object Oriented) per gestire le varie tipologie di contratto necessarie. La lettura del riferimento (costituito da una funzione di hash crittografica) riuscirebbe a far comprendere la tipologia di clausola contrattuale corretta per il caso specifico, richiamando la relativa classe al fine della costruzione dell’oggetto contenente la regola pattizia necessaria a regolare l’accordo tra le parti.
Attraverso la tripla “prose, parameters and code” la prosa legale verrebbe collegata tramite determinati parametri al codice dello smart contract al fine di consentirne l’automazione.
- Smart contract tra codice software e diritto
Per poter dar conto però delle possibili soluzioni, occorre innanzitutto analizzare il contenuto tipico di un contratto.
In via generale negli accordi scritti si rinvengono due tipi di contenuti: a) quelli relativi agli aspetti operativi, ossia specifiche azioni che le parti devono porre in essere in esecuzione del contratto e che abbiamo interesse ad automatizzare; b) quelli relativi ad aspetti non operativi la cui automazione non assume particolare rilevanza.
In termini linguistici la semantica degli aspetti non operativi può essere molto complessa, mentre la prima tipologia di aspetti appare più facilmente traducibile in linguaggio di programmazione.
Nel contesto di un contratto si trovano così clausole che specificano gli obblighi delle parti e le azioni che le stesse devono intraprendere, altre che disciplinano le regole da applicare in caso di inadempimento, altre ancora definiscono la legge applicabile, il foro competente. Vi sono poi gli elementi accessori, quali le condizioni ed i termini (che si prestano più facilmente ad una automazione), così come una serie di clausole definitorie rispetto a come debbono intendersi alcuni termini inseriti nell’accordo.
Sulla base di tali considerazioni sono stati proposti nel settore finanziario dei formalismi, derivati dai Ricardian Contracts, basati su dei template al fine di standardizzare i documenti contrattuali. In particolare, un template sarebbe una rappresentazione elettronica di un documento legale contenente sia una parte in prosa sia dei parametri. Ogni parametro avrebbe un identificativo univoco, un tipo e dei valori al proprio interno.
Aumentando la complessità dei parametri si riuscirebbe a riportare in un linguaggio eseguibile dalla macchina le intenzioni delle parti, in modo da renderle automaticamente eseguibili. Così mentre alcuni parametri potrebbero essere considerati come “dati primitivi” altri potrebbero avere natura più complessa, come liste, fino a poter contenere vere e proprie espressioni intese come funzioni (come ad esempio il calcolo degli interessi giornalieri). Il parametro, inoltre, potrebbe far riferimento ad un elemento esterno, valorizzato tramite i dati ricevuti da un oracolo.
La soluzione, seppur può contribuire ad una più agevole trasposizione delle regole contrattuali in codice software, di certo non risolve il problema della varietà del contenuto semantico contenuto nei contratti.
In particolare, costruire delle clausole attraverso la definizione di parametri può apparire semplice per quelle previsioni che afferiscono ad eventi o elementi numericamente certi (un termine, l’applicazione di un interesse, il pagamento di una somma, etc.), ma di certo non può considerarsi una metodologia risolutiva per il complesso contenuto di un contratto.
Tale risultato potrebbe risolversi con lo sviluppo di un linguaggio formale uniforme per la stesura dei contratti (che dovrebbe essere al contempo di facile interpretazione e scrittura, ma anche eseguibile dalla macchina). Il contratto, originariamente scritto in un linguaggio più naturale, così da renderlo producibile in giudizio, verrebbe tradotto automaticamente in codice software da attestare su una macchina in modo da ottenere uno smart contract.
L’ipotesi è suggestiva, ma a chi scrive sembra di difficile attuazione nel breve termine. Se solo si tiene a mente la complessità dei sistemi giuridici, le specificità di un sistema rispetto ad un altro e le esperienze ed i tentativi di standardizzazione anche all’interno di un solo contesto, appaiono evidenti gli ostacoli ed i problemi che sarebbe necessario superare (in Italia un tentativo di standardizzare gli atti societari ai fini della loro comunicazione al Registro Imprese è stato poi abbandonato per le difficoltà incontrate nel riuscire a far adottare dei template univoci da parte degli operatori).
L’utilizzo di marcatori XML all’interno del testo contrattuale potrebbe, forse, facilitare l’individuazione delle tipologie di clausole, ma non eliminerebbe la necessità di tradurre poi tali clausole in codice sorgente eseguibile da una macchina.
D’altra parte esempi di standardizzazione di clausole esistono già da tempo nel commercio internazionale (si pensi agli INCOTERMS dell’International Chamber of Commerce, ai principi UNIDROIT, oppure al lavoro dell’UNCITRAL) e consentono agli operatori di riferirsi in maniera sintetica ad un insieme di obbligazioni chiare e definite. Un’opera analoga potrebbe essere svolta con riferimento agli smart contracts provvedendo a codificare un insieme di clausole definite che abbiano come compito quello di formalizzare, a livello giuridico ed a livello software, una serie di obblighi che le parti possono tipicamente assumere nell’ambito dei singoli contratti.
D’altra parte i sistemi di machine learning, analizzando grandi quantità di documenti legali, potrebbero fornire un utile supporto a tale standardizzazione, riuscendo ad individuare ricorrenze e pattern idonei a standardizzare il contenuto della volontà delle parti producendo anche il codice software da riprodurre nello smart contract attestato sulla blockchain. Ciò però richiede sicuramente la specializzazione degli algoritmi anche sulla base della normativa applicabile.
- Smart Contract e disciplina civilistica del contratto
Allo stato attuale volendo tentare delle classificazioni si può ritenere che uno smart contract:
- Può accedere ad un contratto più ampio con cui le parti raggiungono degli accordi all’esterno di una blockchain e decidono di formalizzare tutte o parte delle fasi esecutive mediante stesura di uno smart contract. In questo caso lo smart contract è accessorio ad un più ampio accordo;
- Può disciplinare tutti gli accordi intercorsi tra le parti, esaurendo il rapporto nell’esecuzione delle azioni previste. Tale smart contract contiene l’intera regolamentazione del rapporto tra le parti e ne garantisce l’esecuzione;
- Può prevedere degli obblighi per una sola parte che li formalizza in uno smart contract che eseguirà le prestazioni al verificarsi di determinate condizioni. In tali casi la fattispecie sarebbe analoga all’offerta al pubblico, in cui una parte rimane vincolata alle proprie dichiarazioni che valgono come proposta di contrarre.
Secondo il nostro diritto un contratto per essere valido deve avere determinati requisiti, stabiliti dall’art. 1325 del codice civile, ossia l’accordo tra le parti, la causa, l’oggetto e la forma.
In merito all’accordo tra le parti l’ordinamento italiano regola doviziosamente il momento genetico dello stesso, chiarendo che in via ordinaria il contratto si conclude nel momento in cui chi fa la proposta viene a conoscenza dell’accettazione della controparte. Si tratta, evidentemente, di una disciplina nata per regolare i rapporti tra presenti o tra persone distanti e che scollega, in via generale, il momento formativo dell’accordo da quello della sua esecuzione (tranne che per i contratti reali che si concludono nel momento in cui la prestazione viene eseguita (ossia, tipicamente, con la traditio del bene oggetto del contratto) e che costituiscono un numero chiuso, nel senso che debbono essere espressamente regolati dalla legge come tali).
Il codice civile, d’altra parte, espressamente regola l’ipotesi in cui, su richiesta del proponente, per la natura dell’affare o secondo gli usi, la prestazione deve eseguirsi senza preventiva risposta, chiarendo che in tali casi il contratto è concluso nel periodo e luogo in cui ha avuto inizio l’esecuzione.
Anche gli smart contracts possono riflettere tale modalità di formazione dell’accordo. Nella prima ipotesi le parti possono aver già raggiunto un accordo che viene formalizzato in un apposito smart contracts ed eseguito al momento del verificarsi delle condizioni già previste da entrambe all’interno dello stesso. Lo smart contracts contiene l’intero accordo ed i riferimenti dei soggetti che lo hanno concluso, regolando così lo scambio di prestazioni tra le medesime.
Nel secondo caso lo smart contracts conterrà la disciplina delle prestazioni che il predisponente si impegna ad effettuare al verificarsi di determinati eventi; l’esecuzione delle stesse sarà automatica, indipendentemente dalla vera e propria manifestazione di consenso dell’altra parte. Sono queste le ipotesi in cui, ad esempio, lo smart contract provvede al trasferimento di assett digitali al verificarsi di una condizione specifica, quale il ricevimento di una criptovaluta.
I requisiti della causa e dell’oggetto di uno smart contract, così come disciplinati dal codice civile, non sembrano porre questioni differenti rispetto a quelle dei contratti “normali”, potendo applicarsi le medesime regole in entrambe i casi. In particolare, il riconoscimento delle valute virtuali come “rappresentazione digitale di valore” (d.l.vo n. 231/2007, art. 1, lett. qq) risolve ogni dubbio in merito alla individuazione dell’oggetto contrattuale nel caso di smart contract che prevedano transazioni di criptovalute.
Infine, con riguardo alla forma del contratto, richiamando quanto evidenziato nei paragrafi precedenti, uno smart contract tipicamente è scritto in codice software e viene attestato su una blockchain per poter provvedere alla sua esecuzione. Si tratta, pertanto, di un programma per elaboratore che, nel nostro ordinamento, è tutelato da disposizioni specifiche che trovano collocazione all’interno della legge sul diritto d’autore (L. n. 633/1941) e che assimilano i programmi per elaboratore alle opere letterarie. Questo potrebbe risolvere il problema relativo alla forma contrattuale di uno smart contract, ritenendo che il medesimo sia sempre un contratto formato per iscritto, essendo redatto in codice software.
D’altra parte, uno smart contract potrebbe essere definito come un documento informatico, ai sensi dell’art. 1 lett. p) del decreto legislativo d.l.vo n. 82/2005 (Codice dell’amministrazione digitale – C.A.D.) (secondo cui è documento informatico “il documento elettronico che contiene la rappresentazione informatica di atti, fatti o dati giuridicamente rilevanti”).
Ai sensi dell’art. 20 comma 1 bis del C.A.D. uno smart contract potrebbe soddisfare il requisito della forma scritta, sia per la facoltà di libera valutazione da parte del giudice di tale elemento sia in quanto, in alcune ipotesi, lo stesso potrebbe essere direttamente riferibile alle parti che lo hanno stipulato, tramite l’associazione alle firme elettroniche degli stessi.
Occorre considerare che la migliore dottrina sul formalismo giuridico dei contratti ha da tempo precisato che il contratto – anzi in genere il documento – è una res signata (un oggetto percebile recante dei segni) con cui è dato pronunciare il giudizio di esistenza di un fatto sussumibile sotto un tipo normativo. Il documento in sé però è solo il mezzo attraverso il quale si conservano le dichiarazioni delle parti; le parole ed i segni contenuti nel documento richiedono comunque un’attività indiretta da parte della mente umana, che deve comprenderle ed interpretarle per conferire loro significato, e, nel caso del diritto, effetti giuridici desumibili dalle norme.
Emerge quindi nuovamente il tema della forma dello smart contract, non come documento su cui il medesimo è creato, ma quale insieme di segni il cui significato sia intellegibile e direttamente riferibile alla volontà delle parti. Tale significato, ossia l’insieme delle parole di codice che servono per dar esecuzione allo smart contract, è sicuramente interpretabile in via immediata dalla macchina (anche virtuale) su cui il programma per elaboratore va in esecuzione; potrebbero però insorgere dei problemi in sede di interpretazione del contratto o qualora il codice non trasponga in maniera fedele le dichiarazioni dei contraenti.
E’ ipotizzabile, in questi casi, applicare la disciplina dell’annullabilità del contratto per errore (artt. 1428 a 1433 c.c.) soprattutto ove si tenga a mente che uno smart contract, come la gran parte dei software, non è altro che la traduzione in un linguaggio comprensibile ad un elaboratore di un percorso logico che si pone in un momento antecedente alla scrittura del programma stesso e che come tale richiede un’attenta formulazione e trasposizione delle dichiarazioni delle parti.
- Conclusioni
Dall’esame sopra compiuto appare evidente che allo stato attuale vi è ancora molta strada da fare per arrivare ad una standardizzazione e tipizzazione degli smart contract.
La strada che sicuramente appare più in grado di tutelare le parti che vogliano disciplinare i propri rapporti attraverso uno smart contract, è quella di accompagnare lo smart contract, anche qualora questo sia destinato a disciplinare interamente le obbligazioni tra le parti, ad un contratto “normale”, con cui le parti definiranno le proprie obbligazioni, i termini e le modalità di esecuzione del contratto, prevedendo anche, all’interno del medesimo, a formalizzare il codice che costituirà lo smart contract, attraverso l’espressa indicazione delle clausole che saranno trasposte nello stesso, gli obiettivi che le parti si prefiggono con tali clausole e strumenti per gestire anche eventuali errori di programmazione del software stesso. Nulla vieta inoltre, in sede di realizzazione del software, di utilizzare le apposite funzioni di commento del software illustrando direttamente all’interno dello stesso quali clausole contrattuali la porzione di codice rappresenta così da poter effettivamente “mappare” lo smart contract al contratto ed alla disciplina pattizia intercorsa tra le parti.
