Quattro autentici casi d'uso blockchain PlatoBlockchain Data Intelligence. Ricerca verticale. Ai.

Quattro autentici casi d'uso di blockchain

Dove i registri condivisi aggiungono valore reale all'IT aziendale

Quasi un anno dopo il primo rilascio più giri, abbiamo imparato moltissimo su come le blockchain, in senso privato e non di criptovaluta, possono e non possono essere applicate a problemi del mondo reale. Consentitemi di condividere ciò che sappiamo finora.

Per cominciare, la prima idea con cui noi (e molti altri) abbiamo iniziato, sembra essere sbagliata. Questa idea, ispirata direttamente dal bitcoin, era che i blockchain privati ​​(o "registri condivisi") potessero essere utilizzati per regolare direttamente la maggior parte delle transazioni di pagamento e scambio nel settore finanziario, utilizzando token on-chain per rappresentare contanti, azioni, obbligazioni e Di Più.

Questo è perfettamente funzionante a livello tecnico, quindi qual è il problema? In una parola, riservatezza. Se più istituzioni utilizzano un libro mastro condiviso, ogni istituzione vede ogni transazione su quel libro mastro, anche se non conosce immediatamente le identità del mondo reale delle parti coinvolte. Si tratta di un problema enorme, sia in termini di regolamentazione che di realtà commerciali della concorrenza interbancaria. Sebbene siano disponibili o in fase di sviluppo varie strategie per mitigare questo problema, nessuna può eguagliare la semplicità e l'efficienza di un database centralizzato gestito da un intermediario fidato, che mantiene il pieno controllo su chi può vedere cosa. Almeno per ora, sembra che le grandi istituzioni finanziarie preferiscano mantenere la maggior parte delle transazioni nascoste in questi database intermedi, nonostante i costi.

Baso questa conclusione non solo sulla nostra esperienza, ma anche sulla direzione presa da diverse importanti startup il cui obiettivo iniziale era quello di sviluppare registri condivisi per le banche. Ad esempio, sia R3CEV che Digital Asset stanno ora lavorando su "linguaggi di descrizione del contratto", in Corda ed DAML rispettivamente (gli esempi precedenti includono MLFi ed Contratti Ricardiani). Queste lingue consentono di rappresentare formalmente e in modo univoco le condizioni di un contratto finanziario complesso in un formato leggibile dal computer, evitando il carenze del calcolo generico in stile Ethereum. Invece, la blockchain svolge solo un ruolo di supporto, archiviando o autenticando i contratti in forma crittografata ed eseguendo un rilevamento di duplicati di base. L'effettiva esecuzione del contratto non avviene sulla blockchain, bensì viene eseguita solo dalle controparti del contratto, con la probabile aggiunta di revisori e regolatori.

A breve termine, questo è probabilmente il meglio che si può fare, ma dove lascia le ambizioni più ampie per le blockchain autorizzate? Esistono altre applicazioni per le quali possono costituire una parte più significativa del puzzle?

Questa domanda può essere affrontata sia teoricamente che empiricamente. Teoricamente, concentrandoci sulle differenze chiave tra blockchain e database tradizionali e su come questi informano l'insieme di possibili casi d'uso. E nel nostro caso, empiricamente, classificando le soluzioni del mondo reale costruite su MultiChain oggi. Non sorprende che, sia che ci concentriamo sulla teoria o sulla pratica, sorgano le stesse classi di casi d'uso:

  • Sistemi finanziari leggeri.
  • Monitoraggio della provenienza.
  • Tenuta dei registri interorganizzativi.
  • Aggregazione multipartitica.

Prima di spiegarli in dettaglio, ricapitoliamo la teoria. Come ho discusso in precedenza, le due differenze più importanti tra blockchain e database centralizzati possono essere caratterizzate come segue:

  1. disintermediazione. Le blockchain consentono a più parti che non si fidano completamente l'una dell'altra di condividere in modo sicuro e diretto un singolo database senza richiedere un intermediario fidato.
  2. riservatezza: Tutti i partecipanti a una blockchain vedono tutte le transazioni in corso. (Anche se utilizziamo indirizzi pseudonimi e crittografia avanzata per nascondere alcuni aspetti di tali transazioni, una blockchain perderà sempre più informazioni di un database centralizzato.)

In altre parole, le blockchain sono ideali per i database condivisi in cui ogni utente è in grado di read tutto, ma nessun singolo utente controlla chi può scrivere che cosa. Al contrario, nei database tradizionali, una singola entità esercita il controllo su tutte le operazioni di lettura e scrittura, mentre gli altri utenti sono interamente soggetti ai capricci di quell'entità. Per riassumere in una frase:

Le blockchain rappresentano un compromesso in cui si ottiene la disintermediazione a scapito della riservatezza.

Nell'esaminare i quattro tipi di caso d'uso di seguito, torneremo ripetutamente a questo compromesso fondamentale, spiegando perché, in ogni caso, il vantaggio della disintermediazione supera il costo di una riservatezza ridotta.

Sistemi finanziari leggeri

Cominciamo con la classe di applicazioni blockchain che risulterà più familiare, in cui un gruppo di entità desidera impostare un sistema finanziario. All'interno di questo sistema, una o più attività scarse vengono negoziate e scambiate tra tali entità.

Affinché in qualsiasi risorsa per rimanere scarsa, due problemi correlati devono essere risolti. Innanzitutto, dobbiamo assicurarci che la stessa unità di asset non possa essere inviata a più di un luogo (una "doppia spesa"). In secondo luogo, deve essere impossibile per chiunque creare nuove unità del bene per capriccio ("falso"). Qualsiasi entità che potesse fare una di queste cose potrebbe rubare un valore illimitato dal sistema.

Una soluzione comune a questi problemi è rappresentata dai gettoni fisici, come monete metalliche o carta stampata in modo sicuro. Questi token risolvono banalmente il problema della doppia spesa, perché le regole della fisica (letteralmente) impediscono che un token si trovi in ​​due posti contemporaneamente. Il problema della falsificazione viene risolto rendendo il gettone estremamente difficile da produrre. Tuttavia, i gettoni fisici soffrono di diversi difetti che possono renderli poco pratici:

  • In quanto beni portatori puri, i token fisici possono essere rubati senza traccia o ricorso.
  • Sono lenti e costosi da spostare in gran numero o su lunghe distanze.
  • È complicato e costoso creare gettoni fisici che non possono essere falsificati.

Queste carenze possono essere evitate lasciando dietro di sé token fisici e ridefinendo la proprietà delle risorse in termini di un registro gestito da un intermediario di fiducia. In passato, questi registri erano basati su documenti cartacei e oggi tendono a funzionare su database regolari. In ogni caso, l'intermediario attua un trasferimento di proprietà modificando il contenuto del libro mastro, in risposta a una richiesta autenticata. A differenza del regolamento con gettoni fisici, le transazioni discutibili possono essere annullate rapidamente e facilmente.

Allora qual è il problema con i libri mastri? In poche parole, concentrazione di controllo. Mettendo così tanto potere in un unico posto, creiamo una sfida significativa alla sicurezza, sia in termini tecnici che umani. Se qualcuno esterno può hackerare il database, può modificare il libro mastro a piacimento, rubando i fondi degli altri o distruggendo completamente il suo contenuto. Ancora peggio, qualcuno all'interno potrebbe corrompere il libro mastro e questo tipo di attacco è difficile da rilevare o provare. Di conseguenza, ovunque disponiamo di un registro centralizzato, dobbiamo investire molto tempo e denaro in meccanismi per mantenere l'integrità di tale registro. E in molti casi, richiediamo una verifica continua utilizzando la riconciliazione basata su batch tra il libro mastro centrale e quelli di ciascuna delle parti che effettuano transazioni.

Inserisci la blockchain (o "libro mastro condiviso"). Ciò fornisce i vantaggi dei libri mastri senza soffrire del problema della concentrazione. Invece, ogni entità gestisce un "nodo" che contiene una copia del libro mastro e mantiene il pieno controllo sulle proprie risorse, che sono protette da chiavi private. Le transazioni si propagano tra i nodi in modo peer-to-peer, con la blockchain che garantisce il mantenimento del consenso. Questa architettura non lascia alcun punto di attacco centrale attraverso il quale un hacker o un insider potrebbe corrompere i contenuti del libro mastro. Di conseguenza, un sistema finanziario digitale può essere implementato in modo più rapido ed economico, con l'ulteriore vantaggio della riconciliazione automatica in tempo reale.

Allora qual è lo svantaggio? Come discusso in precedenza, tutti i partecipanti a un libro mastro condiviso vedono tutte le transazioni in corso, rendendolo inutilizzabile in situazioni in cui è richiesta la riservatezza. Invece, le blockchain sono adatte a ciò che chiamo leggero sistemi finanziari, vale a dire quelli in cui la posta in gioco economica o il numero di partecipanti è relativamente basso. In questi casi, la riservatezza tende a essere un problema minore - anche se i partecipanti prestano molta attenzione a ciò che fanno gli altri, non impareranno molto di valore. Ed è proprio così perché la posta in gioco è bassa e preferiamo evitare il fastidio e il costo di creare un intermediario.

