Leverans kontra betalning på blockchain

Hur blockkedjor kan lösa det äldsta problemet i boken

Handel mellan människor är lika gammal som mänskligheten själv. Det började i det ögonblick då grottmannen Ogg sa till grottmannen Ugg: "Jag ger dig sten, du ger mig bär". Men handel medför ett grundläggande problem: det kräver litar. Vad hindrar Ogg från att använda berget för att baska Ugg och sedan ta tag i båda stenarna och bär innan du flyr iväg? Hur översätter vi ett muntligt utbytesavtal till en verkställighetsmekanism som säkerställer att båda parter håller sitt ord?

För att ta ett modernt exempel sålde jag för några år sedan en bil på begagnad marknaden. Jag hittade en köpare över Internet, vi träffade personligen, han lät testa bilen och vi kom överens om ett pris. Så han gick till sin bank för att få en kassakontroll, som faktiskt är kontanter i en mer kompakt form. Vi gick tillsammans till ett postkontor, där jag kan underteckna och skicka in ett officiellt regeringsformulär som överför lagligt ägande av bilen.

Så där står vi vid postfönstret och når en besvärlig återvändsgränd. Checken ligger fortfarande i hans ficka, och jag har det undertecknade formuläret. Vi träffades för några timmar sedan och har ingen anledning att lita på varandra. Skickar jag in formuläret först och hoppas att han ger mig checken snarare än att springa iväg? Eller lämnar han mig checken och hoppas att jag ger i formuläret? Hur som helst utsätter någon sig för risken för svek.

Och då gick det upp för mig att jag skulle sluta oroa mig och bara lämna in formuläret. Varför? Eftersom en av två saker kan hända nästa. Antingen överlämnar köparen mig checken, i vilket fall alla är glada och utbytet är klart. Men tänk om han springer iväg istället? I så fall kommer postkontor att se och riva upp formuläret jag just gav honom. Bingo, vi har själva ett säkert utbyte.

Såg du vad som hände där? Vårt dilemma löstes med hjälp av en mellanhand, i detta fall postkontor. Kontoristen ser till att antingen en rättvis transaktion äger rum eller ingen transaktion alls. Och inte bara någon mellanhand kan tillhandahålla den här tjänsten. Det måste vara någon som båda parter litar på. När det gäller en anställd på ett statligt postkontor härrör detta från vårt förtroende för regeringen själv. Om postkontorstjänstemän kunde mutas kan antingen jag eller köparen konstruera en situation där vi hamnar med både kontanter och bil. I själva verket i många länder, korruption som denna kan vara en enorm dränering för välstånd.

Grottmänniskor och bilar är en sak, men låt oss flytta vårt fokus till den finansiella världen, där handel spelar en central roll. Naturligtvis betalar banker inte sina anställda för att springa av med någon annans aktier. Men ett säkert utbyte av finansiella tillgångar är fortfarande ett viktigt problem, eftersom det finns mindre tecknade sätt på vilka deltagare i en transaktion inte kan hålla sitt löfte. Till exempel kan en part bli insolvent, eller en plötslig förändring av marknadsförhållandena kan hindra dem från att säkra en tillgång. De kan drabbas av kontorsfel eller av de påfrestande effekterna av en redovisningsbedrägeri hos en annan motpart.

Som ett resultat av dessa ”avvecklingsrisker”Avvecklas de flesta finansiella transaktioner med leverans kontra betalning (DvP). Detta är bara en snygg term för postkontorsprocessen som beskrivs ovan. DvP ser till att, om en part i en transaktion inte levererar vad som lovades, kan den andra parten hålla tillgången de erbjöd i utbyte.

Och hur implementeras leverans kontra betalning i finansvärlden? Du gissade det via betrodda mellanhänder. Dessa kan vara andra banker, clearinghus eller centrala värdepappersförvarare. Eftersom de flesta av dagens affärer sker digitalt handlar det inte om att hantera överföringen av fysiska certifikat eller kontanter. Snarare uppnås DvP genom att förmedlaren samtidigt uppdaterar ett antal poster i sin databas och / eller sänder instruktioner till andra institutioner.

Leverans kontra betalning med blockchain

