Contratti intelligenti: il buono, il cattivo e il pigro

Timestamp: 1 novembre 2015 8:59

Perché le blockchain private non dovrebbero essere ansiose di eseguire codice

Non sono un fan del termine "contratti intelligenti". Per cominciare, è stato utilizzato da così tante persone per così tante cose diverse, che probabilmente dovremmo semplicemente vietarlo completamente. Ad esempio, il primo riferimento noto è del 1997, quando Nick Szabo lo usò per descrivere oggetti fisici che cambiare il loro comportamento sulla base di alcuni dati. Più recentemente, il termine è stato usato per l'esatto opposto: descrivere il calcolo su una blockchain che è influenzato da eventi esterni come il tempo. Per ora mettiamo da parte entrambi questi significati.

Voglio concentrarmi qui sui "contratti intelligenti" nel senso di un calcolo di uso generale che avviene su una blockchain. Questo significato è stato reso popolare da Ethereum, il cui white paper è sottotitolato "Un contratto intelligente di nuova generazione e una piattaforma applicativa decentralizzata". Come risultato dell'attenzione che Ethereum ha ricevuto, questo significato è diventato dominante, con le banche (e altre) che lavorano su prove di concetto di contratti intelligenti. Naturalmente, poiché stiamo parlando di istituzioni finanziarie regolamentate, questo è principalmente nel contesto di blockchain privati ​​o autorizzati, che hanno un insieme limitato di partecipanti identificati. Per ragioni che sono ora capito bene, le blockchain pubbliche, per tutta la loro genialità, non sono ancora adatte per scopi aziendali.

Quindi il futuro è luminoso per i contratti intelligenti nelle blockchain private? Beh, più o meno, ma non proprio. Vedi, il problema è:

Nelle blockchain private, i contratti intelligenti combinano quattro buone idee con una cattiva.

Allora quali sono le buone idee? (a) esprimere la logica aziendale come un programma per computer, (b) rappresentare gli eventi che attivano tale logica come messaggi al programma, (c) utilizzare firme digitali per dimostrare chi ha inviato i messaggi e (d) mettere tutto quanto sopra sopra una blockchain.

E quello cattivo? Esecuzione di ogni programma per ogni messaggio su ogni nodo blockchain. In altre parole, creare il file esecuzione di tutti i programmi il lavoro della blockchain, invece di usarlo semplicemente come conservazione per i programmi e i messaggi. Eppure questa esecuzione globale è l'intera ragione per cui Ethereum è stato sviluppato.

Se sei a conoscenza del file natura deterministica del calcolo, conoscere il fermare il problemae capire come dipendenze dei dati prevenire la concorrenza allora potresti già essere convinto. Ma se no, fatti un caffè, fai un respiro profondo e seguimi nella tana del coniglio ...

Capire Ethereum

Per comprendere i contratti intelligenti in stile Ethereum, dobbiamo iniziare con bitcoin, la prima (e ancora la più popolare) blockchain pubblica. La blockchain bitcoin è stata originariamente progettata per una sola cosa: spostare la valuta bitcoin da un proprietario all'altro. Ma una volta che è stato installato e funzionante, le persone hanno iniziato a incorporare "metadati" nelle transazioni per servire ad altri scopi, come beni digitali ed autenticazione notarile. Mentre alcuni bitcoiners combattuta queste applicazioni, un meccanismo ufficiale per i metadati è stato introdotto nel marzo 2014, con l'utilizzo crescere in modo esponenziale da allora.

Oltre ai progetti basati sulla blockchain bitcoin, sono state sviluppate e lanciate molte blockchain pubbliche di nuova generazione, come Nxt, Bitshares, Ripple ed Stellar. Questi sono stati progettati da zero per supportare una più ampia gamma di attività, come asset creati dagli utenti, scambio decentralizzato e prestiti garantiti. Ognuna di queste blockchain ha un diverso set di funzionalità, come deciso dai suoi sviluppatori, e ognuna deve essere aggiornata da tutti i suoi utenti quando viene aggiunta una nuova funzionalità. Le cose hanno iniziato a diventare piuttosto complicate.

