Smart Contract e Blockchain - Cosa sono e come funzionano

Scrivo questo articolo a seguito di una serie di domande che mi vengono poste sempre più di frequente da clienti e collaboratori interessati a valutare l'introduzione, nelle loro aziende o realtà lavorative, di soluzioni innovative basate su due dei principali trend topic degli ultimi mesi: Smart Contract e Blockchain. Come sempre in questi casi, per prima cosa è opportuno fare chiarezza sulle definizioni, alle quali proverò ad affiancare alcuni esempi per rendere più chiari sia gli argomenti trattati che i rispettivi ambiti applicativi: nella seconda parte dell'articolo proverò a descrivere i punti di contatto tra i due concetti, sottolineando i vantaggi e i limiti legati al loro utilizzo combinato: la parte conclusiva è dedicata a una serie di spunti e riflessioni sul tema, con un approfondimento dedicato agli effetti che gli Smart Contract in tecnologia Blockchain possono avere sulle odierne attività professionali di notai e avvocati, sia in positivo (Legal 4.0) che in negativo (Disruptive Innovation).

Smart Contract

Con il termine Smart Contract (contratto intelligente) si intende un protocollo informatico che ha il compito di verificare e garantire il rispetto di determinate condizioni contrattuali stipulate tra le parti: in altre parole, si tratta di un codice informatico programmato per svolgere in automatico le principali mansioni che, in ambito contrattualistico, vengono solitamente affidate a una controparte terza come un notaio o avvocato.

Uno degli esempi più elementari di Smart Contract è dato dal sistema di acquisto e attivazione tramite codice product key utilizzato da molti applicativi software, che può essere riassunto nelle seguenti fasi:

• L'utente scarica il software sul proprio computer, che però risulta bloccato (in tutto o in parte) fino a quando non viene acquistata una licenza;
• tale licenza viene consegnata, subito dopo l'acquisto, mediante il rilascio di un codice product key generato automaticamente;
• una volta ottenuto il codice product key, all'utente non resta che inserirlo all'interno del software per ottenere lo sblocco dello stesso e accedere alle funzionalità acquistate.

Come si può facilmente vedere, l'intero processo di acquisizione, acquisto e attivazione del software sopra descritto è governato da un automatismo informatico che si occupa di verificare il rispetto di determinate condizioni - la presenza di un codice valido, ovvero prodotto a seguito di un regolare acquisto - e di garantirne il rispetto mediante la conseguente attivazione del prodotto. Inutile dire che il sistema può essere programmato per gestire efficacemente anche clausole contrattuali aggiuntive più o meno complesse, come ad esempio la disattivazione automatica dopo alcuni mesi (licenza a tempo), ovvero in caso di doppia installazione (licenza per singolo utente), ovvero in caso di modifiche all'hardware del computer (licenza per singolo PC), e così via: il tutto, ovviamente, in modo totalmente automatico.

Altri validi esempi di Smart Contract possono includere: l'iscrizione ad Amazon Prime, in base alla quale il sistema verifica l'avvenuto pagamento della fee annuale e, di conseguenza, abilita o disabilita il servizio di spedizione immediata ovvero l'accesso alla piattaforma di video-streaming Prime Video; il sistema DRM (Digital Rights Management) di servizi come ITunes, Google Play o Spotify, che verificano e garantiscono l'erogazione e l'accesso a determinati contenuti sulla base dell'avvenuto pagamento e/o abbonamento; e così via.

Contratti intelligenti di questo tipo vengono utilizzati fin dai primi anni '90 e costituiscono ormai uno standard per la maggior parte dei prodotti e servizi informatici con i quali abbiamo quotidianamente a che fare: si tratta di meccanismi che fino a pochi anni fa non avevano bisogno di un nome, in quanto considerati parte integrante delle transazioni elettroniche che li determinavano. Il cambiamento di prospettiva si è verificato a seguito dell'avvento e della diffusione dell'Internet of Things, che oggi consente di utilizzare gli stessi protocolli di acquisto, verifica delle condizioni ed erogazione automatizzata del servizio per una serie di mercati tradizionalmente regolati da una impostazione contrattualistica di tipo tradizionale: dai prodotti finanziari ai servizi assicurativi, dall'acquisto di giornali e riviste ai sistemi di gestione delle campagne pubblicitarie, e così via.

Blockchain