Att prata om databaser tar oss snyggt till ämnet blockchains. En blockchain tillåter att en huvudbok eller databas delas och synkroniseras mellan ett antal parter. Till skillnad från vanliga databaser kan blockchain-databaser ändras säkert och direkt av flera användare även om de är i hård konkurrens med varandra. Om du arbetar inom företags-IT kanske du vill tänka på konsekvenserna av den meningen.

För att förstå hur leverans kontra betalning fungerar på en blockchain måste vi börja med att förstå bitcoins transaktionsmodell. Det bör noteras här att andra blockchain-design använder en annan modell för transaktioner, och vi kommer att prata mer om dessa skillnader senare.

En bitcoin-transaktion har en uppsättning in- och utgångar. Varje ingång är ansluten till en utgång från en tidigare transaktion, med all bitcoin från den tidigare utgången som flödar in. Bitcoins i en transaktions ingångar omfördelas sedan över dess utgångar enligt de kvantiteter som skrivs in. Dessutom innehåller varje transaktionsoutput den offentliga identifieraren för sin nya ägare, för vilken ägaren har en motsvarande privat nyckel. En bitcoin-transaktion är endast giltig om:

• Den totala mängden bitcoin i transaktionens ingångar är större eller lika med kvantiteten skriven i dess utdata. Varje skillnad tas ut som en avgift av "gruvarbetaren" som bekräftar transaktionen i ett block, vilket skapar en marknadsmekanism genom vilken transaktioner kan bjuda på bekräftelse.
• Transaktionen godkänns av ägarna av varje tidigare produktion som den transaktionen "spenderar". Detta godkännande uttrycks via en kryptografisk signatur av innehållet i den nya transaktionen. Signaturen för en tidigare utdata kan bara skapas med den privata nyckeln som matchar dess offentliga identifierare.

Båda dessa regler är avgörande i en finansiell huvudbok som delas mellan icke-förtroende parter. Utan det första kunde någon skapa bitcoins ur luften. Och utan det andra kunde alla spendera andras bitcoins. Men vi behöver också en tredje regel, som tillämpas globalt snarare än inom enskilda transaktioner:

• Varje transaktionsoutput kan endast användas av en efterföljande transaktion. Detta förhindrar en attack som kallas dubbel utgifterna där samma bitcoins skickas till mer än en mottagare.

För att genomdriva denna regel innehåller blockkedjan en kronologisk logg över giltiga transaktioner som inte strider mot varandra, och denna logg verifieras oberoende av varje nod i nätverket.

Transaktionsmodellen för bitcoin kan enkelt utökas för att representera alla finansiella tillgångar. I stället för en transaktionsoutput som innehåller bitcoins kan den innehålla en tillgångsidentifierare och kvantitet. Alla regler som täcker bitcoin-transaktioner gäller fortfarande, vilket hindrar deltagare från att (a) skapa tillgångar ur luften, (b) spendera andras tillgångar och (c) spendera samma tillgång två gånger. För tillgångar som inte är kryptovalutor tenderar vi att insistera på att input och output-kvantiteter balanserar exakt snarare än att låta gruvarbetare samla in skillnaden.

Så hur skapar vi en säker leverans kontra betalningstransaktion med den här modellen? Låt oss säga att Alice och Bob har kommit överens om att byta ut Alice £ 10 för Bob $ 15. För bekvämlighets skull antar vi att Alice redan har exakt £ 10 som sitter snyggt i en enda transaktionsutgång, och Bob har också $ 15. (Om detta inte är fallet kan de enkelt flytta sina medel för att göra det.)

Till att börja med bygger endera parten en transaktion med två ingångar och två utgångar. De två ingångarna spenderar de tidigare utgångarna som innehåller Alice £ 10 respektive Bob $ 15. När det gäller utgångarna innehåller den första Alice identifierare och $ 15, och den andra går till Bob som innehåller £ 10. Eftersom input- och output-kvantiteterna i båda valutorna balanserar uppfyller vår transaktion det första villkoret ovan. För att uppfylla den andra måste både Alice och Bob nu underteckna transaktionen, eftersom den spenderar tidigare utgångar som tillhör var och en av dem.