Essendo stato coinvolto in alcuni di questi progetti, Vitalik Buterin ha posto una domanda semplice ma brillante: invece di molte blockchain specifiche per l'applicazione, perché non avere una singola blockchain pubblica che può essere programmata per qualunque cosa potremmo desiderare? Questa über-blockchain sarebbe infinitamente estendibile, limitata solo dall'immaginazione di chi la utilizza. Il mondo degli appassionati di criptovaluta è stato convinto quasi all'unanimità da questa potente idea. E così, con 18 milioni di dollari in crowdfunding e con grande emozione, è nato Ethereum.

Ethereum è una nuova blockchain pubblica con una criptovaluta associata chiamata "ether", come centinaia che è venuto prima. Ma a differenza di altri blockchain, Ethereum consente a chiunque di creare un "contratto" all'interno della blockchain. Un contratto è un programma per computer con un database in miniatura associato, che può essere modificato solo dal programma che lo possiede. Se un utente blockchain desidera modificare un database, deve inviare un messaggio firmato digitalmente al suo contratto. Il codice nel contratto esamina questo messaggio per decidere se e come reagire. (Questo "incapsulamento"Di codice e dati è anche un fondamento di orientata agli oggetti programmazione.)

I contratti di Ethereum possono essere scritti in uno dei numerosi nuovi linguaggi di programmazione, come Solidity ed serpente. Come la maggior parte dei linguaggi di programmazione, questi sono Turing completo, nel senso che possono esprimere qualsiasi calcolo di uso generale. Una caratteristica fondamentale delle lingue complete di Turing è il struttura ad anello, che esegue un'operazione ripetutamente fino a quando una condizione non viene soddisfatta. Ad esempio, un ciclo potrebbe essere utilizzato per stampare i numeri da uno a un milione, senza richiedere un milione di righe di codice. Per motivi di efficienza, i programmi scritti per Ethereum lo sono compilato (cioè convertito) in più compatto codice a byte prima di essere riposto sulla catena. I nodi Ethereum eseguono quindi questo bytecode all'interno di un file macchina virtuale, che è essenzialmente un computer simulato in esecuzione all'interno di uno reale.

Quando un contratto Ethereum viene creato sulla blockchain, imposta lo stato iniziale del suo database. Poi si ferma, aspettando educatamente finché non viene chiamato. Quando un utente della blockchain (o di un altro contratto) gli invia un messaggio in una transazione, il contratto entra in azione. A seconda del codice contenuto, può identificare l'origine del messaggio, attivare altri contratti, modificare il proprio database e / o inviare una risposta al chiamante. Tutti questi passaggi vengono eseguiti in modo indipendente su ogni nodo della rete, con risultati identici.

Per fare un esempio, un semplice Ethereum contratto di sottovaluta mantiene un database di saldi utente per un particolare asset. Se riceve un messaggio per trasferire fondi da Alice a Bob, (a) controllerà che il messaggio sia stato firmato da Alice, (b) verificherà che Alice abbia fondi sufficienti, (c) trasferirà fondi da Alice all'account di Bob nel database e (d) rispondere che l'operazione è andata a buon fine. Ovviamente, non abbiamo bisogno di Ethereum per questo, perché una semplice blockchain in stile bitcoin con supporto di risorse native può fare la stessa cosa. Ethereum si distingue davvero per la complessa logica di business in più fasi, come il crowdfunding, gli scambi decentralizzati e le strutture di governance gerarchica. O almeno così la promessa va.

Scomponendola

Ora che sappiamo come funzionano i contratti intelligenti di Ethereum, possiamo suddividerli in cinque parti costitutive:

  1. Esprimere la logica aziendale come programmi per computer.
  2. Rappresentare gli eventi che innescano quella logica come messaggi ai programmi.
  3. Utilizzo delle firme digitali per dimostrare chi ha inviato i messaggi.
  4. Mettere i programmi, i messaggi e le firme su una blockchain.
  5. Esecuzione di ogni programma per ogni messaggio su ogni nodo.

Per ripetere ciò che ho detto all'inizio, credo che le parti da 1 a 4 siano ottime idee. Cominciamo con i primi due (che, a proposito, non sono nuovi). A differenza dei contratti legali che possono avere differenze di interpretazione, i programmi per computer non sono ambigui. Per un dato programma in un linguaggio di programmazione ben definito, lo stesso input porta sempre allo stesso output. Quindi, se una logica aziendale viene espressa come un programma per computer e gli eventi sono rappresentati come messaggi a quel programma, il risultato aziendale è scolpito nella pietra. In effetti, questa proprietà deterministica del calcolo fa casualità un problema complicato nell'informatica, e anche i fanatici di Google possono farlo sbagli.

