Levering versus betaling på en blockchain

Hvordan blokkjeder kan løse det eldste problemet i boken

Handel mellom mennesker er like gammelt som menneskeheten selv. Det begynte i det øyeblikket hulemannen Ogg sa til hulemannen Ugg: "me give you rock, you give me bær". Men handel fører med seg et grunnleggende problem: det krever stole på. Hva stopper Ogg fra å bruke steinen til å slå Ugg, og deretter gripe begge steinene og bær før du løper bort? Hvordan oversetter vi en verbal utvekslingsavtale til en håndhevingsmekanisme som sikrer at begge sider holder ord?

For å ta et moderne eksempel, solgte jeg for noen år siden en bil på bruktmarkedet. Jeg fant en kjøper over Internett, vi møttes personlig, han fikk testet bilen og vi ble enige om en pris. Så han dro til banken sin for å få en kassesjekk, som faktisk er kontanter i en mer kompakt form. Vi gikk sammen til et postkontor, hvor jeg kan signere og sende inn et offisielt myndighetsskjema som overfører juridisk eierskap til bilen.

Så der står vi ved postvinduet og kommer til en vanskelig blindvei. Sjekken er fortsatt i lommen hans, og jeg holder det signerte skjemaet. Vi møttes for noen timer siden og har ingen grunn til å stole på hverandre. Leverer jeg inn skjemaet først og håper han gir meg sjekken i stedet for å stikke av? Eller gir han meg sjekken og håper jeg gir i skjemaet? Uansett, noen utsetter seg selv for risikoen for svik.

Og da gikk det opp for meg at jeg skulle slutte å bekymre meg og bare levere inn skjemaet. Hvorfor? Fordi én av to ting kan skje neste gang. Enten gir kjøperen meg sjekken, i så fall er alle fornøyde og byttet er fullført. Men hva om han stikker av i stedet? I så fall vil postkontoret se, og rive opp skjemaet jeg nettopp ga ham. Bingo, vi har en trygg utveksling.

Så du hva som skjedde der? Vårt dilemma ble løst ved bruk av en mellommann, i dette tilfellet postkontoret. Ekspeditøren sørger for at enten en rettferdig transaksjon finner sted, eller ingen transaksjon i det hele tatt. Og ikke en hvilken som helst mellommann kan tilby denne tjenesten. Det må være noen som begge parter stoler på. Når det gjelder en ansatt i et statlig eid postkontor, skyldes dette vår tillit til myndighetene selv. Hvis postkontorfunksjonærer kunne bestikkes, kunne enten jeg eller kjøperen konstruert en situasjon der vi ender opp med både kontanter og bil. Faktisk i mange land, kan korrupsjon som dette være et stort tap på velstand.

Hulemenn og biler er én ting, men la oss flytte fokus til finansverdenen, der handel spiller en rolle sentral rolle. Selvfølgelig betaler ikke bankene sine ansatte for å stikke av med andres aksjer. Men sikker utveksling av finansielle eiendeler er fortsatt et viktig problem, fordi det er mindre tegneserieaktige måter som deltakere i en transaksjon kan unnlate å holde løftet. For eksempel kan en part bli insolvent, eller en plutselig endring i markedsforholdene kan hindre dem i å sikre en eiendel. De kan lide av geistlige feil eller av konsekvenser av en regnskapssvindel hos en annen motpart.

Som et resultat av disse "oppgjørsrisiko”, gjøres de fleste finansielle transaksjoner ved hjelp av levering kontra betaling (DvP). Dette er bare en fancy betegnelse for postkontorprosessen beskrevet ovenfor. DvP sikrer at hvis en part i en transaksjon ikke leverer det som ble lovet, kan den andre parten beholde eiendelen de tilbød i bytte.

Og hvordan implementeres levering kontra betaling i finansverdenen? Du gjettet det, via pålitelige mellommenn. Dette kan være andre banker, oppgjørssentraler eller verdipapirsentraler. Siden de fleste av dagens handler skjer digitalt, er dette ikke et spørsmål om å administrere overføring av fysiske sertifikater eller kontanter. Snarere oppnås DvP ved at mellommannen samtidig oppdaterer en rekke poster i databasen sin og/eller sender instruksjoner til andre institusjoner.

Levering kontra betaling med blockchain

Å snakke om databaser bringer oss pent til emnet blokkjeder. En blokkjede lar en hovedbok eller database deles og synkroniseres mellom en rekke parter. Men i motsetning til vanlige databaser, kan blokkjededatabaser trygt og direkte modifiseres av flere brukere selv om de er i hard konkurranse med hverandre. Hvis du jobber med bedrifts-IT, vil du kanskje tenke litt over implikasjonene av den setningen.

