Levering versus betaling på en blockchain

Hvordan blockchains kan løse det ældste problem i bogen

Handel mellem mennesker er lige så gammel som menneskeheden selv. Det begyndte i det øjeblik, hvor hulemanden Ogg sagde til hulemanden Ugg: "me give you rock, you give me berries". Men handel medfører et grundlæggende problem: det kræver tillid. Hvad forhindrer Ogg i at bruge stenen til at slå Ugg og derefter gribe begge sten , bær før du løber væk? Hvordan oversætter vi en mundtlig udvekslingsaftale til en håndhævelsesmekanisme, der sikrer, at begge sider holder deres ord?

For at tage et moderne eksempel, så solgte jeg for nogle år siden en bil på brugtmarkedet. Jeg fandt en køber over internettet, vi mødtes personligt, han fik bilen testet og vi blev enige om en pris. Så han gik til sin bank for at få en kassecheck, som reelt er kontanter i en mere kompakt form. Vi gik sammen til et postkontor, hvor jeg kan underskrive og indsende en officiel regeringsformular, der overfører det juridiske ejerskab af bilen.

Så der står vi ved posthusets vindue, og vi når en akavet blindgyde. Checken er stadig i hans lomme, og jeg holder den underskrevne formular. Vi mødtes for et par timer siden og har ingen grund til at stole på hinanden. Skal jeg aflevere formularen først og så håbe, at han giver mig checken i stedet for at stikke af? Eller giver han mig checken og håber jeg giver i formularen? Uanset hvad, er der nogen, der udsætter sig selv for risikoen for forræderi.

Og så gik det op for mig, at jeg skulle lade være med at bekymre mig og bare aflevere formularen. Hvorfor? Fordi en af ​​to ting kunne ske næste gang. Enten giver køberen mig checken, i så fald er alle glade, og byttet er gennemført. Men hvad nu hvis han stikker af i stedet for? I så fald vil postbetjenten se og rive den formular, jeg lige har givet ham. Bingo, vi har os en sikker byttehandel.

Så du, hvad der skete der? Vores dilemma blev løst ved at bruge en mellemmand, i dette tilfælde postkontoret. Ekspedienten sikrer, at enten en fair transaktion finder sted, eller ingen transaktion overhovedet. Og ikke en hvilken som helst mellemmand kan levere denne service. Det skal være nogen, som begge parter har tillid til. Hvis der er tale om en ansat på et statsejet postkontor, skyldes det vores tillid til selve regeringen. Hvis postekspedienter kunne bestikkes, kunne enten jeg eller køberen lave en situation, hvor vi ender med både kontanter og bil. Faktisk i mange lande, kan korruption som denne være et enormt dræn for velstand.

Hulemænd og biler er én ting, men lad os flytte vores fokus til den finansielle verden, hvor handel spiller en central rolle. Selvfølgelig betaler banker ikke deres ansatte for at stikke af med en andens aktier. Men sikker udveksling af finansielle aktiver er fortsat et vigtigt problem, fordi der er mindre tegneserieagtige måder, hvorpå deltagere i en transaktion kan undlade at overholde deres løfte. For eksempel kan en part blive insolvent, eller en pludselig ændring i markedsforholdene kan forhindre dem i at sikre et aktiv. De kan lide af skrivefejl eller af afsmittende virkninger af en regnskabssvig hos en anden modpart.

Som et resultat af disse "afviklingsrisici”, afvikles de fleste finansielle transaktioner vha levering kontra betaling (DvP). Dette er blot et fancy udtryk for postkontorprocessen beskrevet ovenfor. DvP sikrer, at hvis den ene part i en transaktion ikke leverer, hvad der blev lovet, kan den anden part beholde det aktiv, de tilbød i bytte.

Og hvordan implementeres levering kontra betaling i finansverdenen? Du gættede det, via betroede mellemmænd. Det kan være andre banker, clearingcentre eller centrale værdipapircentraler. Da de fleste af nutidens handler foregår digitalt, er dette ikke et spørgsmål om at administrere overførslen af ​​fysiske certifikater eller kontanter. Tværtimod opnås DvP ved, at formidleren samtidig opdaterer en række poster i deres database og/eller sender instruktioner til andre institutioner.

Levering kontra betaling med blockchain

