Fire ekte blockchain-brukssaker

Hvor delte hovedbøker tilføyer reell verdi i bedriftens IT

Nesten et år etter første utgivelse multikate, vi har lært enormt mye om hvordan blokkjeder, i en privat og ikke-kryptovaluta forstand, kan og ikke kan brukes på virkelige problemer. Tillat meg å dele det vi vet så langt.

Til å begynne med virker den første ideen som vi (og mange andre) startet med å være feil. Denne ideen, inspirert av bitcoin direkte, var at private blokkjeder (eller "delte hovedbøker") kunne brukes til å direkte gjøre opp flertallet av betalings- og vekslingstransaksjoner i finanssektoren, ved hjelp av on-chain tokens for å representere kontanter, aksjer, obligasjoner og mer.

Dette er perfekt brukbart på et teknisk nivå, så hva er problemet? I et ord, konfidensialitet. Hvis flere institusjoner bruker en delt reskontro, så ser hver institusjon hver transaksjon på den hovedboken, selv om de ikke umiddelbart kjenner til den virkelige identiteten til de involverte partene. Dette viser seg å være et stort spørsmål, både når det gjelder regulering og den kommersielle realiteten i konkurranse mellom banker. Mens ulike strategier er tilgjengelige eller under utvikling for å avhjelpe dette problemet, kan ingen matche enkelheten og effektiviteten til en sentralisert database som administreres av en pålitelig mellommann, som opprettholder full kontroll over hvem som kan se hva. For øyeblikket ser det ut til at store finansinstitusjoner foretrekker å holde de fleste transaksjoner skjult i disse mellomliggende databasene, til tross for kostnadene det medfører.

Jeg baserer denne konklusjonen ikke bare på vår egen erfaring, men også på retningen fra flere fremtredende nyetablerere som hadde som opprinnelig mål å utvikle delte hovedbøker for banker. For eksempel jobber både R3CEV og Digital Asset nå med "språk for kontraktbeskrivelse", i Corda og DAML henholdsvis (tidligere eksempler inkluderer MLFi og Ricardian-kontrakter). Disse språkene tillater at vilkårene for en kompleks finansiell kontrakt blir representert formelt og utvetydig i et datamaskinnelig lesbart format, uten å mangler av generell beregning av Ethereum-stil. I stedet spiller blockchain bare en støttende rolle, lagring eller notarisering av kontrakter i kryptert form, og utføring av noen grunnleggende duplikatdeteksjon. Den faktiske gjennomføringen av kontrakten foregår ikke på blockchain - det utføres bare av kontraktsmotpartene, med sannsynlig tillegg av revisorer og regulatorer.

På kort sikt er dette sannsynligvis det beste som kan gjøres, men hvor etterlater det de bredere ambisjonene om tillatte blokkjeder? Er det andre applikasjoner som de kan utgjøre en mer viktig del av puslespillet for?

Dette spørsmålet kan tilnærmes både teoretisk og empirisk. Teoretisk sett ved å fokusere på nøkkelforskjellene mellom blokkjeder og tradisjonelle databaser, og hvordan disse informerer om mulige brukssaker. Og i vårt tilfelle, empirisk, ved å kategorisere de virkelige løsningene som bygges på MultiChain i dag. Ikke overraskende, uansett om vi fokuserer på teori eller praksis, oppstår de samme brukssakene:

• Lette økonomiske systemer.
• Herkomstsporing.
• Interorganisatorisk journalføring.
• Fleraggregasjon.

Før vi forklarer disse i detalj, la oss oppsummere teorien. Som jeg har gjort diskutert før, kan de to viktigste forskjellene mellom blokkeringer og sentraliserte databaser karakteriseres som følger:

1. disintermediation. Blokkjeder gjør det mulig for flere parter som ikke helt stoler på hverandre for å trygt og direkte dele en enkelt database uten å kreve en klarert formidler.
2. Konfidensialitet: Alle deltakerne i en blockchain ser alle transaksjonene som skjer. (Selv om vi bruker pseudonyme adresser og avansert kryptografi for å skjule noen aspekter av disse transaksjonene, vil en blockchain alltid lekke mer informasjon enn en sentralisert database.)

