Delivery versus payment on a blockchain

How blockchains can solve the oldest problem in the book

Trading between people is as old as humanity itself. It began at the moment when caveman Ogg said to caveman Ugg: “me give you rock, you give me berries”. But trading carries with it a fundamental problem: it requires trust. What stops Ogg from using the rock to bash Ugg, then grabbing both rock and berries before running away? How do we translate a verbal exchange agreement into an enforcement mechanism that ensures both sides keep their word?

To take a modern example, a few years ago I sold a car on the second-hand market. I found a buyer over the Internet, we met in person, he had the car tested and we agreed on a price. So he went to his bank to get a cashier’s check, which is effectively cash in a more compact form. We walked together to a post office, where I can sign and submit an official government form that transfers legal ownership of the car.

So there we are, standing at the post office window, and we reach an awkward impasse. The check is still in his pocket, and I’m holding the signed form. We met a few hours ago and have no reason to trust each other. Do I hand in the form first then hope he gives me the check, rather than run away? Or does he hand me the check then hope I give in the form? Either way, someone is exposing themselves to the risk of betrayal.

And then it dawned on me that I should stop worrying and just hand in the form. Why? Because one of two things could happen next. Either the buyer hands me the check, in which case everyone’s happy and the exchange is complete. But what if he runs off instead? In that case, the post office clerk will see, and tear up the form I just gave him. Bingo, we have ourselves a safe exchange.

Did you see what happened there? Our dilemma was solved through the use of an intermediary, in this case the post office clerk. The clerk ensures that either a fair transaction takes place, or no transaction at all. And not just any intermediary can provide this service. It has to be someone trusted by both parties. In the case of an employee of a government-owned post office, this stems from our trust in the government itself. If post office clerks could be bribed, either I or the buyer could engineer a situation where we end up with both cash and car. Indeed, in many countries, corruption like this can be a huge drain on prosperity.

Cavemen and cars are one thing, but let’s shift our focus to the financial world, in which trading plays a central role. Of course, banks don’t pay their employees to run off with someone else’s shares. But the safe exchange of financial assets remains an important problem, because there are less cartoonish ways in which participants in a transaction can fail to uphold their promise. For example, one party might become insolvent, or a sudden change in market conditions might prevent them from securing an asset. They can suffer from clerical errors or from the knock-on effects of an accounting fraud at another counterparty.

As a result of these “settlement risks”, most financial transactions are settled using delivery versus payment (DvP). This is just a fancy term for the post office process described above. DvP ensures that, if one party to a transaction doesn’t deliver what was promised, the other party can keep the asset they offered in exchange.

And how is delivery versus payment implemented in the world of finance? You guessed it, via trusted intermediaries. These could be other banks, clearing houses or central securities depositories. Since most of today’s trades occur digitally, this isn’t a matter of managing the transfer of physical certificates or cash. Rather, DvP is achieved by the intermediary simultaneously updating a number of records in their database and/or transmitting instructions to other institutions.

Delivery versus payment by blockchain

Talking about databases brings us neatly to the subject of blockchains. A blockchain allows a ledger or database to be shared and synchronized between a number of parties. However, unlike regular databases, blockchain databases can be safely and directly modified by multiple users even if they are in fierce competition with each other. If you work in corporate IT, you might want to give the implications of that sentence some thought.

To understand how delivery versus payment works on a blockchain, we need to start by understanding bitcoin’s transactional model. It should be noted here that other blockchain designs use a different model for transactions, and we’ll talk more about these differences later on.

A bitcoin transaction has a set of inputs and outputs. Each input is connected to one output of a previous transaction, with all the bitcoin from the previous output flowing in. The bitcoin in a transaction’s inputs are then redistributed across its outputs according to the quantities written within. In addition, each transaction output contains the public identifier of its new owner, for which the owner holds a corresponding private key. A bitcoin transaction is only valid if:

• The total quantity of bitcoin in the transaction’s inputs is greater or equal to the quantity written in its outputs. Any difference is collected as a fee by the “miner” who confirms the transaction in a block, creating a market mechanism by which transactions can bid for confirmation.
• The transaction is approved by the owners of every prior output which that transaction “spends”. This approval is expressed via a cryptographic signature of the new transaction’s content. The signature for a prior output can only be created using the private key which matches its public identifier.

