Introduction to Ethereum Payment Channels
I no longer post directly on Medium; to view the latest copy of this article please go to https://www.wealdtech.com/articles/introduction-to-ethereum-payment-channels/
Ethereum and related blockchain technologies are known for their ability to transfer money in a decentralised and trustless manner, but struggle to carry out micropayments in a cost-effective fashion. This article discusses the problem with using transactions for micropayments, introduces payment channels, and provides an overview to how they work.
A simple Ethereum payment looks roughly like the transaction below:
Ether is sent from the sender’s wallet to the Ethereum network. The network allocates that amount to the recipient’s wallet. It also takes an additional sum — the transaction fee — in payment for its services, represented in the diagram as the small additional amount sent along by the sender.
This is all well and good when sending relatively large amounts (at time of writing 1 Ether is worth about $300USD) but causes a problem when a sender wants to make a much smaller payment. For example, if the sender wanted to send just 0.0001 Ether ($0.03USD) then the transaction would look like this:
Because the transaction cost is independent of the amount of Ether being sent it is now more than double the value of the funds. Having to pay $0.06 to send $0.03 is obviously not a useful solution, and so another way of sending guaranteed small payments across the network had to be found.
The solution? Payment channels, which break the part where the sender deposits the funds to the network and the part where the receiver obtains the funds from the network in to two separate activities, as shown below:
The dotted line moving from top to bottom of the image represents time moving on. We also have another new idea in this diagram, which is that some of the funds deposited can be returned to the sender.
How does this operate? First, the sender deposits their funds by sending an appropriate transaction to the network:
The deposit is registered in the blockchain just like any other transaction, providing a public confirmation that the sender has deposited funds.
Next, the sender sends any number of payment promises directly to the recipient. Generating a payment promise is a way of the sender saying to the recipient “If you send a transaction containing this promise you will receive these funds” but, crucially, is not itself a transaction. This means that any number of promises can be generated without the cost of transaction fees. For example, the sender might promise the recipient 0.01 Ether:
The recipient can use the information in the blockchain to confirm that the promise they have been given is good. In this case, “good” means “can be sent to the network to receive these funds”.
At a later date the sender might promise an additional 0.01 Ether to the recipient, so they create a new promise for 0.02 Ether (the original 0.01 Ether plus the additional 0.01 Ether) and send that directly to the recipient, again bypassing the network:
At this point, it is important to realise that promises are not cumulative. The recipient is holding a promise for 0.01 Ether and a promise for 0.02 Ether, but can only use one of them. This is because sending a transaction containing a promise to the network will close the channel and void all other promises. Obviously in this situation the recipient would send the highest-value promise to the network.
Let’s see that last point in operation. We’ll assume that the channel has gone on for a while longer and the recipient is now holding a promise for 0.4 Ether. They send a transaction containing this promise to the network:
Sending the promise to the network causes it to honour the promise, sending 0.4 Ether to the recipient. This action terminates the payment channel so the unspent deposit, in this case 0.6 Ether, is returned to the sender.
If we look at the transaction costs for using the payment channel to aggregate 40 0.01 Ether transactions compared to sending individual transactions we have:
- Cost for the individual payments is 40 * 0.00021 = 0.0084 Ether
- Cost for the payment channel is 0.001 + 0.0005 = 0.0015 Ether
and the relative benefit of payment channels increases as the number of transactions increases and/or the value of each individual transaction decreases (note that these transaction costs are illustrative rather than guarantees for any particular payment channel implementation).
The above calculation highlights the main area in which payment channels are most useful: aggregating a large number of relatively small transfers where the transaction cost is an appreciable percentage of the value transferred. This has an added benefit in that promises can be confirmed in milliseconds rather than waiting for confirmations from the blockchain. That said, there are other opportunities to use payment channels and payment promises.
This article provides an overview of payment channels but questions remain: what does the smart contract at the heart of payment channels look like? How exactly does a sender open a channel? What is inside a promise? It also ignores some of the realities of Ethereum, for the sake of keeping the introduction simple. The next article will provide details about implementing payment channels with Ethereum.