E le firme digitali e le blockchain? Questi evitano la necessità di un'autorità centrale per determinare quali messaggi sono stati inviati, in quale ordine e da chi. Invece, ogni partecipante crea una coppia di file chiavi private e pubblichee distribuisce la sua chiave pubblica una volta agli altri partecipanti. In seguito, loro segno ogni messaggio con la propria chiave privata prima di distribuirlo in rete. Gli altri partecipanti possono quindi verificare l'origine del messaggio utilizzando solo la chiave pubblica del mittente. È roba crittografica intelligente. Infine, mettendo il programma e i messaggi firmati su una blockchain, possiamo garantire che ogni partecipante abbia una visione identica di chi ha fatto cosa e quando. Combinato con il calcolo deterministico, questo significa i partecipanti non possono essere in disaccordo sul risultato finale dell'attività.

Ma per quanto riguarda l'ultima idea, di ogni nodo che esegue ogni programma per ogni messaggio? Qui arriviamo alla parte controversa. Perché sebbene questa esecuzione globale possa essere piacevole da avere, non è nemmeno necessaria. Poiché il calcolo è deterministico, non fa differenza se un programma viene eseguito da un nodo, ogni nodo o un processo esterno. Inoltre, non importa se ciò avviene in tempo reale, su richiesta o 10 anni dopo. Il risultato del calcolo sarà sempre lo stesso. E se per qualche motivo non è così, ciò può essere dovuto solo a un file problema nel software o nella rete blockchain.

Il problema con il calcolo

Se non importa dove avviene un calcolo, perché non farlo ovunque? Bene, si scopre che i programmi per computer sono imprevedibili. Per quanto innocenti possano sembrare, possono volerci molto tempo per correre. E a volte, continuano a correre per sempre. Considera il seguente esempio classico (noto come LCG):

  1. Impostato x a un numero di una cifra a tua scelta
  2. Impostato y a 123 * x + 567
  3. Impostato x alle ultime due cifre di y, Cioè e modulo 100
  4. If x è più che 2 quindi torna al passaggio 2
  5. Altrimenti fermarsi e visualizzare il valore di x

Abbastanza semplice, vero? Quindi ecco una domanda per te: questo programma finirà mai? O si bloccherà in un file ciclo infinito? Non sei così sicuro? Bene, lascia che ti metta fuori dalla tua miseria: Dipende dal valore iniziale di x.

If x is 0, 1, 2, 5, 6, 7 or 8, il programma si interrompe abbastanza rapidamente. Ma se x is 3, 4 or 9, continua indefinitamente. Non mi credi? Apri Excel e prova tu stesso (avrai bisogno della funzione "MOD").

Se non puoi prevederlo solo guardando il codice, non sentirti troppo male. Perché non solo è difficile per le persone, è impossibile per i computer. Il problema di determinare se un determinato programma terminerà l'esecuzione è chiamato fermare il problema. Nel 1936, Alan Turing, di "Turing complete" e Il gioco dell'imitazione fama, ha dimostrato che non può essere risolto per il caso generale. Salvo banali eccezioni, l'unico modo per scoprire se un programma finirà di funzionare è eseguirlo per tutto il tempo necessarioe potrebbe durare per sempre.

Per quelli di noi che preferirebbero vivere senza schermate blu della morte ed palloni da spiaggia rotanti, è tutto piuttosto scomodo. Ma conviviamo con esso e, sorprendentemente, la maggior parte del software funziona senza problemi per la maggior parte del tempo. In caso contrario, i sistemi operativi moderni come Windows ci proteggono dal codice in fuga permettendoci di terminare i programmi manualmente. Tuttavia la stessa cosa non si può fare su una blockchain come Ethereum. Se permettessimo ai singoli nodi di terminare i calcoli a piacimento, i diversi nodi avrebbero opinioni diverse sul risultato di quei calcoli. In altre parole, il file il consenso della rete verrebbe meno. Allora cosa deve fare una blockchain?

