Perché molti casi d'uso degli smart contract sono semplicemente impossibili

Il dott. Gideon Greenspan è il fondatore e CEO di Coin Sciences, l'azienda dietro la piattaforma MultiChain per blockchain private.

In questo articolo Opinioni , Greenspan discute dei contratti intelligenti basati sulla blockchain e del motivo per cui questa applicazione della Tecnologie potrebbe essere affetta da aspettative esagerate.

Come sviluppatore di una popolare piattaforma blockchain, a volte mi viene chiesto se gli smart contract simili a Ethereum siano sulla roadmap di MultiChain. La risposta che do sempre è sempre: "No, o almeno non ancora".

Ma nel mondo pieno di clamore delle blockchain,contratti intelligenti sono di gran moda, quindi perché no? Beh, il problema è che, mentre ora conosciamo tre casi d'uso forti per blockchain in stile bitcoin autorizzate (provenienza, tenuta dei registri aziendali e Finanza leggera), dobbiamo ancora trovare l'equivalente per Ethereumcontratti intelligenti.

Non è che le persone T capiscano cosa vogliono che facciano gli smart contract. Piuttosto, è che molte di queste idee sono semplicemente impossibili. Quando le persone intelligenti sentono il termine "smart contract", la loro immaginazione tende a scatenarsi. Evocano sogni di software intelligenti autonomi, che vanno nel mondo, portando con sé i dati per il viaggio. Sfortunatamente, la realtà degli smart contract è più banale.

Uno smart contract è un pezzo di codice che viene memorizzato su una blockchain, attivato dalle transazioni blockchain e che legge e scrive dati nel database di quella blockchain. Tutto qui. Davvero.

Uno smart contract è solo un nome fantasioso per il codice che gira su una blockchain e interagisce con lo stato di quella blockchain. E qual è il codice? È Pascal, è Python, è PHP. È Java, è Fortran, è C++. Se parliamo di database, sono procedure archiviate scritte in un'estensione di SQL.

Tutti questi linguaggi sono fondamentalmente equivalenti, risolvono gli stessi tipi di problemi negli stessi tipi di modi. Naturalmente, ognuno ha i suoi punti di forza e di debolezza: saresti pazzo a creare un sito web in C o a comprimere un video HD in Ruby. Ma almeno in linea di principio, potresti farlo se volessi. Pagheresti solo un prezzo elevato in termini di praticità, prestazioni e, molto probabilmente, i tuoi capelli.

Il problema con i contratti intelligenti T è solo che le aspettative delle persone sono esagerate, ma che queste aspettative portano molti a spendere tempo e denaro su idee che non possono essere implementate.

Sembra che le grandi aziende abbiano risorse sufficienti per percorrere un lungo cammino, dal momento in cui il senior management incontra una nuova Tecnologie, a quando i vantaggi e i limiti di quella tecnologia vengono realmente compresi. Forse la nostra esperienza può aiutare ad accorciare questo lasso di tempo.

Negli ultimi nove mesi ci sono stati proposti molti casi d'uso di contratti intelligenti e ci siamo ritrovati a rispondere, più e più volte, che semplicemente non erano realizzabili.

Di conseguenza, abbiamo identificato i tre malintesi più comuni sugli smart contract. Queste idee T sono sbagliate perché la Tecnologie è immatura o gli strumenti non sono ancora disponibili.

Piuttosto, fraintendono le proprietà fondamentali del codice che risiede in un database e viene eseguito in modo decentralizzato.

1. Contattare servizi esterni

Spesso, il primo caso d'uso proposto è uno smart contract che modifica il suo comportamento in risposta a un evento esterno. Ad esempio, una Politiche assicurativa agricola che paga in modo condizionale in base alla quantità di pioggia in un dato mese.

Il processo immaginato è più o meno questo: lo smart contract attende fino all'orario prestabilito, recupera il bollettino meteo da un servizio esterno e si comporta di conseguenza in base ai dati ricevuti.

