Evitare il inutile progetto blockchain

Come determinare se hai trovato un caso d'uso reale blockchain

Le blockchain sono sovrascritte. Ecco, l'ho detto. A partire dal SIBOS a moneyxnumx / 20 per coprire storie di The Economist ed Euromoney, tutti sembrano arrampicarsi a bordo del carro blockchain. E senza dubbio, come gli altri nello spazio, stiamo assistendo a un numero in rapido aumento di aziende che sviluppano prove concettuali la nostra piattaforma e / o chiedere il nostro aiuto.

Come giovane startup, penseresti che saremmo al settimo cielo. Sicuramente ora è il momento di raccogliere un sacco di soldi e costruire quella piattaforma blockchain di prossima generazione ad alte prestazioni che abbiamo già progettato. Cosa diamine stiamo aspettando?

Ti dirò cosa. Stiamo aspettando di ottenere una comprensione più chiara di dove blockchain sinceramente aggiungere valore nell'IT aziendale. Vedete, gran parte di questi progetti in arrivo ha niente a che fare con le blockchain. Ecco come si svolge. La grande azienda sente che le blockchain sono la prossima grande cosa. La grande azienda trova internamente alcune persone interessate all'argomento. La grande azienda dà loro un budget e dice loro di andare a fare qualcosa di blockchainy. Presto arrivano bussando alla nostra porta, agitando le banconote da un dollaro, chiedendo us per aiutare loro pensare a un caso d'uso. Dite cosa adesso?

Per quanto riguarda coloro che hanno in mente un progetto, qual è il problema? In molti casi, il progetto può essere realizzato perfettamente utilizzando un normale database relazionale. Sai, piacciono a grandi colossi di ferro Oracle ed SQL Server, o per i più aperti, MySQL ed Postgres. Vorrei iniziare impostando le cose:

Se i tuoi requisiti sono soddisfatti dai database relazionali di oggi, saresti pazzo a usare una blockchain.

Perché? Perché prodotti come Oracle e MySQL hanno decenni di sviluppo alle spalle. Sono stati distribuiti su milioni di server che eseguono trilioni di query. Contengono alcuni dei codici più accuratamente testati, sottoposti a debug e ottimizzati sul pianeta, elaborando migliaia di transazioni al secondo senza perdere tempo.

E le blockchain? Bene, nostro prodotto è stato uno dei primi sul mercato ed è stato disponibile per esattamente 5 mesi, con alcune migliaia di download. In realtà è estremamente stabile, perché l'abbiamo costruito Bitcoin Core, il software che alimenta bitcoin. Ma anche così, l'intera categoria di prodotti è ancora nei suoi pannolini.

Quindi sto dicendo che le blockchain sono inutili? Assolutamente no. Ma prima di intraprendere questo brillante progetto blockchain, devi avere un'idea molto chiara di perché stai usando una blockchain. Ci sono un sacco di condizioni che devono essere soddisfatte. E se non lo sono, dovresti tornare al tavolo da disegno. Forse puoi definire meglio il progetto. O forse puoi risparmiare a tutti un sacco di tempo e denaro, perché non hai bisogno di una blockchain.

1. Il database

Ecco la prima regola. Le blockchain sono una tecnologia per database condivisi. Quindi devi iniziare sapendo perché stai usando un database, con il quale intendo un repository strutturato di informazioni. Questo può essere un tradizionale database relazionale, che contiene una o più tabelle simili a fogli di calcolo. O può essere il più trendy NoSQL varietà, che funziona più come un file system o un dizionario. (A livello teorico, i database NoSQL sono comunque solo un sottoinsieme di database relazionali.)

Un libro mastro per le attività finanziarie può essere naturalmente espresso come una tabella di database in cui ogni riga rappresenta un tipo di attività di proprietà di una determinata entità. Ogni riga ha tre colonne contenenti: (a) l'identificatore del proprietario come un numero di conto, (b) un identificatore per il tipo di attività come “USD” o “AAPL” e (c) la quantità di tale attività detenuta da tale proprietario.

I database vengono modificati tramite "transazioni" che rappresentano un insieme di modifiche al database che devono essere accettate o respinte nel loro insieme. Ad esempio, nel caso di un libro mastro delle attività, un pagamento da un utente a un altro è rappresentato da una transazione che deduce la quantità appropriata da una riga e la aggiunge a un'altra.