At tale om databaser bringer os pænt til emnet blockchains. En blockchain gør det muligt at dele og synkronisere en hovedbog eller database mellem en række parter. Men i modsætning til almindelige databaser kan blockchain-databaser sikkert og direkte modificeres af flere brugere, selvom de er i hård konkurrence med hinanden. Hvis du arbejder med virksomheds-IT, vil du måske overveje konsekvenserne af denne sætning.

For at forstå, hvordan levering versus betaling fungerer på en blockchain, skal vi starte med at forstå bitcoins transaktionsmodel. Det skal bemærkes her, at andre blockchain-designs bruger en anden model for transaktioner, og vi vil tale mere om disse forskelle senere.

En bitcoin-transaktion har et sæt input og output. Hvert input er forbundet med én udgang fra en tidligere transaktion, hvor al bitcoin fra den tidligere udgang flyder ind. Bitcoinen i en transaktions input bliver derefter omfordelt på tværs af dens udgange i overensstemmelse med mængderne skrevet indeni. Derudover indeholder hver transaktionsoutput den offentlige identifikator for dens nye ejer, for hvilken ejeren har en tilsvarende privat nøgle. En bitcoin-transaktion er kun gyldig, hvis:

• Den samlede mængde bitcoin i transaktionens input er større eller lig med mængden skrevet i dens output. Enhver forskel opkræves som et gebyr af "miner", der bekræfter transaktionen i en blok, hvilket skaber en markedsmekanisme, hvormed transaktioner kan byde på bekræftelse.
• Transaktionen er godkendt af ejerne af alle tidligere output, som denne transaktion "bruger". Denne godkendelse udtrykkes via en kryptografisk signatur af den nye transaktions indhold. Signaturen for et tidligere output kan kun oprettes ved hjælp af den private nøgle, som matcher dens offentlige identifikator.

Begge disse regler er afgørende i en finansiel hovedbog, som deles mellem ikke-tillidsfulde parter. Uden den første kunne enhver skabe bitcoins ud af den blå luft. Og uden den anden kunne alle bruge alle andres bitcoins. Men vi har også brug for en tredje regel, som håndhæves globalt snarere end inden for individuelle transaktioner:

• Hver transaktionsoutput kan kun bruges af én efterfølgende transaktion. Dette forhindrer et angreb kendt som dobbelt-udgifter hvor de samme bitcoins sendes til mere end én modtager.

For at håndhæve denne regel indeholder blockchain en kronologisk log over gyldige transaktioner, som ikke er i konflikt med hinanden, og denne log verificeres uafhængigt af hver knude i netværket.

Bitcoin-transaktionsmodellen kan nemt udvides til at repræsentere ethvert finansielt aktiv. I stedet for et transaktionsoutput, der indeholder bitcoins, kan det indeholde en aktividentifikator og en mængde. Alle reglerne for bitcoin-transaktioner gælder stadig, hvilket forhindrer deltagere i at (a) skabe aktiver ud af den blå luft, (b) bruge andres aktiver og (c) bruge det samme aktiv to gange. For ikke-cryptocurrency-aktiver har vi en tendens til at insistere på, at input- og outputmængder balancerer nøjagtigt, i stedet for at tillade minearbejdere at indsamle forskellen.

Så hvordan skaber vi en sikker levering versus betalingstransaktion ved hjælp af denne model? Lad os sige, at Alice og Bob er blevet enige om at bytte Alices £10 til Bobs $15. For nemheds skyld antager vi, at Alice allerede har præcis 10 £ i en enkelt transaktionsoutput, og Bob har ligeledes 15 $. (Hvis dette ikke er tilfældet, kan de nemt flytte deres midler rundt for at gøre det sådan.)

Til at begynde med bygger hver af parterne en transaktion med to input og to output. De to input bruger de tidligere output, der indeholder henholdsvis Alices £10 og Bobs $15. Hvad angår output, indeholder den første Alices identifikator og $15, og den anden går til Bob, der indeholder £10. Da input- og outputmængderne i begge valutaer balancerer, opfylder vores transaktion den første betingelse ovenfor. For at opfylde den anden skal både Alice og Bob nu underskrive transaktionen, da den bruger tidligere output, der tilhører hver af dem.