Con il termine Blockchain (catena di blocchi) si intende una struttura dati condivisa e immutabile: una sorta di archivio digitale che contiene la totalità delle attività effettuate da tutti gli aventi diritto, raggruppati in "blocchi" e concatenati in ordine cronologico. Queste attività possono essere transazioni finanziarie, record contenenti informazioni, o qualsiasi altra informazione che abbia senso registrare all'interno di una base dati. Sintetizzando molto, potremmo dunque definire la blockchain come una sorta di database distribuito, gestito dalla totalità degli aventi diritto - i cosiddetti "nodi" - attraverso un client dedicato che svolge le seguenti operazioni:

• Aggiungere nuove attività,  sulla base di un protocollo condiviso in base al quale gli altri nodi identificano l'operazione come autorizzata e quindi aggiornano la loro copia locale di conseguenza.
• Autorizzare le aggiunte dei nuovi "blocchi", ovvero gruppi di nuove attività provenienti dagli altri nodi che compongono la blockchain.
• Gestire una copia privata dell'intero archivio, ovvero dell'intera blockchain, e mantenerla costantemente aggiornata aggiungendo le nuove attività provenienti dai nodi autorizzati.

Salta immediatamente all'occhio come la blockchain, pur essendo sostanzialmente una base dati, possieda delle caratteristiche peculiari in termini di sicurezza e a garanzia dell'integrità delle informazioni contenute. La prima cosa da comprendere è che la blockchain non è composta da un insieme di record, ovvero di singoli elementi, ma dalle attività effettuate dai singoli nodi.

Caratteristiche di un archivio tradizionale

Per comprendere meglio questo concetto prendiamo a esempio la seguente tabella, che potremmo trovare all'interno di un tipico database relazionale o di un foglio excel:

ID Utente	Nome	Saldo
1	Mario	100
2	Luigi	200
3	Andrea	300

Immaginiamo ora di dover registrare, all'interno di questa tabella, un aumento del saldo di Mario dovuto al fatto che Andrea decide di inviargli 100: inutile dire che, di conseguenza, dovremo registrare anche una diminuzione del saldo di Andrea di pari entità. Dovendo gestire la cosa con un database tradizionale, tale modifica avrebbe il seguente effetto sulla tabella di cui sopra:

ID Utente	Nome	Saldo
1	Mario	200
2	Luigi	200
3	Andrea	200

La transazione di denaro tra Andrea e Mario sarebbe inoltre presumibilmente registrata in una seconda tabella B, nel seguente modo:

ID Transazione	Inviato da	Ricevuto da	Valore	Data e Ora	Annullata
1	Andrea	Mario	100	18/03/2019 15:30	No

La transazione ha dunque provocato la modifica del Saldo di due record nella tabella A e l'aggiunta di un intero record nella tabella B, che registra le transazioni (ovvero i movimenti di denaro) tra utenti.

Supponiamo adesso che, per qualsiasi motivo, Andrea abbia un ripensamento e decida di annullare la transazione appena effettuata: e assumiamo, sempre per ipotesi, che abbia la possibilità di farlo. A seconda degli strumenti a sua disposizione, è possibile che Andrea possa compiere questo annullamento autonomamente - ad esempio sfruttando l'interfaccia utente del sito web tramite il quale ha effettuato la disposizione - oppure rivolgendosi a un operatore autorizzato, il quale potrà a sua volta gestire direttamente la pratica per mezzo di un proprio pannello  gestionale oppure richiedere la modifica manuale da parte dell'amministratore di sistema. A prescindere da chi effettuerà materialmente l'operazione, l'annullamento di una transazione comporterà la modifica del valore del campo Annullata della tabella B (da "No" a "Si") e, di conseguenza, il valore del Saldo dei record corrispondenti ai due individui oggetto della transazione nella tabella A.

Tipicamente, il software che gestisce strutture dati di questo tipo consente:

• all'utente, di annullare le proprie transazioni (tabella B, modifica del solo campo Annullata, soltanto se il record è inviato da lui): in conseguenza di tale modifica, il sistema provvederà a modificare la tabella A di conseguenza e (nella maggior parte dei casi) a registrare l'attività svolta in un apposito log, ovvero un registro di tutte le operazioni effettuate sull'archivio;
• all'operatore autorizzato, di annullare le transazioni effettuate da qualsiasi utente (tabella B, modifica del solo campo Annullata, per qualsiasi record): anche in questo caso, in conseguenza di tale modifica, il sistema provvederà a modificare la tabella A di conseguenza ed eventualmente a registrare l'operazione effettuata in un apposito log di sistema;
• all'amministratore di sistema, di intervenire su tutte le tabelle in qualsivoglia modo (tabelle A e B, modifica, inserimento, eliminazione o aggiunta di nuovi record). Anche in questo caso, tutte le modifiche effettuate saranno auspicabilmente registrate in un apposito log di sistema;

Riepilogando, siamo dunque di fronte a un archivio per sua natura centralizzato e modificabile in conseguenza di operazioni effettuabili da utenti, operatori autorizzati e/o amministratori di sistema: ciascuna di queste persone, o per meglio dire ciascuno di questi ruoli, ha la possibilità di intervenire sulla base dati in vario modo a seconda dei permessi (grant) a lui concessi. Tutte le attività effettuate, come possiamo vedere, sono registrate nell'apposita tabella delle transazioni e tracciate mediante un log di sistema, che consente di tenere traccia di tutte le operazioni svolte sull'archivio così da poter controllare a posteriori eventuali alterazioni o manomissioni compiute da utenti, operatori e persino amministratori.

A prima vista, un archivio organizzato in questo modo potrebbe sembrare sufficientemente sicuro e "blindato" da qualsivoglia operazione non autorizzata. Ma è davvero così? In realtà, un sistema del genere è soggetto a una pluralità di possibili attacchi: in primo luogo da parte degli amministratori di sistema, che potrebbero alterare i dati delle tabelle A e B annullando transazioni o addirittura aggiungendo transazioni mai eseguite o cancellando transazioni come se non fossero mai state effettuate; in seconda battuta da parte di hacker o altri operatori o utenti non autorizzati, che potrebbero manomettere i dati e le informazioni contenute negli archivi collegandosi con credenziali rubate o non corrispondenti alla loro identità. Anche la presenza del file di log di tutte le attività effettuate non garantisce un livello di sicurezza sufficiente perché, nella maggior parte dei casi, può essere anch'esso cancellato o alterato dagli amministratori di sistema per coprire le proprie tracce o per "occultare" all'utenza eventuali incongruenze, malfunzionamenti o attacchi esterni.

Caratteristiche di una Blockchain

Alla base dell'ideazione del concetto di blockchain vi è proprio la necessità di ridurre ai minimi termini, quando non di eliminare del tutto, la possibilità di questo tipo di alterazioni non autorizzate: tale garanzia è data dalle due principali caratteristiche evidenziate in precedenza, ovvero il suo essere una struttura dati condivisa e immutabile.

• Condivisa, perché ogni utente possiede una copia integrale dell'intero archivio sul proprio dispositivo.
• Immutabile, perché non prevede la modifica o la cancellazione delle attività inserite ma solo inserimenti di ulteriori attività.

Poiché questi due aspetti, estremamente importanti, vengono spesso fraintesi dai non addetti ai lavori, vale senz'altro la pena di approfondirli singolarmente.

Condivisione

Come abbiamo avuto cura di sottolineare in precedenza, una caratteristica comune alla quasi totalità degli archivi tradizionali è la centralizzazione della base dati. Quest'ultima infatti risiede tipicamente su un server, o su un insieme (cluster) di server ridondati ovvero sincronizzati tra loro, accessibile più o meno simultaneamente da parte dei client a seconda del dispositivo e/o delle tecnologie utilizzate: l'interfaccia utente di un sito web, una mobile app, un client desktop, e così via. In tutti questi casi, l'accesso ai dati è basato su una logica client-server che presuppone necessariamente una distinzione tra chi utilizza quei dati (gli utenti) e chi ha il compito di gestirli, custodirli e metterli a disposizione (gli amministratori di sistema). Avere una base dati centralizzata significa esattamente questo, indipendentemente da dove i dati siano effettivamente memorizzati (su server di proprietà del gestore oppure no) e/o se la proprietà degli stessi sia sua, degli utenti o di terze parti. Nella maggior parte dei casi, il gestore di un archivio centralizzato ha anche il controllo degli accessi e delle eventuali operazioni che è possibile effettuare (o delegare) agli utenti: esistono tuttavia alcuni scenari implementativi, come nel caso dei sistemi host-proof o nei protocolli di comunicazione che prevedono una end-to-end encryption,  in cui il database è centralizzato ma il gestore non può accedere ai dati dei singoli utenti in quanto questi ultimi sono criptati con chiavi di decodifica note soltanto a chi accede ovvero a chi invia e riceve. Anche in questi casi, tuttavia, la centralizzazione del database consente al gestore di mantenere alcuni fondamentali strumenti di controllo sui dati: ad esempio, la possibilità di eliminarli o di renderli inaccessibili all'utente.

