Sì, potresti aver bisogno di una blockchain

Balaji S. Srinivasan è l'ex CTO di Coinbase, un Board Partner di Andreessen Horowitz e un membro del comitato consultivo di CoinDesk.

Il seguente articolo è stato originariamente pubblicato su Consensus Magazine e distribuito esclusivamente ai partecipanti all'evento Consensus 2019 di CoinDesk.

C'è un certo tipo di sviluppatore che afferma che le blockchain sono soloterribile database. Come dice la narrazione, perché non usare semplicemente PostgreSQL per la tua applicazione? È maturo, robusto e ad alte prestazioni. Rispetto ai database relazionali, lo scettico sostiene che le blockchain sono solo database lenti, goffi e costosi che T sono scalabili.

Mentre alcune critiche a questa critica sono già là fuori (1,2), proporrei una semplice confutazione ONE frase: le blockchain pubbliche sono utili per archiviare lo stato condiviso, in particolare quando tale stato condiviso rappresenta dati preziosi che gli utenti desiderano esportare/importare senza errori, come il loro denaro.

Il problema dell'esportazione/importazione dei dati

Dai un'occhiata ai diagrammi delle nuvole perServizi Web Amazon,Microsoft Azure, O Google CloudSono presenti icone per bilanciatori di carico, transcodificatori, code e funzioni lambda.

Ci sono icone per VPC e ogni tipo di database sotto il TUE, incluso il nuovo blockchain gestitaservizi (che sono distinti dalle blockchain pubbliche, sebbene potenzialmente utili in alcune circostanze).

Ciò per cui T c'è ICON è lo stato condiviso tra gli account. Vale a dire, tutti questi diagrammi cloud presuppongono implicitamente che una singola entità e i suoi dipendenti (vale a dire, l'entità con accesso al account radice cloud) è l' ONE a disporre il diagramma dell'architettura e a leggere o scrivere sull'applicazione su cui si basa. Più precisamente, questi diagrammi presuppongono in genere la presenza di un singolo attore economico, vale a dire l'entità che paga le fatture del cloud.*

Ma se visualizziamo i diagrammi cloud non solo per ONE , ma ONE cento attori economici aziendali alla volta, sorgono alcune domande immediate. Questi attori possono interagire? I loro utenti possono estrarre i loro dati e inserirli in altre applicazioni? E dato che gli utenti sono essi stessi attori economici, se questi dati rappresentano qualcosa di valore monetario, possono gli utenti essere sicuri che i loro dati T siano stati modificati durante tutta questa esportazione e importazione?

Questi sono i tipi di domande che sorgono quando pensiamo all'esportazione e all'importazione dei dati dall'applicazione di ogni entità come a un requisito di prima classe. E (con eccezioni che approfondiremo), in generale, la risposta a queste domande oggi è in genere no.

No, in genere le diverse applicazioni T dispongono di software interoperabile, né consentono agli utenti di esportare/importare facilmente i propri dati in un formato standard, né forniscono agli utenti la certezza che i loro dati T siano stati intenzionalmente manomessi o inavvertitamente danneggiati durante tutte le operazioni di esportazione e importazione.

Il motivo si riduce agli incentivi. Per la maggior parte dei principali servizi Internet, non esiste semplicemente alcun incentivo finanziario per consentire agli utenti di esportare i propri dati, per non parlare di consentire ai concorrenti di importare rapidamente tali dati. Mentre alcuni lo chiamano ilportabilità dei datiproblema, chiamiamolo problema di esportazione/importazione dati per focalizzare l'attenzione sui meccanismi specifici di esportazione e importazione.

Approcci attuali al problema dell'esportazione/importazione dei dati

Anche se T sono ancora presenti incentivi finanziari per una soluzione generale al problema dell'esportazione/importazione dei dati, sono stati creati meccanismi per molti casi speciali importanti. Questi meccanismi includono API, esportazioni JSON/PDF/CSV, file MBOX e (in un contesto bancario) SFTP.