Med andre ord, blokkeringer er ideelle for delte databaser der hver bruker er i stand til lese alt, men ingen enkelt bruker kontrollerer hvem som kan skrive hva. I tradisjonelle databaser utøver en enhet derimot kontroll over alle lese- og skriveoperasjoner, mens andre brukere er helt utsatt for den enhetens innfall. For å oppsummere det i en setning:

Blockchains representerer en avveining der disintermediation oppnås på bekostning av konfidensialitet.

Når vi undersøker de fire brukssakene nedenfor, kommer vi gjentatte ganger tilbake til denne kjerneavveiningen og forklarer hvorfor fordelene ved disintermediation i hvert tilfelle oppveier kostnadene ved redusert konfidensialitet.

Lette økonomiske systemer

La oss starte med den klassen av blockchain-applikasjoner som vil være mest kjent, der en gruppe enheter ønsker å opprette et finansielt system. Innenfor dette systemet blir en eller flere knappe eiendeler omgjort og utvekslet mellom disse enhetene.

I rekkefølge for noen for å forbli knappe, må to relaterte problemer løses. Først må vi sørge for at samme enhet av eiendelen ikke kan sendes til mer enn ett sted (et "dobbeltforbruk"). For det andre må det være umulig for noen å lage nye enheter av eiendelen på et innfall ("forfalskning"). Enhver enhet som kan gjøre en av disse tingene, kan stjele ubegrenset verdi fra systemet.

En vanlig løsning på disse problemene er fysiske symboler, for eksempel metallmynter eller trykt papir. Disse tokens løser trivielt problemet med dobbeltbruk, fordi fysikkens regler (bokstavelig talt) forhindrer et token i å være på to steder samtidig. Problemet med forfalskning løses ved å gjøre symbolet ekstremt vanskelig å produsere. Likevel lider fysiske tokens av flere mangler som kan gjøre dem upraktiske:

• Som rene bæreraktiver kan fysiske tokens stjeles uten spor eller regress.
• De er sakte og kostbare å bevege seg i stort antall eller over lange avstander.
• Det er vanskelig og dyrt å lage fysiske tokens som ikke kan smides.

Disse manglene kan unngås ved å legge igjen fysiske tokens og omdefinere eiendoms eierskap i form av en reskontro som forvaltes av en pålitelig mellommann. Tidligere var disse hovedbokene basert på papirregistreringer, og i dag har de en tendens til å kjøre på vanlige databaser. Uansett vedtar mellommannen en overføring av eierskap ved å endre hovedbokens innhold, som svar på en godkjent forespørsel. I motsetning til oppgjør med fysiske tokens, kan tvilsomme transaksjoner raskt og enkelt reverseres.

Så hva er problemet med hovedbøker? I et nøtteskall, konsentrasjon av kontroll. Ved å sette så mye strøm på ett sted, skaper vi en betydelig sikkerhetsutfordring, både teknisk og menneskelig. Hvis noen eksterne kan hacke seg inn i databasen, kan de endre hovedboken etter eget ønske, stjele andres midler eller ødelegge innholdet fullstendig. Enda verre, noen på innsiden kan ødelegge hovedboken, og denne typen angrep er vanskelig å oppdage eller bevise. Som et resultat må vi, uansett hvor vi har en sentralisert hovedbok, investere betydelig tid og penger i mekanismer for å opprettholde hovedbokens integritet. Og i mange tilfeller krever vi løpende verifisering ved hjelp av batchbasert avstemming mellom hovedboken og de av hver av de transaksjonsparter.

Skriv inn blockchain (eller “delt reskontro”). Dette gir fordelene med ledgers uten å lide av konsentrasjonsproblemet. I stedet kjører hver enhet en "node" med en kopi av hovedboken og opprettholder full kontroll over sine egne eiendeler, som er beskyttet av private nøkler. Transaksjoner forplanter seg mellom noder på en peer-to-peer-måte, med blockchain som sørger for at konsensus opprettholdes. Denne arkitekturen etterlater ikke noe sentralt angrepspunkt gjennom hvilket en hacker eller insider kan ødelegge hovedbokens innhold. Som et resultat kan et digitalt finanssystem implementeres raskere og billigere, med den ekstra fordelen av automatisk avstemming i sanntid.