For å forstå hvordan levering kontra betaling fungerer på en blokkjede, må vi begynne med å forstå bitcoins transaksjonsmodell. Det skal bemerkes her at andre blockchain-design bruker en annen modell for transaksjoner, og vi vil snakke mer om disse forskjellene senere.

En bitcoin-transaksjon har et sett med innganger og utganger. Hver inngang er koblet til én utgang fra en tidligere transaksjon, med all bitcoin fra den forrige utgangen som strømmer inn. Bitcoinen i en transaksjons innganger blir deretter omfordelt på tvers av utgangene i henhold til mengdene skrevet i. I tillegg inneholder hver transaksjonsutgang den offentlige identifikatoren til den nye eieren, som eieren har en tilsvarende privat nøkkel for. En bitcoin-transaksjon er bare gyldig hvis:

• Den totale mengden bitcoin i transaksjonens innganger er større eller lik mengden skrevet i utgangene. Enhver forskjell samles inn som et gebyr av "gruvearbeideren" som bekrefter transaksjonen i en blokk, og skaper en markedsmekanisme som transaksjoner kan by for bekreftelse på.
• Transaksjonen er godkjent av eierne av hver tidligere utgang som transaksjonen "bruker". Denne godkjenningen uttrykkes via en kryptografisk signatur av den nye transaksjonens innhold. Signaturen for en tidligere utgang kan bare opprettes ved å bruke den private nøkkelen som samsvarer med dens offentlige identifikator.

Begge disse reglene er avgjørende i en finansiell hovedbok som deles mellom ikke-tillitsfulle parter. Uten den første kunne hvem som helst lage bitcoins ut av løse luften. Og uten den andre kunne alle bruke alle andres bitcoins. Men vi trenger også en tredje regel, som håndheves globalt i stedet for innenfor individuelle transaksjoner:

• Hver transaksjonsutgang kan bare brukes av én påfølgende transaksjon. Dette forhindrer et angrep kjent som double-utgifter der de samme bitcoinene sendes til mer enn én mottaker.

For å håndheve denne regelen inneholder blokkjeden en kronologisk logg over gyldige transaksjoner som ikke er i konflikt med hverandre, og denne loggen blir uavhengig verifisert av hver node i nettverket.

Bitcoin-transaksjonsmodellen kan enkelt utvides til å representere enhver finansiell eiendel. I stedet for en transaksjonsutgang som inneholder bitcoins, kan den inneholde en eiendelidentifikator og mengde. Alle reglene som dekker bitcoin-transaksjoner gjelder fortsatt, og hindrer deltakere i å (a) skape eiendeler ut av løse luften, (b) bruke andres eiendeler og (c) bruke den samme eiendelen to ganger. For eiendeler som ikke er kryptovaluta, har vi en tendens til å insistere på at inngangs- og utgangsmengder balanserer nøyaktig, i stedet for å la gruvearbeidere samle inn forskjellen.

Så hvordan lager vi en sikker levering kontra betalingstransaksjon ved å bruke denne modellen? La oss si at Alice og Bob har blitt enige om å bytte Alices £10 mot Bobs $15. For enkelhets skyld antar vi at Alice allerede har nøyaktig 10 pund i en enkelt transaksjonsutgang, og Bob har også 15 dollar. (Hvis dette ikke er tilfelle, kan de enkelt flytte rundt midlene sine for å gjøre det slik.)

Til å begynne med bygger hver av partene en transaksjon med to innganger og to utganger. De to inngangene bruker de tidligere utgangene som inneholder henholdsvis Alices £10 og Bobs $15. Når det gjelder utdataene, inneholder den første Alices identifikator og $15, og den andre går til Bob som inneholder £10. Siden inngangs- og utgangsmengdene i begge valutaer balanserer, oppfyller transaksjonen vår den første betingelsen ovenfor. For å oppfylle den andre, må både Alice og Bob nå signere transaksjonen, siden den bruker tidligere utganger som tilhører hver av dem.

