Come individuare una blockchain mezza cotta

Quando catene e blocchi non servono a nessuno scopo

Sono trascorsi circa 18 mesi da quando il settore finanziario si è svegliato, in massa, alle possibilità di blockchain autorizzati, o per usare il termine più generale "registri distribuiti". Il periodo da allora ha visto uno tsunami di attività, tra cui rapporti di ricerca, investimenti strategici, progetti pilota e la formazione di numerosi consorzi. Nessuno può accusare il mondo bancario di non prendere sul serio il potenziale di questa tecnologia.

Naturalmente, la crescita esplosiva dei progetti blockchain ha guidato lo sviluppo di piattaforme blockchain autorizzate, su cui sono basati tali progetti. Ad esempio, il nostro prodotto più giri nell'ultimo anno è triplicato, indipendentemente dal fatto che misuriamo il traffico web, i download mensili o le richieste commerciali. E, naturalmente, ci sono molte altre piattaforme, come ad esempio BigChainDB, Catena, Corda, Crediti, Elementi, Eris, Tessuto, Ethereum (distribuito in una rete chiusa), idracatena ed catena aperta. Per non parlare delle altre startup che hanno sviluppato una sorta di piattaforma blockchain ma non l'hanno resa disponibile al pubblico.

Per le aziende che desiderano esplorare e comprendere una nuova tecnologia, l'abbondanza di scelta è generalmente una buona cosa. Tuttavia, nel caso delle blockchain, che rimangono ancora vagamente definite e poco comprese, questa cornucopia presenta un significativo svantaggio: molte delle piattaforme "blockchain" disponibili in realtà non affrontano il problema principale che dovrebbero risolvere. E qual è quel problema? Mi permetta di citare il succinto definizione video di Richard Gendal Brown, CTO di R3, in toto:

Un libro mastro distribuito è un sistema che consente alle parti che non si fidano completamente reciprocamente di giungere a un consenso sull'esistenza, la natura e l'evoluzione di una serie di fatti condivisi senza dover fare affidamento su una terza parte centralizzata completamente attendibile.

Per fare un esempio estremo, considera un mucchio di mattoncini Lego legati insieme con lo spago. Se usiamo il termine "catena a blocchi" per descrivere questo capo di moda, chi può dire che non lo stiamo descrivendo accuratamente? Eppure, quella particolare catena di blocchi non aiuterà più parti a condividere in modo sicuro e diretto un database senza un intermediario centrale. Allo stesso modo, molte piattaforme "blockchain" fanno qualcosa in relazione a catene di blocchi, ma mancano anche delle proprietà necessarie per servire da base per un database peer-to-peer.

Un'altra catena di blocchi che non aiuta con la condivisione del database - source.

Blockchain minimo praticabile

Al fine di comprendere i requisiti di base di un libro mastro distribuito, aiuta a chiarire in che modo questi sistemi differiscono dai normali database, che sono controllati da una singola entità. Ad esempio, consideriamo un semplice sistema per tracciare chi possiede le azioni di una determinata azienda. Il libro mastro, come implementato in un database, ha una riga per ogni proprietario contenente due colonne: l'identificatore del proprietario, come il loro nome, e la quantità corrispondente di condivisioni.

Ecco sei modi cruciali in cui questo sistema potrebbe fallire i suoi utenti:

• contraffazione: Trasferimento di azioni da una persona a un'altra senza l'autorizzazione del mittente.
• Censura: Rifiuto di soddisfare la richiesta di qualcuno di trasferire alcune condivisioni altrove.
• Inversione: Annullamento di un trasferimento che è avvenuto ad un certo punto in passato.
• Illegittimità: Modifica della quantità totale di azioni nel sistema senza un'azione corrispondente da parte dell'emittente.
• incoerenza: Fornire risposte diverse alle richieste di utenti diversi.
• I tempi di inattività: Non risponde alle richieste di informazioni in arrivo.

A causa di tutte queste possibilità, gli azionisti devono mantenere un alto livello di fiducia in chiunque gestisca questo libro mastro per loro conto. La creazione e la gestione di un'organizzazione degna di tale fiducia comporta notevoli problemi e costi.