Så hva er ulempen? Som diskutert tidligere, ser alle deltakerne i en delt hovedbok alle transaksjonene som skjer, noe som gjør den ubrukelig i situasjoner der det kreves konfidensialitet. I stedet passer blokkeringer til det jeg kaller lettvekt finansielle systemer, nemlig de der den økonomiske innsatsen eller antall deltakere er relativt lavt. I disse tilfellene pleier konfidensialitet å være mindre av et problem - selv om deltakerne følger nøye med på hva hverandre gjør, vil de ikke lære mye av verdien. Og det er nettopp fordi innsatsen er lav for at vi foretrekker å unngå bryet og kostnadene ved å sette opp en mellommann.

Noen åpenbare eksempler på lette økonomiske systemer inkluderer: crowdfunding, gavekort, lojalitetspoeng og lokale valutaer - spesielt i tilfeller der eiendeler kan innløses på mer enn ett sted. Men vi ser også brukstilfeller i den vanlige finanssektoren, for eksempel peer-to-peer-handel mellom kapitalforvaltere som ikke er i direkte konkurranse. Blokkjeder blir til og med testet som intern regnskapssystemer, i store organisasjoner der hver avdeling eller lokasjon må ha kontroll over midlene sine. I alle disse tilfellene gir lavere kostnader og friksjon av blokkjeder en umiddelbar fordel, mens tap av konfidensialitet ikke er noe som bekymrer deg.

Herkomstsporing

Her er en annen brukssak som vi gjentatte ganger hører fra MultiChains brukere: sporing av opprinnelse og bevegelse av høyverdige varer over en forsyningskjede, for eksempel luksusvarer, legemidler, kosmetikk og elektronikk. Og like viktige dokumenter som dokumentasjon eller kredittbrev. I forsyningskjeder som strekker seg over tid og avstand, lider alle disse artiklene av forfalskning og tyveri.

Problemet kan løses ved hjelp av blokkjeder på følgende måte: når elementet med høy verdi opprettes, utstedes et tilsvarende digitalt token av en pålitelig enhet som fungerer for å autentisere opprinnelsesstedet. Hver gang det fysiske elementet skifter hender, flyttes det digitale token parallelt, slik at den virkelige verdikjeden reflekteres nøyaktig av en kjede av transaksjoner på blockchain.

Hvis du vil, fungerer tokenet som et virtuelt "ekthetssertifikat", som er mye vanskeligere å stjele eller smi enn et stykke papir. Ved mottak av det digitale tokenet kan den endelige mottakeren av den fysiske varen, enten en bank, distributør, forhandler eller kunde, verifisere forvaringskjeden helt tilbake til opprinnelsesstedet. Faktisk, i tilfelle dokumentasjon som konneksjoner, kan vi fjerne det fysiske elementet helt.

Selv om alt dette er fornuftig, vil den skarpe leseren legge merke til at en vanlig database, administrert (si) av produsenten av en vare, kan utføre den samme oppgaven. Denne databasen vil lagre en oversikt over den nåværende eieren av hvert element, akseptere signerte transaksjoner som representerer hvert eierskifte, og svare på innkommende forespørsler angående gjeldende status.

Så hvorfor bruke en blockchain i stedet? Svaret er at for denne typen applikasjoner er det en fordel med distribuert tillit. Uansett hvor en sentralisert database holdes, vil det være mennesker på det stedet som har muligheten (og kan bestikkes) til å ødelegge innholdet, og markere forfalskede eller stjålne gjenstander som legitime. Derimot, hvis herkomst spores på en blockchain som tilhører deltakerne i en forsyningskjede, kan ingen enkeltpersoner eller små grupper av enheter ødelegge forvaringskjeden, og sluttbrukere kan ha større tillit til svarene de får. Som en bonus kan forskjellige tokens (for eksempel for noen varer og tilsvarende fraktbrev) byttes trygt og direkte, med en toveis bytte garantert på laveste blockchain-nivå.

Hva med taushetsplikt? Blokkjeders egnethet for opprinnelse i forsyningskjeden er et godt resultat av applikasjonens enkle mønster av transaksjoner. I motsetning til finansielle markedsplasser beveger de fleste tokens i en retning, fra opprinnelse til sluttpunkt, uten å bli gjentatt frem og tilbake mellom blockchain-deltakerne. Hvis konkurrenter sjelden handler med hverandre (f.eks. Leketøyprodusent til leketøyprodusent eller forhandler til forhandler), kan de ikke lære hverandres "blockchain" -adresser og koble dem til virkelige identiteter. Videre kan aktiviteten enkelt deles inn i flere hovedbøker, som hver representerer en annen rekkefølge eller type goder.