Tutto questo sembra abbastanza semplice, ma è anche impossibile. Perché? Perché una blockchain è un sistema basato sul consenso, il che significa che funziona solo se ogni nodo raggiunge uno stato identico dopo aver elaborato ogni transazione e blocco.

Tutto ciò che avviene su una blockchain deve essere completamente deterministico, senza alcuna possibilità che le differenze si insinuino. Nel momento in cui due nodi onesti non sono d'accordo sullo stato della catena, l'intero sistema diventa inutile.

Ora, ricorda che gli smart contract vengono eseguiti indipendentemente da ogni nodo su una catena. Pertanto, se uno smart contract recupera alcune informazioni da una fonte esterna, questo recupero viene eseguito ripetutamente e separatamente da ogni nodo. Ma poiché questa fonte è esterna alla blockchain, non vi è alcuna garanzia che ogni nodo riceverà la stessa risposta.

Forse la fonte cambierà la sua risposta nel tempo tra le richieste da nodi diversi, o forse diventerà temporaneamente non disponibile. In entrambi i casi, il consenso è rotto e l'intera blockchain muore.

Quindi, qual è la soluzione alternativa? In realtà, è piuttosto semplice. Invece di uno smart contract che avvia il recupero di dati esterni, ONE o più parti fidate ("oracoli") creano una transazione che incorpora tali dati nella catena. Ogni nodo avrà una copia identica di questi dati, quindi possono essere utilizzati in modo sicuro in un calcolo di smart contract.

In altre parole, è un oracolo a inserire i dati nella blockchain anziché uno smart contract a importarli.

Quando si tratta di smart contract che causano Eventi nel mondo esterno, si verifica un problema simile. Ad esempio, a molti piace l'idea di uno smart contract che richiama l'API di una banca per trasferire denaro. Ma se ogni nodo esegue in modo indipendente il codice nella catena, chi è responsabile della chiamata di questa API?

Se la risposta è solo ONE nodo, cosa succede se quel particolare nodo non funziona correttamente, deliberatamente o meno? E se la risposta è ogni nodo, possiamo fidarci di ogni nodo con la password di quell'API? E vogliamo davvero che l'API venga chiamata centinaia di volte? Ancora peggio, se lo smart contract ha bisogno di sapere se la chiamata API ha avuto successo, torniamo al problema di dipendere da dati esterni.

Come prima, è disponibile una semplice soluzione alternativa. Invece dello smart contract che chiama un'API esterna, utilizziamo un servizio affidabile che monitora lo stato della blockchain ed esegue determinate azioni in risposta. Ad esempio, una banca potrebbe monitorare in modo proattivo una blockchain ed eseguire trasferimenti di denaro che rispecchiano le transazioni on-chain. Ciò non presenta alcun rischio per il consenso della blockchain perché la catena svolge un ruolo completamente passivo.

Esaminando queste due soluzioni alternative, possiamo fare alcune osservazioni.

Innanzitutto, entrambi richiedono un'entità fidata per gestire le interazioni tra la blockchain e il mondo esterno. Sebbene ciò sia tecnicamente possibile, mina l'obiettivo di un sistema decentralizzato.

In secondo luogo, i meccanismi utilizzati in queste soluzioni alternative sono semplici esempi di lettura e scrittura di un database. Un oracolo che fornisce informazioni esterne sta semplicemente scrivendo tali informazioni nella catena. E un servizio che rispecchia lo stato della blockchain nel mondo reale non sta facendo altro che leggere da quella catena. In altre parole, qualsiasi interazione tra una blockchain e il mondo esterno è limitata alle normali operazioni del database.

Parleremo di questo fatto più avanti.

2. Applicazione dei pagamenti on-chain

Ecco un'altra proposta che tendiamo a sentire molto spesso: usare uno smart contract per automatizzare il pagamento delle cedole per un cosiddetto "smart BOND". L'idea è che il codice dello smart contract avvii automaticamente i pagamenti nei tempi appropriati, evitando processi manuali e garantendo che l'emittente non possa essere inadempiente.

Naturalmente, affinché ciò funzioni, anche i fondi utilizzati per effettuare i pagamenti devono risiedere all'interno della blockchain, altrimenti uno smart contract non potrebbe in alcun modo garantire il pagamento.