Blockchain o registri distribuiti eliminano la necessità di questo tipo di operatore di database centrale, consentendo agli utenti di un database di interagire direttamente tra loro su base peer-to-peer. Nel nostro esempio, gli azionisti potrebbero detenere in modo sicuro le loro azioni su una blockchain che gestiscono collettivamente ed effettuare immediatamente trasferimenti reciproci su quella catena. (Lo svantaggio è una significativa perdita di riservatezza tra gli utenti della catena, che non affronteremo qui, ma ho precedentemente discusso a lungo.)

Tutto ciò ci riporta alla questione delle piattaforme blockchain. Per fungere da base fattibile per la condivisione di database peer-to-peer, una blockchain deve proteggere i suoi partecipanti da tutti e sei i tipi di errore del database: falsificazione, censura, inversione, transazioni illegittime, incoerenza e tempi di inattività. Mentre molti prodotti sul mercato soddisfano questi requisiti, alcuni di essi risultano insufficienti. Chiamo queste blockchain "cotte a metà" perché potrebbero essere indirizzate alcuni di questi rischi, ma non tutti. Almeno per alcuni aspetti, gli utenti del database rimangono dipendenti dal buon comportamento di un singolo partecipante, che è precisamente lo scenario che vogliamo evitare.

Queste blockchain cotte a metà sono disponibili in qualsiasi numero di varietà, ma tre archetipi si distinguono come i più comuni o ovvi. Non nominerò singoli prodotti perché, beh, non voglio offendere. La community di startup blockchain è abbastanza piccola che molti di noi si conoscono attraverso conferenze e altri incontri e le interazioni tendono ad essere positive. Tuttavia, se le blockchain (nel senso di utili database peer-to-peer) emergeranno mai come una categoria di prodotti coerente, è importante distinguere tra soluzioni semi-cotte e soluzioni reali.

L'unica blockchain validatrice

Un modello che abbiamo visto alcune volte è una blockchain in cui solo un partecipante può generare i blocchi in cui le transazioni sono confermate. Le transazioni vengono inviate a questo nodo invece di essere trasmesse alla rete nel suo insieme, quindi la loro accettazione è soggetta ai capricci di questa parte piuttosto che a un qualche tipo di consenso della maggioranza. Tuttavia, una volta che un blocco è stato creato da questa parte centrale, viene trasmesso agli altri nodi della rete, che possono confermare in modo indipendente la validità delle transazioni all'interno e registrare il nuovo blocco localmente e permanentemente.

Per tornare alle nostre sei forme di malfunzionamento del database, questo tipo di blockchain è tutt'altro che inutile. Le transazioni devono essere firmate digitalmente dall'entità di cui spostano i fondi, quindi non possono essere falsificate dalla parte centrale. Non possono essere invertiti perché ogni nodo mantiene la propria copia della catena. E le transazioni non possono eseguire operazioni illegali come la creazione di risorse dal nulla, poiché ogni nodo convalida indipendentemente ogni transazione per correttezza. Infine, ogni nodo mantiene la propria copia del database, quindi il suo contenuto è sempre disponibile per la lettura.

Sfortunatamente, quattro su sei non sono sufficienti. Il nodo di validazione può facilmente censurare singole transazioni, rifiutando di includerle nei blocchi che crea. Anche se gli operatori di questo nodo sono onesti, un errore del sistema o delle comunicazioni può renderlo non disponibile, causando l'interruzione dell'elaborazione di tutte le transazioni. Inoltre, a seconda della configurazione, il nodo di convalida potrebbe essere in grado di trasmettere diverse versioni della blockchain a diversi partecipanti. In termini di censura e coerenza, il database contiene ancora un singolo punto di errore, su cui si basano tutti gli altri nodi.

Una piattaforma offre una svolta a questo schema, in cui i blocchi sono generati centralmente da un singolo nodo, ma un quorum di altri nodi designati li firma per indicare il consenso. In termini di rischio di incoerenza, questo sicuramente aiuta. I nodi nel quorum presteranno le loro firme solo a una singola versione della blockchain, che può quindi essere considerata autorevole. Tuttavia, i nodi quorum non possono essere d'aiuto se il generatore di blocchi censura le transazioni o perde la connessione a Internet. In definitiva, questo tipo di blockchain utilizza ancora un'architettura hub-speak, piuttosto che una rete peer-to-peer.

La blockchain di stato condivisa

