Levering versus betaling op een blockchain

Hoe blockchains het oudste probleem in het boek kunnen oplossen

Handel tussen mensen is zo oud als de mensheid zelf. Het begon op het moment dat holbewoner Ogg tegen holbewoner Ugg zei: 'Ik geef je steen, jij geeft me bessen'. Maar handel brengt een fundamenteel probleem met zich mee: het vereist vertrouwen. Wat weerhoudt Ogg om de rots te gebruiken om Ugg te bashen, en vervolgens beide rotsen te grijpen en bessen voordat ze wegrennen? Hoe vertalen we een mondelinge uitwisselingsovereenkomst naar een handhavingsmechanisme dat ervoor zorgt dat beide partijen zich aan hun woord houden?

Om een ​​modern voorbeeld te nemen, een paar jaar geleden verkocht ik een auto op de tweedehandsmarkt. Ik vond een koper via internet, we ontmoetten elkaar persoonlijk, hij liet de auto testen en we spraken een prijs af. Dus ging hij naar zijn bank om een ​​kascheque te krijgen, die in feite compacter is in een compactere vorm. We liepen samen naar een postkantoor, waar ik een officieel overheidsformulier kan ondertekenen en indienen dat het wettelijk eigendom van de auto overdraagt.

Daar staan ​​we dan, bij het raam van het postkantoor, en we komen in een lastige impasse. De cheque zit nog in zijn zak en ik houd het ondertekende formulier vast. We hebben elkaar een paar uur geleden ontmoet en hebben geen reden om elkaar te vertrouwen. Moet ik eerst het formulier inleveren en dan hopen dat hij me de cheque geeft, in plaats van weg te rennen? Of geeft hij me de cheque en hoopt dan dat ik het formulier geef? Hoe dan ook, iemand stelt zichzelf bloot aan het risico van verraad.

En toen drong het tot me door dat ik ophield me zorgen te maken en gewoon de vorm in te leveren. Waarom? Omdat een van de volgende twee dingen kan gebeuren. Ofwel geeft de koper mij de cheque, in dat geval is iedereen tevreden en is de ruil compleet. Maar wat als hij in plaats daarvan wegrent? In dat geval zal de postbeambte het formulier zien dat ik hem zojuist heb gegeven. Bingo, we hebben een veilige uitwisseling.

Zag je wat daar gebeurde? Ons dilemma werd opgelost door het inschakelen van een tussenpersoon, in dit geval de postbeambte. De griffier zorgt ervoor dat er ofwel een eerlijke transactie plaatsvindt, ofwel helemaal geen transactie. En niet zomaar een tussenpersoon kan deze dienst leveren. Het moet iemand zijn die door beide partijen wordt vertrouwd. Bij een medewerker van een postkantoor van de overheid komt dit voort uit ons vertrouwen in de overheid zelf. Als de griffiers van het postkantoor zouden kunnen worden omgekocht, zou ik of de koper een situatie kunnen creëren waarin we zowel met contant geld als met de auto eindigen. Inderdaad veel landenkan corruptie als deze een enorme aanslag op de welvaart betekenen.

Holbewoners en auto's zijn één ding, maar laten we onze focus verleggen naar de financiële wereld, waarin handel een rol speelt centrale rol. Banken betalen hun werknemers natuurlijk niet om weg te lopen met de aandelen van iemand anders. Maar de veilige uitwisseling van financiële activa blijft een belangrijk probleem, omdat er minder cartoonachtige manieren zijn waarop deelnemers aan een transactie hun belofte niet kunnen nakomen. Een partij kan bijvoorbeeld insolvabel worden of een plotselinge verandering in de marktomstandigheden kan hen ervan weerhouden een actief veilig te stellen. Ze kunnen last hebben van administratieve fouten of van de domino-effecten van een boekhoudfraude bij een andere tegenpartij.