Ricorda che una blockchain è solo un database, in questo caso un registro finanziario contenente l' BOND emessa e un po' di denaro. Quindi, quando parliamo di pagamenti di cedole, in realtà stiamo parlando di operazioni di database che avvengono automaticamente in un momento concordato.

Sebbene questa automazione sia tecnicamente fattibile, soffre di una difficoltà finanziaria. Se i fondi utilizzati per i pagamenti delle cedole sono controllati dallo smart contract dell'obbligazione, allora quei pagamenti possono effettivamente essere garantiti. Ma ciò significa anche che quei fondi non possono essere utilizzati dall'emittente BOND per nient'altro. E se quei fondi T sono sotto il controllo dello smart contract, allora non c'è modo in cui il pagamento possa essere garantito.

In altre parole, uno smart BOND è inutile per l'emittente o inutile per l'investitore. E se ci pensate, questo è un risultato del tutto ovvio.

Dal punto di vista di un investitore, il punto di BOND è il suo tasso di rendimento interessante, a costo di un certo rischio di insolvenza. E per l'emittente, lo scopo di un'obbligazione è raccogliere fondi per un'attività produttiva ma in qualche modo rischiosa, come la costruzione di una nuova fabbrica.

Non c'è modo per l'emittente BOND di utilizzare i fondi raccolti, garantendo al contempo che l'investitore verrà rimborsato. Non dovrebbe sorprendere che la connessione tra rischio e rendimento non sia un problema che le blockchain possono risolvere.

3. Nascondere dati riservati

Come ho già scritto in precedenza, la sfida più grande nell’implementazione delle blockchain è la trasparenza radicale che esse forniscono.

Ad esempio, se 10 banche impostano insieme una blockchain e due conducono una transazione bilaterale, questa sarà immediatamente visibile alle altre otto. Sebbene esistano varie strategie per mitigare questo problema, nessuna batte la semplicità e l'efficienza di un database centralizzato in cui un amministratore fidato ha il pieno controllo su chi può vedere cosa.

Alcune persone pensano che gli smart contract possano risolvere questo problema. Partono dal fatto che ogni smart contract contiene il suo database in miniatura, su cui ha il pieno controllo. Tutte le operazioni di lettura e scrittura su questo database sono mediate dal codice del contratto, rendendo impossibile per ONE contratto leggere direttamente i dati di un altro. (Questo stretto accoppiamento tra dati e codice è chiamato incapsulamento ed è il fondamento del popolare paradigma di programmazione orientato agli oggetti).

Quindi, se ONE smart contract T può accedere ai dati di un altro, abbiamo risolto il problema della riservatezza della blockchain? Ha senso parlare di nascondere informazioni in uno smart contract? Sfortunatamente, la risposta è no.

Perché anche se ONE smart contract T riesce a leggere i dati di un altro, quei dati sono comunque archiviati su ogni singolo nodo della catena. Per ogni partecipante alla blockchain, sono nella memoria o sul disco di un sistema che quel partecipante controlla completamente. E non c'è nulla che impedisca loro di leggere le informazioni dal proprio sistema, se e quando scelgono di farlo.

Nascondere i dati in uno smart contract è quasi sicuro quanto nasconderli nel codice HTML di una pagina web. Certo, gli utenti web normali T li vedranno, perché non vengono visualizzati nella finestra del loro browser. Ma tutto ciò che serve è che un browser web aggiunga una funzione "Visualizza sorgente" (come hanno tutti) e le informazioni diventano universalmente visibili.

Allo stesso modo, per i dati nascosti nei contratti intelligenti, tutto ciò che serve è che qualcuno modifichi il proprio software blockchain per visualizzare lo stato completo del contratto, e ogni parvenza di segretezza andrà persa.

Un programmatore decente potrebbe farlo in circa un'ora.

A cosa servono gli smart contract