Alcuni ovvi esempi di sistemi finanziari leggeri includono: crowdfunding, carte regalo, punti fedeltà e valute locali, specialmente nei casi in cui le risorse sono rimborsabili in più di un luogo. Ma stiamo anche assistendo a casi d'uso nel settore finanziario tradizionale, come il trading peer-to-peer tra asset manager che non sono in concorrenza diretta. Le blockchain vengono persino testate come interno sistemi contabili, nelle grandi organizzazioni in cui ogni dipartimento o sede deve mantenere il controllo dei propri fondi. In tutti questi casi, il minor costo e l'attrito delle blockchain forniscono un vantaggio immediato, mentre la perdita di riservatezza non è un problema.

Monitoraggio della provenienza

Ecco una seconda classe di casi d'uso che sentiamo ripetutamente dagli utenti di MultiChain: tracciare l'origine e il movimento di articoli di alto valore lungo una catena di fornitura, come beni di lusso, prodotti farmaceutici, cosmetici ed elettronica. Allo stesso modo, documenti critici come polizze di carico o lettere di credito. Nelle catene di fornitura che si estendono nel tempo e nella distanza, tutti questi articoli subiscono contraffazione e furto.

Il problema può essere affrontato utilizzando blockchain nel modo seguente: quando viene creato l'elemento di alto valore, un token digitale corrispondente viene emesso da un'entità fidata, che agisce per autenticare il suo punto di origine. Quindi, ogni volta che l'elemento fisico cambia di mano, il token digitale viene spostato in parallelo, in modo che la catena di custodia del mondo reale sia rispecchiata precisamente da una catena di transazioni sulla blockchain.

Se vuoi, il token agisce come un "certificato di autenticità" virtuale, che è molto più difficile da rubare o falsificare rispetto a un pezzo di carta. Dopo aver ricevuto il token digitale, il destinatario finale dell'articolo fisico, che sia una banca, un distributore, un rivenditore o un cliente, può verificare la catena di custodia fino al punto di origine. In effetti, nel caso di documentazione come polizze di carico, possiamo eliminare del tutto l'elemento fisico.

Sebbene tutto ciò abbia senso, il lettore astuto noterà che un database regolare, gestito (diciamo) dal produttore di un articolo, può svolgere lo stesso compito. Questo database memorizzerebbe un record dell'attuale proprietario di ogni elemento, accettando transazioni firmate che rappresentano ogni cambio di proprietà e rispondere alle richieste in arrivo riguardanti lo stato attuale dei lavori.

Allora perché usare invece una blockchain? La risposta è che, per questo tipo di applicazione, c'è un vantaggio nella fiducia distribuita. Indipendentemente da dove si trovi un database centralizzato, ci saranno persone in quel luogo che hanno la capacità (e possono essere corrotte) di corromperne il contenuto, contrassegnando gli oggetti contraffatti o rubati come legittimi. Al contrario, se la provenienza viene tracciata su una blockchain che appartiene collettivamente ai partecipanti di una catena di approvvigionamento, nessuna singola entità o piccolo gruppo di entità può corrompere la catena di custodia e gli utenti finali possono avere più fiducia nelle risposte che ricevono. Come bonus, diversi gettoni (ad esempio per alcune merci e la corrispondente polizza di carico) possono essere scambiati in modo sicuro e diretto, con uno scambio a due vie garantito al livello blockchain più basso.

E il problema della riservatezza? L'idoneità delle blockchain per la provenienza della catena di approvvigionamento è un felice risultato del semplice modello di transazioni di questa applicazione. A differenza dei mercati finanziari, la maggior parte dei token si muove in un'unica direzione, dall'origine all'endpoint, senza essere scambiata ripetutamente avanti e indietro tra i partecipanti alla blockchain. Se i concorrenti raramente effettuano transazioni tra loro (ad es. Dal produttore di giocattoli al produttore di giocattoli o dal rivenditore al rivenditore), non possono apprendere gli "indirizzi" blockchain degli altri e collegarli alle identità del mondo reale. Inoltre, l'attività può essere facilmente suddivisa in più registri, ognuno dei quali rappresenta un ordine o un tipo di merce diverso.

Transazioni finanziarie rispetto alla catena di fornitura