Transaktionen kan nu afsluttes ved at inkludere den i blockchain, men vi mangler stadig at overveje problemet med dobbeltforbrug. Hvad hvis Alice havde oprettet en modstridende transaktion ved at bytte de samme £10 med en anden modpart, som tilbød hende en bedre handel? Her kommer den tredje regel i spil, hvor blockchain sikrer, at hvert output kun kan bruges én gang. Hvis den konkurrerende transaktion transmitteres efter Alices udveksling med Bob er på blockchain, så bliver den simpelthen ikke bekræftet. Og hvis den konkurrerende transaktion blev bekræftet først, mislykkes Alices udveksling med Bob i stedet. Uanset hvad, så sikrer blockchain levering kontra betaling for Alice og Bobs udveksling, såvel som enhver anden. Hvis Bob ikke får Alices £10, så får Alice ikke sine $15.

Kraften til delvise transaktioner

Så blockchains giver os en måde for to parter at komme sammen, bygge og underskrive en udvekslingstransaktion og sikre, at den lykkes eller mislykkes som helhed. Dette muliggør levering kontra betaling på en delt finansbog, uden at du behøver en betroet mellemmand til at styre processen. De minearbejdere, der bekræfter transaktioner i blokke, har stadig en vis magt, men det er meget mindre end en traditionel mellemmand. Det værste, de kan gøre, er at nægte at bekræfte en bestemt transaktion i sin helhed, og dette krænker ikke DvP. Desuden, hvis minedrift deles mellem parterne, der faktisk skaber transaktionerne, forsvinder denne risiko fuldstændigt, da alle får en chance for at bekræfte deres egen.

Så langt så godt. Men blockchains i bitcoin-stil har flere tricks i ærmet. Husk, at en transaktion skal underskrives af ejeren af ​​hvert tidligere output, som transaktionen bruger. Som standard låser denne signatur hele listen over input og output i transaktionen. Kryptografien sikrer, at den mindste ændring af et input eller output ville gøre signaturen ugyldig. For at følge eksemplet ovenfor, hvis Bob blev erstattet af Carol efter Alice underskrev transaktionen, ville transaktionen fuldstændig mislykkes.

Men hvad nu hvis Alice er ligeglad med, hvem hun udfører udvekslingen med? Til de fleste formål, hvorfor skulle hun bekymre sig? Medmindre Alice er fast besluttet på at arbejde specifikt med Bob, er der kun to dele af transaktionen, der virkelig vedrører hende. For det første det faktum, at hendes 10 £ output vil blive brugt, snarere end en anden mængde eller aktiv. For det andet, at hun modtager $15 i et nyt output til gengæld. Så længe alle pengene i systemet er rene, har Alice ikke rigtig noget imod, hvor de $15 kommer fra, eller hvad der ellers kunne ske for at lette hendes udveksling.

Måske vil en enkelt part komme sammen med $15 og foretage et direkte bytte for Alices £10. Men måske vil Bob og Carol kun bytte $7.50 hver. I dette tilfælde vil de tilføje to input til transaktionen sammen med to output, der indsamler £5 hver. Eller måske vil Carol faktisk veksle $15 til 950 rubler, mens Sasha i Moskva har 950 rubler og leder efter £10. I dette tilfælde kan en 3-vejs udveksling finde sted, hvor hver part stadig kun bekymrer sig om deres egen brik i puslespillet. Den transaktion, som Alice startede, kan gennemføres på et uendeligt antal forskellige måder. Men fra Alices perspektiv opnår disse alle det samme formål at give hende $15 i bytte for £10, og de gør hende alle lige glade.

Hvordan letter en blockchain dette? Gennem delvise transaktioner og delvise underskrifter. Alice starter en transaktion med et enkelt input (hendes £10) og et enkelt output ($15 til hende). Hun låser disse dele af transaktionen ned med en digital signatur, som angiver, at et hvilket som helst antal andre input eller output kan tilføjes. Hun overrækker denne delvise transaktion til Bob og siger "se hvad du kan gøre". Måske giver hun det også til Carol og til en række andre potentielle modparter eller syndikatbyggere. Hver af disse kan tilføje deres egne par af input og output, enten for at balancere udvekslingen eller for at skabe en større deltransaktion, der kan videregives igen. Uanset hvad nogen gør, kan transaktionen kun udføres (dvs. afvikles gennem bekræftelse på blockchain), når input- og outputaktiverne er balancerede.

En blockchain-transaktion er kun en del af digitale data, så disse deltransaktioner kan sendes via e-mail eller et hvilket som helst andet kommunikationsmedie. De kan endda blive offentliggjort offentligt, fordi deltagerne i den potentielle transaktion ved det blockchain vil tage sig af dem. Alices underskrift sikrer, at hun kun vil bruge £10, hvis nogen giver hende $15 i bytte.