Als gevolg van deze "afwikkelingsrisico's”, Worden de meeste financiële transacties afgehandeld met levering versus betaling (DvP). Dit is slechts een mooie term voor het hierboven beschreven postkantoorproces. DvP zorgt ervoor dat als de ene partij bij een transactie niet levert wat beloofd is, de andere partij het aangeboden actief in ruil kan houden.

En hoe wordt levering versus betaling geïmplementeerd in de financiële wereld? Je raadt het al, via vertrouwde tussenpersonen. Dit kunnen andere banken zijn, verrekenkamers of centrale effectenbewaarinstellingen. Aangezien de meeste transacties van vandaag digitaal plaatsvinden, is dit geen kwestie van het beheer van de overdracht van fysieke certificaten of contant geld. DvP wordt eerder bereikt doordat de tussenpersoon tegelijkertijd een aantal records in hun database bijwerkt en / of instructies naar andere instellingen verzendt.

Levering versus betaling via blockchain

Praten over databases brengt ons netjes bij het onderwerp blockchains. Met een blockchain kan een grootboek of database worden gedeeld en gesynchroniseerd tussen een aantal partijen. In tegenstelling tot reguliere databases kunnen blockchain-databases echter veilig en direct worden gewijzigd door meerdere gebruikers, zelfs als ze met elkaar concurreren. Als je in de IT van een bedrijf werkt, wil je misschien even stilstaan ​​bij de implicaties van die zin.

Om te begrijpen hoe levering versus betaling werkt op een blockchain, moeten we beginnen met het begrijpen van het transactionele model van bitcoin. Opgemerkt moet hier worden dat andere blockchain-ontwerpen een ander model gebruiken voor transacties, en we zullen later meer over deze verschillen praten.

Een bitcoin-transactie heeft een reeks inputs en outputs. Elke ingang is verbonden met één uitgang van een vorige transactie, waarbij alle bitcoin van de vorige uitgang naar binnen stroomt. De bitcoin in de ingangen van een transactie wordt vervolgens herverdeeld over de uitgangen volgens de daarin geschreven hoeveelheden. Bovendien bevat elke transactie-uitvoer de openbare identificatie van de nieuwe eigenaar, waarvoor de eigenaar een bijbehorende privésleutel heeft. Een bitcoin-transactie is alleen geldig als:

• De totale hoeveelheid bitcoin in de invoer van de transactie is groter of gelijk aan de hoeveelheid die in de uitvoer is geschreven. Elk verschil wordt als vergoeding geïnd door de "mijnwerker" die de transactie in een blok bevestigt, waardoor een marktmechanisme ontstaat waarmee transacties kunnen bieden ter bevestiging.
• De transactie wordt goedgekeurd door de eigenaren van elke eerdere output die die transactie “uitgeeft”. Deze goedkeuring wordt uitgedrukt via een cryptografische handtekening van de inhoud van de nieuwe transactie. De handtekening voor een eerdere uitvoer kan alleen worden gemaakt met de privésleutel die overeenkomt met de openbare identificatie.

Beide regels zijn cruciaal in een financieel grootboek dat wordt gedeeld door niet-vertrouwende partijen. Zonder de eerste zou iedereen uit het niets bitcoins kunnen maken. En zonder de tweede zou iedereen de bitcoins van iedereen kunnen uitgeven. Maar we hebben ook een derde regel nodig, die wereldwijd wordt gehandhaafd in plaats van binnen individuele transacties:

• Elke transactie-uitvoer kan slechts door één volgende transactie worden gebruikt. Dit voorkomt een aanval die bekend staat als dubbele uitgaven waarin dezelfde bitcoins naar meer dan één ontvanger worden gestuurd.

Om deze regel af te dwingen, bevat de blockchain een chronologisch logboek van geldige transacties die niet met elkaar in conflict zijn, en dit logboek wordt onafhankelijk geverifieerd door elk knooppunt in het netwerk.