Tenuta dei registri interorganizzativi

Entrambi i casi d'uso precedenti si basano su asset tokenizzati, ovvero rappresentazioni on-chain di un elemento di valore trasferito tra i partecipanti. Tuttavia esiste un secondo gruppo di casi d'uso della blockchain che non è correlato alle risorse. Invece, la catena funge da meccanismo per la registrazione e l'autenticazione collettiva in qualsiasi tipo di dati, il cui significato può essere finanziario o altro.

Uno di questi esempi è un audit trail delle comunicazioni critiche tra due o più organizzazioni, ad esempio nel settore sanitario o legale. Nessuna singola organizzazione del gruppo può essere considerata affidabile per il mantenimento di questo archivio di record, perché le informazioni falsificate o cancellate danneggerebbero in modo significativo le altre. Tuttavia è fondamentale che tutti concordino sui contenuti dell'archivio, al fine di evitare controversie.

Per risolvere questo problema, abbiamo bisogno di un database condiviso in cui vengono scritti tutti i record, con ogni record accompagnato da un timestamp e una prova dell'origine. La soluzione standard sarebbe creare un intermediario fidato, il cui ruolo è raccogliere e archiviare i record a livello centrale. Ma le blockchain offrono un approccio diverso, dando alle organizzazioni un modo per gestire congiuntamente questo archivio, impedendo ai singoli partecipanti (o piccoli gruppi di essi) di corromperlo.

Una delle conversazioni più illuminanti che ho avuto negli ultimi due anni è stata con Michael Mainelli of Z / Yen. Da 20 anni la sua azienda costruisce sistemi in cui più entità gestiscono collettivamente un audit trail digitale condiviso, utilizzando timestamp, firme digitali e uno schema di consenso round robin. Quando ha spiegato i dettagli tecnici di questi sistemi, è diventato chiaro che sono blockchain autorizzati sotto ogni aspetto. In altre parole, non c'è nulla di nuovo nell'utilizzo di una blockchain per la conservazione dei record interorganizzativi: è solo che il mondo è finalmente diventato consapevole della possibilità.

In termini di dati effettivi memorizzati sulla blockchain, ci sono tre opzioni popolari:

  • Dati non crittografati. Questo può essere letto da ogni partecipante alla blockchain, fornendo piena trasparenza collettiva e risoluzione immediata in caso di controversia.
  • Dati crittografati. Può essere letto solo dai partecipanti con la chiave di decrittazione appropriata. In caso di controversia, chiunque può rivelare questa chiave a un'autorità di fiducia come un tribunale e utilizzare la blockchain per dimostrare che i dati originali sono stati aggiunti da una determinata parte in un determinato momento.
  • Dati con hash. Un "hash”Agisce come un'impronta digitale compatta, rappresentando un impegno per un particolare pezzo di dati mantenendo tali dati nascosti. Dati alcuni dati, qualsiasi parte può facilmente confermare se corrisponde a un dato hash, ma deducendo dati da il suo hash è computazionalmente impossibile. Solo l'hash viene posizionato sulla blockchain, con i dati originali memorizzati fuori catena dalle parti interessate, che possono rivelarlo in caso di controversia.

Come accennato in precedenza, il prodotto Corda di R3CEV ha adottato questo terzo approccio, memorizzare gli hash su una blockchain per autenticare i contratti tra controparti, senza rivelarne il contenuto. Questo metodo può essere utilizzato sia per le descrizioni dei contratti leggibili da computer, sia per i file PDF contenenti documentazione cartacea.

Naturalmente, la riservatezza non è un problema per la conservazione dei registri interorganizzativi, perché l'intero scopo è creare un archivio condiviso che tutti i partecipanti possano vedere (anche se alcuni dati sono crittografati o sottoposti ad hashing). In alcuni casi, infatti, una blockchain può aiutare a gestire l'accesso a dati confidenziali off-chain, fornendo una registrazione immutabile delle richieste di accesso firmate digitalmente. In entrambi i casi, il vantaggio immediato della disintermediazione è che non è necessario creare e considerare attendibile alcuna entità aggiuntiva per mantenere questo record.

Aggregazione multipartitica

Tecnicamente parlando, questa classe finale di caso d'uso è simile a quella precedente, in quanto più parti scrivono dati su un record gestito collettivamente. Tuttavia in questo caso la motivazione è diversa: superare la difficoltà infrastrutturale di combinare informazioni da un gran numero di fonti separate.