Esaminiamoli uno per uno per comprendere la situazione attuale.

• API. ONE dei modi più popolari per esportare/importare dati è tramite le Application Programming Interface, meglio note come API. Alcune aziende ti permettono di ottenere alcuni dei tuoi dati o ti danno la possibilità di scrivere dati sul tuo account. Ma c'è un costo. Innanzitutto, il loro formato dati interno è in genere proprietario e non uno standard del settore. In secondo luogo, a volte le API non sono centrali per il loro CORE business e possono essere spentoIn terzo luogo, a volte le API sono centrali per il loro CORE business e il prezzo può essere drammaticamente sollevato. In generale, se stai leggendo o scrivendo su un'API ospitata, sei alla mercé del provider dell'API. Chiamiamo questo rischio di piattaforma, ed essere de-piattaformati senza tante cerimonie hadanneggiato molti UN avvio.
• Formato JSON.Un'altra soluzione correlata è quella di consentire agli utenti o agli script di scaricare file JSON, o di leggerli/scriverli sulle API sopra menzionate. Questo va bene per quanto riguarda questo, ma JSON è un formato molto libero e può descrivere praticamente qualsiasi cosa. Ad esempio, FacebookAPI graficoe LinkedInAPI RESTgestiscono cose simili ma restituiscono risultati JSON molto diversi.
• Italiano:Un'altra soluzione molto parziale è quella di consentire agli utenti di esportare un PDF. Questo funziona per i documenti, poiché il PDF è unstandard aperto che può essere letto da altre applicazioni come Anteprima, Adobe Acrobat, Google Drive, Dropbox e così via. Ma un PDF è pensato per essere un prodotto finale, per essere letto da un Human. Non è pensato per essere un input per nessuna applicazione oltre a un visualizzatore di PDF.
• Formato CSV.L'umile file con valori separati da virgole si avvicina di più a ciò che vogliamo per una soluzione generale al problema di importazione/esportazione dei dati. A differenza del backend di un'API proprietaria, CSV è unformato standarddescritto daLa RFC 4180. A differenza di JSON, che può rappresentare quasi tutto, un CSV in genere rappresenta solo una tabella. E a differenza di un PDF, un CSV può essere in genere modificato localmente da un utente tramite un foglio di calcolo o utilizzato come input leggibile dalla macchina per un'applicazione locale o cloud. Poiché la maggior parte dei tipi di dati può essere rappresentata in un database relazionale e poiché i database relazionali possono solitamente essereesportato come un set di CSV potenzialmente giganteschi, è anche piuttosto generico. Tuttavia, i CSV sono svantaggiati in alcuni modi. Innanzitutto, a differenza di un'API proprietaria, T sono ospitati. Vale a dire, non esiste un singolo posto canonico in cui leggere o scrivere un CSV che rappresenti (ad esempio) un record di transazioni o una tabella di metadati di mappa. In secondo luogo, i CSV T sono a prova di manomissione. Se un utente esporta un record di transazioni dal servizio A, lo modifica e lo ricarica nel servizio B, il secondo servizio non ne sarebbe più a conoscenza. In terzo luogo, i CSV T hanno controlli di integrità integrati per proteggere da errori involontari. Ad esempio, le colonne di un CSV T hanno informazioni di tipo esplicite, il che significa che una colonna contenente i mesi dell'anno da 1 a 12 potrebbe avere il suo tipo convertito automaticamente durante l'importazione in un semplice intero, causando confusione.
• MBOX.Sebbene meno noto del CSV,Formato MBOXper rappresentare raccolte di messaggi di posta elettronica è la cosa più vicina a una struttura dati standardizzata creata per l'importazione e l'esportazione tra le principali piattaforme e applicazioni indipendenti. In effetti, ci sono statidocumenti proponendo l'uso di MBOX in contesti esterni alla posta elettronica. Mentre CSV rappresenta dati tabulari, MBOX rappresenta un tipo di dati strutturati in log. È essenzialmente un singolo file di testo semplice di messaggi di posta elettronica in ordine cronologico, ma può anche rappresentare immagini/file allegati tramite MIME. Come CSV, i file MBOX sono un standard apertoe può essere esportato, modificato localmente e reimportato. E come CSV, MBOX ha gli svantaggi di non avere un host canonico o un controllo di integrità dei dati intrinseco.
• Accesso tramite FTP. Prima di proseguire, c'è ONE altro meccanismo di esportazione/importazione dati che merita di essere menzionato: il protocollo di trasferimento file sicuro, o SFTP. Sebbene venerabile, questo è in realtà il modo in cui gli individui inviano pagamenti ACH avanti e FORTH l'uno all'altro. In sostanza, gli istituti finanziari utilizzano server SFTP per acquisire dati di transazioni elettroniche in file formattati in modo specialee trasmetterlo alla Federal Reserve ogni giorno per sincronizzare gli addebiti e gli accrediti ACH tra loro (vedereQui,Qui,Qui, E Qui).

