Atomic Swaps and HTLCs

Atomic swaps are a method of exchanging one asset for another, such as two cryptocurrencies, even if they exist on distinct blockchains. The idea is to do this in a trustless way, avoiding counterparty risk, so that the swap either goes ahead and both parties receive what was agreed, or the whole thing is cancelled. It should not be possible for one ‘leg’ of the exchange to go through on its own without the corresponding payment. So, we can treat the entire exchange as a single trade which either goes through or not. As separate blockchains exist in isolation, and cannot directly communicate, atomic swaps are a useful cross-chain solution. They help to build a more interoperable ecosystem of interacting blockchains. Furthermore, atomic swaps can also be used with off-chain payments such as on the lightning network, connecting these with on-chain transactions.

atomic
If Alice hands over her bitcoin first, can she trust Bob to give her the ether?

Consider the scenario: Alice owns bitcoin, which she wants to use to purchase ether from Bob. The exchange rate (BTCETH) at the time is about 13. So, they agree to a swap where she sends one bitcoin to Bob and, in return, he sends 13 ether to Alice’s Ethereum account address.

This is fine in theory but, before sending her payment transaction to the Bitcoin blockchain, she has second thoughts. What happens if Bob does not submit his corresponding transaction? In that case, she will have sent him the bitcoin with nothing in return. Can he really be trusted? So, she asks Bob to submit his transaction first. However, Bob is also not really sure that he can trust Alice. If he submits his Ethereum transaction before Alice’s payment is confirmed, how can he be sure that he will be paid? To be safe, both parties in this transaction want the other to confirm their payment first. Consequently, they do not go ahead with the exchange.

What can be done to resolve the issue of trust and counterparty risk? This is not something specific to cryptocurrencies. Whenever two parties want to exchange any items of value, there is the possibility that one of them will not follow through with their side of the agreement. Here are three possible solutions. Continue reading “Atomic Swaps and HTLCs”

Proof of Stake

I previously described how Bitcoin is secured by a Proof of Work (PoW) protocol. Now, I describe an alternative method of achieving the same goal — Proof of Stake (PoS). This is currently being used for some blockchains, such as Cardano, and there are also plans for Ethereum to move from its current PoW incarnation to a PoS system. Both methods have their benefits and drawbacks, with PoS requiring much less energy but, on the other hand, is more complex with more possible attack vectors. Opinion is divided on which is the better,with defenders of either system having very strong convictions. In this post, I concentrate on describing how proof of stake works and only briefly touch on the possible benefits of one method over another. There are many different implementations of proof of stake so, here, I give an overview of the methods used without concentrating on any one particular utilization.

As explained in an earlier post, whichever method is used to secure a blockchain, it should require miners to spend some resource in order to build blocks. For PoW chains like Bitcoin, this resource is computing power or hashrate. For PoS chains, the resource is the underlying tokens or cryptocurrency represented by the blockchain itself. More precisely, as it just requires miners to lock up coins for a period, it is the opportunity cost of these coins that they spend. This is an internal resource of the blockchain rather than an external one as with PoW. Before going any further, there is a slight matter of terminology. The people who build blocks for a proof of work chain are called miners whereas, in proof of stake, they are called validators. Other terms, such as forgers, are also in use. Personally, I think it would have been simpler to use the same word regardless of the protocol but, to be consistent with the common usage, I will refer to block builders as validators.

Let’s just refresh our understanding of what a protocol needs to do. It should;

  • allow anyone with the necessary resources to participate in building the blockchain.
  • allow the network to reach agreement on a single global blockchain state at each time.
  • (immutability) ensure that, once a block is added and considered to be confirmed, then it will remain in the chain indefinitely.

Furthermore, these properties should continue to hold even in the event that a minority of validators are acting dishonestly or, even, are collaborating to attack the network.

In proof of stake, individuals register to become a validator by locking up a quantity of the blockchain asset. The protocol then divides up time into a sequence of successive slots, one for each block. It needs to assign one validator per slot, and do this in a way such that, on average, the number of slots assigned to each validator is in proportion to their stake size. Then, when their time slot is reached, it is the job of the validator to collect together transactions from the mempool, and construct a valid block to append to the chain. In return, they receive a reward which can be one of, or a combination of, the transaction fees in the block and the block reward.

building a blockchain
Figure 1: Validators building a blockchain.

Each block is appended to the one constructed in the previous time slot so that, as time progresses, the validators continually add blocks on top of blocks, building the chain. Figure 1 shows this procedure with the cryptopunks acting as validators. Unlike with PoW where anyone who is able to create a valid block can submit it for inclusion, here the protocol needs to verify that the block used in each time slot has indeed been created by the validator assigned to it. This can be achieved with public key cryptography where, when they purchase a stake, each validator has to supply a public key. They then sign their blocks using the associated private key, proving that they were created by or, at least, approved by the assigned validator. Continue reading “Proof of Stake”