Transaksjonen kan nå fullføres ved å inkludere den i blokkjeden, men vi må fortsatt vurdere problemet med dobbeltforbruk. Hva om Alice hadde opprettet en motstridende transaksjon ved å bytte de samme £10 med en annen motpart som tilbød henne en bedre avtale? Her kommer den tredje regelen inn, der blokkjeden sørger for at hver utgang kun kan brukes én gang. Hvis den konkurrerende transaksjonen overføres etter at Alices utveksling med Bob er på blokkjeden, vil den rett og slett ikke bli bekreftet. Og hvis den konkurrerende transaksjonen ble bekreftet først, vil Alices utveksling med Bob mislykkes i stedet. Uansett, blokkjeden sikrer levering kontra betaling for Alice og Bobs utveksling, så vel som alle andre. Hvis Bob ikke får Alices £10, får ikke Alice sine $15.

Kraften til deltransaksjoner

Så blokkjeder gir oss en måte for to parter å komme sammen, bygge og signere en byttetransaksjon, og sikre at den lykkes eller mislykkes som helhet. Dette muliggjør levering kontra betaling på en delt reskontro, uten at du trenger en pålitelig mellommann for å administrere prosessen. Gruvearbeiderne som bekrefter transaksjoner i blokker har fortsatt en viss makt, men det er mye mindre enn en tradisjonell mellommann. Det verste de kan gjøre er å nekte å bekrefte en bestemt transaksjon i sin helhet, og dette bryter ikke med DvP. Videre, hvis gruvedrift deles mellom partene som faktisk oppretter transaksjonene, faller denne risikoen helt bort, siden alle vil få en sjanse til å bekrefte sin egen.

Så langt så bra. Men blokkjeder i bitcoin-stil har flere triks i ermet. Husk at en transaksjon må signeres av eieren av hver tidligere utgang som transaksjonen bruker. Som standard låser denne signaturen ned hele listen over innganger og utganger i transaksjonen. Kryptografien sikrer at den minste endring av en inngang eller utgang vil gjøre signaturen ugyldig. For å følge eksemplet ovenfor, hvis Bob ble erstattet av Carol etter at Alice signerte transaksjonen, ville transaksjonen mislykkes fullstendig.

Men hva om Alice ikke bryr seg om hvem hun utfører utvekslingen med? For de fleste formål, hvorfor skulle hun bry seg? Med mindre Alice er fast bestemt på å jobbe spesifikt med Bob, er det bare to deler av transaksjonen som virkelig angår henne. For det første det faktum at hennes produksjon på £10 vil bli brukt, i stedet for en annen mengde eller eiendel. For det andre at hun mottar $15 i en ny utgang i retur. Så lenge alle pengene i systemet er rene, bryr Alice seg egentlig ikke om hvor disse $15 kommer fra, eller hva annet som kan skje for å lette utvekslingen hennes.

Kanskje en enkelt fest kommer sammen med $15 og utfører en rett swap for Alices £10. Men kanskje vil Bob og Carol bare bytte $7.50 hver. I dette tilfellet vil de legge til to innganger til transaksjonen, sammen med to utganger som samler inn £5 hver. Eller kanskje Carol faktisk ønsker å bytte $15 for 950 rubler, mens Sasha i Moskva har 950 rubler og ser etter £10. I dette tilfellet kan en 3-veis utveksling finne sted, der hver part fortsatt bare bryr seg om sin egen del av puslespillet. Transaksjonen som Alice startet kan gjennomføres på et uendelig antall forskjellige måter. Men fra Alices perspektiv oppnår disse alle det samme formålet med å gi henne $15 i bytte for £10, og alle gjør henne like glad.

Hvordan legger en blokkjede til rette for dette? Gjennom deltransaksjoner og delsignaturer. Alice starter en transaksjon med en enkelt inngang (hennes £10) og en enkelt utgang ($15 til henne). Hun låser ned disse delene av transaksjonen med en digital signatur som sier at et hvilket som helst antall andre innganger eller utganger kan legges til. Hun gir denne deltransaksjonen til Bob og sier "se hva du kan gjøre". Kanskje hun gir det til Carol også, og til en rekke andre potensielle motparter eller syndikatbyggere. Hver av disse kan legge til sine egne par av innganger og utganger, enten for å balansere utvekslingen, eller for å lage en større deltransaksjon som kan overleveres igjen. Uansett hva noen gjør, kan transaksjonen bare utføres (dvs. gjøres opp gjennom bekreftelse på blokkjeden) når inngangs- og utgangseiendelene er balansert.

En blokkjedetransaksjon er bare en del av digitale data, så disse deltransaksjonene kan sendes via e-post eller et annet kommunikasjonsmedium. De kan til og med legges ut offentlig, fordi deltakerne i den potensielle transaksjonen vet det blokkjeden vil ta seg av dem. Alices signatur sikrer at hun bare vil bruke £10 hvis noen gir henne $15 i bytte.

