Fai attenzione al contratto intelligente impossibile

Nodo di origine: 1576899

Le tre idee sbagliate più comuni sul contratto intelligente

Come sviluppatori di una popolare piattaforma blockchain, a volte ci viene chiesto se ci sono contratti intelligenti simili a Ethereum più giri tabella di marcia. La risposta che do sempre è: no, o almeno non ancora.

Ma nel mondo pieno di hype delle blockchain, i contratti intelligenti sono di gran moda, quindi perché mai no? Bene, il problema è che, mentre ora conosciamo tre forti casi d'uso per blockchain in stile Bitcoin autorizzati (provenienza, record interaziendali e finanza leggera), dobbiamo ancora trovare l'equivalente per i contratti intelligenti in stile Ethereum.

Non è che alla gente manchino le idee su cosa vogliono fare contratti intelligenti. Piuttosto, è che tante di queste idee sono semplicemente impossibili. Vedi, quando le persone intelligenti sentono il termine "contratti intelligenti", la loro immaginazione tende a scatenarsi. Evocano sogni di software autonomo intelligente, andando nel mondo, prendendo i suoi dati per il viaggio.

Sfortunatamente la realtà dei contratti intelligenti è molto più banale di tutto ciò che:

Un contratto intelligente è un pezzo di codice che viene archiviato su una blockchain, attivato da transazioni blockchain e che legge e scrive dati nel database di quella blockchain.

Questo è tutto. Veramente. Un contratto intelligente è solo un nome di fantasia per il codice che viene eseguito su una blockchain e interagisce con lo stato di quella blockchain. E cosa is codice? È Pascal, è Python, è PHP. È Java, è Fortran, è C ++. Se stiamo parlando di database, lo è procedura di archiviazione scritto in un'estensione di SQL. Tutti questi linguaggi sono fondamentalmente equivalenti, risolvendo gli stessi tipi di problemi negli stessi modi. Naturalmente, ognuno ha i suoi punti di forza e di debolezza: saresti pazzo a costruire un sito Web in C o comprimere video HD in Ruby. Ma almeno in linea di principio, potresti farlo se lo volessi. Pagheresti solo un prezzo pesante in termini di convenienza, prestazioni e molto probabilmente i tuoi capelli.

Il problema con i contratti intelligenti non è solo che le aspettative delle persone sono esagerate. È che queste aspettative stanno portando molti a spendere tempo e denaro in idee che non possono essere attuate. Sembra che le grandi aziende dispongano di risorse sufficienti per percorrere un lungo cammino, dal momento in cui l'alta dirigenza incontra una nuova tecnologia, fino a quando i vantaggi e i limiti di tale tecnologia sono veramente compresi. Forse la nostra esperienza può aiutare a ridurre questa volta.

Negli ultimi nove mesi, ci sono stati presentati molti casi d'uso di contratti intelligenti e ci siamo ritrovati a rispondere, ripetutamente, che semplicemente non potevano essere fatti. Di conseguenza, abbiamo identificato le tre idee sbagliate del contratto intelligente che sono più comunemente detenute. Queste idee non sono sbagliate perché la tecnologia è immatura o gli strumenti non sono ancora disponibili. Piuttosto, fraintendono il proprietà fondamentali del codice che vive in un database e funziona in modo decentralizzato.

Contattare i servizi esterni

Spesso, il primo caso d'uso proposto è un contratto intelligente che modifica il suo comportamento in risposta a un evento esterno. Ad esempio, una polizza assicurativa agricola che paga in modo condizionale in base alla quantità di pioggia in un determinato mese. Il processo immaginato procede in questo modo: il contratto intelligente attende fino al tempo prestabilito, recupera il bollettino meteorologico da un servizio esterno e si comporta in modo appropriato 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 l'elaborazione di ogni transazione e blocco. Tutto ciò che avviene su una blockchain deve essere completamente deterministico, senza possibilità di far insinuare le differenze. Nel momento in cui due nodi onesti non sono d'accordo sullo stato della catena, l'intero sistema diventa inutile.

Ricordiamo ora che i contratti intelligenti vengono eseguiti in modo indipendente da ogni nodo di una catena. Pertanto, se un contratto intelligente recupera alcune informazioni da una fonte esterna, questo recupero viene eseguito ripetutamente e separatamente da ciascun nodo. Ma poiché questa fonte è al di fuori della blockchain, non vi è alcuna garanzia che ogni nodo riceverà la stessa risposta. Forse l'origine cambierà la sua risposta nel tempo tra le richieste da diversi nodi, o forse diventerà temporaneamente non disponibile. Ad ogni modo, il consenso viene interrotto e l'intera blockchain muore.