Het bitcoin-transactiemodel kan eenvoudig worden uitgebreid om elk financieel actief te vertegenwoordigen. In plaats van een transactie-output die bitcoins bevat, kan deze een asset-ID en -hoeveelheid bevatten. Alle regels met betrekking tot bitcoin-transacties zijn nog steeds van toepassing, waardoor wordt voorkomen dat deelnemers (a) uit het niets activa creëren, (b) andermans activa uitgeven en (c) hetzelfde activum twee keer uitgeven. Voor niet-cryptocurrency-activa hebben we de neiging erop te staan ​​dat de input- en output-hoeveelheden precies in evenwicht zijn, in plaats van miners toe te staan ​​het verschil te verzamelen.

Dus hoe creëren we een veilige levering versus betalingstransactie met behulp van dit model? Laten we zeggen dat Alice en Bob zijn overeengekomen om Alice's £ 10 in te wisselen voor Bob's $ 15. Gemakshalve gaan we ervan uit dat Alice al precies £ 10 heeft in een enkele transactie-output, en Bob heeft ook $ 15. (Als dit niet het geval is, kunnen ze hun geld gemakkelijk verschuiven om dit mogelijk te maken.)

Om te beginnen bouwt elke partij een transactie met twee inputs en twee outputs. De twee inputs besteden de eerdere outputs met respectievelijk Alice's £ 10 en Bob's $ 15. Wat de uitgangen betreft, de eerste bevat de identificatiecode van Alice en $ 15, en de tweede gaat naar Bob met £ 10. Aangezien de invoer- en uitvoerhoeveelheden in beide valuta's in evenwicht zijn, voldoet onze transactie aan de eerste voorwaarde hierboven. Om aan de tweede te voldoen, moeten zowel Alice als Bob de transactie nu ondertekenen, omdat deze eerdere output van elk van hen besteedt.

De transactie kan nu worden afgerond door deze op de blockchain op te nemen, maar we moeten nog steeds het probleem van dubbele uitgaven overwegen. Wat als Alice een tegenstrijdige transactie had gemaakt door dezelfde £ 10 uit te wisselen met een andere tegenpartij die haar een betere deal aanbood? Hier komt de derde regel in het spel, waarbij de blockchain ervoor zorgt dat elke output maar één keer kan worden uitgegeven. Als de concurrerende transactie wordt verzonden nadat Alice's uitwisseling met Bob op de blockchain zit, wordt deze gewoon niet bevestigd. En als de concurrerende transactie eerst werd bevestigd, mislukt Alice's uitwisseling met Bob. Hoe dan ook, de blockchain zorgt voor levering versus betaling voor de uitwisseling van Alice en Bob, evenals voor elke andere. Als Bob de £ 10 van Alice niet krijgt, krijgt Alice zijn $ 15 niet.

De kracht van partiële transacties

Blockchains bieden ons dus een manier voor twee partijen om samen te komen, een ruiltransactie op te bouwen en te ondertekenen en ervoor te zorgen dat deze als geheel slaagt of mislukt. Dit maakt levering versus betaling op een gedeeld grootboek mogelijk, zonder dat er een vertrouwde tussenpersoon nodig is om het proces te beheren. De mijnwerkers die transacties in blokken bevestigen, hebben nog steeds enige macht, maar het is veel minder dan een traditionele tussenpersoon. Het ergste wat ze kunnen doen is weigeren een bepaalde transactie te bevestigen in zijn geheel, en dit schendt DvP niet. Bovendien, als mijnbouw wordt gedeeld tussen de partijen die de transacties daadwerkelijk creëren, valt dit risico volledig weg, omdat iedereen de kans krijgt om zijn eigen te bevestigen.

Tot nu toe zo goed. Maar blockchains in bitcoin-stijl hebben meer trucs in petto. Bedenk dat een transactie moet worden ondertekend door de eigenaar van elke eerdere output die die transactie uitgeeft. Standaard vergrendelt deze handtekening de volledige lijst van inputs en outputs binnen de transactie. De cryptografie zorgt ervoor dat de kleinste wijziging aan een invoer of uitvoer de handtekening ongeldig zou maken. Om het bovenstaande voorbeeld te volgen, als Bob werd vervangen door Carol nadat Alice de transactie had ondertekend, zou de transactie volledig mislukken.