Til slutt, hvis Alice velger å deaktivere tilbudet, er alt hun trenger å gjøre å bruke de samme £10 i en annen transaksjon, ganske enkelt ved å sende det tilbake til seg selv. Fordi blokkjeden ikke vil tillate at den samme produksjonen brukes to ganger, gjør dette hennes eksisterende delvise transaksjon verdiløs. Alle de andre deltakerne på blokkjeden vil se dette, og slutte å kaste bort tiden sin på å prøve å fullføre utvekslingen.

Fra DvP til smarte kontrakter

Som jeg har hevdet tidligere, kan en blokkjede i bitcoin-stil sees på som en måte å administrere synkronisering og sikkerhet i en delt relasjonsdatabase. Både bitcoin- og databasetransaksjoner behandles atomisk, noe som betyr at de lykkes eller mislykkes som helhet. Nøkkelen til analogien er ekvivalensen mellom en transaksjonsutgang i en blokkjede og en rad i databasen. En blokkjedetransaksjon som bruker noen utganger og skaper noen andre er det samme som en databasetransaksjon som sletter noen rader og lager noen andre i stedet. (En databaseoperasjon som endrer en eksisterende rad tilsvarer å slette den raden og lage en ny oppdatert i stedet. Denne ekvivalensen ligger til grunn for den populære MVCC metode for samtidighetskontroll i databaser, hvor blokkjeder i bitcoin-stil kan sees på som en distribuert form.)

Så la oss forestille oss at våre økonomiske data holdes i en database, der hver rad inneholder tre deler av informasjon: eierens identifikator, en eiendelidentifikator og en eiendelmengde. En blokkjede gjør at denne hovedboken kan deles trygt mellom deltakerne, selv om de ikke stoler på hverandre i det hele tatt. På språket til databaser sikrer den at:

• Eiendelsmengdene i radene slettet av en transaksjon samsvarer med de i radene den oppretter.
• For hver rad som slettes (eller endres) av en transaksjon, må transaksjonen signeres av eieren av den raden.
• Hvis en databaserad ble slettet av én transaksjon, forhindrer dette en annen transaksjon i å slette den igjen.

La oss se på den første av disse reglene, nemlig at transaksjoner må bevare eiendelsmengder. Vi kan utvide dette til den generelle forestillingen om en "transaksjonsbegrensning". En transaksjonsbegrensning har form av en svart boks som ser to sett med rader for hver transaksjon: (a) radene slettet av transaksjonen, (b) radene den oppretter. Den svarte boksens jobb er å se på disse to settene og svare "ja" eller "nei" på om transaksjonen er gyldig. I vårt spesifikke tilfelle vil det kun svare ja hvis de totale eiendelsmengdene i begge settene stemmer nøyaktig overens.

Når vi har muligheten til å bruke transaksjonsbegrensninger, kan de utvides til å inneholde et hvilket som helst sett med regler. Noen eksempler kan være "en enhet av denne eiendelen kan bare opprettes hvis disse tre andre eiendelene samtidig er låst i deponering" eller "denne eiendelen kan bare overføres hvis det er en tilsvarende rad som rapporterer utilstrekkelig regn". Fra perspektivet til en blokkjedes distribuerte arkitektur, gjør logikken inne i boksen ingen forskjell, så lenge den kan gi oss en klar og konsistent evaluering av hver transaksjon den ser.

Som et resultat kan transaksjonsbegrensninger tjene som en generell metode for å begrense datatransformasjonene som blokkjededeltakere kan utføre. Denne tilnærmingen til "smarte kontrakter" gir et alternativ til lagrede prosedyrer brukes i Ethereum og dens Eris derivat. I et fremtidig stykke vil vi dykke dypere inn i fordelene og ulempene ved disse to paradigmene, når det gjelder enkelhet, skalerbarhet og samtidighet.

Du kan følg meg på Twitter her. Se også: Avslutte bitcoin vs blockchain-debatten.

Teknisk tillegg

For å bygge delvise DvP-transaksjoner, bruk en signaturtype of SINGLE|ANYONECANPAY. Hvis du bruker multikateden preparelockunspent, createrawexchange og appendrawexchange API-samtaler ta vare på detaljene for deg. Se Komme i gang side for et enkelt eksempel på hvordan de kan brukes.

Legg inn kommentarer på Linkedin.

Kilde: https://www.multichain.com/blog/2015/09/delivery-versus-payment-blockchain/