Transaktionen kan nu slutföras genom att inkludera den i blockchain, men vi måste fortfarande överväga problemet med dubbla utgifter. Vad händer om Alice hade skapat en motstridig transaktion som bytte samma £ 10 med en annan motpart som erbjöd henne en bättre affär? Här spelar den tredje regeln in, där blockchain säkerställer att varje produktion bara kan spenderas en gång. Om den konkurrerande transaktionen överförs efter Alice utbyte med Bob är på blockchain, blir det helt enkelt inte bekräftat. Och om den konkurrerande transaktionen bekräftades först, misslyckas Alices utbyte med Bob istället. Hur som helst, blockchain säkerställer leverans kontra betalning för Alice och Bobs utbyte, liksom alla andra. Om Bob inte får Alice £ 10, får Alice inte sina $ 15.

Kraften i partiella transaktioner

Så blockchains ger oss ett sätt för två parter att samlas, bygga och underteckna en växlingstransaktion och se till att den lyckas eller misslyckas som helhet. Detta möjliggör leverans kontra betalning på en delad huvudbok, utan att behöva en betrodd mellanhand för att hantera processen. Gruvarbetarna som bekräftar transaktioner i block har fortfarande viss kraft, men det är mycket mindre än en traditionell mellanhand. Det värsta de kan göra är att vägra att bekräfta en viss transaktion i sin helhet, och detta bryter inte mot DvP. Dessutom, om gruvdrift delas mellan parterna som faktiskt skapar transaktionerna, faller denna risk helt bort, eftersom alla kommer att få en chans att bekräfta sina egna.

Än så länge är allt bra. Men blockchains i bitcoin-stil har fler knep i ärmen. Kom ihåg att en transaktion måste undertecknas av ägaren av varje tidigare utdata som den transaktionen spenderar. Som standard låser denna signatur hela listan med in- och utdata i transaktionen. Kryptografin säkerställer att den minsta ändringen av en ingång eller utgång skulle göra signaturen ogiltig. För att följa exemplet ovan, om Bob ersattes av Carol efter Alice undertecknade transaktionen, skulle transaktionen misslyckas helt.

Men tänk om Alice inte bryr sig vem hon utför utbytet med? För de flesta ändamål, varför skulle hon bry sig? Om inte Alice är fast besluten att arbeta specifikt med Bob, finns det bara två delar av transaktionen som verkligen berör henne. Först det faktum att hennes £ 10 produktion kommer att spenderas, snarare än en annan mängd eller tillgång. För det andra att hon får $ 15 i en ny produktion i gengäld. Så länge alla pengar i systemet är rena, bryr sig Alice inte riktigt var de $ 15 kommer ifrån, eller vad som annars kan hända för att underlätta hennes utbyte.

Kanske kommer en enda part tillsammans med $ 15 och göra en direkt byte mot Alice £ 10. Men kanske vill Bob och Carol bara byta 7.50 dollar vardera. I det här fallet skulle de lägga till två ingångar till transaktionen, tillsammans med två utgångar som samlar £ 5 vardera. Eller kanske Carol faktiskt vill byta $ 15 för 950 rubel, medan Sasha i Moskva har 950 rubel och letar efter £ 10. I det här fallet kan ett 3-vägsutbyte äga rum, där varje part fortfarande bara bryr sig om sin egen pusselbit. Transaktionen som Alice startade kan genomföras på ett oändligt antal olika sätt. Men ur Alice perspektiv uppnår dessa alla samma syfte att ge henne $ 15 i utbyte mot £ 10, och alla gör henne lika glad.

Hur underlättar en blockchain detta? Genom partiella transaktioner och partiella signaturer. Alice startar en transaktion med en enda ingång (hennes £ 10) och en enda output ($ 15 till henne). Hon låser ner dessa delar av transaktionen med en digital signatur som anger att valfritt antal andra ingångar eller utgångar kan läggas till. Hon överlämnar denna partiella transaktion till Bob och säger "se vad du kan göra". Kanske överlämnar hon det också till Carol och till valfritt antal andra potentiella motparter eller syndikatbyggare. Var och en av dessa kan lägga till sina egna in- och utgångspar, antingen för att balansera utbytet, eller för att skapa en större partiell transaktion som kan överlämnas igen. Oavsett vad någon gör kan transaktionen bara genomföras (dvs. avvecklas genom bekräftelse på blockchain) när ingångs- och utgångstillgångarna är balanserade.

En blockchain-transaktion är bara en bit digitala data, så dessa partiella transaktioner kan skickas via e-post eller något annat kommunikationsmedium. De kan till och med publiceras offentligt, eftersom deltagarna i den potentiella transaktionen vet det blockchain tar hand om dem. Alice signatur säkerställer att hon bara kommer att spendera £ 10 om någon ger henne $ 15 i utbyte.