2. Scrittori multipli

Questo è facile. Le blockchain sono una tecnologia per database con più autori. In altre parole, ci deve essere più di un'entità che sta generando le transazioni che modificano il database. Sai chi sono questi scrittori?

Nella maggior parte dei casi gli autori eseguiranno anche "nodi" che contengono una copia del database e inoltrano le transazioni ad altri nodi in un peer-to-peer moda. Tuttavia, le transazioni potrebbero anche essere create da utenti che non eseguono un nodo da soli. Si consideri ad esempio un sistema di pagamenti gestito collettivamente da un piccolo gruppo di banche ma che ha milioni di utenti finali su dispositivi mobili, che comunicano solo con i sistemi della propria banca.

3. Assenza di fiducia

E ora per la terza regola. Se più entità stanno scrivendo nel database, deve esserci anche un certo grado di sfiducia tra queste entità. In altre parole, le blockchain sono una tecnologia per database con più autori non attendibili.

Potresti pensare che la sfiducia sorge solo tra organizzazioni separate, come le banche che commerciano in un mercato o le società coinvolte in una catena di approvvigionamento. Ma può anche esistere all'interno di un'unica grande organizzazione, ad esempio tra dipartimenti o operazioni in diversi paesi.

Cosa intendo nello specifico per sfiducia? Voglio dire che un utente non è disposto a consentire a un altro di modificare le voci del database di cui "possiede". Allo stesso modo, quando si tratta di leggere il contenuto del database, un utente non accetterà come vangelo la “verità” riportata da un altro utente, perché ognuno ha incentivi economici o politici diversi.

4. Disintermediazione

Quindi il problema, come definito finora, è abilitare un database con più scrittori non attendibili. E c'è già una soluzione ben nota a questo problema: l'intermediario di fiducia. Cioè, qualcuno di cui tutti gli scrittori si fidano, anche se non si fidano completamente l'uno dell'altro. In effetti, il mondo è pieno di database di questa natura, come il libro mastro dei conti in una banca. La tua banca controlla il database e garantisce che ogni transazione sia valida e autorizzata dal cliente di cui sposta i fondi. Non importa quanto cortesemente chiedi, la tua banca non ti permetterà mai di modificare direttamente il loro database.

Le blockchain eliminano la necessità di intermediari affidabili abilitando database con più autori non attendibili da modificare direttamente. Non è richiesto alcun gatekeeper centrale per verificare le transazioni e autenticare la loro fonte. Invece, la definizione di una transazione viene estesa per includere una prova di autorizzazione e una prova di validità. Le transazioni possono quindi essere verificato ed elaborato in modo indipendente da ogni nodo che mantiene una copia del database.

Ma la domanda che devi porre è: Vuoi o hai bisogno di questa disintermediazione? Dato il tuo caso d'uso, c'è qualcosa di sbagliato nell'avere una parte centrale che gestisce un database autorevole e funge da gatekeeper delle transazioni? Buoni motivi per preferire un database basato su blockchain rispetto a un intermediario di fiducia potrebbero includere costi inferiori, transazioni più veloci, automatiche riconciliazione, una nuova regolamentazione o una semplice incapacità di trovare un intermediario adatto.

5. Interazione delle transazioni

Quindi le blockchain hanno senso per i database condivisi da più autori che non si fidano completamente l'uno dell'altro e che modificano direttamente quel database. Ma non è ancora abbastanza. Le blockchain brillano davvero dove ce ne sono alcune interazione tra le transazioni creato da questi scrittori.

Cosa intendo per interazione? Nel vero senso del termine, ciò significa che le transazioni create da scrittori diversi spesso dipendono l'una dall'altra. Ad esempio, supponiamo che Alice invii alcuni fondi a Bob e quindi Bob ne invii alcuni a Charlie. In questo caso, la transazione di Bob dipende da quella di Alice e non c'è modo di verificare la transazione di Bob senza prima verificare quella di Alice. A causa di questa dipendenza, le transazioni appartengono naturalmente a singolo database condiviso.

Oltre a ciò, una bella caratteristica delle blockchain è che è possibile creare transazioni collaborativamente da più autori, senza che entrambe le parti si espongano al rischio. Questo è ciò che consente consegna contro pagamento insediamento da eseguire in modo sicuro su una blockchain, senza richiedere un intermediario di fiducia.

