- Torna al menu
- Torna al menuPrezzi
- Torna al menuRicerca
- Torna al menuConsenso
- Torna al menu
- Torna al menu
- Torna al menu
- Torna al menuWebinar ed Eventi
Quattro casi d'uso reali della blockchain
Secondo ONE ricercatore, le istituzioni finanziarie potrebbero avere a disposizione modalità più limitate di quanto si pensasse in precedenza per sfruttare la Tecnologie .
Il dott. Gideon Greenspan è il fondatore e CEO di Coin Sciences, l'azienda dietro la piattaforma MultiChain per blockchain private.
In questo articolo Opinioni , Greenspan delinea quattro casi d'uso per le blockchain autorizzate, sostenendo che le istituzioni finanziarie potrebbero incontrare maggiori limitazioni di quanto si pensasse in precedenza nel tentativo di sfruttare la Tecnologie .
A quasi un anno dal primo lancio di MultiChain, abbiamo imparato moltissimo su come le blockchain, in senso privato e non criptovalutario, possano e non possano essere applicate a problemi del mondo reale.
Permettetemi di condividere ciò che sappiamo finora.
Per cominciare, la prima idea con cui noi (e molti altri) siamo partiti sembra sbagliata. Questa idea, ispirata direttamente da Bitcoin , era che le blockchain private (o "registri condivisi") potessero essere utilizzate per regolare direttamente la maggior parte delle transazioni di pagamento e di scambio nel settore Finanza , utilizzando token on-chain per rappresentare denaro, azioni, obbligazioni e altro.
Tutto ciò è perfettamente fattibile a livello tecnico, quindi qual è il problema?
In una parola: riservatezza. Se più istituzioni utilizzano un registro condiviso, allora ogni istituzione vede ogni transazione su quel registro, anche se T conosce immediatamente le identità reali delle parti coinvolte.
Questo si rivela 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.
Per ora, almeno, sembra che le grandi istituzioni finanziarie preferiscano KEEP la maggior parte delle transazioni nascoste in questi database intermediari, nonostante i costi che ciò comporta.
Baso questa conclusione non solo sulla nostra esperienza, ma anche sulla direzione intrapresa da diverse startup di spicco il cui obiettivo iniziale era sviluppare registri condivisi per le banche. Ad esempio, sia R3CEV che Digital Asset stanno ora lavorando su "linguaggi di descrizione dei contratti", inCorda E DANNAZIONE rispettivamente (esempi precedenti includono MLFi <a href="https://www.lexifi.com/product/technology/contract-description-language">https://www.lexifi.com/product/ Tecnologie/contract-description-language</a> e Contratti ricardiani).
Questi linguaggi consentono di rappresentare formalmente e inequivocabilmente le condizioni di un contratto finanziario complesso in un formato leggibile dal computer, evitando al contempo lacarenze Di Ethereum- calcolo di uso generale in stile. Invece, la blockchain svolge solo un ruolo di supporto, memorizzando o notarizzando i contratti in forma crittografata ed eseguendo un rilevamento di base dei duplicati.
L’effettiva esecuzione del contratto non avviene sulla blockchain, bensì viene eseguita solo dalle controparti del contratto, con la probabile aggiunta di revisori e autorità di regolamentazione.
Nel NEAR termine, questo è probabilmente il meglio che si possa fare, ma dove lascia le ambizioni più ampie per le blockchain autorizzate? Ci sono altre applicazioni per cui possono costituire una parte più significativa del puzzle?
Questa domanda può essere affrontata sia teoricamente che empiricamente.
In teoria, concentrandosi sulle differenze chiave tra blockchain e database tradizionali e su come queste informano l'insieme dei possibili casi d'uso. E nel nostro caso, empiricamente, categorizzando le soluzioni del mondo reale che vengono costruite sul nostro prodotto oggi.
Non sorprende che, sia che ci concentriamo sulla teoria o sulla pratica, emergano le stesse classi di casi d'uso:
- Tenuta dei registri interorganizzativi
- Sistemi finanziari leggeri
- Aggregazione multipartitica
- Tracciamento della provenienza.
Teoria
Prima di spiegarli in dettaglio, ricapitoliamo la teoria. Come ho già detto in precedenza, le due differenze più importanti tra blockchain e database centralizzati possono essere caratterizzate come segue:
Disintermediazione.Le blockchain consentono a più parti, che non si fidano completamente l'una dell'altra, di condividere in modo sicuro e diretto un unico database, senza la necessità di un intermediario di fiducia.
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 traspare sempre più informazioni di un database centralizzato).
In altre parole, le blockchain sono ideali per database condivisi in cui ogni utente è in grado di leggere tutto, ma nessun singolo utente controlla chi può scrivere 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 tale entità.
Per riassumere in ONE frase: le blockchain rappresentano un compromesso in cui la disintermediazione viene ottenuta a discapito della riservatezza.
Nell'esaminare i quattro tipi di casi d'uso di seguito, torneremo ripetutamente su questo compromesso CORE , spiegando perché, in ogni caso, il vantaggio della disintermediazione supera il costo della ridotta riservatezza.
Sistemi finanziari leggeri
Cominciamo con la classe di applicazioni blockchain che ci saranno più familiari, in cui un gruppo di entità desidera creare un sistema finanziario. All'interno di questo sistema, ONE o più asset scarsi vengono transati e scambiati tra tali entità.
Affinché un asset rimanga scarso, devono essere risolti due problemi correlati. Innanzitutto, dobbiamo garantire che la stessa unità dell'asset non possa essere inviata in più di ONE posto (una "doppia spesa"). In secondo luogo, deve essere impossibile per chiunque creare nuove unità dell'asset per capriccio ("contraffazione"). Qualsiasi entità che potesse fare una di queste cose potrebbe rubare valore illimitato dal sistema.
Una soluzione comune a questi problemi sono i token fisici, come monete metalliche o carta stampata in modo sicuro. Questi token risolvono in modo banale il problema della doppia spesa, perché le regole della fisica impediscono (letteralmente) che ONE token si trovi in due posti contemporaneamente.
Il problema della contraffazione viene risolto rendendo il token estremamente difficile da produrre. Tuttavia, i token fisici soffrono di diverse carenze che possono renderli poco pratici:
- In quanto asset al portatore puro, i token fisici possono essere rubati senza possibilità di ricorso
- È difficile e costoso creare token fisici che T possano essere falsificati
- Sono lenti e costosi da trasportare in grandi numeri o su lunghe distanze.
Queste carenze possono essere evitate abbandonando i token fisici e ridefinendo la proprietà degli asset in termini di un registro gestito da un intermediario fidato. In passato, questi registri erano basati su registrazioni cartacee e oggi tendono a funzionare su database regolari. In entrambi i casi, l'intermediario attua un trasferimento di proprietà modificando il contenuto del registro, in risposta a una Request autenticata. A differenza del regolamento con token fisici, le transazioni discutibili possono essere rapidamente e facilmente annullate.
Quindi qual è il problema con i registri? In poche parole, la concentrazione del controllo.
Concentrando così tanto potere in ONE posto, creiamo una sfida significativa per la sicurezza, sia in termini tecnici che Human . Se qualcuno esterno può hackerare il database, può modificare il registro a piacimento, rubando fondi o distruggendone completamente il contenuto.
Ancora peggio, qualcuno dall'interno potrebbe corrompere il registro, e questo tipo di attacco è difficile da rilevare o provare. Di conseguenza, ovunque abbiamo un registro centralizzato, dobbiamo investire molto tempo e denaro in meccanismi per mantenere l'integrità di quel registro. E in molti casi, richiediamo una verifica continua utilizzando la riconciliazione basata su batch tra il registro centrale e quelli di ciascuna delle parti che effettuano transazioni.
Entra in gioco la blockchain (o "libro mastro condiviso"). Questa fornisce i vantaggi dei registri senza soffrire del problema della concentrazione.
Invece, ogni entità gestisce un "nodo" che detiene una copia del registro e mantiene il pieno controllo sui propri asset, che sono protetti da chiavi private. Le transazioni si propagano tra i nodi in modalità 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 il contenuto del registro. Di conseguenza, un sistema finanziario digitale può essere implementato più rapidamente ed economicamente, con l'ulteriore vantaggio della riconciliazione automatica in tempo reale.
Quindi qual è lo svantaggio? Come discusso in precedenza, tutti i partecipanti a un registro condiviso vedono tutte le transazioni in corso, rendendolo inutilizzabile in situazioni in cui è richiesta la riservatezza. Invece, le blockchain sono adatte a quelli che chiamo sistemi finanziari leggeri, 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 meno un problema: anche se i partecipanti prestano molta attenzione a ciò che fanno gli altri, T Imparare molto di valore. Ed è proprio perché la posta in gioco è bassa che preferiamo evitare la seccatura e il costo di istituire un intermediario.
Ecco alcuni esempi evidenti di sistemi finanziari leggeri: crowdfunding, carte regalo, punti fedeltà e valute locali, soprattutto nei casi in cui i beni sono riscattabili in più di ONE luogo.
Ma stiamo anche assistendo a casi d'uso nel settore Finanza mainstream, come il trading peer-to-peer tra gestori patrimoniali che non sono in competizione diretta. Le blockchain vengono persino testate come sistemi di contabilità interna, in grandi organizzazioni in cui ogni reparto o sede deve mantenere il controllo dei propri fondi.
In tutti questi casi, il costo inferiore e la minore frizione delle blockchain offrono un vantaggio immediato, mentre la perdita di riservatezza non è un problema.
Tracciamento 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 attraverso uncatena di fornitura, come beni di lusso, prodotti farmaceutici, cosmetici ed elettronica. E allo stesso modo, elementi critici di documentazione come polizze di carico o lettere di credito.
Nelle catene di fornitura che si estendono nel tempo e nello spazio, tutti questi articoli sono soggetti a contraffazione e furto.
Il problema può essere affrontato utilizzando le blockchain nel modo seguente: quando viene creato l'oggetto di alto valore, un token digitale corrispondente viene emesso da un'entità attendibile, che agisce per autenticare il suo punto di origine. Quindi, ogni volta che l'oggetto fisico cambia proprietario, il token digitale viene spostato in parallelo, in modo che la catena di custodia del mondo reale sia rispecchiata con precisione da una catena di transazioni sulla blockchain.
Se vogliamo, il token funziona come un "certificato di autenticità" virtuale, molto più difficile da rubare o falsificare di 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 le polizze di carico, possiamo fare a meno dell'articolo fisico del tutto.
Sebbene tutto ciò abbia senso, il lettore attento noterà che un database normale, gestito (ad esempio) dal produttore di un articolo, può svolgere lo stesso compito. Questo database memorizzerebbe un record del proprietario attuale di ogni articolo, accettando transazioni firmate che rappresentano ogni cambio di proprietà e rispondendo alle richieste in arrivo relative allo stato attuale delle cose.
Quindi perché usare una blockchain invece? La risposta è che, per questo tipo di applicazione, c'è un vantaggio nella fiducia distribuita.
Indipendentemente da dove sia custodito un database centralizzato, ci saranno persone in quel luogo che hanno la capacità (e possono essere corrotte) di corromperne il contenuto, contrassegnando gli articoli falsificati o rubati come legittimi. Al contrario, se la provenienza è tracciata su una blockchain che appartiene collettivamente ai partecipanti di una supply chain, nessuna entità individuale 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 token (ad esempio per alcuni beni e la relativa polizza di carico) possono essere scambiati in modo sicuro e diretto, con uno scambio bidirezionale garantito al livello più basso della blockchain.
E per quanto riguarda il problema della riservatezza? L'idoneità delle blockchain per la provenienza della supply chain è un felice risultato del semplice schema di transazioni di questa applicazione. A differenza dei mercati finanziari, la maggior parte dei token si muove in una sola direzione, dall'origine all'endpoint, senza essere ripetutamente scambiati avanti e indietro tra i partecipanti alla blockchain.
Se i concorrenti effettuano raramente transazioni tra loro (ad esempio, tra produttori di giocattoli o tra rivenditori), non possono Imparare i rispettivi "indirizzi" blockchain e collegarli alle identità del mondo reale.
Inoltre, l'attività può essere facilmente suddivisa in più registri, ognuno dei quali rappresenta un diverso ordine o tipo di bene.
Tenuta dei registri interorganizzativi
Entrambi i casi d'uso precedenti si basano su asset tokenizzati, ovvero rappresentazioni on-chain di un bene di valore trasferito tra i partecipanti.
Tuttavia, esiste un secondo gruppo di casi d'uso della blockchain che non è correlato alle risorse. Invece, la blockchain agisce come un meccanismo per registrare e notarizzare collettivamente qualsiasi tipo di dato, il cui significato può essere finanziario o altro.
ONE esempio del genere è un audit trail di comunicazioni critiche tra due o più organizzazioni, ad esempio nei settori sanitario o legale. Nessuna organizzazione individuale del gruppo può essere ritenuta affidabile per la manutenzione di questo archivio di record, perché informazioni falsificate o eliminate danneggerebbero significativamente le altre. Tuttavia, è fondamentale che tutti concordino sul contenuto dell'archivio per prevenire controversie.
Per risolvere questo problema, abbiamo bisogno di un database condiviso in cui tutti i record siano scritti, con ogni record accompagnato da un timestamp e da una prova di origine. La soluzione standard sarebbe quella di creare un intermediario fidato, il cui ruolo è quello di raccogliere e archiviare i record centralmente.
Ma le blockchain offrono un approccio diverso. Danno alle organizzazioni un modo per gestire congiuntamente questo archivio, impedendo al contempo ai singoli partecipanti (o a piccoli gruppi di essi) di corromperlo.
ONE delle conversazioni più illuminanti che ho avuto negli ultimi due anni è stata con Michael Mainelli di Z/Yen. Per 20 anni, la sua azienda ha creato sistemi in cui più entità gestiscono collettivamente un audit trail digitale condiviso, utilizzando timestamping, firme digitali e uno schema di consenso round-robin.
Mentre spiegava i dettagli tecnici di questi sistemi, è diventato chiaro che si tratta di blockchain autorizzate sotto ogni aspetto. In altre parole, non c'è nulla di nuovo nell'usare una blockchain per la tenuta dei registri interorganizzativi, è solo che il mondo è finalmente diventato consapevole di questa possibilità.
Per quanto riguarda i dati effettivi memorizzati sulla blockchain, ci sono tre opzioni popolari:
Dati non crittografati.Può essere letto da ogni partecipante alla blockchain, garantendo la massima trasparenza collettiva e una risoluzione immediata in caso di controversia.
Dati crittografati.Questo può essere letto solo dai partecipanti con la chiave di decifratura appropriata. In caso di controversia, chiunque può rivelare questa chiave a un'autorità attendibile come un tribunale e utilizzare la blockchain per dimostrare che i dati originali sono stati aggiunti da una certa parte in un certo momento.
Dati sottoposti ad hash.Un "hash" agisce come un'impronta digitale compatta, che rappresenta un impegno verso un particolare pezzo di dati, mantenendoli nascosti. Dati alcuni dati, qualsiasi parte può facilmente confermare se corrispondono a un dato hash, ma dedurre i dati dal suo hash è computazionalmente impossibile. Solo l'hash viene inserito nella blockchain, con i dati originali archiviati off-chain dalle parti interessate, che possono rivelarli in caso di controversia.
Come accennato in precedenza, il prodotto Corda di R3CEV ha adottato questo terzo approccio, memorizzando hash su una blockchain per autenticare i contratti tra controparti, senza rivelarne il contenuto. Questo metodo può essere utilizzato sia per descrizioni di contratti leggibili dal computer, sia per file PDF contenenti documentazione cartacea.
Naturalmente, la riservatezza non è un problema per la tenuta 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 hash). In effetti, in alcuni casi una blockchain può aiutare a gestire l'accesso ai dati riservati off-chain, fornendo un record immutabile di richieste di accesso firmate digitalmente.
In ogni caso, il vantaggio diretto della disintermediazione è che non è necessario creare alcuna entità aggiuntiva di cui ci si possa fidare per la tenuta di questa documentazione.
Aggregazione multipartitica
Tecnicamente parlando, questa classe finale di casi d'uso è simile alla ONE, in quanto più parti scrivono dati su un record gestito collettivamente. Ma, 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. A un certo punto, si accorgono di condividere molti clienti, quindi stipulano un accordo di condivisione reciproca in cui si scambiano dati di verifica per evitare lavoro duplicato.
Tecnicamente, l'accordo è implementato utilizzando la replicazione standard 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. Ognuna delle cinque banche gestisce il proprio database master, insieme a quattro repliche di sola lettura delle altre. Con cinque master e 20 repliche, abbiamo 25 istanze di database in totale.
Sebbene fattibile, ciò richiederebbe molto tempo e risorse al reparto IT di ogni banca.
Facciamo un salto in avanti fino al punto in cui 20 banche condividono informazioni in questo modo, e stiamo guardando a 400 istanze di database in totale. Per 100 banche, raggiungiamo 10.000 istanze. In generale, se ogni parte condivide informazioni con tutte le altre, il numero totale di istanze di database cresce con il quadrato del numero di partecipanti. A un certo punto di questo processo, il sistema è destinato a crollare.
Quindi qual è la soluzione? ONE ovvia è che tutte le banche inviino i propri dati a un intermediario fidato, il cui compito è aggregare tali dati in un singolo database master. Ogni 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 è gestito direttamente dalle banche che lo utilizzano. Le blockchain portano anche il vantaggio aggiuntivo diridondanza E Rifacimentoper il sistema nel suo complesso.
È importante chiarire che una blockchain non agisce solo come un database distribuito comeCassandra O Ripensare DBA differenza di questi sistemi, ogni nodo blockchain applica una serie di regole che impediscono a ONE partecipante di modificare o eliminare i dati aggiunti da un altro.
In effetti, sembra esserci ancora un po' di confusione su questo: ONE 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, che si uniscono e si allontanano a piacimento, se concessi i permessi appropriati.
Sebbene io sia un po' scettico sulla tanto citata connessione tra blockchain e Internet of Things, penso che potrebbe essere qui che risiede una forte sinergia del genere. Ovviamente, ogni "cosa" sarebbe troppo piccola per archiviare una copia completa della blockchain in locale. Piuttosto, trasmetterebbe transazioni contenenti dati a una rete distribuita di nodi blockchain, che li raccoglierebbero tutti insieme per un ulteriore recupero e analisi.
Conclusione: Blockchain nella Finanza
Ho iniziato questo articolo mettendo in discussione il caso d'uso iniziale previsto per le blockchain nel settore Finanza , vale a dire la liquidazione in blocco di transazioni di pagamento e di scambio.
Sebbene io creda che questa conclusione stia diventando saggezza comune (con ONE notevole eccezione), ciò non significa che le blockchain non abbiano altre applicazioni in questo settore. Infatti, per ciascuna delle quattro classi di casi d'uso delineate sopra, vediamo chiare applicazioni per banche e altre istituzioni finanziarie. Rispettivamente, queste sono: piccoli circoli commerciali, provenienza per Finanza commerciale, notarizzazione di contratti bilaterali e aggregazione di dati AML/KYC.
La cosa fondamentale da capire è che, dal punto di vista architettonico, le nostre quattro classi di casi d'uso non sono specifiche della Finanza, ma sono ugualmente rilevanti per altri settori quali assicurazioni, sanità, distribuzione, produzione e IT.
In effetti, le blockchain private dovrebbero essere prese in considerazione in 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, con conseguenti notevoli risparmi in termini di problemi e costi.
Questo articolo è stato originariamente pubblicato suBlog MultiChained è stato ripubblicato qui con il permesso dell'autore.
Scrigno del tesoroimmagine tramite Shutterstock
Nota: Le opinioni espresse in questa rubrica sono quelle dell'autore e non riflettono necessariamente quelle di CoinDesk, Inc. o dei suoi proprietari e affiliati.