Slutligen, om Alice väljer att inaktivera erbjudandet är allt hon behöver göra att spendera samma £ 10 i en annan transaktion, helt enkelt genom att skicka tillbaka det till sig själv. Eftersom blockchain inte tillåter att samma produktion spenderas två gånger, gör detta hennes befintliga partiella transaktion värdelös. Alla andra deltagare på blockchain kommer att se detta och sluta slösa bort sin tid på att försöka slutföra utbytet.

Från DvP till smarta kontrakt

Som jag har argumenterade tidigare, en blockchain i bitcoin-stil kan ses som ett sätt att hantera synkronisering och säkerhet i en delad relationsdatabas. Både bitcoin- och databastransaktioner behandlas atomärt, vilket innebär att de lyckas eller misslyckas som helhet. Nyckeln till analogin är ekvivalensen mellan en transaktionsutmatning i en blockchain och en rad i databasen. En blockchain-transaktion som spenderar vissa utdata och skapar andra är densamma som en databastransaktion som tar bort vissa rader och skapar andra i stället. (En databasåtgärd som modifierar en befintlig rad motsvarar att radera den raden och skapa en ny uppdaterad i stället. Denna ekvivalens ligger till grund för den populära MVCC metod för samtidig valutakontroll i databaser, av vilka blockkedjor i bitcoin-stil kan ses som en distribuerad form.)

Så låt oss föreställa oss att våra ekonomiska data lagras i en databas, där varje rad innehåller tre uppgifter: dess ägarens identifierare, en tillgångsidentifierare och en tillgångsmängd. En blockchain gör det möjligt att dela denna huvudbok säkert mellan sina deltagare, även om de inte litar på varandra alls. På databasens språk säkerställer det att:

• Tillgångsmängderna i raderna som raderas av en transaktion matchar dem i raderna den skapar.
• För varje rad som tas bort (eller ändras) genom en transaktion måste transaktionen undertecknas av ägaren av den raden.
• Om en databasrad raderades av en transaktion, förhindrar detta att en annan transaktion raderas igen.

Låt oss titta på den första av dessa regler, nämligen att transaktioner måste bevara tillgångsmängder. Vi kan bredda detta till det allmänna begreppet "transaktionsbegränsning". En transaktionsbegränsning har formen av en svart ruta som ser två uppsättningar rader för varje transaktion: (a) raderna raderade av transaktionen, (b) de rader som den skapar. Den svarta lådans uppgift är att titta på dessa två uppsättningar och svara "ja" eller "nej" om transaktionen är giltig. I vårt specifika fall svarar det bara ja om den totala tillgångsmängden i båda uppsättningarna matchar exakt.

När vi har möjlighet att tillämpa transaktionsbegränsningar kan de utvidgas till att innehålla alla regler. Några exempel kan vara "en enhet av den här tillgången kan bara skapas om dessa tre andra tillgångar samtidigt är låsta i spärr" eller "den här tillgången kan bara överföras om det finns en motsvarande rad som rapporterar otillräckligt regn". Ur perspektivet av en blockchains distribuerade arkitektur gör logiken inuti rutan ingen skillnad, så länge det kan ge oss en bestämd och konsekvent utvärdering av varje transaktion som den ser.

Som ett resultat kan transaktionsbegränsningar fungera som en allmän metod för att begränsa datatransformationer som blockchain-deltagare kan utföra. Detta tillvägagångssätt för "smarta kontrakt" ger ett alternativ till Lagrade procedurer används i Ethereum och dess Eris derivat. I ett framtida stycke kommer vi att dyka djupare in i fördelarna och nackdelarna med dessa två paradigmer när det gäller enkelhet, skalbarhet och samtidighet.

Du kan följ mig på Twitter här. Se även: Avsluta bitcoin vs blockchain-debatten.

Tekniskt tillägg

Använd a för att bygga partiella DvP-transaktioner signaturtyp of SINGLE|ANYONECANPAY. Om du använder MultiKedja, den preparelockunspent, createrawexchange och appendrawexchange API-samtal ta hand om detaljerna för dig. Se Komma igång sida för ett enkelt exempel på hur de kan användas.

Skicka eventuella kommentarer på Link.

Källa: https://www.multichain.com/blog/2015/09/delivery-versus-payment-blockchain/