Le blockchain private sono più che "solo" database condivisi

Perché i detrattori della blockchain mancano il punto

E così continua. A partire dal Post popolari a tweet sprezzanti a previsioni sul futuro, il mondo e sua madre si stanno mettendo in fila per lanciare pomodori a blockchain privati, prima anche capendo cosa sono.

Dire che una blockchain privata è solo un database condiviso è come dire che HTML e HTTP sono “solo” ipertesti distribuiti. È sbagliato in due modi. Innanzitutto, quello semantico: le blockchain private sono una tecnologia che Abilita database condivisi, come penne abilitano la scrittura e HTML / HTTP abilitano l'ipertesto distribuito. La blockchain bitcoin e la sua applicazione primaria non possono essere separate in modo significativo, perché l'una non potrebbe esistere senza l'altra. Ma questa equivalenza non si applica affatto alle blockchain private.

Il secondo errore è l'uso della parola "giusto". Appena? Erano HTML e HTTP ad appena un modo per fare ipertesto distribuito? L'ipertesto era inventato decenni prima, quindi queste tecnologie sono una nota in calce nella storia del computer? Oh, ma lasciami contare i modi in cui hanno guadagnato il loro posto: (a) un semplice linguaggio con marcatori che qualsiasi laico potesse imparare, (b) a schema di indirizzamento gerarchico che funziona sia con TCP / IP che con il nostro modello concettuale di luogo, (c) a protocollo semplice per il recupero dei contenuti da parte dello stato e (d) entrambi cliente ed server software che ha dato vita a tutto. Potremmo anche dire che Newton era solo uno scienziato e Dostoevskij solo uno scrittore.

Quindi chiariamolo perfettamente: sì, le blockchain private sono solo un modo per condividere un database. Ma consentono un nuovo tipo di database condiviso, con enormi implicazioni per il mondo finanziario e non solo. E se sei disposto a leggere, ti dirò esattamente perché.

Cos'è un database?

Un database è un repository di informazioni strutturate, organizzato in tabelle. Puoi pensarlo come una raccolta di uno o più fogli di calcolo Excel, che possono essere facoltativamente collegati tra loro. Ogni tabella contiene informazioni su un insieme di entità di un tipo particolare, con un'entità per riga. Ogni tabella ha anche una o più colonne, che descrivono aspetti diversi di tali entità. Ad esempio, la tabella della directory del personale interno di WidgetCo potrebbe contenere colonne per ID dipendente, nome, cognome, dipartimento, numero di telefono interno e numero di camera.

Uno dei modi importanti in cui i database vanno oltre i fogli di calcolo è che contengono regole sui dati archiviati all'interno. Queste regole aiutano a garantire che le informazioni rimangano sane e coerenti a beneficio dell'intera organizzazione. In oggi database più popolari, le regole assumono una serie di forme comuni:

• Il schema del database definisce quale tipo di informazione è consentita in ciascuna colonna. Ad esempio, il numero di telefono deve contenere 4 cifre e non può essere lasciato in bianco ("null").
• Chiavi uniche in cui si afferma che una determinata colonna (ad es. ID impiegato) deve avere un valore diverso in ogni riga.
• Controlla i vincoli che impongono relazioni tra i valori di colonna in ogni riga. Ad esempio, se il dipartimento è "Approvvigionamento", il numero della stanza deve iniziare con un 3 o 4.
• Chiavi esterne che impongono relazioni tra le tabelle. Ad esempio, se il database contiene un'altra tabella utilizzata per le buste paga, potrebbe esserci una regola secondo cui ogni ID impiegato nella tabella delle buste paga deve essere presente anche nella directory staff.

Una transazione è una raccolta di modifiche a un database accettata o rifiutata nel suo insieme. Ogni volta che una transazione modifica il database, il software garantisce il rispetto delle regole del database. Se una parte di una transazione viola una di queste regole, l'intera transazione verrà rifiutata con un errore corrispondente.

