- 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
Il valore dei registri replicati e condivisi dai primi principi
In questo post, Richard G Brown sviluppa un argomento a favore dei registri condivisi replicati partendo dai principi fondamentali.
Le "valute digitali"T servono a spiegare perché i registri distribuiti sono importanti. In questo post, Richard Gendal Brown di IBM sviluppa un argomento a favore dei registri condivisi replicati partendo dai primi principi.
Si tratta di un "articolo didattico" rivolto a coloro, in particolare nel settore Finanza , che preferiscono che le spiegazioni delle nuove tecnologie siano basate sulla descrizione di un problema aziendale reale piuttosto che iniziare con la descrizione di una presunta soluzione.
Quindi, in questo articolo non troverete alcun riferimento alle valute digitali, perché a quanto pare T sono necessarie per argomentare a favore delle tecnologie di contabilità distribuita.
Inizieremo con i sistemi bancari
Inizia pensando aoggisistemi bancari. In quanto segue, uso un esempio di deposito e pagamenti bancari. Ma la stessa logica si applica ovunque si guardi, come sosterrò più avanti.
Immaginiamo un mondo con tre banche:Banca A,Banca B E Banca Ce due clienti,Cliente A E Cliente B. Ogni banca gestisce i propri sistemi IT che usa per KEEP traccia dei saldi. Questo è un mondo molto simile a quello odierno.
COSÌ Banca AI sistemi di registrano i saldi perBanca AI clienti di,Banca BI sistemi di registrano i saldi perBanca Bi clienti e così via.
Forse l'immagine LOOKS a questa:

Due osservazioni immediate saltano all'occhio:
- Per prima cosa, guardaBanche A E B.Banca AI sistemi di ’s registrano che gli sono dovuti 1 milione di sterline daBanca B. E Banca BI sistemi diAnche registrano questo fatto: registrano cheBanca B deve£1 milione aBanca A. Quindi le stesse informazioni vengono registrate due volte, da due sistemi sviluppati, mantenuti e gestiti in modo indipendente. E in altri domini, questa duplicazione è molto più grande e costosa, come discuteremo di seguito.
- In secondo luogo, guardaCliente A. Hanno dei soldi da pagareBanche A E Ce sono scoperti aBanca BIn altre parole,Banche A E Cdevo dei soldi aCliente AChi registra questo fatto?Banche A e C! Diamo per scontata questa situazione, ma sembra davvero strano cheCliente Adeve fidarsiEntrambiche la banca sarà buona per i soldiE che i registri della banca saranno accurati. Sembra un conflitto di interessi, se mai ce ne fosse ONE ...
Abbiamo quindi due fenomeni interessanti: i depositanti devono fidarsi che le loro banche siano brave a gestire i soldiEper rendere conto delle cose correttamente. E le banche stesse devono spendere un sacco di tempo e denaro per sviluppare sistemi che fanno tutti più o meno la stessa cosa, e poi spendere ancora più tempo e denaro per controllare conl'un l'altroper garantire che i loro sistemi concordino su fatti comuni.
Anche nel nostro semplice esempio, ci sono potenzialmente sette voci corrispondenti separate da verificare.

I "fatti" bancari vengono solitamente registrati da almeno due entità diverse ed è necessario un costoso processo di riconciliazione per garantire che la visione del mondo di ciascuna parte sia la stessa.
Non si tratta solo di depositi bancari. I Mercati dei titoli e dei derivati hanno lo stesso schema
Questa storia riguarda i depositi bancari. Maesattamente lo stessosi potrebbe raccontare una storia sui sistemi di titoli e sui sistemi derivati.
In effetti, in quest’ultimo caso, il problema potrebbe essere anche peggiore: non solo dobbiamo essere sicuri che tutti siano d’accordo su chi ha fatto quali accordi con chi, ma dobbiamo anche essere sicuri che i loro sistemi concordino sugli obblighi risultanti che ne derivano – devono anche concordare sullogica aziendale.
Pensate a quanti sistemi quasi identici esistono nel panorama finanziario, ognuno ONE funziona in modo leggermente diverso e produce risultati leggermente diversi che devono essere esaminati e risolti. È estremamente costoso.
Torniamo alla storia bancaria
Ma per ora concentriamoci sull’esempio bancario.
Si può fare qualcosa di veramente interessante con i cinque registri con cui abbiamo lavorato. Si possono scrivere in un modo diverso, con tutte le stesse informazioni memorizzate in unsepararetabella, anziché distribuita su cinque tabelle diverse:

I cinque registri separati sulla sinistra possono essere scritti, esattamente in modo equivalente, come la singola tabella sulla destra, e viceversa. È possibile derivarne ONE dall'altro. L'unica differenza è che la tabella sulla destra ha una colonna in più, così possiamo registrare sia l'emittente che il detentore di un credito.
In altre parole, invece di avere una visione parziale del mondo detenuta da ogni banca, potremmo avere una singola tabella che registraqualunque cosa e ottenere lo stesso risultato.
Perché allora non avere un unico registro bancario mondiale?
Ciò solleva una domanda interessante. Se è così costoso e complicato per ogni banca gestire il proprio sistema che contiene la propria visione ristretta del mondo, e poi dover controllare che corrisponda agli altri sistemi in cui i fatti si sovrappongono, perché non pagare semplicemente qualcuno per gestirne uno?separareregistro che tutti concordano sarà autorevole?
Dopotutto, come abbiamo dimostrato sopra, qualsiasi banca che lo volesse potrebbe facilmente ricavare la propria visione del mondo da questa mega-tabella, in modo del tutto banale.
Naturalmente, dovremmo riflettere su come mediare l’accesso al registro – chi è autorizzato a osservare o aggiornare quali registrazioni – ma sappiamo come farlo… e non è un problema impossibile.
Sei arrabbiato?
Ora, è allettante dire che una cosa del genere sarebbe folle: immaginate quanto potente sarebbe l'azienda checorsoun tale sistema. E immaginate le implicazioni catastrofiche per il mondo se ci fosse un'interruzione del sistema!
Forse il sistema costoso, soggetto a errori, ma fondamentalmente decentralizzato e robusto (antifragile?) che abbiamo oggi è un prezzo che vale la pena pagare.
Ma sorge spontanea una domanda interessante: e se esistesse un modo per ottenere i vantaggi di un sistema condiviso a livello globale senza doversi confrontare con la difficile questione politica di come controllare un operatore onnipotente o di come gestire il rischio di un'interruzione di un'infrastruttura così importante e centrale?
Forse possiamo riuscirci…
Il registro replicato e condiviso
Ricorda cosa abbiamo ottenuto nel diagramma sopra: abbiamo creato una singola tabella che potrebbe descrivere Tuttosaldi bancari e che era intrinsecamente condiviso: diversi attori avevano autorizzazioni diverse per aggiornare diverse parti di esso.
Ma la preoccupazione nella sezione precedente era che un registro globale condiviso sarebbe stato controllato da una singola entità potente e che questo sistema centralizzato avrebbe potuto rappresentare un rischio sistemico. Quindi possiamo apportare due modifiche al modello?
- Primo, perché non replicare il libro mastroin maniera massiccia. Quindi, anziché ONE copia, fatene tante. Forse ONE copia in ogni banca. Quindi ora T c'è un singolo punto di errore. Dovremmo preoccuparci di Come queste copie sono mantenute sincronizzate, ovviamente, quindi T si tratta di una ' WIN' inequivocabile, ma avere copie in ogni banca potrebbe anche rendere l'integrazione con l'infrastruttura esistente un po' più semplice. Forse questo aiuterebbe anche a facilitare l'adozione.
- In secondo luogo, perché non far sì che coloro che partecipano al sistema, magari solo le banche o magari anche i loro clienti, siano anche congiuntamente responsabili del suo mantenimento e della sua protezione. Dopotutto, sappiamo chi sono tutti gli altri in questo mondo, quindi sappiamo chi punire se imbrogliano. Quindi sostituiamo una singola entità potente con un modello in cuitutticontribuisce alla sicurezza del sistema.
Se così fosse, forse l'immagine apparirebbe così:

Se una singola copia del registro globale condiviso non è desiderabile o rischiosa, allorareplicandoloa tutti i partecipanti potrebbe dare il meglio di entrambi i mondi. Ora il problema diventa ONE di mantenere automaticamente sincronizzati i sistemi piuttosto che riconciliare e gestire manualmente le pause.
L'immagine qui sopra LOOKS superficialmente simile a ONE ho disegnato all'inizio dell'articolo. Ma c'è una differenza di fondamentale importanza. In Questomodello, tutti i partecipanti hanno una copia del libro mastro ma hanno solo il diritto di modificare le voci che li riguardano. Quindi è siareplicato E condiviso.
Ed è per questo che chiamo questo concetto "'replicato, registro condiviso'Penso che questa formulazione sia più adatta a evocare il modello mentale corretto rispetto, ad esempio, a "registro distribuito".
E a seconda che si vogliano modellare saldi, altre attività o ancheaccorditra le parti, ci sono startup che lavorano a un progetto. Ho scritto un pezzo l'anno scorso cheha tentato di dare un senso ai vari attori là fuori– e da allora ne sono emersi molti altri.
'Contratti intelligenti'
Vale la pena prestare particolare attenzione all'idea di aggiungerelogica aziendale a questo concetto: in modo che i "fatti" registrati T riguardino solo chi possiede cosa, ma accordi effettivi tra le parti.
Ciò apre l'intrigante possibilità dei "contratti intelligenti": un mondo in cui le controparti dei derivati concordano che un pezzo condiviso dicodicerappresenta l'accordo che hanno stipulato tra loro e lo eseguono sul registro condiviso e replicato, eliminando forse completamente la necessità di creare, mantenere, gestire e riconciliare le proprie piattaforme derivate proprietarie?
Forse addirittura consentendo al codice di prendere in custodia le attività presenti nel registro, per gestire automaticamente i flussi di cassa e i margini?
Domande in sospeso
Vorrei sottolineare che questo approccio solleva molte questioni tecniche: non è un’idea del tutto buona.
Ad esempio, sappiamo che la Tecnologie di replicazione sottostante funziona come descritto? In tutti gli scenari di minaccia plausibili? Come possiamo essere sicuri che ONE banca (o un cliente) T possa vedere (o modificare) le informazioni di un altro? Quanti dati conterrebbe un sistema del genere? Sarebbe scalabile? ÈVeramenteè una buona idea modellare gli accordi legali in codice piuttosto che in inglese?
Conclusione
Sembra che vi siano molteplici esempi di sistemi duplicati in modo costoso in molteplici aree del sistema bancario.
L'idea di uncondivisoil registro promette bene, conreplicazionedai partecipanti come meccanismo per ridurre il rischio e mutualizzare il suo funzionamento. Ma se questa argomentazione sia valida in pratica deve essere testata. Quindi mi aspetto di vedere sempre più sperimentazioni da parte di banche e altri nei prossimi mesi e anni.
Nota dell'autore: Per evitare dubbi, nel pezzo sopra, eronon parlando di Bitcoin – questo post riguarda il dominio che a volte chiamo il mondo non-simile a Bitcoin, come definito in questo post.
Questo post è apparso originariamente suIl blog di RichardÈ stato ripubblicato qui con autorizzazione.
Immagine del registrotramite Shutterstock
Nota: Las opiniones expresadas en esta columna son las del autor y no necesariamente reflejan las de CoinDesk, Inc. o sus propietarios y afiliados.
Richard Brown
Richard Gendal Brown è il direttore Tecnologie di R3. In precedenza, è stato Executive Architect per l'innovazione del settore bancario e Mercati finanziari presso IBM UK.