Interorganisatorisk journalføring

Begge de tidligere brukssakene er basert på tokeniserte eiendeler, dvs. on-chain-representasjoner av en verdipost overført mellom deltakerne. Imidlertid er det en andre gruppe av blockchain brukstilfeller som ikke er relatert til eiendeler. I stedet fungerer kjeden som en mekanisme for samlet opptak og notarisering noen type data, hvis betydning kan være økonomisk eller på annen måte.

Et slikt eksempel er et revisjonsspor av kritisk kommunikasjon mellom to eller flere organisasjoner, for eksempel innen helse- eller juridisk sektor. Ingen individuelle organisasjoner i gruppen kan stole på å opprettholde dette arkivet med poster, fordi forfalsket eller slettet informasjon vil skade de andre betydelig. Det er likevel viktig at alle er enige om arkivets innhold, for å forhindre tvister.

For å løse dette problemet trenger vi en delt database der alle postene er skrevet, med hver post ledsaget av en tidsstempel og opprinnelsesbevis. Standardløsningen vil være å opprette en pålitelig mellommann, hvis rolle er å samle og lagre postene sentralt. Men blokkjeder tilbyr en annen tilnærming, noe som gir organisasjonene en måte å administrere dette arkivet i fellesskap, samtidig som individuelle deltakere (eller små grupper derav) forhindres i å ødelegge det.

En av de mest opplysende samtalene jeg har hatt de siste to årene var med Michael Mainelli of Z / Yen. I 20 år har selskapet hans bygget systemer der flere enheter samlet administrerer en delt digital revisjonsspor ved hjelp av tidsstempling, digitale signaturer og en round robin-konsensusordning. Da han forklarte de tekniske detaljene i disse systemene, ble det klart at de er tillatte blokkjeder i alle henseender. Det er med andre ord ikke noe nytt ved å bruke en blockchain for interorganisatorisk journalføring - det er bare at verden endelig har blitt klar over muligheten.

Når det gjelder de faktiske dataene som er lagret på blockchain, er det tre populære alternativer:

• Ukryptert data. Dette kan leses av alle deltakere i blockchain, og gir full kollektiv åpenhet og umiddelbar løsning i tilfelle en tvist.
• Krypterte data. Dette kan bare leses av deltakere med riktig dekrypteringsnøkkel. I tilfelle en tvist kan hvem som helst avsløre denne nøkkelen til en pålitelig myndighet som en domstol, og bruke blockchain for å bevise at de opprinnelige dataene ble lagt til av en bestemt part på et bestemt tidspunkt.
• Hashed data. En “hash”Fungerer som et kompakt digitalt fingeravtrykk, som representerer en forpliktelse til et bestemt stykke data, mens dataene holdes skjult. Gitt noen data, kan enhver part enkelt bekrefte om den samsvarer med en gitt hash, men utledende data fra dens hash er beregningsmessig umulig. Bare hasjen plasseres på blockchain, med de originale dataene lagret utenfor kjeden av interesserte parter, som kan avsløre det i tilfelle en tvist.

Som nevnt tidligere har R3CEVs Corda-produkt tatt denne tredje tilnærmingen, lagring av hash på en blockchain for å notarisere kontrakter mellom motparter, uten å avsløre innholdet. Denne metoden kan brukes både for datamaskinlesbare kontraktsbeskrivelser, samt PDF-filer som inneholder papirdokumentasjon.

Naturligvis er konfidensialitet ikke et spørsmål for interorganisatorisk journalføring, fordi hele formålet er å lage et delt arkiv som alle deltakerne kan se (selv om noen data er kryptert eller hash). I noen tilfeller kan faktisk en blockchain hjelpe deg med å administrere tilgang til konfidensielle off-chain-data ved å gi en uforanderlig oversikt over digitalt signerte tilgangsforespørsler. Uansett er den direkte fordelen med disintermediation at ingen ekstra enheter må opprettes og stole på for å opprettholde denne posten.

Fleraggregasjon

Teknisk sett er denne endelige brukssaken lik den forrige, ved at flere parter skriver data til en samlet administrert post. Men i dette tilfellet er motivasjonen annerledes - å overvinne den infrastrukturelle vanskeligheten med å kombinere informasjon fra et stort antall separate kilder.