Immagina due banche con database interni di verifiche dell'identità dei clienti. Ad un certo punto notano che condividono molti clienti, quindi entrano in un accordo di condivisione reciproca in cui si scambiano i dati di verifica per evitare il lavoro duplicato. Tecnicamente, l'accordo viene implementato utilizzando lo standard replica dei dati master-slave, in cui ogni banca mantiene una copia live di sola lettura del database dell'altra ed esegue query in parallelo sul proprio database e sulla replica. Fin qui tutto bene.

Ora immagina che queste due banche ne invitino altre tre a partecipare a questo circolo di condivisione. Ciascuna delle 5 banche gestisce il proprio database principale, insieme a 4 repliche di sola lettura delle altre. Con 5 master e 20 repliche, abbiamo in totale 25 istanze di database. Sebbene fattibile, ciò richiede tempo e risorse notevoli nel reparto IT di ciascuna banca.

Avanti veloce al punto in cui 20 banche condividono le informazioni in questo modo e stiamo esaminando 400 istanze di database in totale. Per 100 banche, raggiungiamo 10,000 istanze. In generale, se tutte le parti condividono le informazioni tra loro, il numero totale di istanze di database cresce con il quadrato del numero di partecipanti. Ad un certo punto di questo processo, il sistema è destinato a rompersi.

Allora qual è la soluzione? Un'opzione ovvia è che tutte le banche inviino i propri dati a un intermediario fidato, il cui compito è aggregare tali dati in un unico database principale. Ciascuna banca potrebbe quindi interrogare questo database in remoto o eseguire una replica locale di sola lettura all'interno delle proprie quattro mura. Sebbene non ci sia nulla di sbagliato in questo approccio, le blockchain offrono un'alternativa più economica, in cui il database condiviso viene gestito direttamente dalle banche che lo utilizzano. Le blockchain portano anche il vantaggio aggiuntivo di ridondanza ed failover per il sistema nel suo insieme.

È importante chiarire che una blockchain non si comporta come un database distribuito come Cassandra or Ripensare DB. A differenza di questi sistemi, ogni nodo blockchain applica una serie di regole che impediscono a un partecipante di modificare o eliminare i dati aggiunti da un altro. In effetti, sembra esserci ancora un po 'di confusione su questo: una piattaforma blockchain rilasciata di recente può essere interrotta da un singolo nodo che si comporta male. In ogni caso, una buona piattaforma renderà anche facile gestire reti con migliaia di nodi, unendoli e uscendo a piacimento, se concessi gli opportuni permessi.

Anche se sono un po 'scettico sulla connessione spesso citata tra blockchain e Internet delle cose, Penso che questo potrebbe essere il punto in cui risiede una forte sinergia. Ovviamente, ogni "cosa" sarebbe troppo piccola per archiviare una copia completa della blockchain a livello locale. Piuttosto, trasmetterebbe le transazioni che trasportano dati a una rete distribuita di nodi blockchain, che li raccoglierebbero tutti insieme per un ulteriore recupero e analisi.

Conclusione: Blockchain in Finance

Ho iniziato questo pezzo mettendo in discussione il caso d'uso iniziale previsto per le blockchain nel settore finanziario, vale a dire il regolamento in blocco di transazioni di pagamento e scambio. Anche se credo che questa conclusione stia diventando saggezza comune (con uno eccezione notevole), ciò non significa che le blockchain non abbiano altre applicazioni in questo settore. In effetti, per ciascuna delle quattro classi di casi d'uso delineate sopra, vediamo chiare applicazioni per banche e altre istituzioni finanziarie. Rispettivamente, questi sono: piccoli circoli commerciali, provenienza per finanza commerciale, autenticazione di contratti bilaterali e aggregazione di dati AML / KYC.

La chiave per capire è che, dal punto di vista architettonico, le nostre quattro classi di casi d'uso non lo sono specifico per finanziare e sono ugualmente rilevanti per altri settori come assicurazioni, sanità, distribuzione, produzione e IT. In effetti, le blockchain private dovrebbero essere prese in considerazione per qualsiasi situazione in cui due o più organizzazioni necessitano di una visione condivisa della realtà e tale visione non proviene da un'unica fonte. In questi casi, le blockchain offrono un'alternativa alla necessità di un intermediario di fiducia, portando a significativi risparmi in termini di problemi e costi.

Si prega di inviare eventuali commenti LinkedIn.

Fonte: https://www.multichain.com/blog/2016/05/four-genuine-blockchain-use-cases/

Timestamp:

Di più da più giri