Both of these rules are crucial in a financial ledger which is shared between non-trusting parties. Without the first, anybody could create bitcoins out of thin air. And without the second, everybody could spend everybody else’s bitcoins. But we also need a third rule, which is enforced globally rather than within individual transactions:

• Each transaction output can only be used by one subsequent transaction. This prevents an attack known as double-spending in which the same bitcoins are sent to more than one recipient.

To enforce this rule, the blockchain contains a chronological log of valid transactions which do not conflict with each other, and this log is independently verified by every node in the network.

The bitcoin transactional model can be easily extended to represent any financial asset. Instead of a transaction output containing bitcoins, it can hold an asset identifier and quantity. All of the rules covering bitcoin transactions still apply, preventing participants from (a) creating assets out of thin air, (b) spending other people’s assets, and (c) spending the same asset twice. For non-cryptocurrency assets, we tend to insist that input and output quantities balance exactly, rather than allowing miners to collect the difference.

So how do we create a safe delivery versus payment transaction using this model? Let’s say that Alice and Bob have agreed to exchange Alice’s £10 for Bob’s $15. For the sake of convenience we’ll assume that Alice already has exactly £10 sitting neatly in a single transaction output, and Bob likewise has $15. (If this is not the case, they can easily shift their funds around to make it so.)

To begin with, either party builds a transaction with two inputs and two outputs. The two inputs spend the prior outputs containing Alice’s £10 and Bob’s $15 respectively. As for the outputs, the first contains Alice’s identifier and $15, and the second goes to Bob containing £10. Since the input and output quantities in both currencies balance, our transaction fulfils the first condition above. To fulfil the second, both Alice and Bob must now sign the transaction, since it spends prior outputs belonging to each of them.

The transaction can now be finalized by including it on the blockchain, but we still need to consider the problem of double-spends. What if Alice had created a conflicting transaction exchanging the same £10 with a different counterparty who offered her a better deal? Here the third rule comes into play, in which the blockchain ensures that each output can only be spent once. If the competing transaction is transmitted after Alice’s exchange with Bob is on the blockchain, then it simply won’t get confirmed. And if the competing transaction was confirmed first, Alice’s exchange with Bob will fail instead. Either way, the blockchain ensures delivery versus payment for Alice and Bob’s exchange, as well as any other. If Bob doesn’t get Alice’s £10, then Alice doesn’t get his $15.

The power of partial transactions

So blockchains give us a way for two parties to come together, build and sign an exchange transaction, and ensure that it succeeds or fails as a whole. This enables delivery versus payment on a shared ledger, without needing a trusted intermediary to manage the process. The miners who confirm transactions in blocks still have some power, but it’s much less than a traditional intermediary. The worst they can do is refuse to confirm a particular transaction in its entirety, and this does not violate DvP. Furthermore, if mining is shared between the parties actually creating the transactions, this risk falls away completely, since everyone will get a chance to confirm their own.

So far, so good. But bitcoin-style blockchains have more tricks up their sleeve. Recall that a transaction must be signed by the owner of each prior output which that transaction spends. By default, this signature locks down the full list of inputs and outputs within the transaction. The cryptography ensures that the slightest modification to an input or output would render the signature invalid. To follow the example above, if Bob was substituted for Carol after Alice signed the transaction, then the transaction would completely fail.

But what if Alice doesn’t care who she performs the exchange with? For most purposes, why should she care? Unless Alice is determined to work specifically with Bob, there are only two parts of the transaction that truly concern her. First, the fact that her £10 output will be spent, rather than a different quantity or asset. Second, that she receives $15 in a new output in return. So long as all the money in the system is clean, Alice doesn’t really mind where that $15 comes from, or what else might happen to facilitate her exchange.

Perhaps a single party will come along with $15 and perform a straight swap for Alice’s £10. But maybe Bob and Carol only want to exchange $7.50 each. In this case, they would add two inputs to the transaction, along with two outputs collecting £5 each. Or maybe Carol actually wants to exchange $15 for 950 rubles, while Sasha in Moscow has 950 rubles and is looking for £10. In this case a 3-way exchange can take place, in which each party still only cares about their own piece of the puzzle. The transaction that Alice started can be completed in an infinite number of different ways. But from Alice’s perspective, these all achieve the same purpose of giving her $15 in exchange for £10, and they all make her equally happy.