La risposta di Ethereum si basa sulle commissioni di transazione, note anche come gas. Il mittente di ogni transazione paese per i calcoli si innesca e questo pagamento viene raccolto dal minatore che lo conferma in un blocco. Per essere più precisi, ogni transazione Ethereum afferma in anticipo quanto dell'etere del mittente può essere speso per elaborarlo. La commissione viene spesa gradualmente man mano che il contratto viene eseguito, passo dopo passo, all'interno della macchina virtuale Ethereum. Se una transazione esaurisce le commissioni prima che termini l'esecuzione, tutte le modifiche al database vengono annullate e la commissione non viene restituita. Se una transazione viene completata correttamente, l'eventuale commissione rimanente viene restituita al mittente. In questo modo, le transazioni possono gravare sulla rete solo nella misura in cui sono disposte a pagare per questo. È indubbiamente una buona soluzione economica, ma richiede una valuta blockchain nativa per funzionare.

Contratti intelligenti vs concorrenza

Se il gas può impedire calcoli impazziti, i contratti intelligenti ottengono il via libera? Beh, non così velocemente, perché c'è un altro problema con i contratti intelligenti di cui dobbiamo parlare:

I contratti intelligenti funzionano male per un throughput elevato delle transazioni.

Concorrenza è una delle questioni fondamentali nell'architettura dei computer. Un sistema ha una buona concorrenza se consente l'esecuzione di più processi contemporaneamente e in qualsiasi ordine. I sistemi simultanei riducono i ritardi e consentono un throughput complessivo molto più elevato, facendo un uso ottimale di tecnologie come programmazione del processo, elaborazione parallela ed partizionamento dei dati. È così che cerca Google 30 miliardi quasi pagine web volte 100,000 al secondo.

In qualsiasi sistema informatico, un insieme di transazioni può essere elaborato simultaneamente solo se non dipendono o interferiscono l'una con l'altra. In caso contrario, diversi ordini di elaborazione potrebbero portare a risultati completamente diversi. Ora ricorda che uno smart contract ha un database associato e che esegue calcoli generici inclusi i loop. Ciò significa che, in risposta a un particolare messaggio, uno smart contract potrebbe leggere o scrivere ogni singola informazione nel proprio database. Ad esempio, se gestisce una sottovaluta, potrebbe decidere di pagare degli interessi a ogni detentore di quella valuta. Ovviamente non sarà sempre così. Ma il problema è: prima di eseguire il programma del contratto per un particolare messaggio, un nodo blockchain non può prevedere quale sottoinsieme del database del contratto verrà utilizzato. Né può dire se questo sottoinsieme avrebbe potuto essere diverso in circostanze diverse. E se un contratto può innescarne un altro, questo problema si estende al intero contenuto di ogni database di ogni contratto. Quindi ogni transazione deve essere trattata come se potesse interferire l'una con l'altra. In termini di database, ogni transazione richiede un blocco globale.

Ora pensa al mondo in cui vive un nodo blockchain. Le transazioni arrivano da peer diversi, in nessun ordine particolare, poiché non esiste una coda gestita centralmente. Inoltre, a intervalli medi compresi tra 12 secondi (Ethereum) e 10 minuti (bitcoin), arriva un nuovo blocco, che conferma un insieme di transazioni in un ordine specifico. Un nodo avrà probabilmente già visto la maggior parte delle transazioni di un blocco, ma alcune potrebbero essere nuove. In ogni caso, è improbabile che l'ordine delle transazioni nel blocco rifletta l'ordine in cui sono arrivate individualmente. E poiché l'ordine delle transazioni potrebbe influenzare il risultato, questo significa le transazioni non possono essere elaborate fino a quando il loro ordine nella blockchain non è confermato.

Ora, è vero che una transazione bitcoin non confermata potrebbe dover essere annullata a causa di un file doppia spesa. Ma una transazione Ethereum non confermata non ha alcun risultato prevedibile. In effetti, le attuali implementazioni di Ethereum non elaborano nemmeno transazioni non confermate. Ma se un nodo Ethereum Prima per elaborare le transazioni immediatamente, sarebbe comunque necessario riavvolgerle e riprodurle nell'ordine corretto quando arriva un blocco. Questa rielaborazione è un enorme spreco di sforzi e impedisce ai processi esterni di in concomitanza leggendo il database di Ethereum mentre va avanti. (Per essere onesti, va notato che bitcoin implementazione di riferimento riavvolge e riproduce anche le transazioni quando arriva un blocco, ma ciò è dovuto solo a una mancanza di ottimizzazione.)