Til sidst, hvis Alice vælger at deaktivere tilbuddet, er det eneste hun skal gøre at bruge de samme £10 i en anden transaktion, mest simpelt hen ved at sende det tilbage til sig selv. Fordi blockchain ikke tillader, at det samme output bliver brugt to gange, gør dette hendes eksisterende delvise transaktion værdiløs. Alle de andre deltagere på blockchain vil se dette og stoppe med at spilde deres tid på at prøve at gennemføre udvekslingen.

Fra DvP til smarte kontrakter

Som jeg har argumenterede tidligere, kan en blockchain i bitcoin-stil ses som en måde at styre synkronisering og sikkerhed i en delt relationel database. Både bitcoin- og databasetransaktioner behandles atomisk, hvilket betyder, at de lykkes eller mislykkes som helhed. Nøglen til analogien er ækvivalensen mellem et transaktionsoutput i en blockchain og en række i databasen. En blockchain-transaktion, der bruger nogle output og skaber nogle andre, er det samme som en databasetransaktion, der sletter nogle rækker og opretter nogle andre i stedet. (En databaseoperation, der ændrer en eksisterende række, svarer til at slette den række og oprette en ny opdateret i stedet. Denne ækvivalens ligger til grund for den populære MVCC metode til samtidighedskontrol i databaser, hvoraf bitcoin-stil blockchains kan ses som en distribueret form.)

Så lad os forestille os, at vores finansielle data opbevares i en database, hvor hver række indeholder tre stykker information: dens ejers identifikator, en aktividentifikator og en aktivmængde. En blockchain gør det muligt at dele denne hovedbog sikkert mellem sine deltagere, selvom de slet ikke stoler på hinanden. På sproget i databaser sikrer det, at:

• Aktivmængderne i rækkerne, der er slettet af en transaktion, svarer til dem i rækkerne, den opretter.
• For hver række, der slettes (eller ændres) af en transaktion, skal transaktionen underskrives af ejeren af ​​den pågældende række.
• Hvis en databaserække blev slettet af en transaktion, forhindrer dette en anden transaktion i at slette den igen.

Lad os se på den første af disse regler, nemlig at transaktioner skal bevare aktivmængder. Vi kan udvide dette til den generelle opfattelse af en "transaktionsbegrænsning". En transaktionsbegrænsning har form af en sort boks, som ser to sæt rækker for hver transaktion: (a) rækkerne slettet af transaktionen, (b) rækkerne, som den opretter. Den sorte boks opgave er at se på disse to sæt og svare 'ja' eller 'nej' for, om transaktionen er gyldig. I vores konkrete tilfælde vil det kun svare ja, hvis de samlede aktivmængder i begge sæt stemmer nøjagtigt overens.

Når vi har mulighed for at anvende transaktionsbegrænsninger, kan de udvides til at indeholde ethvert sæt regler. Nogle eksempler kan være "en enhed af dette aktiv kan kun oprettes, hvis disse tre andre aktiver samtidig er låst i deponering" eller "dette aktiv kan kun overføres, hvis der er en tilsvarende række, der rapporterer utilstrækkelig regn". Fra perspektivet af en blockchains distribuerede arkitektur gør logikken inde i boksen ingen forskel, så længe den kan give os en konkret og konsekvent evaluering af hver transaktion, den ser.

Som et resultat kan transaktionsbegrænsninger tjene som en generel metode til at begrænse de datatransformationer, som blockchain-deltagere kan udføre. Denne tilgang til "smarte kontrakter" giver et alternativ til lagrede procedurer anvendes i Ethereum og Eris afledte. I et fremtidigt stykke vil vi dykke dybere ned i fordelene og ulemperne ved disse to paradigmer, hvad angår enkelhed, skalerbarhed og samtidighed.

Du kan følg mig på Twitter her. Se også: Afslutning af bitcoin vs blockchain-debatten.

Teknisk tillæg

For at bygge delvise DvP-transaktioner skal du bruge en signaturtype of SINGLE|ANYONECANPAY. Hvis du bruger multikæde, preparelockunspent, createrawexchange , appendrawexchange API-opkald tage sig af detaljerne for dig. Se den Kom godt i gang side for et simpelt eksempel på, hvordan de kan bruges.

Skriv eventuelle kommentarer på LinkedIn.

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