Ognuno di questi meccanismi è ampiamente utilizzato. Ma non sono sufficienti per abilitare il caso generale di importazione ed esportazione a prova di manomissione di dati preziosi tra attori economici arbitrari, siano essi entità aziendali, singoli utenti o script headless. Per questo, abbiamo bisogno di blockchain pubbliche.

Le blockchain pubbliche abilitano lo stato condiviso incentivando l'interoperabilità. Le blockchain pubbliche convertono molti tipi di problemi di importazione/esportazione di dati in una classe generale di problemi di stato condiviso. E lo fanno in parte incorporando molte delle migliori caratteristiche dei meccanismi descritti sopra.

• Le blockchain pubbliche forniscono metodi canonici per l'accesso in lettura/scrittura come un'API aziendale ospitata, ma senza lo stesso rischio di piattaforma. Nessun singolo attore economico può chiudere o negare il servizio ai clienti di una blockchain pubblica decentralizzata come Bitcoin o Ethereum.
• Consentono inoltre ai singoli utenti di esportare dati critici sul proprio computer locale o su una nuova applicazione come JSON/CSV/ MBOX (inviando fondi o esportando chiavi private), fornendo al contempo garanzie crittografiche di integrità dei dati.
• Forniscono un mezzo per attori economici arbitrari (siano essi aziende, singoli utenti o programmi) per interagire senza problemi. Ogni attore economico che legge da una blockchain pubblica vede lo stesso risultato e qualsiasi attore economico con fondi sufficienti può scrivere su una blockchain pubblica nello stesso modo. Non è necessaria alcuna configurazione di account e nessun attore può essere bloccato dall'accesso in lettura/scrittura.
• E forse la cosa più importante è che le blockchain pubbliche offrono incentivi finanziari per l'interoperabilità e l'integrità dei dati.

Quest'ultimo punto merita di essere elaborato. Una blockchain pubblica come Bitcoin o Ethereum in genere registra il trasferimento di cose di valore monetario. Questa cosa potrebbe essere la Criptovaluta intrinseca della catena, un token emesso in cima alla catena o un altro tipo di asset digitale.

Poiché i dati associati a una blockchain pubblica rappresentano qualcosa di valore monetario, alla fine forniscono l'incentivo finanziario per l'interoperabilità. Dopo tutto, qualsiasi app web o mobile che voglia ricevere (ad esempio) BTC deve rispettare le convenzioni della blockchain Bitcoin . In effetti, gli sviluppatori dell'applicazione non avrebbero scelta, dato che Bitcoin , per progettazione, ha una singola catena proof-of-work canonica più lunga con convalida crittografica di ogni blocco in quella catena.

Ecco, questo è l’incentivo finanziario per l’importazione.