Tecnicamente parlando, ci sono molte somiglianze tra blockchain e database distribuiti più tradizionali come Cassandra e MongoDB. In entrambi i casi, le transazioni possono essere avviate da qualsiasi nodo della rete e devono raggiungere tutti gli altri nodi come parte di un consenso sullo stato di sviluppo del database. Sia la blockchain che i database distribuiti devono far fronte alla latenza (ritardi di comunicazione che derivano dalla distanza tra i nodi) e alla possibilità che alcuni nodi e / o collegamenti di comunicazione falliscano in modo intermittente.

Database distribuiti sono in circolazione da un po 'di tempo, quindi qualsiasi sviluppatore di piattaforme blockchain farebbe bene a capire i loro algoritmi di consenso e le strategie che usano per ordinare transazioni a livello globale e risolvere i conflitti. Tuttavia, è importante non portare il confronto troppo lontano, perché le blockchain devono affrontare una sfida aggiuntiva cruciale: un'assenza di fiducia tra i nodi del database. Mentre i database distribuiti si concentrano sul fornire scalabilità, robustezza e alte prestazioni entro i limiti di una singola organizzazione, le blockchain devono essere riprogettate per attraversare quei confini.

Per tornare ai nostri sei tipi di rischio di database, un nodo in un database distribuito deve solo preoccuparsi dei tempi di inattività, ovvero la possibilità che altri nodi non siano disponibili. I nodi possono presumere in sicurezza che ogni transazione e messaggio sulla rete siano validi e non si preoccupano di falsificazione, censura, inversione, illegittimità o incoerenza. Il loro peggior problema riguarda due transazioni simultanee ma valide, avviate su nodi diversi, che influiscono sullo stesso dato. Risolvere questi conflitti non è affatto banale, ma è ancora molto più facile che preoccuparsi di "Difetti bizantini“, In cui alcuni nodi agiscono deliberatamente per interrompere il funzionamento di altri.

Un database può essere condiviso solo in sicurezza operanti in confidi i limiti se i nodi trattano tutte le attività sulla rete con un certo sospetto. Ad esempio, ogni transazione che modifica il database deve essere firmata individualmente in modo digitale poiché, in un'architettura peer-to-peer, non esiste altro modo per conoscerne il vero punto di origine. Allo stesso modo, ogni messaggio in arrivo, come l'annuncio di un nuovo blocco, deve essere valutato criticamente per il suo contenuto e contesto. A differenza dei database distribuiti, i nodi non devono essere in grado di modificare immediatamente e direttamente lo stato di un altro nodo.

Alcune piattaforme "blockchain" sono state sviluppate iniziando con un database distribuito e cospargendo alcune funzionalità per renderle più blockchainy. Ad esempio, raggruppando le transazioni in blocchi e memorizzando gli hash (impronte digitali) di tali blocchi nel database, mirano ad aggiungere una forma di immutabilità. Ma a meno che ogni nodo non sia sicuro che il suo elenco di hash non possa essere modificato da un altro nodo, questo tipo di immutabilità è facilmente giocabile. La risposta standard a queste critiche è che ogni problema di sicurezza può essere risolto con tempo e codice sufficienti. Ma è un po 'come tenere alcuni prigionieri in un campo aperto e cercare di impedirgli di fuggire con fili e fossati. È molto più sicuro utilizzare una struttura in cemento appositamente costruita, le cui porte sono bloccate e le cui finestre sono sbarrate.

L'unica nuvola blockchain

Di gran lunga il fenomeno più strano che ho visto sono le piattaforme blockchain a cui è possibile accedere solo attraverso la piattaforma-come-un-servizio basata su cloud dello sviluppatore. Per essere chiari, non stiamo parlando di alcuni dei partecipanti di una blockchain la scelta per ospitare i loro nodi sul loro provider cloud preferito, come ad esempio Microsoft Azure or Amazon Web Services. Piuttosto, questa è una blockchain che può esclusivamente accedere attraverso le API esposte dai server di un'azienda che la "ospita".