Maar wat als Alice er niet om geeft met wie ze de uitwisseling uitvoert? Voor de meeste doeleinden waarom zou het haar iets kunnen schelen? Tenzij Alice vastbesloten is specifiek met Bob samen te werken, zijn er slechts twee delen van de transactie die haar echt aangaan. Ten eerste het feit dat haar output van £ 10 wordt uitgegeven, in plaats van een andere hoeveelheid of activa. Ten tweede dat ze in ruil daarvoor $ 15 ontvangt in een nieuwe output. Zolang al het geld in het systeem schoon is, vindt Alice het niet erg waar die $ 15 vandaan komt, of wat er nog meer kan gebeuren om haar uitwisseling te vergemakkelijken.

Misschien komt een enkel feestje samen met $ 15 en ruilt ze een directe ruil voor Alice's £ 10. Maar misschien willen Bob en Carol elk slechts $ 7.50 ruilen. In dit geval zouden ze twee inputs aan de transactie toevoegen, samen met twee outputs die elk £ 5 zouden verzamelen. Of misschien wil Carol eigenlijk $ 15 ruilen voor 950 roebel, terwijl Sasha in Moskou 950 roebel heeft en £ 10 zoekt. In dit geval kan er een 3-way exchange plaatsvinden, waarbij elk feest nog steeds alleen om zijn eigen stukje van de puzzel geeft. De transactie die Alice heeft gestart, kan op oneindig veel verschillende manieren worden afgerond. Maar vanuit het perspectief van Alice bereiken deze allemaal hetzelfde doel: haar $ 15 geven in ruil voor £ 10, en ze maken haar allemaal even gelukkig.

Hoe faciliteert een blockchain dit? Door gedeeltelijke transacties en gedeeltelijke handtekeningen. Alice start een transactie met een enkele input (haar £ 10) en een enkele output ($ 15 voor haar). Ze sluit deze delen van de transactie af met een digitale handtekening waarin staat dat een willekeurig aantal andere inputs of outputs kunnen worden toegevoegd. Ze geeft deze gedeeltelijke transactie aan Bob en zegt 'kijk wat je kunt doen'. Misschien geeft ze het ook aan Carol, en aan een aantal andere potentiële tegenpartijen of syndicaat-bouwers. Elk van deze kan zijn eigen paren van inputs en outputs toevoegen, hetzij om de uitwisseling in evenwicht te brengen, hetzij om een ​​grotere gedeeltelijke transactie te creëren die opnieuw kan worden overgedragen. Wat iemand ook doet, de transactie kan alleen worden uitgevoerd (dwz afgerekend via bevestiging op de blockchain) als de input- en outputactiva in evenwicht zijn.

Een blockchain-transactie is slechts een deel van digitale gegevens, dus deze gedeeltelijke transacties kunnen via e-mail of elk ander communicatiemedium worden verzonden. Ze kunnen zelfs openbaar worden geplaatst, omdat de deelnemers aan de potentiële transactie dat weten de blockchain zorgt voor ze. De handtekening van Alice zorgt ervoor dat ze alleen £ 10 uitgeeft als iemand haar $ 15 in ruil daarvoor geeft.

Als Alice er ten slotte voor kiest om het aanbod uit te schakelen, hoeft ze alleen maar diezelfde £ 10 uit te geven aan een andere transactie, simpelweg door het terug te sturen naar zichzelf. Omdat de blockchain niet toestaat dat dezelfde output twee keer wordt uitgegeven, maakt dit haar bestaande gedeeltelijke transactie waardeloos. Alle andere deelnemers aan de blockchain zullen dit zien en stoppen met het verspillen van hun tijd aan het proberen om de uitwisseling te voltooien.

Van DvP tot slimme contracten