Ci sono altri tipi di regole più esoteriche che potrei elencare, ma hanno tutte una cosa in comune. Rispondono alla domanda: Il database è in uno stato valido? In altre parole, agiscono come un vincolo sul contenuto del database se visto in un singolo punto nel tempo. E questo funziona bene per un database che si trova all'interno di una singola organizzazione, perché il compito principale dei vincoli è prevenire l'errore del programmatore. Se una delle applicazioni interne di WidgetCo provasse a inserire un numero di telefono a 3 cifre nella directory, ciò non sarebbe dovuto a malizia, ma piuttosto a un bug nel pensiero o nel codice dello sviluppatore. La capacità di un database di rilevare questi errori è senza dubbio utile e aiuta a prevenire la propagazione di informazioni errate all'interno di un'organizzazione, ma non risolve i problemi di fiducia. (I vincoli possono anche aiutare a semplificare la logica dell'applicazione, ad esempio tramite cascata di chiavi esterne or clausole duplicate, ma questi sono ancora solo modi per aiutare gli sviluppatori.)

Condivisione del database

Ora pensiamo a come la directory del personale interno di WidgetCo potrebbe essere condivisa con il mondo esterno. In molti casi, non vi è alcun problema nel fornire lettura condivisa accesso. La directory può essere esportata in un file di testo e inviata per e-mail a clienti e fornitori. Può essere pubblicato su Internet, proprio come questo. Può anche essere fornita un'API per consentire la ricerca tramite codice esterno. La lettura condivisa è un gioco da ragazzi tecnico, una questione di decidere chi può vedere cosa.

Ma le cose iniziano a diventare più appiccicose quando pensiamo scrittura condivisa. Cosa succede se WidgetCo vuole un'entità esterna modificare il suo database? Forse i telefoni vengono sostituiti da PhoneCo, che aggiornerà quindi i numeri di telefono nell'elenco personale. In questo caso, WidgetCo creerebbe un nuovo "account" da utilizzare per PhoneCo. A differenza degli account per uso interno di WidgetCo, l'account di PhoneCo è autorizzato a modificare la colonna del numero di telefono e non aggiungere o eliminare mai le righe. Tutte le transazioni di PhoneCo vengono elaborate dal sistema di database WidgetCo, che ora applica due tipi di restrizioni:

• Regole globali che si applicano a tutti gli utenti del database. Ad esempio, la compagnia telefonica non può cambiare un numero per contenere solo 3 cifre, e nessun altro può farlo.
• Regole per account che limitano ciò che PhoneCo è autorizzato a fare, in questo caso modificando solo la colonna del numero di telefono delle righe esistenti.

Fin qui tutto bene. Abbiamo un database di scrittura condiviso. Funziona perché WidgetCo è responsabile del database e la compagnia telefonica ottiene l'accesso in virtù della buona grazia di WidgetCo. Se PhoneCo ha iniziato a impostare i numeri di telefono in modo casuale, WidgetCo può chiudere il loro accesso, risolvere il contratto e ripristinare alcuni vecchi dati da un backup. E se WidgetCo ha iniziato a comportarsi male, diciamo invertendo i nuovi numeri di telefono inseriti da PhoneCo, sarebbe del tutto inutile, dal momento che danneggerebbe solo WidgetCo. La compagnia telefonica considererebbe WidgetCo un cliente peculiare ma non particolarmente interessato, purché pagasse la fattura in tempo.

Ma ora vediamo cosa succede se due o più parti vogliono condividere un database che (a) nessuna delle parti controlla, (b) può essere scritto da qualsiasi parte e (c) può essere invocato da tutti. A peggiorare le cose, diciamo che queste parti hanno diversi incentivi, non si fidano l'una dell'altra e possono persino essere concorrenti feroci. In questo caso, la soluzione è sempre stata la stessa: introdurre un intermediario di fiducia. Questo intermediario gestisce centralmente un database, fornisce account a tutte le parti e garantisce che tutte le operazioni siano consentite in base a un insieme di regole noto. In molti casi, soprattutto finanziari, ogni parte conserva ancora la propria copia dei dati, quindi tutti impiegano molto tempo a verificare che i loro database sono d'accordo.

Tutto diventa piuttosto disordinato e ingombrante. Ma se stiamo parlando di a database di scrittura condiviso in un ambiente di fiducia limitata, attualmente non esiste alternativa. Questo è uno dei motivi principali per cui le transazioni finanziarie passano case di compensazione centrale, perché usi Google Calendar anche in un piccolo gruppo di lavoro, e perché la meraviglia che proviene dalla folla è wikipedia spende milioni di dollari sull'hosting. Anche come interfaccia utente del web passa al lato client, i server centralizzati continuano a memorizzare i dati su cui si basano tali interfacce.

Scrittura condivisa reale

Diciamo quindi che volevamo consentire la condivisione di un database, in un senso di scrittura, senza un'autorità centrale. Ad esempio, diverse aziende concorrenti vogliono mantenere un elenco di personale congiunto a vantaggio dei loro reciproci clienti. Come potrebbe essere? Bene, avrebbe bisogno di un numero di cose:

• Una solida rete peer-to-peer che consente alle transazioni di essere create da qualsiasi parte e propagate rapidamente a tutti i nodi connessi.
• Un modo per identificare i conflitti tra le transazioni e risolverli automaticamente.
• Una tecnologia di sincronizzazione che garantisce la convergenza di tutti i peer su una copia identica del database.
• Un metodo per contrassegnare diverse informazioni come appartenenti a diversi partecipanti e applicare questa forma di proprietà dei dati senza un'autorità centrale.
• Un paradigma per esprimere restrizioni su quali operazioni sono consentite, ad esempio per impedire a una società di gonfiare la directory con voci fittizie.

Accidenti. Questo è un elenco difficile proprio lì, e semplicemente non è supportato dai database standard di oggi. attuale tecnologia di replica peer-to-peer è goffo e ha un approccio complesso alla risoluzione dei conflitti. Quei database che supportano sicurezza basata su righe richiede ancora un'autorità centrale per farla rispettare. E le restrizioni standard a livello di database come chiavi univoche e vincoli di controllo non possono proteggere un database da modifiche dannose. La linea di fondo è questa:

Abbiamo bisogno di un sacco di nuove cose per far funzionare i database di scrittura condivisi, ed è proprio così che le blockchain forniscono loro.

Non entrerò in troppi dettagli in merito come le blockchain fanno queste cose, perché io ne ho coperto gran parte prima. Alcuni elementi chiave includono regolari peer-to-peer tecniche, raggruppamento transazioni in blocchi, senso unico funzioni hash crittografiche, una festa multipla algoritmo di consenso, distribuito controllo della concorrenza multiversione e autorizzazioni per riga basate su crittografia a chiave pubblica. Una lunga lista di vecchie idee combinate in un modo nuovo. HTML / HTTP, se lo desideri.

Oltre a tutti questi, i database di scrittura condivisi richiedono un tipo completamente nuovo di regola limitare le trasformazioni che una transazione può eseguire. Questa è un'innovazione assolutamente fondamentale e fa la differenza se condividiamo un database tra entità non attendibili. Questi tipi di regole possono essere espressi come vincoli di transazione in stile bitcoin o forzati in stile Ethereum procedura di archiviazione ("Contratti intelligenti"), ciascuno dei quali ha vantaggi e svantaggi. Forse ci sono altri modi migliori in attesa di essere scoperti. Ma condividono tutti la proprietà di legare insieme lo stato del database prima e dopo una transazione. In altre parole, rispondono alla domanda: È stata una transazione valida? Ciò è fondamentalmente diverso dal chiedere se il database è valido in un singolo momento.

Se ti stai chiedendo se questo tipo di database ha utili applicazioni nel mondo reale, questa è una domanda giusta. Ma potresti notare l'intenso interesse per le blockchain private di almeno un settore, a causa del loro potenziale per semplificare i processi e ridurre costi e ritardi. Le istituzioni finanziarie sono utenti pesanti delle piattaforme di database odierne e tali piattaforme non consentono uno scenario di scrittura condiviso. Questo è ciò che le banche stanno cercando.

Questo problema e la sua soluzione non hanno assolutamente nulla a che fare con il bitcoin e l'idea di denaro senza censura. In effetti, l'unica connessione a bitcoin è il tecnico somiglianza tra la blockchain bitcoin e come sono alcune di queste blockchain private implementato oggi. Una differenza fondamentale è che le blockchain private non sono necessarie prova di lavoro mining, poiché i blocchi vengono creati da un insieme chiuso di partecipanti identificati. Nel tempo i due mondi potrebbero divergere ulteriormente, poiché le loro esigenze sono completamente diverse. Che ti piaccia o meno la regolamentazione finanziaria, il semplice fatto è che le blockchain private sono potenzialmente utili in un mondo regolamentato, mentre almeno per ora, blockchain pubblici non lo sono.

Se potessi finire con un'analogia, l'ONU Dichiarazione sui principi di diritto internazionale non dice ai paesi che possono detenere il territorio che desiderano, purché sia ​​circondato da una recinzione chiaramente contrassegnata. Piuttosto, afferma che "Nessuna acquisizione territoriale derivante dalla minaccia o dall'uso della forza deve essere riconosciuta come legale". In altre parole, è una regola relativa alla legittimità di i cambiamenti, non solo di situazioni. E la dichiarazione delle Nazioni Unite, che ora ci sembra così ovvia, è stata una rivoluzione completa nel diritto internazionale. Significava un mondo non più basato sul potere e sull'autorità unilaterali, ma in cui le differenze possono essere risolte per consenso reciproco.

Quando si tratta di database condivisi, le blockchain private fanno esattamente la stessa cosa.