The last three articles have discussed the design and implementation of payment channels. It is now time to understand both their uses and limitations, with a critical examination of the use cases for unmanaged payment channels.

Payment channels have two main use cases: service provision and delayed transactions. Details of these are below.

Use Case: Service Provision

The classic use case for payment channels is micropayments. Obvious examples are current utility and subscription services, for example an internet service provider or electricity company. These companies currently choose one of two models to charge customers: either a flat rate subscription with limits or a metered service paid in arrears. Both models have significant drawbacks for either or both of the producer and consumer of the service, ultimately resulting in increased costs for the consumer.

Taking the example of an internet service provider using a flat rate subscription, the graph below shows the data usage in solid green and the payments to the service provider in dashed blue:

Traditional mismatch between data usage and billing for an internet service provider

The two lines have no relationship to one another, meaning that there are times the consumer and internet service provider are both paying for data that is not used. Payment channels can be used to provide a billing system that is fairer to both parties.

Before opening the channel the service provider and consumer must agree upon the unit cost and supply of the service (for example, 0.0004 Ether/GB of data) and the off-chain mechanism to pass promises from consumer to the service provider. The service provider also provides the consumer a short grace period, during which the consumer can use data prior to paying for it.

The consumer opens the payment channel to the provider for an agreed-upon billing period e.g. a month. As the consumer uses data they build up an amount of money owed, and before their grace period expires they send a payment promise to the provider to cover their usage. This starts a new grace period, and the consumer continues to send payment promises as they use data.

The above process continues until the end of the month, at which point the provider uses the last promise sent by the consumer to close the payment channel. The consumer then opens a new payment channel to the provider and the next billing cycle starts.

Matching data usage and billing with payment channels

The two lines now show a clear relationship between usage and billing.

This model can be used in a number of other areas such as media (pay per minute of video viewed, pay per article read) and volume work (pay per hundred words proof-read). In general, this model works wherever a service is delivered with a cost, including where the costs are implicit (e.g. advertisements in web pages and apps).

Use Case: Delayed Transactions

Another use case for payment channels is delayed transactions. An obvious example of this is an Initial Coin Offering (ICO).

ICOs have been in the news recently for their deleterious effect on the Ethereum network, with massive spikes in transaction volume at the time that an ICO begins. This has multiple problems: non-ICO transactions are delayed, transaction costs increase hugely as users attempt to out-spend each other for their transactions to be included, and the impression for normal users is that the Ethereum network has simply stopped working.

The graph below illustrates this problem, highlighting the jump in transaction volume immediately after the start of the ICO.

Traditional ICO impact on Ethereum network

Standard unmanaged payment channels can be used to significantly reduce the rush of transactions over a short period of time, as follows: a company wishing to run an ICO decides to run it with these rules:

potential investors need to open a payment channel to the ICO’s address any time up to the published start date of the ICO. The payment channel must expire 1 week after the ICO start date for the company to consider the channel valid

once the ICO starts potential investors can send off-chain requests to the company over the following 3 days, providing the information about their payment channel and the amount they wish to invest. The company responds to each request stating whether the potential investor has been accepted in to the ICO

potential investors who have been accepted send an off-chain payment promise to the company. The company closes the payment channels with the promise in return for ICO tokens at some point before expiry of the channel (which will be 1 week after the ICO start date, as per the first rule)

potential investors who have not been accepted expire their channel once the expiry time has passed and retain their original funds

Using the above system there is no incentive for ICO participants to open a channel early prior to the ICO, nor is there a need for the company running the ICO to close the channels in a rush. This results in a much flatter transaction graph, as shown below:

Payment channel impact on Ethereum network

In this scenario, optional changes to the standard payment channel could provide additional significant benefits. Specifically, the contract could disburse the ICO tokens on close of the payment channel and also recognise when an ICO is fully subscribed, allowing unsuccessful participants to retrieve their deposited funds before the payment channel’s natural expiration.

Benefits of Unmanaged Payment Channels

What has become the identifying feature of payment channels is also their most important benefit: the ability to carry out off-chain payments. Without payment channels all transactions are limited by the speed and capacity of the Ethereum network, and suffer a minimum transaction cost, all of which are affected by other transactions on the network and so have the additional issue of inconsistency.

The other major benefit of payment channels is their ability to provide proof that a payment can be made without requiring a network transaction. This allows the proof of payment and actual payment to be separated in time, letting the participants choose the conditions under which to open and close the payment channel.

As can be seen from the examples outlined earlier in this article: payment channels are useful when surety of payment is required but immediate payment is either unnecessary, undesirable, or impractical.

Limitations of Unmanaged Payment Channels

Despite their uses, unmanaged payment channels also have their limitations.

The first is one that is implicit throughout the use cases presented above as well as in previous articles: a mechanism is required to pass promises from sender to recipient.

The second limitation is that payment channels have no context. The sender can promise Ether to the recipient, but there is nothing in the payment channel to allow the two parties to agree upon what the payment represents. This is especially important with long-lived payment channels, where the value of the funds initially deposited in the payment channel and the value of the product or service being purchased with those funds can vary.

The third and final main limitation of payment channels is a dilemma: the longer a payment channel stays open the more cost-effective it becomes, but the longer the funds deposited are unavailable to either party. This can be understood with two examples.

In the first, the participants set up a payment channel, transfer a single promise, and close the channel. The cost savings for the single transfer are minimal but the sender and receiver have access to their funds almost immediately.

In the second, the participants set up a payment channel and transfer many promises without ever closing the channel. The cost savings are now huge, but neither participant ultimately receives their funds.

Picking a suitable expiry for a payment channel will depend on the needs of the participants, and may well be different for each pair. Ultimately, both participants will need to compromise.

There are some other limitations of payment channels, but the above are the most critical ones in the context of deploying payment channels in a real-world situation.

Summary

Payment channels are a good solution to a specific set of problems, but they create issues of their own when they move from the purely technical realm and attempt to solve real business problems.

The next article introduces the Orinoco Hub, a payment channel management system that addresses the limitations laid out above and more, allowing payment channels to be seen as a tool of real business use.