A differenza di un database centralizzato, una base dati condivisa non prevede alcun gestore: l'archivio è infatti posseduto nella sua totalità da tutti gli utenti, in quanto ciascuno di essi dispone di una copia integrale sul proprio dispositivo. Ovviamente, questo non significa che chiunque possa vedere qualsiasi cosa. I dati sono infatti memorizzati mediante l'utilizzo di primitive crittografiche che consentono ad ogni singolo client di svolgere soltanto le seguenti operazioni:

• accedere ai dati che lo riguardano, ovvero quelli accessibili a tutti i nodi e/o per i quali il client possiede le relative chiavi di decrittazione.
• verificare la validità e l'integrità formale di qualsiasi dato presente nell'archivio, ivi incluse le richieste di inserimento di nuovi blocchi da parte degli altri client, pur senza potervi accedere.

Il secondo punto è particolarmente importante in termini di sicurezza, perché consente a ciascun client di verificare la "correttezza" dell'intero archivio (e dei nuovi blocchi) senza entrare nel merito del loro contenuto effettivo: in altre parole, ciascun client assume anche il ruolo di "controllore" della validità dei blocchi di dati presenti nella blockchain nonché dei nuovi blocchi aggiunti dagli altri client.

Questi controlli, che in una blockchain vengono chiamati meccanismi di consenso, vengono effettuati mediante verifiche crittografiche complesse ed hanno il compito di proteggere la rete da attori malintenzionati. I meccanismi di consenso possono essere di diverso tipo, a seconda della tipologia di blockchain utilizzata:

• Proof-of-Work (PoW): un protocollo che mette i nodi in competizione tra loro per risolvere un riddle, ovvero un indovinello computazionale: il nodo che risolve il calcolo che valida un blocco trasmette il risultato agli altri, che possono facilmente verificare che l’attività sia stata svolta correttamente. In questo modello di consenso, utilizzato della maggior parte delle criptovalute ad oggi diffuse nel mondo (Bitcoin, Ethereum, Litecoin, Monero, Dash, Zcash, Decred e molti altri), i nodi che risolvono il riddle vengono ricompensati con una reward in criptovaluta di valore concordato: per questo motivo vengono chiamati miners, ovvero "minatori", in quanto il loro operato è assimilabile a quello dei lavoratori all'interno di una miniera.
• Proof-of-Stake (PoS): un protocollo in base al quale i nodi selezionati per effettuare i controlli vengono selezionati in modo pseudocasuale privilegiando quelli che detengono il maggior numero di "titoli" risultanti dalle operazioni presenti nella blockchain (informazioni, criptovaluta, etc.), sulla base del principio che i nodi più esposti sono anche i più affidabili, o meglio i più motivati a portare a termine il processo di convalida.

Esistono poi una serie di verifiche crittografiche ulteriori - non meno importanti delle precedenti in termini di sicurezza delle informazioni e controllo dell'integrità formale dei dati - che possono essere verificate in tempo reale da qualsiasi nodo:

• Proof-of-Ownership: consente di determinare la proprietà di un bene (ad es. un titolo) in base all'ultima operazione di transazione verificata ad esso relativa.
• Proof-of-Existence: consente di dimostrare che l'operazione esiste, ovvero che è effettivamente stata effettuata.
• Proof-of-Publication: consente di dimostrare che l'operazione è avvenuta in un determinato momento temporale.
• Proof-of-Integrity: consente di verificare l'integrità dei dati dell'operazione: una volta verificata, una operazione non può essere alterata in alcun modo senza invalidarne l'esito positivo di convalida.
• Proof-of-Authenticity: consente di determinare il passaggio di proprietà (ownership) di un bene, a partire dall'owner originario, in base al tracciamento di tutte le operazioni di transazioni verificate ad esso relative.