Allora, di cosa si tratta nel modello di transazione di bitcoin che rende possibile l'esecuzione fuori ordine? In bitcoin, ogni transazione afferma esplicitamente il suo rapporto con altre transazioni. Ha un insieme di input e output, in cui ogni input è collegato all'output di una transazione precedente che "spende". Non ci sono altre dipendenze di cui preoccuparsi. Finché (a) due transazioni bitcoin non tentano di spendere lo stesso output e (b) l'output di uno non porta all'input di un altro, un nodo bitcoin può essere sicuro che le transazioni siano indipendenti e può elaborarli in qualsiasi ordine. Le loro posizioni finali nella blockchain non contano affatto.

Per utilizzare la terminologia informatica formale, le transazioni di Ethereum devono essere rigorosamente totalmente ordinato, il che significa che è necessario definire l'ordine relativo tra ogni coppia di transazioni. Al contrario, le transazioni bitcoin formano un file grafico aciclico diretto che è solo parzialmente ordinato, il che significa che è consentita una certa ambiguità nell'ordinamento delle transazioni. Quando si tratta di concorrenza, questo fa la differenza nel mondo.

Per guardarlo in termini pratici, si è parlato molto di blockchain private nell'azienda. Ma una blockchain privata è solo un file database distribuito con alcune funzionalità aggiuntive. E se oggi provi a vendere un database di classe enterprise che non supporta la concorrenza, saresti deriso fuori dalla stanza. Altrettanto ridicolo sarebbe il suggerimento che un singolo nodo debba attendere 12 secondi prima di vedere il risultato delle proprie transazioni. Come lo stesso Vitalik recentemente twittato:

Per noi di Coin Sciences questa non è solo una questione accademica, perché dobbiamo decidere se e come incorporare i contratti intelligenti più giri. Stranamente, nonostante le centinaia di richieste di funzionalità e abbiamo ricevuto finora, solo due sono stati correlati a contratti intelligenti, e anche allora in una forma più debole di quella fornita da Ethereum. Quindi, pur mantenendo una mente aperta, potrebbe risultare che i contratti intelligenti non risolvano alcun problema reale per i nostri utenti.

A favore di Ethereum

Se sei interessato solo a un lato dell'argomento, puoi smettere di leggere qui. Ma ti starai chiedendo: i creatori di Ethereum sono stupidi? Perché mai dovrebbero richiedere l'esecuzione globale in un database distribuito pubblico, se ogni nodo potesse semplicemente scegliere quali programmi desidera eseguire? Ci sono buone ragioni per il metodo Ethereum?

In realtà, se parliamo di blockchain pubblici, credo che ci siano. Ma per comprendere queste ragioni, dobbiamo pensare alle dinamiche della stessa rete Ethereum.

Prevenire lo spam nelle transazioni

Una blockchain è gestita da una rete peer-to-peer, in cui ogni nodo è connesso a un sottoinsieme casuale degli altri nodi. Quando una nuova transazione viene creata su un nodo, si diffonde rapidamente e in modo casuale agli altri attraverso un processo chiamato "relaying". In una rete pubblica aperta, chiunque può creare transazioni, quindi abbiamo bisogno di un modo per proteggerci spam nelle transazioni che potrebbe sopraffare il sistema. Poiché la rete è decentralizzata, ciò può essere ottenuto solo dai singoli nodi che valutano le nuove transazioni man mano che arrivano e decidono se inoltrarle o meno. Sebbene questo meccanismo non possa impedire a uno spammer di travolgente un singolo nodo, protegge la rete nel suo complesso.

In una rete pubblica, quando un nodo decide se ritrasmettere una nuova transazione, un criterio chiave è il rapporto tra la sua tariffa e il suo costo per la rete. Nel caso del bitcoin, questo costo si basa principalmente sulla dimensione grezza della transazione in byte. In Ethereum, a formula più complessa viene utilizzato, in base allo sforzo computazionale che la transazione consumerà. In ogni caso, le commissioni agiscono come un meccanismo di mercato per la prevenzione dello spam nelle transazioni.