Zoals ik heb eerder betoogdkan een bitcoin-achtige blockchain worden gezien als een manier om synchronisatie en beveiliging in een gedeelde relationele database te beheren. Zowel bitcoin- als databasetransacties worden atomair behandeld, wat betekent dat ze als geheel slagen of falen. De sleutel tot de analogie is de gelijkwaardigheid tussen een transactie-uitvoer in een blockchain en een rij in de database. Een blockchain-transactie die sommige outputs uitgeeft en andere creëert, is hetzelfde als een databasetransactie die sommige rijen verwijdert en in plaats daarvan enkele andere creëert. (Een databasebewerking die een bestaande rij wijzigt, komt overeen met het verwijderen van die rij en het creëren van een nieuwe bijgewerkte rij in plaats daarvan. Deze gelijkwaardigheid ligt ten grondslag aan de populaire rij MVCC methode van gelijktijdigheidscontrole in databases, waarvan bitcoin-achtige blockchains kunnen worden gezien als een gedistribueerde vorm.)

Laten we ons dus voorstellen dat onze financiële gegevens worden bewaard in een database, waarin elke rij drie stukjes informatie bevat: de identificatie van de eigenaar, een activum-ID en een activumhoeveelheid. Een blockchain maakt het mogelijk om dit grootboek veilig te delen tussen de deelnemers, zelfs als ze elkaar helemaal niet vertrouwen. In de taal van databases zorgt het ervoor dat:

• De activumhoeveelheden in de rijen die door een transactie zijn verwijderd, komen overeen met die in de rijen die het maakt.
• Voor elke rij die door een transactie wordt verwijderd (of gewijzigd), moet de transactie worden ondertekend door de eigenaar van die rij.
• Als een databaserij door een transactie is verwijderd, wordt voorkomen dat een andere transactie deze opnieuw verwijdert.

Laten we eens kijken naar de eerste van deze regels, namelijk dat transacties de hoeveelheden van activa moeten behouden. We kunnen dit verbreden tot het algemene idee van een "transactiebeperking". Een transactiebeperking heeft de vorm van een zwarte doos die voor elke transactie twee reeksen rijen ziet: (a) de rijen die door de transactie zijn verwijderd, (b) de rijen die het creëert. Het is de taak van de black box om naar deze twee sets te kijken en met 'ja' of 'nee' te antwoorden of de transactie geldig is. In ons specifieke geval zal het alleen ja antwoorden als de totale activahoeveelheden in beide sets exact overeenkomen.

Zodra we de mogelijkheid hebben om transactiebeperkingen toe te passen, kunnen ze worden uitgebreid met elke set regels. Enkele voorbeelden kunnen zijn: 'een eenheid van dit item kan alleen worden gemaakt als deze drie andere items tegelijkertijd in escrow zijn vergrendeld' of 'dit item kan alleen worden overgedragen als er een overeenkomstige rij is die onvoldoende regen meldt'. Vanuit het perspectief van de gedistribueerde architectuur van een blockchain maakt de logica in de doos geen verschil, zolang het ons een duidelijke en consistente evaluatie kan geven van elke transactie die het ziet.

Dientengevolge kunnen transactiebeperkingen dienen als een algemene methode voor het beperken van de gegevenstransformaties die blockchain-deelnemers kunnen uitvoeren. Deze benadering van 'slimme contracten' biedt een alternatief voor de opgeslagen procedures gebruikt in Ethereum en Eris derivaat. In een toekomstig stuk zullen we dieper ingaan op de voor- en nadelen van deze twee paradigma's, in termen van eenvoud, schaalbaarheid en gelijktijdigheid.

Je kunt volg mij hier op Twitter. Zie ook: Beëindiging van het bitcoin versus blockchain-debat.

Technisch addendum

Gebruik a. Om gedeeltelijke DvP-transacties te bouwen handtekeningtype of SINGLE|ANYONECANPAY. Als je gebruikt MultiChain preparelockunspent, createrawexchange en appendrawexchange API-aanroepen zorg voor de details voor u. Zie de Ermee beginnen pagina voor een eenvoudig voorbeeld van hoe ze kunnen worden gebruikt.

Plaats eventuele opmerkingen op LinkedIn.

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