Immutabilità

In tutti i casi in cui il processo di verifica dovesse rilevare una anomalia, una discrepanza e, più in generale, ogniqualvolta il meccanismo di consenso determina la presenza di un errore, il blocco viene rifiutato nella sua interezza, e tutti hanno visibilità del fatto che le operazioni ivi contenute non sono state autorizzate: viceversa, se il blocco viene convalidato, questo viene immediatamente aggiunto alla blockchain in modo permanente e immutabile; in altre parole, nessun nodo alla blockchain potrà più modificarlo o rimuoverlo. La permanenza, o per meglio dire l'immutabilità di ciascuna operazione, è un'altra importantissima caratteristica di questa base dati.

Per spiegare in poche parole cosa si intende con immutabilità e perché è importante è opportuno ritornare all'esempio di archivio tradizionale fatto in precedenza: se ben ricordate, entrambe le tabelle - la Tabella A, relativa ai saldi dei vari utenti, e la tabella B, relativa alle singole transazioni - erano strutturate per ospitare record che potevano essere aggiunti, modificati o persino eliminati (dagli amministratori di sistema) in qualsiasi momento. In una blockchain questo approccio non sarebbe possibile, in quanto - come abbiamo detto - è possibile effettuare soltanto inserimenti, ovvero operazioni di aggiunta ai dati e alle informazioni già presenti.

Questa particolare caratteristica della blockchain "costringe", nel processo di creazione dell'archivio, ad abbandonare il consueto design model tipico dei database relazionali in favore di una struttura dati basata su una serie di transazioni consequenziali e informazioni a corredo veicolate e registrate tramite metadati. In altre parole, se dovessimo gestire una base dati analoga a quella dell'esempio, le tabelle A e B di cui sopra sarebbero sostituite da una struttura dati simile alla seguente:

ID Transazione	Inviato da	Ricevuto da	Valore	Data e Ora
1		23458972437	100	17/03/2019 15:30
2		98238642623	200	17/03/2019 16:00
3		35708523838	300	17/03/2019 16:30
4	35708523838	23458972437	100	18/03/2019 15:30

Come si può vedere si tratta di una struttura dati che ricalca grossomodo la tabella B, con alcune semplici ma importanti differenze:

• Le colonne "Inviato da" e "Ricevuto da" sono state anonimizzate, ovvero rese anonime e non direttamente riconducibili a persone reali: si tratta di una misura di sicurezza piuttosto comune nelle principali blockchain ad oggi diffuse per tutelare la riservatezza dei dati dei singoli nodi e, al tempo stesso, garantire la trasparenza delle transazioni. L'identificativo univoco che distingue la ownership e la authenticity delle transazioni è solitamente un hash del codice univoco assoluto associato al proprio client (wallet), generato automaticamente al momento del primo ingresso nella blockchain.
• La colonna "Annullata" è stata rimossa, in quanto si tratta di un campo modificabile e quindi non utilizzabile in una blockchain che prevede l'immutabilità di ciascuna transazione: di conseguenza, è facile comprendere come annullare una transazione all'interno di una blockchain possa avvenire solo aggiungendo una transazione uguale e contraria, ovvero facendo in modo che l'utente che ha ricevuto denaro - l'unico a poter aggiungere transazioni a suo titolo - lo invii indietro all'utente da cui lo ha ricevuto. Questo spiega come mai le criptovalute sono uno strumento particolarmente sicuro per chi riceve denaro, in quanto non esiste alcun modo per bloccare, annullare o invalidare un pagamento ricevuto. Non a caso sono da anni gli strumenti preferiti da chi ha bisogno di riscuotere pagamenti a seguito di acquisti di beni, servizi o prestazioni illegali, riscatti da ransomware, e così via.
• Il Saldo iniziale di tutti gli utenti, che nell'archivio tradizionale era memorizzato nella tabella A, è stato riportato sotto forma di transazione: nello specifico, le prime tre transazioni (aventi ID 1, 2 e 3) rappresentano lo stato iniziale del saldo degli utenti presenti nella blockchain: trattandosi di un saldo iniziale e predeterminato, l'informazione "inviato da" non è valorizzata, in quanto l'origine della transazione non è riconducibile ad alcun utente.