Quindi qual è la soluzione? In realtà, è piuttosto semplice. Invece di un contratto intelligente che avvia il recupero di dati esterni, una o più parti di fiducia ("oracoli") crea una transazione che incorpora tali dati nella catena. Ogni nodo avrà una copia identica di questi dati, quindi può essere tranquillamente utilizzato in un calcolo di smart contract. In altre parole, un oracolo spinge i dati sulla blockchain piuttosto che su un contratto intelligente traino dentro.

Quando si tratta di contratti intelligenti che causano eventi nel mondo esterno, appare un problema simile. Ad esempio, a molti piace l'idea di un contratto intelligente che chiama l'API di una banca per trasferire denaro. Ma se ogni nodo esegue autonomamente il codice nella catena, chi è il responsabile della chiamata di questa API? Se la risposta è solo un nodo, cosa succede se quel particolare nodo non funziona correttamente, deliberatamente o no? 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 il contratto intelligente deve sapere se la chiamata API è andata a buon fine, torniamo al problema di dipendere da dati esterni.

Come prima, è disponibile una semplice soluzione alternativa. Invece del contratto intelligente 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 guardare in modo proattivo una blockchain ed eseguire trasferimenti di denaro che rispecchiano le transazioni su catena. Ciò non presenta rischi per il consenso della blockchain perché la catena gioca un ruolo completamente passivo.

Guardando 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 esempi chiari di leggere e scrivere 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 più di questo fatto più avanti.

Applicazione di pagamenti a catena

Ecco un'altra proposta che tendiamo a sentire molto: l'utilizzo di un contratto intelligente per automatizzare il pagamento dei coupon per un cosiddetto "legame intelligente". L'idea è che il codice del contratto intelligente avvenga automaticamente i pagamenti nei momenti opportuni, evitando processi manuali e garantendo che l'emittente non possa essere inadempiente.

Naturalmente, affinché questo funzioni, anche i fondi utilizzati per effettuare i pagamenti devono vivere all'interno della blockchain, altrimenti un contratto intelligente non potrebbe garantire il loro pagamento. Ricordiamo ora che una blockchain è solo un database, in questo caso un libro mastro finanziario contenente l'obbligazione emessa e alcuni contanti. Pertanto, quando parliamo di pagamenti di coupon, ciò di cui stiamo effettivamente parlando sono 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 dal contratto intelligente dell'obbligazione, tali pagamenti possono effettivamente essere garantiti. Ma questo significa anche quei fondi non può essere utilizzato dall'emittente obbligazionario per nient'altro. E se quei fondi non sotto il controllo del contratto intelligente, quindi non è possibile garantire il pagamento.

In altre parole, un'obbligazione intelligente non ha senso per l'emittente o è inutile per l'investitore. E se ci pensate, questo è un risultato completamente ovvio. Dal punto di vista di un investitore, l'intero punto di un'obbligazione è il suo tasso di rendimento interessante, al costo di un certo rischio di insolvenza. E per l'emittente, l'obiettivo di un'obbligazione è quello di raccogliere fondi per un'attività produttiva ma alquanto rischiosa, come la costruzione di una nuova fabbrica. L'emittente obbligazionario non ha modo di utilizzare i fondi raccolti, garantendo allo stesso tempo il rimborso dell'investitore. Non dovrebbe sorprenderlo la connessione tra rischio e rendimento non è un problema che la blockchain può risolvere.

Nascondere dati riservati

Come ho fatto scritto in precedenza, la più grande sfida nella distribuzione di blockchain è la radicale trasparenza che forniscono. Ad esempio, se dieci banche hanno impostato una blockchain insieme e due conducono una transazione bilaterale, questo 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 i contratti intelligenti possano risolvere questo problema. Cominciano dal fatto che ogni contratto intelligente contiene un proprio database in miniatura, sul quale ha il pieno controllo. Tutte le operazioni di lettura e scrittura su questo database sono mediate dal codice del contratto, rendendo impossibile per un contratto la lettura diretta dei dati di un altro. (Questo stretto accoppiamento tra dati e codice si chiama incapsulamento ed è il fondamento del popolare programmazione orientata agli oggetti paradigma.)