How does a blockchain facilitate this? Through partial transactions and partial signatures. Alice starts a transaction with a single input (her £10) and a single output ($15 to her). She locks down these parts of the transaction with a digital signature which states that any number of other inputs or outputs can be added. She hands this partial transaction to Bob and says “see what you can do”. Maybe she hands it to Carol as well, and to any number of other potential counterparties or syndicate-builders. Each of these can add on their own pairs of inputs and outputs, either to balance the exchange, or to create a larger partial transaction that can be handed on again. No matter what anyone does, the transaction can only be executed (i.e. settled through confirmation on the blockchain) once the input and output assets are balanced.

A blockchain transaction is just a chunk of digital data, so these partial transactions can be sent over email or any other communications medium. They can even be posted publicly, because the participants in the potential transaction know that the blockchain will take care of them. Alice’s signature ensures that she will only spend £10 if someone gives her $15 in exchange.

Finally, if Alice chooses to disable the offer, all she has to do is spend that same £10 in another transaction, most simply by sending it back to herself. Because the blockchain won’t allow the same output to be spent twice, this makes her existing partial transaction worthless. All the other participants on the blockchain will see this, and stop wasting their time trying to complete the exchange.

From DvP to smart contracts

As I have argued previously, a bitcoin-style blockchain can be viewed as a way to manage synchronization and security in a shared relational database. Both bitcoin and database transactions are treated atomically, meaning that they succeed or fail as a whole. The key to the analogy is the equivalence between a transaction output in a blockchain, and a row in the database. A blockchain transaction which spends some outputs and creates some others is the same as a database transaction which deletes some rows and creates some others instead. (A database operation that modifies an existing row is equivalent to deleting that row and creating a new updated one in its place. This equivalence underlies the popular MVCC method of concurrency control in databases, of which bitcoin-style blockchains can be seen as a distributed form.)

So let’s imagine that our financial data is held in a database, in which each row contains three pieces of information: its owner’s identifier, an asset identifier and an asset quantity. A blockchain enables this ledger to be safely shared between its participants, even if they do not trust each other at all. In the language of databases, it ensures that:

• The asset quantities in the rows deleted by a transaction match those in the rows it creates.
• For every row deleted (or modified) by a transaction, the transaction must be signed by the owner of that row.
• If a database row was deleted by one transaction, this prevents another transaction from deleting it again.

Let’s look at the first of these rules, namely that transactions must preserve asset quantities. We can broaden this into the general notion of a “transaction constraint”. A transaction constraint takes the form of a black box which sees two sets of rows for each transaction: (a) the rows deleted by the transaction, (b) the rows that it creates. The black box’s job is to look at these two sets and answer ‘yes’ or ‘no’ as to whether the transaction is valid. In our specific case, it will only answer yes if the total asset quantities in both sets match exactly.

Once we have the ability to apply transaction constraints, they can be extended to contain any set of rules. Some examples might be “a unit of this asset can only be created if these three other assets are simultaneously locked in escrow” or “this asset can only be transferred if there’s a corresponding row reporting insufficient rain”. From the perspective of a blockchain’s distributed architecture, the logic inside the box make no difference, so long as it can give us a definite and consistent evaluation of every transaction that it sees.

As a result, transaction constraints can serve as a general method for restricting the data transformations that blockchain participants can perform. This approach to “smart contracts” provides an alternative to the stored procedures used in Ethereum and its Eris derivative. In a future piece we’ll dive deeper into the advantages and disadvantages of these two paradigms, in terms of simplicity, scalability and concurrency.

You can follow me on Twitter here. See also: Ending the bitcoin vs blockchain debate.

Technical addendum

To build partial DvP transactions, use a signature type of SINGLE|ANYONECANPAY. If you’re using MultiChain, the preparelockunspent, createrawexchange and appendrawexchange API calls take care of the details for you. See the Getting Started page for a simple example of how they can be used.

Please post any comments on LinkedIn.

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