E' facile notare come la mancanza della tabella A non costituisca un problema, in quanto è possibile ricostruire la situazione dei saldi correnti di ciascun utente in qualsiasi momento semplicemente "sommando" tutte le transazioni, aggiungendo e sottraendo il valore di ciascuna ai rispettivi utenti. Nell'ipotesi in cui sia assolutamente necessario tenere traccia del saldo dell'utente pagatore (o di entrambi gli utenti) all'interno della transazione, è sempre possibile aggiungere tali informazioni nei metadati della transazione stessa (Saldo Aggiornato Inviato a, Saldo Aggiornato Ricevuto da).

Sull'importanza della immutabilità in termini di sicurezza e integrità dei dati abbiamo già detto molto, quindi ci limiteremo a porre l'accento sui vantaggi che porta in termini di trasparenza e controllo. Appare subito evidente che si tratta di un meccanismo superiore a qualsiasi log di attività, proprio perché integra sia le informazioni vere e proprio che il registro delle attività effettuate da ciascun nodo: il tutto, ed è forse la cosa più importante di tutti, senza la possibilità che un amministratore di sistema (o hacker, o altro utente o operatore più o meno autorizzato) possa intervenire in alcun modo sui dati e nascondere le sue tracce.

Smart Contract e Blockchain

Veniamo ora alla parte conclusiva di questa analisi, che illustra il punto di incontro tra i concetti di Smart Contract e Blockchain. Come abbiamo detto nel paragrafo dedicato ai primi, la caratteristica principale dello Smart Contract è il suo essere una trasposizione di un accordo contrattuale in un protocollo informatico ad esso corrispondente, ovvero l'implementazione di un set di regole condivise tra i contraenti all'interno di un codice sorgente. Nel caso di uno Smart Contract che certifica l'acquisto di una product key valida per 5 attivazioni, l'acquirente si aspetta dunque di ricevere un prodotto dotato di un software che sia in grado di "attivarsi" per 5 volte prima di dare il fatidico messaggio: "spiacente, la tua chiave di attivazione è scaduta".

Si può facilmente comprendere come l'utente medio non abbia, né possa avere, alcuna reale consapevolezza del funzionamento del suddetto software: in altre parole, non è tutelato in alcun modo da possibili malfunzionamenti, modifiche o aggiornamenti futuri che potrebbero modificare in qualsiasi momento il codice sorgente alla base dello Smart Contract e, di conseguenza, le condizioni contrattuali da lui sottoscritte. Per questo motivo, è corretto affermare che la maggior parte degli Smart Contract oggi utilizzati sono basati quasi interamente sulla fiducia, ovvero sul livello di trust della parte contraente a cui spetta l'implementazione degli stessi. Tale livello di trust può essere misurato in vari modi: affidabilità, attendibilità, dimensioni della base utenti, numero di recensioni positive, e via dicendo. La presenza pervasiva dei social network, dei siti di valutazione, nonché di un gran numero di certificazioni e standard di sicurezza (es. PCI-DSS), consente ormai a ciascun utente di poter dare piena fiducia non soltanto ai colossi del settore (Amazon, PayPal, eBay, Spotify, Netflix, JustEat, etc.), ma anche a realtà considerevolmente più piccole (ePrice, Zalando, Groupalia e così via), fino ad arrivare all'e-commerce di quartiere. Si tratta in buona sostanza dello stesso meccanismo cognitivo che ha portato, dopo alcuni anni di ragionevole diffidenza, a "fidarsi" della maggior parte dei siti e servizi - grandi, ma anche meno grandi - che richiedono il numero di carta di credito e/o hanno necessità di trattare dati personali.

Ora, benché il livello di trust di molti di questi servizi sia ormai elevatissimo, appare evidente come la fiducia riposta nell'implementatore non possa essere l'unica misura a garanzia dell'utente che sottoscrive uno Smart Contract. Al contrario, esistono numerosi casi di storia recente dove questa fiducia è risultata essere eccessiva o persino malriposta: si pensi, a titolo di esempio, a scandali come quello di Cambridge Analytica (Facebook) o ai recentissimi casi legati alle mobile app Research (Facebook) e Screenwise (Google). Al di là degli effetti, è indubbio che alla base di queste violazioni sussista una falla implementativa (voluta dall'implementatore ovvero sfruttata dalla controparte) di Smart Contract stipulati su base fiduciaria.

