Smart Legal Contract - Conversione di una scrittura privata
In questa pagina trovi...
Proseguendo il nostro percorso esplorativo, ci dedichiamo alla creazione di un nuovo smart contract. Proveremo a tradurre un modello di scrittura privata in codice informatico, perseguendo principalmente due finalità: comprendere in quale modo gli elementi essenziali del contratto possano trovare posto all’interno del codice e, analizzare vantaggi e limiti dell’operazione.
Questo contenuto rappresenta un pagina della sezione “Sviluppare uno Smart Contract” ed è fortemente consigliato seguire l’ordine di lettura proposto nella stessa. Il progetto rappresenta un percorso lineare che prevede la conoscenza delle nozioni e delle considerazioni emerse in precedenza.
Indice dei contenuti della pagina
Il contratto e il Codice civile
Questa parte iniziale è dedicati a te, amico informatico, cercheremo di vedere in modo semplice e lineare cosa sia effettivamente un contratto e cosa siano questi elementi essenziali, nonché la ragione di così tanta importanza nel mondo giuridico. I nostri lettori giuristi si sentano liberi di saltare questa parte, proseguendo alla voce “Il modello per l’esperimento”.
Partiamo innanzi tutto da cosa sia un contratto. Ognuno di noi conclude contratti ogni giorno, magari non ti soffermi a pensarci ma quando vai a fare la spesa, quando rinnovi l’abbonamento Netflix, quando porti la macchina dal meccanico, in ognuno di questi casi vi è un contratto anche se non firmi nulla.
La definizione precisa di contratto è contenuta nell’articolo 1321 del Codice civile:
Il legislatore è chiaro: due o più parti creano un nuovo rapporto o ne modificano uno precedente; il rapporto deve essere patrimoniale e non personale, ne consegue ad esempio che il matrimonio non possa essere considerato un contratto.
Il Codice civile definisce all’articolo 1325 quali siano gli elementi essenziali.
1) l'accordo delle parti;
2) la causa;
3) l'oggetto;
4) la forma, quando risulta che è prescritta dalla legge sotto pena di nullità."
In assenza di tali elementi il contratto è invalido e inefficace.
Detta in parole povere, puoi anche avere il tuo bel contratto cartaceo in mano ma se il giudice verifica l’assenza di uno di questi elementi, ti sentirai dire che non esiste alcun contratto.
Oltre agli elementi essenziali esistono anche gli elementi accidentali, questi sono: condizione, termine, onere (o modus). Questi elementi non devono essere necessariamente presenti, sarà discrezione delle parti decidere se inserirli all’interno del contratto o meno. Per ora non ci interessano, è sufficiente tenere a mente che esistono.
Analizziamo ora ciascun elemento essenziale. Ti prego di prestare attenzione al fatto che le definizioni che seguono sono sintetiche e semplificate; il Codice civile dedica 26 articoli all’argomento, ma non è mia intenzione scendere così nel dettaglio ma farti capire il nodo della questione.
Accordo: è l’incontro delle manifestazioni di volontà delle parti. Vi è quindi un soggetto che formula la proposta e un soggetto che esterna l’accettazione. Quando queste due volontà si incontrano l’accordo è concluso. (Disciplina “Dell’accordo delle parti” artt. 1326 e ss.)
Causa: termine dal significato assai diverso dal quello inteso nel parlato comune e da non confondere con i motivi soggettivi che hanno portato le parti alla conclusione del contratto. Spesso viene definita come funzione economica – sociale del contratto, in sostanza delinea gli effetti che il contratto è in grado di produrre. Ad esempio, se vai in libreria e acquisti un libro, in questo caso la funzione del contratto, e quindi la causa, è “scambio di un bene (libro) con il prezzo (importo pagato)”. (Disciplina “Della causa del contratto” artt. 1343 e ss.)
Oggetto: sono le prestazioni che le parti si impegnano ad eseguire. Il Codice stesso stabilisce quali siano i requisiti che l’oggetto deve possedere per poter essere ritenuto idoneo: possibile, lecito, determinato o determinabile. (Disciplina “Dell’oggetto del contratto” artt. 1346 e ss.)
Forma: è il mezzo con il quale la volontà delle parti viene manifestata. Questa rileva solamente quando espressamente stabilito dalla legge. Questo significa che, se nulla è stabilito dalla legge, le parti sono libere di stipulare il contratto anche in forma orale senza che venga meno la validità dello stesso. Attenzione al fatto che la forma deve investire tutti gli elementi del contratto. Questo significa che se stipuliamo un contratto in forma scritta non è ammesso stabilire l’oggetto in forma orale, sarà necessario che anche l’oggetto compaia in forma scritta. (Disciplina “Della forma del contratto” artt. 1350 e ss.)
Il modello per l'esperimento
Una delle finalità del contenuto di oggi è verificare se possano essere rispettate le disposizioni del Codice civile in materia di contratto, nello specifico art. 1325. Per fare ciò seguiremo questi step:
1- creazione di un modello di contratto in forma tradizionale;
2- individuazione degli elementi essenziali all’interno di esso;
3- traduzione del contratto in codice informatico;
4- verifica della presenza degli elementi essenziali del contratto all’interno dello smart contract.
Per riuscire con successo in questo esperimento è essenziale concentrarsi sull’obiettivo evitando inutili distrazioni. Per tale ragione lo smart contract(SC) creato avrà un aspetto sperimentale, ben lontano da quello di uno SC che può essere trovato su blockchain. Una delle caratteristiche alle quali saremo costretti a rinunciare sarà la famosissima automaticità della prestazione, ma non temere, sarà oggetto di futuri contenuti. Tra gli obiettivi dell’esperimento vi è anche verificare quali siano le conseguenze di un approccio rigido alla materia, e cosa può comportare usare lo strumento forzandolo a digitalizzare qualcosa di analogico invece che predisporre una struttura ad hoc.
Senza indugio definiamo il caso.
Le parti del contratto sono Tizio e Caio. Il primo, proprietario di una bellissima macchina da cucire Singer dei primi del 900; il secondo, appassionato di antiquariato e desideroso di poter esibire una macchina da cucire nel proprio studio. Le due parti si accordano per la cifra di 650 euro, redigono quindi una scrittura privata che sottoscrivono il giorno stesso. Siamo quindi di fronte ad un contratto di compravendita, con Tizio nella parte del venditore e Caio come acquirente.
Articolo 1470 del Codice civile. Nozione:
La compravendita è un contratto tipico, questo significa che è disciplinato in tutti i suoi aspetti dal Codice civile. Il contratto tipico, a differenza di quello atipico (delineato dalle parti in base alle specifiche necessità) trova delle regole prefissate dal legislatore. Le parti non saranno quindi costrette a prevedere ogni possibile problema che potrebbe insorgere determinando una specifica regola, in caso di controversia il giudice utilizzerà le disposizioni del Codice civile per la risoluzione della stessa.
Ecco il modello che useremo come linea guida per lo smart contract.
CONTRATTO DI COMPRAVENDITA DI BENE MOBILE
Con la presente scrittura privata, da valersi ad ogni effetto di legge,
tra
– il Sig. Tizio, nato a … il …, e residente in …, C.F. …,
in qualità di proprietario e venditore
e
– il Sig. Caio, nato a … il …, e residente in …, C.F. …,
in qualità di acquirente
premesso che
(I) – il sig. Tizio è proprietario di una macchina da cucire Singer del 1905,
(II) – la macchina da cucire ha vernice originale e non è mai stata restaurata,
(III) – il prezzo concordato per la macchina da cucire è di euro 650,00.
si conviene e si stipula quanto segue:
Art. 1
Il sig. Tizio dichiara di trasferire ai sensi dell’art.1470 c.c. la macchina da cucire, di cui al punto (I) delle premesse, al sig. Caio che accetta la proprietà del bene verso corrispettivo di cui al punto (III) delle premesse.
Art. 2
Il sig. Caio paga il prezzo di cui al punto (III) delle premesse al sig. Tizio il quale rilascia la quietanza di pagamento con la presente scrittura privata.
Art. 3
Il sig. Caio dichiara di ricevere il bene di cui al punto (I) delle premesse con la sottoscrizione della presente scrittura privata.
Letto, approvato e sottoscritto
Luogo e data
Firma Tizio Firma Caio
Quali sono gli elementi essenziali di questo contratto?
Accordo: le parti hanno manifestato la loro volontà nell’atto e ne è la prova la firma che ciascuno di loro ha apposto in calce.
Causa: scambio di cosa contro prezzo.
Oggetto: trasferimento della proprietà della macchina da cucire Singer verso prestazione del prezzo.
Forma: atto scritto.
Non essendo prevista dalla legge la forma scritta sotto pena di nullità per la compravendita di bene mobile, le parti avrebbero concluso ugualmente un valido contratto anche in assenza della scrittura privata. Tuttavia tale forma è necessaria per il nostro esperimento, dovremo quindi assicurarci che anche nello smart contract essa investa tutti gli elementi essenziali.
Il codice dello Smart Legal Contract
Vediamo come predisporre uno smart contract che riproduca il medesimo contenuto del modello sopra creato. Procederemo con più speditezza rispetto quanto fatto nella pagina “Nozioni basilari di coding – Smart Contract per la Notarizzazione“, soffermandoci unicamente su quanto non affronto in precedenza.
Struttura ed elementi
Apriamo Remix, creiamo un nuovo file “.sol”, inseriamo licenza, pragma e scegliamo l’identificatore per il contratto, nel mio caso “VenditaSinger”.
Ora, sotto forma di commento al codice stendiamo delle linee guida per procedere in modo ordinato.
Prima di tutto inseriamo un commento che definisca quale sia il contenuto dello smart contract:
“/* Questo smart contract definisce un contratto di compravendita*/“.
Cerchiamo ora di capire quali variabili ci possano servire e quali funzioni dovremo creare per interagire con esse; in un secondo momento definiremo ciascuna di queste voci.
Nel modello cartaceo in prima battuta definivamo i dati anagrafici delle parti del contratto, poi le premesse, tre articoli e infine la data e le sottoscrizioni. Proviamo a replicare la medesima struttura, inseriamo quindi:
“//Elenco variabili di stato
//identità delle parti che stipulano il contratto
//premesse
//testo del contratto
//Firme“.
Stabiliamo anche quale tipo di funzioni inserire. Io ho scelto queste:
“//Elenco Funzioni
/* Lo smart contract contiene le seguenti funzioni:
-lettura testo del contratto (lettura);
-lettura identità delle parti (lettura);
-Sottoscrizione dell’accordo (scrittura);
-Verifica sottoscrizione (lettura);
*/“.
La scelta di variabili e funzioni potrebbe variare in base alla propria esperienza di programmazione, quelle scelte hanno la finalità di creare dei parallelismi con l’esperienza del modello cartaceo. Senza alcun dubbio servirà una funzione per poter sottoscrivere, o meglio dichiarare il proprio consenso; altrettanto essenziale sarà una funzione che permetta alle parti di leggere il testo del contratto.
Variabili di stato
Definiamo quindi le variabili di stato seguendo la traccia creata.
Identità delle parti.
In merito all’identità delle parti assegniamo a ciascuna sia una variabile string che una variabile address. In questo momento stiamo semplicemente definendo l’esistenza delle variabili e non il loro contenuto. Sappiamo però di voler inserire le generalità delle parti (string), e la possibilità di ricondurre a ciascuna l’indirizzo di un wallet (address). Scegliamo degli identificatori (Tizio, IdTizio, Caio, IdCaio) che permettano di ricondurre agilmente i dati ad un determinato soggetto. Attributo di visibilità “private” in quanto non vogliamo che le variabili siano visibili dall’esterno del contratto.
Premesse e testo del contratto.
Le premesse e i gli articoli del modello della scrittura privata come possono essere rappresentati?
Chiaramente anche queste come stringhe in quanto sicuramente non sono un dato numerico ma un dato testuale. Creiamo quindi le variabili “Premesse” e “TestoContratto“. Nulla ci impedisce di creare un’unica variabile che contenga entrambe ma la ritengo una soluzione meno chiara. Come detto in precedenza, stiamo creando le variabili ma senza definire ancora il contenuto. Attributo di visibilità? “private” per la medesima ragione di prima.
Firme.
Per inserire la firma introduciamo un nuovo tipo di dato. Si tratta della variabile “bool”. Un valore booleano è un dato che conosce solo due stati “true” e “false”. É adatto quindi a rappresentare situazioni che ammettano solo due risposte. Ad esempio: “il soggetto è in vita? true o false?”. “Il soggetto è cittadino italiano? true o false?”.
Nel nostro caso la domanda sottointesa è “il soggetto ha firmato?”. Il valore booleano appena creato assume di default il valore “false”; questa informazione è di fondamentale importanza perché non vogliamo creare un contratto già firmato! É essenziale che le parti possano leggere il contratto e solo successivamente esprimere il loro consenso. Come avrai già intuito, per trasformare il valore Firma da false a true, sarà necessario l’esercizio di una function da parte di ciascun soggetto.
Il costruttore - il contenuto delle variabili
Abbiamo creato delle variabili, con degli identificatori chiari e precisi, dobbiamo ora assegnare a ciascuna di esse il corretto valore e contenuto, per fare ciò utilizziamo il costruttore. Cos’è il constructor?
Possiamo vederlo come una funzione che riceve automatica esecuzione al deploy dello smart contract. Questo ci permetterà di poter assegnare uno specifico valore alle variabili senza che si renda necessario l’esercizio di un’apposita funzione ad avvenuto deploy.
Scriviamo quindi “constructor () { }“, inserendo tra le parentesi graffe l’assegnazione del valore delle variabili.
Partendo quindi dal venditore, assegniamo alla variabile string “IdTizio” una stringa corrispondente alle generalità di Tizio; alla variabile address inseriamo una chiave pubblica, nel mio caso “0x5B38Da6a701c568545dCfcB03FcB875f56beddC4”, che corrisponde alla prima chiave degli accounts virtuali messi a disposizione dalla JavaScript VM. Procediamo nel medesimo modo anche per Caio. Attenzione, tu dovrai assegnare a Tizio e Caio le chiavi che compaiono tra i tuoi accounts virtuali. Perché inseriamo queste chiavi pubbliche? Perchè rappresentano gli strumenti che Remix ci mette a disposizione per simulare quanto accadrebbe inserendo le chiavi pubbliche dei wallets Ethereum delle parti, ma senza spendere soldi.
Infine definiamo le variabili string “Premesse” e “TestoContratto“, copiando il contenuto del modello della scrittura privata. Come puoi notare nell’immagine, qualora si rendesse necessario andare a capo a causa di una stringa di testo troppo lunga, sarà sufficiente chiudere le virgolette a fine riga e riaprile a capo. Il compilatore leggerà le righe come un’unica stringa fino al segnale di chiusura dato dal punto e virgola.
Le functions
Definiamo ora le funzioni esercitabili.
Tre di queste sono funzioni in lettura, una sola invece è in scrittura. Vediamo quindi le ragioni che giustificano il loro inserimento. Con le prime due funzioni consentiamo alle parti di leggere il testo del contratto (così come predisposto nel modello cartaceo) e le generalità con le quali le stesse si identificano. Con la terza funzione, function in scrittura, permettiamo alle parti di firmare il contratto. Con la quarta funzione permettiamo alle parti di verificare se siano state apposte firme al contratto. Quest’ultima function è del tutto superflua in quanto, con un deploy reale, le eventuali sottoscrizioni figurerebbero come transazioni registrate su blockchain. Sarebbe infatti sufficiente verificare attraverso un blockchain explorer la presenza di transazioni già avvenute o ancora in stato di pendenza. Per fare ciò può essere usato uno strumento come Etherscan (come visto in “Nozioni basilari di coding – Smart Contract per la Notarizzazione” alla voce “Consultazione della blockchain Ethereum”).
Vediamo però di comprendere come si compongono queste functions.
Lettura del testo del contratto.
Le funzioni in lettura le incontriamo ora per la prima volta, analizziamo quindi la prima di queste. Obiettivo della funzione? Rendere possibile alle parti la conoscenza del contenuto da sottoscrivere. Dopo aver definito che si tratta di una funzione scrivendo “function” assegniamo l’identificatore “LeggiTestoContratto“, seguono quindi le “( )“. Le due parentesi sono vuote in quanto non viene assegnato alcun dato in input alla funzione. Seguono poi, un attributo di visibilità “public“, che indica che la funzione è visibile ed esercitabile dall’esterno del contratto, e “view“, un parametro che comunica la natura di solo lettura e quindi l’assenza di costi di esercizio. Infine “returns” in quanto la funzione deve restituire qualcosa al suo esercizio. Cosa restituisce? Vogliamo che restituisca due stringhe, inseriamo quindi “string”, con relativo attributo di memorizzazione “memory“, per due volte all’interno delle parentesi tonde. Apriamo dunque le parentesi graffe e inseriamo ciò che la funzione deve effettivamente fare: “return (Premesse, TestoContratto);”. Ossia restituiscimi prima la string “Premesse” e poi la string “TestoContratto“. Attenzione che, a differenza di quanto fatto poco prima, il termine da scrivere ora è “return” e non “returns“.
Proviamo subito il corretto funzionamento di quanto creato. Facciamo il deploy del contratto. Andiamo alla scheda Deploy & Run transactions, alla voce Environment deve essere selezionato JavaScript VM, ora clicchiamo sul pulsante Deploy e una spunta verde conferma che questo avviene con successo. Visualizziamo ora le funzioni disponibili (in arancione quelle in scrittura in azzurro quelle in lettura) e selezioniamo “LeggiTestoContratto”. Come puoi vedere Remix ci restituisce il contenuto delle due stringhe con successo, visualizzandole sia sotto il pulsante premuto, che nella finestra del terminale, così come sarebbe visualizzato in blockchain.
Lettura delle generalità delle parti.
Passiamo ora alla seconda funzione, “GeneralitaParti“. Come puoi vedere la prima e l’ultima riga(61,64) sono praticamente identiche a quelle appena analizzate, in quanto cambiano semplicemente gli identificatori di riferimento. Alle righe 62 e 63 è presente invece un meccanismo che limita l’esercizio della funzione. Volendo attribuire una protezione elevata alle generalità delle parti inseriamo una struttura che prende il nome di “require“. La sua funzione? Semplicissimo, verifica che la condizione specificata al suo interno sia rispettata, altrimenti restituisce errore impedendone l’esercizio. La condizione stabilita all’interno può cosi essere sintetizzata: consenti l’uso della funzione solo dopo aver verificato che colui che la esercita sia il venditore o l’acquirente, se cosi non fosse restituisci il messaggio “Non sei parte del contratto”.
In dettaglio, il termine “msg.sender” indica l’address di colui che esercita la function, segue un doppio simbolo di uguale e l’address del venditore. Le prime volte che si programma si commette spesso l’errore di inserire un solo “=”, tuttavia la funzione dell’uguale è quella di assegnare un valore; per fare un confronto e verificare l’uguaglianza è invece necessario inserire “==”.
Segue poi il simbolo “||” e la medesima costruzione di prima con l’indirizzo dell’acquirente. Il significato di “||” è “oppure”, quindi verifica che sia presente o la prima condizione o la seconda. Il costrutto require prevede infine che dopo la virgola possa essere personalizzata una stringa di errore.
Verifichiamo quindi il corretto funzionamento. Esercitiamo la funzione prima come venditore o acquirente, selezionando il corretto address alla voce “account” (figura 6a), e poi con un address differente per verificare il corretto funzionamento del require (figura 6b).
Nell’immagine 6b, è possibile vedere come l’esercizio della funzione da parte di colui che non sia o venditore o acquirente genera un errore che comporta il “Revert”, ossia il ritorno allo stato iniziale, prima che la funzione fosse esercitata. Viene inoltre visualizzata la stringa di errore inserita nella funzione “Non sei parte del contratto”.
Sottoscrizione.
Analizziamo ora l’unica funzione di scrittura prevista. Inseriamo quindi “function“, l’identificatore della funzione “Firma“, “()” due parentesi vuote (in quanto non diamo alcun valore in input) e l’attributo di visibilità “public“, perché vogliamo che la funzione sia esercitabile dall’esterno. A questo punto all’interno delle due parentesi graffe indichiamo le istruzioni da eseguire. Come avviene la firma? Con la modifica del valore booleano dichiarato tra le variabili di stato, che dal valore di default “false”, sarà modificato in “true” (al termine dell’approfondimento faremo ovviamente delle considerazioni giuridiche in merito a tale meccanismo). Prevediamo quindi:
1- un require che consenta l’esercizio della funzione alle sole parti del contratto;
2- due costrutti “IF”, uno per il venditore e l’altro per l’acquirente, per modificare il valore booleano di ciascuno di essi.
Il costrutto “if” lo incontriamo per la prima volta, è il famosissimo if this than that al quale si riferiscono la maggior parte degli articoli giuridici. Vediamo il funzionamento: IF + (condizione) + operazione da compiere + “;”.
Alla riga 70, 71 (figura 7) è definito il costrutto che permette a Tizio di esprimere il proprio consenso, possiamo leggerlo così: “se (if), colui che esercita la funzione (msg.sender) ha la chiave pubblica corrispondente all’indirizzo di Tizio(==0xAb8483F64d9…), allora modifica il valore “FirmaTizio” in vero (=true).
Due indicazioni importanti: la prima, ricorda che “==” indica un confronto di valori e “=” un comando per impostare uno specifico valore; la seconda, puoi tranquillamente sostituire l’indirizzo di Tizio (0xAb8483F64d9…) con la variabile di stato “Tizio”, in quanto definita all’interno del constructor (alla riga 30 “Tizio=0x5B38Da6a701c568545dCfcB03FcB875f56beddC4;”). Questa seconda alternativa permette di ottenere un codice sicuramente più snello e probabilmente anche maggiormente comprensibile. Alla figura 7a puoi vedere a confronto la medesima funzione scritta nelle due differenti versioni.
Verifichiamo ora il funzionamento eseguendo il deploy del contratto e la firma tramite account del venditore.
La spunta verde ci conferma la corretta esecuzione della funzione. Nel terminale è possibile verificare la function eseguita e l’address del msg.sender (venditore).
Ricordiamo che questi dati, se eseguiti con “environment: injected Web3”, restano memorizzati nella blockchain Ethereum; nella pagina “Nozioni basilari di coding – Smart Contract per la Notarizzazione” alla voce “Consultazione della blockchain Ethereum” abbiamo infatti analizzato la molteplicità di informazioni disponibili per ogni transazione.
La ragione principale per la quale non è stata inserita nello smart contract una variabile che rappresenti l’informazione “Data di firma del contratto”, risiede nel fatto che ad ogni operazione compiuta su blockchain viene assegnato il dato “timestamp“. Di conseguenza sarà possibile verificare direttamente su blockchain sia il momento in cui è avvenuto il deploy che il momento in cui ciascuna delle parti ha eseguito la funzione “Firma“.
Invece, per controllare che le operazioni effettuate siano andate a buon fine in ambiente Javascript VM, utilizziamo la function “VerificaSottoscrizione“.
Verifica delle Sottoscrizioni.
Con la funzione “VerificaSottoscrizione” possiamo leggere i valori booleani contenuti nelle variabili bool “FirmaTizio” e “FirmaCaio“.
Verifichiamo quindi tramite la sua esecuzione che i parametri di default siano “false” (figura 8a).
Dopo aver eseguito la function “Firma” con l’account del venditore (Tizio), utilizziamo la funzione “VerificaSottoscrizione” per controllare che sia stato modificato il valore della relativa variabile booleana “FirmaTizio.” (Figura 8b)
Considerazioni conclusive
Siamo giunti al termine della fase di coding, è ora il momento di fare alcune opportune considerazioni.
Rinfrescando nella mente il pensiero che si sia trattato di un esperimento con il quale abbiamo privato lo smart contract delle sue caratteristiche innovative (quali l’automaticità dell’esecuzione), cosa è stato possibile osservare?
É stato possibile riprodurre il contenuto del testo scritto?
Possono dirsi presenti gli elementi essenziali del contratto ex articolo 1325 del Codice civile?
E infine, può avere senso utilizzare lo strumento dello smart contract in questo modo?
Procediamo con ordine.
Il testo del contratto.
Attraverso l’utilizzo delle variabili string è stato possibile riprodurre la scrittura privata senza difficoltà, inserendo:
– generalità delle parti,
– premesse e articoli del modello di scrittura privata.
La data viene invece rappresentata dal timestamp della blockchain. In merito a tale elemento restano ferme le considerazioni giuridiche già proposte alla sezione “Quadro Normativo” in forza del contenuto dei commi 3° e 4° dell’articolo 8 ter, L. 12/2019.
Le sottoscrizioni delle parti sono state rappresentate come variabili booleane, ma di questo parleremo tra poco, in quanto argomento meritevole di una riflessione aggiuntiva.
Elementi essenziali del contratto.
Causa e oggetto non hanno rappresentano un problema, in quanto emerge in modo chiaro la natura del contratto di compravendita e l’oggetto delle prestazioni.
In merito alla forma, è la stessa legge 12/2019 all’articolo 8 ter comma 2, a stabilire che “Gli smart contract soddisfano il requisito della forma scritta” con quel grosso “ma” derivante dal proseguimento “previa identificazione informatica delle parti interessate, attraverso un processo avente i requisiti fissati dall’Agenzia per l’Italia digitale con linee guida” vista l’assenza di queste ultime.
L’elemento dell’accordo è invece condizionato dalla function “Firma”, con l’esercizio di questa le parti manifestano la loro volontà. Spendiamo quindi qualche parola in più.
Firma e identificazione delle parti.
Come visto più volte, l’identificazione delle parti attraverso la blockchain è un argomento molto delicato. Dato per assodato che per interagire con uno smart contract è indispensabile avere un wallet, quindi chiave pubblica e chiave privata, resta il fatto che dietro ad esso non vi sia alcun accertamento dell’identità del soggetto. Se è vero che il sistema di chiavi asimmetriche garantisce che ad una chiave pubblica sia legata una sola chiave privata, a mio avviso, le problematiche sono più che evidenti. Mettiamo in gioco il parallelismo che spesso emerge tra chiave pubblica del wallet e IBAN del conto bancario. Entrambi hanno un dato pubblico, il codice alfanumerico da comunicare per ricevere denaro; ed entrambi una password di accesso per disporre pagamenti in uscita. Tuttavia, il titolare del conto bancario è sottoposto ad un preciso processo di identificazione, mentre il titolare del wallet non ha necessità di provare la propria identità. Questo è dovuto all’assenza di un intermediario con evidenti problematiche legate alle sicurezza. É risaputo che vi sono wallets milionari, ai quali i proprietari non riescono ad accedere a causa dello smarrimento della chiave privata. Vi sono però anche wallets completamente vuoti a causa di una involontaria diffusione della chiave privata. L’impossibilità di poter modificare e reimpostare la chiave privata assegnata ad un wallet rende in queste casistiche l’account totalmente inutile, lasciando all’utente l’unica possibilità di crearne uno nuovo.
Se il wallet oltre ad essere uno strumento di pagamento diviene anche uno strumento di identificazione nel contratto, quali possono essere le conseguenze della diffusione involontaria o volontaria della chiave privata? Nulla impedirebbe la conclusione di contratti contrari alla volontà del creatore del wallet e senza poter dimostrare che l’esercizio della function non sia stato da lui effettuato. É evidente che debba essere presente un sistema aggiuntivo che permetta al proprietario di riottenere il controllo modificando o disconoscendo l’attività proveniente dall’account violato. Potrebbe essere utile integrare quindi una ulteriore forma di controllo, quale ad esempio un codice OTP al fine di poter effettuare la firma del contratto.
Queste sono le mie personalissime considerazioni in attesa della definizione delle questione per mezzo delle future linee guida dell’AgID.
Accordo tra le parti.
Vi sono diversi aspetti riguardanti lo smart contract creato che, se trascurati, potrebbero portare ad errate considerazioni. Sorvolando sulle problematiche appena esposte, e considerando la data e l’identificazione delle parti come non problematiche, si può ritenere di essere di fronte ad un valido smart legal contract.
Il primo quesito è: chi ha scritto il contratto?
Cancelliamo dalla mente l’espressione impropria che troppo spesso viene utilizzata “le parti pubblicano il contratto su blockchain”. Come visto più volte, il deploy è un’operazione che viene esercitata da un solo account, il quale ne sostiene il costo. Questo comporta che solo una parte scrive il codice dello smart contract, e che l’accordo tra le parti nasca in seguito con l’esercizio delle functions di firma.
Abbiamo visto anche che l’inserimento di apposite funzioni permette all’acquirente di conoscere il testo della scrittura privata (Premesse, TestoContratto, nonché le generalità delle parti). Tuttavia così facendo quello che l’acquirente visualizza è il contenuto di variabili string e non il codice integrale dello smart contract. Come emerso nella pagina “Nozioni basilari di coding – Smart Contract per la Notarizzazione“ alla voce “Consultazione della blockchain Ethereum” il deploy del contratto non rende il codice sorgente immediatamente consultabile; sarà necessario che colui che l’ha pubblicato esegua la funzione “Verify and Publish”. Solo così facendo il contraente potrà stipulare il contratto conscendo l’effettivo codice dello smart contract.
Pubblicare il codice sorgente comporta due principali conseguenze:
– rendere possibile al contraente l’analisi del contratto verificando l’immutabilità delle variabili,
– vanificazione degli sforzi compiuti per rendere “private” alcuni dati, che divengono inevitabilmente visibili a chiunque (in quanto public blockchain).
Vale la pena? Vantaggi e Svantaggi.
Fin dall’inizio abbiamo sottolineato la natura sperimentale dell’esercizio, con evidente snaturamento dello smart contract.
Perché mai le parti dovrebbero preferire questa soluzione al posto di una semplicissima scrittura privata? Gli unici elementi distintivi che possono avere un’utilità sono: la pubblicità (se voluta), la certificazione della data di firma, e l’immutabilità.
Di contro invece si contano: i costi superiori, la pubblicità (se non voluta), le competenze e il tempo necessario alla creazione del contratto.
Lo smart contract così creato a differenza del foglio di carta, che le parti possono stracciare in forza del mutuo dissenso, non può essere eliminato. A onor del vero, non sarebbe difficile inserire una funzione apposita, non dissimile da quella di firma, per manifestare il mutuo dissenso.
Lo smart contract è uno strumento che chiaramente non si presta a sostituire un qualsiasi contratto. Tuttavia quanto fatto oggi è un’estremizzazione. I vantaggi derivanti dall’uso dello smart contract sono notevoli quando i beni oggetto del contratto sono digitali (soprattutto se on-chain), e quando è possibile beneficiare dell’automaticità delle prestazioni. Nei futuri contenuti tratteremo quindi i beni digitali e i tokens.
Ultimo aggiornamento : 03-2021