Concediamo, per amor di argomenti, che un fornitore centralizzato di blockchain abbia davvero un gruppo di nodi in esecuzione sotto il suo controllo. Che differenza fa questo per gli utenti del sistema che inviano richieste API e ricevono risposte? I partecipanti non hanno modo di valutare se le transazioni di tutti sono state elaborate senza omissioni o errori. Forse il servizio centrale non funziona correttamente o forse censura o annulla deliberatamente alcune transazioni. E se ritieni che il provider blockchain non abbia motivo di farlo, perché non utilizzarli per ospitare un normale database centralizzato? Otterrai un prodotto più maturo con prestazioni migliori e non rischierai di lavorare con le nuove tecnologie. In breve, le blockchain centralizzate sono utili quanto Lego su una stringa.

Risolvere il mistero

Ora abbiamo visto tre tipi di piattaforme che si commercializzano come "blockchain" e che fanno effettivamente uso di una catena di blocchi, ma che non risolvono il problema fondamentale per cui sono progettati questi sistemi. Ricapitolando, ciò significa consentire a un singolo database di essere condiviso in modo sicuro e diretto attraverso i confini di fiducia, senza un intermediario centrale.

Oltre a indicare questo fenomeno peculiare, credo che sia istruttivo considerare ciò che potrebbe essere alla base. Perché così tante startup blockchain costruiscono prodotti che non mantengono la promessa di questa tecnologia, ottenendo spesso niente di più dei tradizionali database centralizzati o distribuiti? Perché così tante persone di talento sprecano così tanto tempo?

Vedo due principali classi di spiegazioni: tecnica e commerciale. Innanzitutto, è piuttosto complicato creare sistemi di consenso distribuito in grado di tollerare uno o più nodi che si comportano in modo imprevedibile in modo imprevedibile. Nel caso di MultiChain, abbiamo in qualche modo imbrogliato, utilizzando l'implementazione di riferimento temprata dalla battaglia di bitcoin come punto di partenza, e quindi sostituendo la prova del lavoro con un algoritmo di consenso strutturalmente simile chiamato "diversità mineraria". I team che sviluppano un nodo blockchain da zero devono riflettere profondamente sui processi asincroni e contraddittori, una combinazione di cui pochi programmatori hanno esperienza. Posso certamente capire la tentazione di prendere una scorciatoia, come l'uso di un singolo nodo per generare blocchi, o il piggybacking su un database distribuito esistente o solo l'esecuzione di nodi in un ambiente attendibile. Scegliere una di queste indubbiamente semplifica la vita degli sviluppatori, anche se ciò mina l'intero punto.

Per motivi commerciali, ogni startup sembra avvicinarsi all'opportunità blockchain da una prospettiva diversa. Qui a Coin Sciences, ci stiamo concentrando su come diventare un fornitore di software (database), quindi distribuiamo MultiChain gratuitamente mentre sviluppiamo un nodo premium con funzionalità aggiuntive. Altre startup vogliono vendere servizi in abbonamento, quindi costruiranno naturalmente una piattaforma che i clienti non possono ospitare. Alcuni sperano di controllare centralmente una blockchain o aiutare i loro partner a farlo (una strana ambizione per una tecnologia di disintermediazione!) E sono naturalmente attratti da algoritmi di consenso che si basano su un singolo nodo. E infine, ci sono aziende il cui obiettivo principale è quello di vendere servizi di consulenza, nel qual caso la loro piattaforma non deve funzionare affatto, a condizione che il suo sito web porti alcuni grandi clienti.

Forse un altro problema è che alcune aziende blockchain sono gestite da persone che senza dubbio esplodono di talento, ma mancano di una profonda comprensione della tecnologia stessa. Nelle startup che ritagliano un nuovo campo, è probabilmente vitale che le decisioni strategiche vengano prese da persone che comprendono la natura di quel campo e in che modo differisce da ciò che è venuto prima. Non poche startup blockchain sembrano essersi dipinte in un angolo perseguendo una visione del prodotto che è attraente per i loro clienti, ma in realtà non può essere costruita.

Come utente di blockchain, come puoi evitare di essere catturato da questi errori? Durante la valutazione di una particolare piattaforma blockchain, assicurati di chiedere se soddisfa i sei requisiti di condivisione sicura del database peer-to-peer: prevenzione di tempi di inattività e incoerenza, nonché falsificazione delle transazioni, censura, inversione e illegittimità. E fai attenzione alle spiegazioni che consistono in troppo borbottio o agitando la mano - probabilmente significano che la risposta è no.

Si prega di inviare eventuali commenti LinkedIn.

Fonte: https://www.multichain.com/blog/2016/12/spot-half-baked-blockchain/