Ma come fa un nodo a sapere se il mittente ha fondi sufficienti per coprire la tariffa che sta offrendo? Nel caso di Ethereum, il saldo di "ether" di ciascun utente è influenzato dal risultato delle transazioni precedenti, da allora i contratti possono sia spendere che pagare ether. Quindi, senza eseguire effettivamente tutti i programmi per tutti i messaggi precedenti, un nodo Ethereum non ha modo di conoscere il saldo aggiornato di un utente. Pertanto, non può valutare se una transazione debba essere inoltrata ad altri nodi. E senza quello, una rete aperta potrebbe essere distrutta banalmente.

Prove di dati compatte

In una blockchain, i blocchi vengono riempiti principalmente dalle transazioni che confermano. Tuttavia ogni blocco ha anche un "header" compatto, che contiene informazioni importanti come un timestamp e un collegamento al blocco precedente. Per blockchain pubbliche basate su prova di hashing del lavoro, l'input per l'algoritmo di hashing è solo questa intestazione di blocco. Ciò significa che l'autorità di una catena può essere valutata da un "client leggero" senza scaricare la maggior parte del suo contenuto. Ad esempio, a novembre 2015, il set completo di intestazioni bitcoin ha una dimensione di 30 MB, rispetto a 45 GB per l'intera catena. Si tratta di un rapporto di 1500: 1, che fa una differenza fondamentale per i dispositivi mobili con larghezza di banda e spazio di archiviazione limitati.

L'intestazione di ogni blocco Ethereum contiene una "radice di stato", che imprime lo stato della catena dopo l'elaborazione delle transazioni in quel blocco. Tra le altre cose, questo stato copre il contenuto del database di ogni contratto, con l'impronta digitale calcolata in modo efficiente utilizzando un file albero delle funzioni hash unidirezionali. La minima modifica al database di qualsiasi contratto porterebbe a una radice di stato completamente diversa, quindi la radice "lega" il contenuto del database. (Una nozione equivalente di "impegni UTXO" per bitcoin è stata discusso ma non ancora implementato.)

Il metodo ad albero per calcolare le radici di stato ha una proprietà importante: Data una radice di stato nota, il valore di una particolare voce in un database di contratti può essere dimostrato in modo efficiente. La dimensione di questa dimostrazione è proporzionale alla profondità di a albero binario le cui foglie sono le singole voci del database, cioè log2 la dimensione totale del database. Ciò significa che, per una singola voce, solo la prova doppio di lunghezza quando la dimensione del database è quadrato - il tipo di scalabilità per cui gli scienziati informatici uccidono. Ora ricorda che la radice dello stato di ogni blocco è nella sua intestazione, che può essere verificata da un client leggero. Di conseguenza, i client leggeri possono eseguire query in modo sicuro ed efficiente su qualsiasi nodo completo della rete per singole voci di database e i nodi pieni non possono mentire.

Ma se le nostre intestazioni blockchain includono una radice di stato e la radice di stato dipende dal contenuto del database, allora ogni nodo deve mantenere aggiornato il database della blockchain. A sua volta questo significa eseguire ogni contratto per ogni messaggio ricevuto fino ad ora. Senza questo, un nodo di mining non conoscerebbe la radice dello stato da inserire in un'intestazione di blocco, né gli altri nodi potrebbero verificare i blocchi che ricevono. La linea di fondo è: se vogliamo che i client leggeri recuperino in modo sicuro prove di dati compatte dalla rete, i nodi completi devono eseguire tutti i calcoli descritti dai dati nella catena.

Il verdetto per le blockchain private

Rivediamo questi due argomenti nel contesto delle blockchain private. La prima cosa da notare sulle catene private è che tendono a non avere un token nativo o una criptovaluta. Questo è per molte ragioni:

  • Il tipo di entità interessate alle catene private non vuole avere a che fare con una nuova classe di attività.
  • Il modello di consenso per le catene private si basa sull'accordo tra un insieme di minatori chiusi, piuttosto che sulla prova del lavoro. Quindi il costo del mining è minimo ei minatori non hanno bisogno di molte ricompense.
  • Poiché tutti i partecipanti a una catena privata sono controllati, c'è meno preoccupazione per spam e abusi.