Tenk deg to banker med interne databaser med bekreftelse av kundeidentitet. På et tidspunkt merker de at de deler mange kunder, så de legger inn en gjensidig delingsordning der de utveksler bekreftelsesdata for å unngå duplisert arbeid. Teknisk sett er avtalen implementert ved bruk av standard replikering av master-slave-data, der hver bank har en skrivebeskyttet kopi av den andres database, og kjører spørsmål parallelt mot sin egen database og replikaen. Så langt så bra.

Tenk deg at disse to bankene inviterer tre andre til å delta i denne kretsen med deling. Hver av de 5 bankene driver sin egen hoveddatabase, sammen med 4 skrivebeskyttede kopier av de andre. Med 5 mestere og 20 kopier har vi totalt 25 databaseforekomster. Selv om det er gjennomførbart, bruker dette merkbar tid og ressurser i hver banks IT-avdeling.

Spol frem til det punktet hvor 20 banker deler informasjon på denne måten, og vi ser på totalt 400 databaseinstanser. For 100 banker når vi 10,000 XNUMX tilfeller. Generelt sett, hvis hvert parti deler informasjon med hverandre, vokser det totale antallet databaseforekomster med kvadratet av antall deltakere. På et eller annet tidspunkt i denne prosessen er systemet nødt til å bryte sammen.

Så hva er løsningen? Et åpenbart alternativ er at alle bankene sender dataene sine til en pålitelig mellommann, hvis jobb er å samle dataene i en enkelt hoveddatabase. Hver bank kunne da søke på denne databasen eksternt, eller kjøre en lokal skrivebeskyttet replika innenfor sine egne fire vegger. Selv om det ikke er noe galt med denne tilnærmingen, tilbyr blokkjeder et billigere alternativ der den delte databasen drives av bankene som bruker den. Blockchains gir også den ekstra fordelen med overflødighet og failover for systemet som helhet.

Det er viktig å avklare at en blockchain ikke fungerer som en distribuert database som Cassandra or Tenk om på DB. I motsetning til disse systemene håndhever hver blockchain-node et sett med regler som forhindrer en deltaker i å endre eller slette dataene som er lagt til av en annen. Faktisk ser det fremdeles ut til å være noen forvirring om dette - en nylig utgitt blockchain-plattform kan bli ødelagt av en enkelt feiloppførende node. Under alle omstendigheter vil en god plattform også gjøre det enkelt å administrere nettverk med tusenvis av noder, bli med og forlate etter ønske, hvis de får de rette tillatelsene.

Selv om jeg er litt skeptisk til den ofte siterte forbindelsen mellom blokkjeder og Tingenes InternettJeg tror dette kan være der en sterk slik synergi ligger. Selvfølgelig ville hver "ting" være for liten til å lagre en full kopi av blockchain lokalt. Snarere vil det overføre databærende transaksjoner til et distribuert nettverk av blockchain-noder, som vil samle det hele for videre henting og analyse.

Konklusjon: Blockchains in Finance

Jeg startet dette stykket med å stille spørsmål ved den opprinnelige brukssaken som var tenkt for blokkjeder i finanssektoren, nemlig bulkoppgjøret av betalings- og vekslingstransaksjoner. Selv om jeg tror denne konklusjonen blir vanlig visdom (med en bemerkelsesverdig unntak), betyr det ikke at blokkjeder ikke har noen andre applikasjoner i denne bransjen. Faktisk ser vi klare applikasjoner for banker og andre finansinstitusjoner for hver av de fire bruksklassene som er skissert ovenfor. Disse er henholdsvis: små handelssirkler, herkomst for handelsfinansiering, bilateral kontraktsnotering og aggregering av AML / KYC-data.

Nøkkelen til å forstå er at våre fire bruksområder ikke er det spesifikk å finansiere, og er like relevante i andre sektorer som forsikring, helsetjenester, distribusjon, produksjon og IT. Faktisk bør private blokkjeder vurderes i enhver situasjon der to eller flere organisasjoner trenger et delt syn på virkeligheten, og det synet ikke stammer fra en enkelt kilde. I disse tilfellene tilbyr blokkjeder et alternativ til behovet for en pålitelig mellommann, noe som fører til betydelige besparelser i problemer og kostnader.

Legg inn kommentarer på Linkedin.

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