Con così tante cose che gli smart contract non possono fare, ONE potrebbe chiedere a cosa servano realmente. Ma per rispondere a questa domanda, dobbiamo tornare ai fondamenti delle blockchain stesse. Per ricapitolare, una blockchain consente a un database di essere condiviso direttamente e in modo sicuro da entità che non si fidano l'una dell'altra, senza richiedere un amministratore centrale.

Le blockchain consentono la disintermediazione dei dati, il che può comportare notevoli risparmi in termini di complessità e costi.

Ogni database viene modificato tramite "transazioni", che contengono un set di modifiche a quel database che devono avere successo o fallire nel complesso. Ad esempio, in un registro finanziario, un pagamento da ALICE a Bob è rappresentato da una transazione che (a) controlla se ALICE ha fondi sufficienti, (b) deduce una quantità dal conto di Alice e (c) aggiunge la stessa quantità a quello di Bob.

In un normale database centralizzato, queste transazioni vengono create da una singola autorità fidata. Al contrario, in un database condiviso basato su blockchain, le transazioni possono essere create da uno qualsiasi degli utenti di quella blockchain. E poiché questi utenti non si fidano completamente l'uno dell'altro, il database deve contenere regole che limitano le transazioni eseguite.

Ad esempio, in un registro finanziario peer-to-peer, ogni transazione deve conservare la quantità totale di fondi, altrimenti i partecipanti potrebbero liberamente darsi quanti soldi desiderano.

ONE possono immaginare vari modi di esprimere queste regole, ma per ora ci sono due paradigmi dominanti, ispirati rispettivamente a Bitcoin ed Ethereum. Il metodo Bitcoin , che potremmo chiamare "vincoli di transazione", valuta ogni transazione in termini di: (a) le voci del database eliminate da quella transazione e (b) le voci create.

In un registro finanziario, la regola stabilisce che la quantità totale di fondi nelle voci eliminate deve corrispondere al totale di quelle create. (Consideriamo la modifica di una voce esistente come l'equivalente dell'eliminazione di tale voce e della creazione di una nuova ONE al suo posto).

Il secondo paradigma, che deriva da Ethereum, è quello degli smart contract. Questo afferma che tutte le modifiche ai dati di un contratto devono essere eseguite dal suo codice. (Nel contesto dei database tradizionali, possiamo pensare a questo come a una stored procedure forzata.) Per modificare i dati di un contratto, gli utenti della blockchain inviano richieste al suo codice, che determina se e come soddisfare tali richieste.

Come in questo esempio, lo smart contract per un libro mastro finanziario esegue le stesse tre attività dell'amministratore di un database centralizzato: verifica della presenza di fondi sufficienti, detrazione da ONE conto e aggiunta a un altro.

Entrambi questi paradigmi sono efficaci e ognuno ha i suoi vantaggi e svantaggi. Per riassumere, i vincoli di transazione in stile bitcoin forniscono concorrenza e prestazioni superiori, mentre gli smart contract in stile Ethereum offrono maggiore flessibilità.

Tornando alla domanda a cosa servono gli smart contract: gli smart contract sono pensati per casi d'uso blockchain che T possono essere implementati con vincoli di transazione.

Dato questo criterio per l'utilizzo di contratti intelligenti, devo ancora vedere un caso d'uso valido per le blockchain autorizzate che si qualifichi.

Tutte le applicazioni blockchain interessanti che conosco possono essere implementate con transazioni in stile bitcoin, che possono gestire autorizzazioni e archiviazione dati generale, nonché creazione, trasferimento, deposito a garanzia, scambio e distruzione di asset. Tuttavia, continuano ad apparire nuovi casi d'uso e T sarei sorpreso se alcuni richiedessero la potenza degli smart contract. O, come minimo, un'estensione del paradigma Bitcoin .

Qualunque sia la risposta, la cosa importante da ricordare è che i contratti intelligenti sono semplicemente ONE metodo per limitare le transazioni eseguite in un database.

Questa è senza dubbio una cosa utile, ed è essenziale per rendere quel database sicuro per la condivisione. Ma gli smart contract non possono fare altro, e certamente non possono uscire dai confini del database in cui risiedono.

Immagine di matita e gommatramite Shutterstock