Ricorda che il primo argomento per l'esecuzione globale era consentire a ciascun nodo Ethereum di decidere se ritrasmettere una transazione in entrata, in base alla commissione che offre. Ebbene, la mancanza di un token nativo rende questo motivo irrilevante perché, se una blockchain non ha token nativo, le transazioni non possono pagare commissioni. Se per qualche motivo lo spam rimane un problema, deve essere controllato in un altro modo, ad esempio revocando le autorizzazioni del mittente.

Consideriamo ora il secondo argomento, per abilitare prove di dati compatte. È probabile che una blockchain pubblica abbia utenti finali su dispositivi mobili o altri portafogli leggeri. Ma questo è meno probabile con le catene private, la cui funzione primaria è condivisione di un database tra aziende più grandi. E se la blockchain is a cui si accede da un dispositivo mobile, è probabile che l'utente mobile sia un cliente di una di queste società e possa fidarsi di ciò che la società gli dice.

Invece, nelle blockchain private, il file problemi dell'esecuzione globale sono particolarmente acute. Se una blockchain privata non ha token nativi, non abbiamo un meccanismo di mercato simile al gas per prevenire il codice in fuga. Invece dovremmo introdurre una sorta di limite fisso in termini di passaggi computazionali per transazione. Ma per consentire alle transazioni di eseguire intenzionalmente molte elaborazioni, questo limite dovrebbe essere elevato. Di conseguenza, la rete potrebbe comunque finire per sprecare molta energia in loop non intenzionali prima di spegnerli definitivamente.

Per quanto riguarda la concorrenza, è molto più probabile che i blockchain privati ​​vedano il tipo di volumi di transazioni che rendono essenziale la concorrenza. La capacità delle blockchain pubbliche è limitata dal fatto che, per essere decentralizzate in modo significativo, hanno bisogno di migliaia di nodi gestiti da appassionati con budget limitati. Al contrario, le catene private hanno molte più probabilità di connettere insieme solo poche dozzine di imprese, nel qual caso capacità e velocità sono essenziali.

Blockchain a due piani

Quindi, se tutto ciò che riguarda i contratti intelligenti ha senso nelle catene private, a parte l'esecuzione globale, dove ci lascia? Che tipo di blockchain ci darà le prestazioni e la flessibilità di cui abbiamo bisogno? Ad essere onesto, ci sto ancora pensando. Ma una risposta potrebbe essere: una blockchain con due livelli.

Il livello inferiore sarebbe costruito su transazioni in stile bitcoin che vengono elaborate istantaneamente e contemporaneamente e non è necessario attendere le conferme dei blocchi. Queste transazioni potrebbero eseguire semplici movimenti di beni, anche sicuri scambi atomici, senza ricorrere a contratti intelligenti. Ma questo livello inferiore verrebbe utilizzato anche come file strato di archiviazione cieco per i programmi e i messaggi che rappresentano processi aziendali più complessi, incorporati come metadati delle transazioni.

Per quanto riguarda il livello superiore, ogni partecipante alla rete sceglierebbe quali programmi vogliono eseguire. Alcuni potrebbero scegliere di non eseguirne affatto, perché sono interessati solo a semplici movimenti di asset. Altri potrebbero eseguire un piccolo gruppo di programmi rilevanti per i loro processi interni (con la consapevolezza che questo gruppo non scambia messaggi con programmi esterni). Alcuni potrebbero persino optare per l'esecuzione globale, elaborando ogni messaggio per ogni programma, proprio come Ethereum. Ma la cosa fondamentale sarebbe quella ogni nodo esegue solo il codice necessario. In informatica questa tecnica è chiamata valutazione pigra, perché implica fare il minor lavoro possibile, senza tralasciare nulla di cruciale. Con una valutazione pigra, se un calcolo blockchain va storto, solo quei nodi che eseguono effettivamente quel programma lo noteranno. La rete stessa non sentirà nulla.

Per quanto riguarda MultiChain, se finiamo per supportare il calcolo completo di Turing, dubito che implementeremo l'esecuzione globale. Forse sceglieremo questo tipo di approccio pigro a due livelli, o forse penseremo a qualcosa di meglio.

Contratti intelligenti nelle blockchain pubbliche