Quindi, se un contratto intelligente non può accedere ai dati di un altro, abbiamo risolto il problema della riservatezza della blockchain? Ha senso parlare di nascondere le informazioni in un contratto intelligente? Sfortunatamente la risposta è no. Perché anche se un contratto intelligente non è in grado di leggere i dati di un altro, tali dati vengono comunque archiviati su ogni singolo nodo della catena. Per ogni partecipante blockchain, è nella memoria o nel disco di a 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 un contratto intelligente è sicuro quanto nasconderlo nel codice HTML di una pagina Web. Certo, i normali utenti web non lo vedranno, perché non viene visualizzato nella finestra del browser. Ma è sufficiente che un browser Web aggiunga una funzione "Visualizza sorgente" (come hanno tutti) e le informazioni nascoste 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 viene persa. Un programmatore decente potrebbe farlo in circa un'ora.

A cosa servono i contratti intelligenti

Con così tante cose che i contratti intelligenti non possono fare, ci si 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 in modo diretto e sicuro da entità che non si fidano l'una dell'altra, senza richiedere un amministratore centrale. Le blockchain consentono la disintermediazione dei dati e questo può portare a significativi risparmi in termini di complessità e costi.

Qualsiasi database viene modificato tramite "transazioni", che contengono una serie di modifiche a quel database che devono avere esito positivo o negativo nel suo insieme. Ad esempio, in un libro mastro 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 quella di Bob .

In un normale database centralizzato, queste transazioni vengono create da un'unica autorità attendibile. Al contrario, in un database condiviso guidato da blockchain, le transazioni possono essere create da qualsiasi utente 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 libro mastro finanziario peer-to-peer, ogni transazione deve preservare la quantità totale di fondi, altrimenti i partecipanti potrebbero darsi liberamente quanti soldi vogliono.

Si possono immaginare vari modi di esprimere queste regole, ma per ora ci sono due paradigmi dominanti, ispirati rispettivamente da 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 libro mastro finanziario, la regola afferma che la quantità totale di fondi nelle voci eliminate deve corrispondere al totale in quelli creati. (Riteniamo che la modifica di una voce esistente sia equivalente all'eliminazione di quella voce e alla creazione di una nuova al suo posto.)

Il secondo paradigma, che proviene da Ethereum, sono i contratti intelligenti. 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 forzata procedura memorizzata.) Per modificare i dati di un contratto, gli utenti blockchain inviano richieste al suo codice, che determina se e come soddisfare tali richieste. Come in questo esempio, il contratto intelligente per un libro mastro finanziario svolge le stesse tre attività dell'amministratore di un database centralizzato: la ricerca di fondi sufficienti, la detrazione da un conto e l'aggiunta a un altro.

Entrambi questi paradigmi sono efficaci e ognuno ha i suoi vantaggi e svantaggi, come ho fatto io discusso in dettaglio in precedenza. Riassumendo, i vincoli di transazione in stile Bitcoin offrono concorrenza e prestazioni superiori, mentre i contratti intelligenti in stile Ethereum offrono una maggiore flessibilità. Quindi, per tornare alla domanda su cosa siano gli smart contract:

I contratti intelligenti sono per i casi d'uso della blockchain che non possono essere implementati con vincoli di transazione.

Dato questo criterio per l'utilizzo di contratti intelligenti, devo ancora vedere un caso d'uso forte per blockchain autorizzati che si qualifica. Tutte le avvincenti applicazioni blockchain che conosco possono essere implementate con transazioni in stile Bitcoin, in grado di gestire autorizzazioni e archiviazione generale dei dati, nonché creazione, trasferimento, deposito a garanzia, scambio e distruzione di risorse. Tuttavia, stanno ancora comparendo nuovi casi d'uso, e non sarei sorpreso se alcuni do richiede la potenza di contratti intelligenti. O, almeno, un'estensione del paradigma Bitcoin.

Qualunque sia la risposta, la chiave da ricordare è che i contratti intelligenti sono semplicemente un metodo per limitare le transazioni eseguite in un database. Questa è senza dubbio una cosa utile ed è essenziale per rendere sicuro quel database per la condivisione. Ma i contratti intelligenti non possono fare nient'altro e certamente non possono sfuggire ai confini del database in cui risiedono.

Si prega di inviare eventuali commenti su LinkedIn.

Timestamp:

Di più da più giri