Alla luce di tutti questi aspetti, possiamo dunque ben comprendere come la fiducia non possa essere considerata una garanzia sufficiente. Ed è proprio qui che entra in gioco la Blockchain, che - se utilizzata correttamente - può risolvere definitivamente questo problema, consentendo agli Smart Contract di fornire una serie di garanzie ulteriori a tutela dei contraenti:

• Garantire che il codice con cui è stato scritto non possa essere modificato, grazie alla caratteristica di immutabilità.
• Garantire che le fonti di dati che determinano le condizioni di applicazione siano verificate e affidabili, grazie ai meccanismi di consenso (Proof-of-Ownership, Proof-of-Authenticity).
• Garantire che le modalità di lettura e controllo di queste fonti sia a sua volta certificato, sempre grazie ai meccanismi di consenso (Proof-of-Existance, Proof-of-Publication, Proof-of-Integrity).

In questo modo, l'utente pagante non correrà il rischio che la licenza di Windows venga disabilitata dopo 3 tentativi anziché 5 per un errore della quantità di operazioni effettuate, o nella data di scadenza del servizio, o perché non è arrivata una conferma di avvenuto pagamento o rinnovo.

Limiti, spunti e riflessioni

Tutto risolto, dunque? Sfortunatamente, non è così semplice. Il fatto che le caratteristiche di immutabilità e verificabilità del codice sorgente (e, ovviamente, delle sue patch evolutive) siano garantite da una Blockchain non solleva un qualsiasi Smart Contract dalla necessità di essere oltremodo preciso sia nella stesura che nell'implementazione delle regole che ne determinano l’applicazione e/o le remediation da porre in atto a seguito di eventuali anomalie: se così non fosse, rischieremmo di ritrovarci con un codice sorgente composto sì da blocchi immutabili e verificabili, ma al tempo stesso fallato ovvero non pienamente corrispondente a quanto pattuito.

Si pone dunque un problema di controllo ab origine, da svolgersi al di fuori della Blockchain. Chi è in grado di svolgere questa attività, verificando la piena corrispondenza del codice sorgente alle condizioni pattuite e, di conseguenza, certificando la validità implementativa dello Smart Contract stesso? Non certo l'utente, che quasi certamente non è dotato delle competenze necessarie per poter valutare simili aspetti. E ovviamente non è una verifica che rientra nelle peculiarità della Blockchain, la quale può al massimo fornirci le informazioni giuridicamente valide per poter dimostrare, a posteriori, la nullità o non validità del contratto. Si tratta di un ruolo che non può che essere ricoperto da una figura terza, tipicamente un tecnico informatico incaricato di svolgere una perizia da un notaio (ex-ante) o un avvocato (ex-post): in altre parole, le medesime figure che garantiscono la stipula dei contratti tradizionali. Ed ecco che torna prepotentemente in auge il ruolo imprescindibile della fiducia, nonché il necessario (ri)coinvolgimento delle figure "tradizionali" che operano nell'ambito contrattualistico, anche se con funzioni, mansioni e modalità di lavoro sostanzialmente diverse: nello specifico, come intermediari che hanno il compito di dialogare con le parti.

Un ruolo che, probabilmente, farà storcere il naso alla quasi totalità dei notai e a buona parte degli avvocati, solitamente molto restii ad abbandonare il ruolo centrale di garante di stipula per assumere una più accessoria (e potenzialmente meno retribuita) funzione di consulente legale e intermediario. Si tratta ovviamente di una reazione emotiva, legata in parte alla paura di perdere privilegi ormai acquisiti e in parte a un'errata concezione degli effetti determinati dai profondi cambiamenti che il mondo del lavoro sta attraversando in questi ultimi anni: a risultare "vincenti", ancora una volta, saranno quei professionisti e quegli studi che sapranno riconfigurare per tempo la propria attività, rivedendo il proprio skill-set e dotandosi delle risorse necessarie per "traghettare" al meglio la propria realtà d'impresa da un modello di business sempre più obsoleto a nuove e promettenti frontiere da esplorare.

L'alternativa è cadere vittime di un lento declino economico e professionale, provocando e subendo l'auto-adempimento delle più nefaste profezie di Disruptive Innovation: una "apocalisse" di cui oggi si fa un gran parlare e che per molti è già in corso, ma che di fatto travolgerà soltanto chi rifiuterà categoricamente di (r)innovarsi a sua volta.