Come ho affermato in precedenza, in la percezione Turing blockchain complete come Ethereum, lì sono buone ragioni per l'esecuzione globale. Ma ecco un'altra domanda: qual è il file impresa caso d'uso per queste catene? Immaginiamo un tempo futuro in cui le imprese avranno una fiducia sufficiente nei blockchain pubblici da utilizzarli per processi aziendali reali. Se un gruppo di società desidera incorporare una logica di calcolo in una blockchain pubblica, ha due scelte: (1) utilizzare una blockchain in stile Ethereum con esecuzione globale o (2) utilizzare in qualsiasi blockchain come un semplice livello di archiviazione e l'esecuzione del codice stesso. E date queste opzioni, perché dovrebbero scegliere (1)?

La scelta razionale sarebbe la blockchain pubblica con (a) il prezzo più basso per byte di archiviazione e / o (b) il più alto livello di sicurezza basato sulla potenza di mining totale. Poiché il calcolo è deterministico, le aziende devono pagare solo la rete Tornare al suo account il loro contratto e messaggi, non in realtà processi loro. Inoltre, utilizzando una blockchain solo per l'archiviazione, possono utilizzare qualsiasi linguaggio di programmazione che desiderano. Questo potrebbe essere il bytecode di Ethereum, JavaScript / ECMAScript per leggibilità o addirittura codice macchina per alte prestazioni. In effetti, Ethereum si contrae può già essere memorizzato utilizzando i metadati sulla blockchain bitcoin. Questo è esattamente l'approccio a due livelli che ho suggerito.

Questa discussione è correlata alla nozione di strati di astrazione, reso famoso dal Modello di rete OSI. Per un'affidabilità e una flessibilità ottimali, ogni strato di un sistema dovrebbe essere il più possibile astratto (cioè indipendente) dagli altri strati. Ad esempio, non vorremmo che i nostri controller del disco rigido contenessero codice per il rendering di immagini JPEG. Allora perché dovremmo volere che una blockchain esegua i programmi che memorizza? Per la maggior parte dei casi d'uso, non ne traiamo alcun vantaggio e ha un costo significativo.

Epilogo

Se l'esecuzione globale non ha senso nei blockchain privati, perché tutti lavorano su questa roba? Penso che questo possa essere spiegato, almeno in parte, da un malinteso su ciò che possono fare le blockchain nel mondo reale. Vedi, le blockchain pubbliche come bitcoin possono farlo spostare direttamente un asset reale (vale a dire, la loro valuta nativa), perché la blockchain definisce la proprietà di quella valuta. Questo fonde due aspetti dei beni che di solito sono distinti: (a) un registro che registra chi possiede il bene e (b) la sua posizione fisica effettiva. Questo rende le criptovalute il massimo strumento al portatore, creando un nuovo mondo coraggioso o un paradiso per i riciclatori di denaro, a seconda di chi chiedi.

Ma per altre risorse che esistono indipendentemente da una blockchain, l'unica cosa che una catena può fare è tenere un file record di chi loro dovrebbero appartiene a. Questo rimarrà il caso fino a quando non vedremo il file emissione primaria di asset su una blockchain, con la proprietà legale di quell'asset definita in termini di database della catena. Per il settore della finanza istituzionale, credo che questa giornata sia ancora lontana, anche a causa dei cambiamenti normativi richiesti. Fino ad allora, ci sarà sempre un passaggio in più, contrattuali e procedurali, tra ciò che dice la blockchain e ciò che accade nel mondo reale. Questo passaggio potrebbe anche includere del codice completo di Turing, eseguito pigramente all'ultimo momento possibile.

Questo problema è evidenziato dal caso degli “smart bond” di cui abbiamo tanto sentito parlare. Un'obbligazione intelligente viene emessa direttamente su una blockchain, con la blockchain che garantisce che i pagamenti delle cedole siano effettuati ai detentori di obbligazioni nei momenti appropriati. Va tutto bene. Ma cosa succede se l'emittente dell'obbligazione non ha fondi sufficienti nel proprio account blockchain per coprire un pagamento dovuto? La blockchain può certamente impostare una bandiera per dire che qualcosa non va, ma non può fare nient'altro. Abbiamo ancora bisogno di un esercito di avvocati e contabili per sistemare l'intero pasticcio, che si tratti di un taglio di capelli, ristrutturazione del debito, confisca o bancarotta totale. In breve:

Se i contratti intelligenti non riescono a mantenere la loro promessa, perché ne stiamo pagando il prezzo?

Grazie per aver letto.

Timestamp:

Di più da più giri