Per quanto riguarda l'incentivo all'esportazione, quando si tratta di denaro in particolare, gli utenti richiedono la possibilità di esportare con assoluta fedeltà e molto rapidamente. Non sono le loro vecchie foto di gatti, di cui potrebbero essere contenti di perdere traccia a causa di inconvenienti o problemi tecnici. Sono i loro soldi, i loro Bitcoin, la loro Criptovaluta. Qualsiasi applicazione che li detiene deve renderli disponibili per l'esportazione quando vogliono ritirarli, che ciò significhi supportare la funzionalità di invio, offrire backup di chiavi private o entrambe le cose. In caso contrario, è improbabile che l'applicazione riceva mai depositi in primo luogo.

Quindi, questo è l'incentivo finanziario per l'esportazione. Quindi, una blockchain pubblica incentiva economicamente ogni attore economico che interagisce con essa a utilizzare lo stesso formato di importazione/esportazione di ogni altro attore, che sia una società, un utente o un programma. In altre parole, le blockchain pubbliche sono il passo successivo all'open source, in quanto forniscono dati aperti. Chiunque può codificare il proprio block explorer leggendo da una blockchain pubblica e chiunque può creare il proprio portafoglio in grado di scrivere su una blockchain pubblica.

Questa è una vera svolta. Ora abbiamo un modo affidabile per incentivare l'uso dello stato condiviso, per consentire simultaneamente a milioni di individui e aziende di accedere alla lettura (e a migliaia di scrivere) dello stesso archivio dati, applicando uno standard comune e mantenendo un'elevata fiducia nell'integrità dei dati.

Questo è molto diverso dallo status quo. Di solito T condividi la password di root per il tuo database su Internet, perché un database che consente a chiunque di leggere/scrivere su di esso di solito viene corrotto. Le blockchain pubbliche risolvono questo problema con la crittografia anziché con i permessi, aumentando notevolmente il numero di utenti simultanei.

È vero che oggi le blockchain pubbliche sono in genere focalizzate su applicazioni monetarie e finanziarie, in cui il set di dati sottostante rappresenta una cronologia delle transazioni append-only con record immutabili. Ciò limita la loro generalità, in termini di gestione di tutte le diverse versioni del problema di importazione/esportazione dei dati. Ma c'è uno sviluppo in corso sulle versioni blockchain pubbliche di cose come OpenStreetMaps, Wikipedia e Twitter, nonché sistemi come Filecoin/IPFS. Questi T rappresenterebbero solo record di transazioni finanziarie in cui l'immutabilità era un requisito, ma potrebbero rappresentare altri tipi di dati (come voci di mappe o enciclopedie) che verrebbero regolarmente aggiornati.

Se fatti bene, questi nuovi tipi di sistemi basati su blockchain pubbliche potrebbero consentire a qualsiasi attore economico con fondi sufficienti e/o credenziali crittografiche non solo di leggere e scrivere, ma anche di modificare i propri record, preservando l'integrità dei dati. Data questa capacità, non c'è motivo per cui T ONE possa mettere un livello SQL in cima a una blockchain pubblica per lavorare con lo stato condiviso che offre, proprio come un vecchio database relazionale. Ciò si traduce in un nuovo tipo di database senza un proprietario privilegiato, in cui tutti i sette miliardi di esseri umani sul pianeta (e i loro script!) sono utenti autorizzati e su cui può scrivere qualsiasi entità con fondi sufficienti.

Quel giorno T è ancora arrivato. Resta da vedere quanto lontano possiamo spingere i casi d'uso per le catene pubbliche. E le sfide di scalabilità abbondano. Ma si spera che sia chiaro che, mentre le blockchain pubbliche sono effettivamente un nuovo tipo di database, offrono qualcosa di molto diverso da ciò che offre un database tradizionale.

* L' ONE eccezione è la cosiddetta funzionalità "Requester Pays" offerta da Amazon e altri servizi cloud. Questa è una funzionalità interessante che consente a qualcuno di pagare per scrivere sul tuo bucket S3. Ma è autorizzata: richiede comunque a ogni potenziale scrittore di aprire un account AWS e il proprietario del bucket deve essere disposto a consentire a tutti di scrivere sul proprio bucket, quindi c'è ancora un singolo proprietario distinto.

Immagine del database tramite Shutterstock