Un buon caso può essere fatto anche per situazioni in cui le transazioni di diversi autori sono correlate tra loro, anche se rimangono indipendenti. Un esempio potrebbe essere un database di identità condiviso in cui più entità convalidano diversi aspetti delle identità dei consumatori. Sebbene ciascuna di tali certificazioni sia indipendente, la blockchain offre un modo utile per riunire tutto in modo unificato.

6. Impostare le regole

Questa non è davvero una condizione, ma piuttosto una conseguenza inevitabile dei punti precedenti. Se abbiamo un database modificato direttamente da più writer e quegli autori non si fidano completamente l'uno dell'altro, il database deve contenere regole incorporate limitando le transazioni eseguite.

Queste regole sono sostanzialmente diverse dalle vincoli che compaiono nei database tradizionali, poiché si riferiscono a legittimità delle trasformazioni piuttosto che lo stato del database in un determinato momento. Ogni transazione viene verificata rispetto a queste regole da ogni nodo della rete e quelle che falliscono vengono rifiutate e non trasmesse.

I registri delle attività contengono un semplice esempio di questo tipo di regola, per impedire che le transazioni creino attività dal nulla. La regola stabilisce che la quantità totale di ciascun bene nel libro mastro deve essere la stessa prima e dopo ogni transazione.

7. Scegli i tuoi validatori

Finora abbiamo descritto un database distribuito in cui le transazioni possono avere origine in molti luoghi, propagarsi tra i nodi in modo peer-to-peer e sono verificate da ogni nodo in modo indipendente. Quindi da dove arriva una "blockchain"? Bene, il lavoro di una blockchain è quello di essere il registro delle transazioni finale autorevole, sui cui contenuti tutti i nodi concordano chiaramente.

Perché abbiamo bisogno di questo registro? Innanzitutto, consente ai nodi appena aggiunti di calcolare i contenuti del database da zero, senza la necessità di fidarsi di un altro nodo. In secondo luogo, affronta la possibilità che alcuni nodi potrebbero perdere alcune transazioni, a causa di tempi di inattività del sistema o di problemi tecnici nelle comunicazioni. Senza un registro delle transazioni, ciò farebbe divergere il database di un nodo da quello degli altri, minando l'obiettivo di un database condiviso.

Terzo, è possibile che due transazioni siano in conflitto, in modo che solo una possa essere accettata. Un classico esempio è a doppia spesa in cui la stessa risorsa viene inviata a due destinatari diversi. In un database peer-to-peer senza autorità centrale, i nodi potrebbero avere opinioni diverse su quale transazione accettare, poiché è presente nessuna risposta giusta oggettiva. Richiedendo che le transazioni siano "confermate" in una blockchain, ci assicuriamo che tutti i nodi convergano sulla stessa decisione.

Finalmente, in Ethereumstile blockchain, il preciso ordinazione delle transazioni gioca un ruolo cruciale, perché ogni transazione può influenzare ciò che accade in ogni successivo. In questo caso la blockchain agisce per definire la cronologia autorevole, senza la quale le transazioni non possono essere elaborate affatto.

Una blockchain è letteralmente una catena di blocchi, in cui ogni blocco contiene un insieme di transazioni confermate come gruppo. Ma chi è responsabile della scelta delle transazioni che vanno in ciascun blocco? Nel tipo di "blockchain privato" adatto per applicazioni aziendali, la risposta è un gruppo chiuso di validatori ("minatori") che firmano digitalmente i blocchi che creano. Questa whitelisting è combinata con una qualche forma di schema di consenso distribuito per impedire a una minoranza di validatori di prendere il controllo della catena. Ad esempio, MultiChain utilizza uno schema chiamato diversità mineraria, in cui i minatori autorizzati lavorano in a round robin moda, con un certo grado di clemenza per consentire nodi non funzionanti.

Indipendentemente dallo schema di consenso utilizzato, i nodi di convalida hanno molto meno potere rispetto al proprietario di un database centralizzato tradizionale. I validatori non possono falsare transazioni o modificare il database in violazione delle sue regole. In un libro mastro delle attività, ciò significa che non possono spendere soldi di altre persone, né modificare la quantità totale di attività rappresentate. Tuttavia ci sono ancora due modi in cui i validatori possono influenzare indebitamente i contenuti di un database:

• Censura delle transazioni. Se un numero sufficiente di validatori collude maliziosamente, può impedire che una determinata transazione venga confermata nella blockchain, lasciandola permanentemente nel limbo.
• Risoluzione parziale dei conflitti. Se due transazioni sono in conflitto, il validatore che crea il blocco successivo decide quale transazione è confermata sulla blockchain, causando il rifiuto dell'altra. La scelta giusta sarebbe la transazione vista per prima, ma i validatori possono scegliere in base ad altri fattori senza rivelarlo.

A causa di questi problemi, quando si distribuisce un database basato su blockchain, è necessario avere un'idea chiara di chi sono i tuoi validatori e perché ti fidi di loro, collettivamente se non da soli. A seconda del caso d'uso, i validatori possono essere scelti come: (a) uno o più nodi controllati da una singola organizzazione, (b) un gruppo principale di organizzazioni che mantengono la catena, o (c) ogni nodo della rete.

8. Esegui il backup dei tuoi beni

Se sei arrivato così lontano, potresti aver notato che tendo a fare riferimento alle blockchain come database condivisi, piuttosto che ai più comuni "registri condivisi". Perché? Perché come tecnologia, le blockchain possono essere applicate a problemi ben oltre il monitoraggio della proprietà degli asset. Qualsiasi database che ha più scrittori non attendibili può essere implementato su una blockchain, senza richiedere un intermediario centrale. Gli esempi includono calendari condivisi, collaborazione in stile wiki e forum di discussione.

Detto questo, per ora sembra che le blockchain siano principalmente di interesse per coloro che seguono il movimento e lo scambio di attività finanziarie. Posso pensare a due motivi per questo: (a) il settore finanziario sta rispondendo alla (in retrospettiva, minuscola) minaccia di criptovalute come bitcoin, e (b) un libro mastro patrimoniale è l'esempio più semplice e naturale di un database condiviso con transazioni interdipendenti create da più entità non affidabili.

Se desideri utilizzare una blockchain come libro mastro delle risorse, devi rispondere a un'altra domanda cruciale: qual è la natura delle risorse che vengono spostate? Con questo non intendo solo contanti, obbligazioni o polizze di carico, anche se ovviamente è importante. La domanda è piuttosto: Chi sta dietro gli asset rappresentati sulla blockchain? Se il database dice che possiedo 10 unità di qualcosa, chi mi permetterà di rivendicare quelle 10 unità nel mondo reale? Chi posso fare causa se non riesco a convertire ciò che è scritto nella blockchain in beni fisici tradizionali? (Guarda questo accordo patrimoniale per un esempio.)

La risposta, ovviamente, varierà a seconda del caso d'uso. Per le attività monetarie, si può immaginare che le banche di custodia accettino contanti in forma tradizionale e quindi accreditino i conti dei depositanti in un libro mastro distribuito basato su blockchain. Nella finanza commerciale, le lettere di credito e le polizze di carico sarebbero sostenute rispettivamente dalla banca dell'importatore e dalla compagnia di navigazione. E più in futuro, possiamo immaginare un momento in cui il emissione primaria di obbligazioni societarie avviene direttamente su una blockchain da parte della società che cerca di raccogliere fondi.

Conclusione

Come ho accennato nell'introduzione, se il tuo progetto non è stato realizzato ognuna di queste condizioni, non dovresti usare una blockchain. In assenza di uno dei primi cinque, dovresti considerare uno dei seguenti: (a) archiviazione di file regolare, (b) un database centralizzato, (c) master-slave replica del databaseo (d) più database a cui gli utenti possono sottoscrivi.

E se realizzi i primi cinque, c'è ancora del lavoro da fare. Devi essere in grado di esprimere le regole della tua applicazione in termini di transazioni consentite da un database. Devi essere sicuro di chi ti puoi fidare come validatori e di come definirai il consenso distribuito. E infine, se stai cercando di creare un libro mastro condiviso, devi sapere chi supporterà gli asset che quel libro mastro rappresenta.

Hai tutte le risposte? Congratulazioni, hai un vero caso d'uso blockchain. E ci piacerebbe avere tue notizie.

Si prega di inviare eventuali commenti LinkedIn. Vedi anche questo seguito: Quattro autentici casi d'uso di blockchain.