Understanding off-chain transactions in blockchain for fun and profit

This article is all about explaining why off-chain transactions are beneficial and how they work for a technical as well as non-technical audience.

Permissionless Blockchains

Open and decentralized blockchains, are blockchains where any participant can join and leave the network at any time. Bitcoin and Ethereum are examples of such a blockchain. Unfortunately, permissionless blockchains feature a very low transaction throughput. That means that the number of transactions that the blockchain can allow, is ranging from 10 to 100 transactions per second.

The reason for this low throughput is the security requirement of permissionless blockchains. If a user receives a transaction e.g. TX1, the user wants to verify whether this transaction is legitimate or not. This verification can only happen, if the user is aware of the transactions that preceded TX1. As such, the transaction dependence grows quickly to be very complex. In practice, a user needs to be aware of all transactions happening in the permissionless blockchain to verify newly received transactions. The need of every user to receive all transactions, slows the blockchain network down such that only about 10 to 100 transactions can be verified per second.

Transaction Validation

Every transaction pays a fee to the blockchain network to be validated. Once a permissionless blockchain reaches its transaction limit (around 10–100 transactions per second), the network fee per transaction will naturally grow due to the high demand. The higher the paid fee, the more likely the transaction will be included sooner in the blockchain. In Bitcoin we have already witnessed average transaction fees beyond 10 USD, and average Ethereum fees have already reached 1 USD.

Microtransaction, are transactions with a value of less than 25 USD. If a user wants to transmit only 1 USD, paying a fee beyond 10 USD is certainly not acceptable. The problem is that this market regulating fee price finding reduces the ability of permissionless blockchains to support microtransactions. If heavily used, permissionless blockchains do not allow to send economically viable microtransactions. This has severe consequences, such that only the rich and middle classes can afford to use permissionless blockchains, and that certain applications are simply not economically viable. Moreover, the processing speed on-chain is also a strong limiting factor.

Off-chain payments

Off-chain 2-party payment channels have been proposed as a solution to scaling both costs and speed. An off-chain transaction is one that is not carried out over the blockchain, but over an out-of-band Internet connection. An off-chain transaction is however still secured by the blockchain. In the following we explain why.

2-party payment channels

A 2-party payment channel is built between 2 users only and the channel can be (i) uni-directional or (ii) bi-directional. A uni-directional payment channel allows to send transactions only in one direction, while a bi-directional payment channel allows both parties to send transactions.

Unidirectional payment channel. A has deposited 1 Ether, that A can use to pay B with off-chain transactions.

To open a payment channel, each user should deposit for example 1 Ether in the channel with a traditional on-chain transaction. A payment channel user can then send e.g. 100 times transactions with a value of 0.01 Ether off-chain through this particular channel. Each of these 100 off-chain transactions are secure, because if the user would misbehave, the previously committed on-chain deposit of 1 Ether value would be used to claim the transmitted funds.

Bi-directional payment channel. Both, A and B have deposited 1 Ether in the payment channel, which they can exchange off-chain among each other.

2-party payment channels are a great improvement, but have a few drawbacks. First, off-chain payments can only be carried out with one counterparty. Second, for each new counterparty, a new and separate payment channel needs to be set up. This process locks up a significant amount of value over time.

To reduce the amount of locked up funds, one proposal is to forward off-chain payments along a route of payment channels, building a so-called payment channel network.

If user A and B have a payment channel, and user B and C have a payment channel, then A could send a payment to C over B: A->B->C. Routing payments has two important implications. First, user B would want to be paid to transmit the payment to C. Second, there needs to be a route discovery protocol, to set up the route from A to C and to communicate this route to A. Route discovery and maintenance is a complex topic which increases the complexity of payment channel networks.

User A can route a payment over B to C. Note that B has to lock up deposit with C, to enable A to forward a payment. In return, user B is likely to request a fee from A. Setting up and maintaining routes is tedious and error prone.

Lightning was announced at Scaling Bitcoin in Hongkong in 2015, and shortly after, Raiden announced to build such payment channel network for Ethereum. Raiden recently published uni-directional payment channel software. Lightning has demonstrated prototypes, but both projects have not yet launched bi-directional channels in production.

2-party payment channel hubs

If one node in a payment channel network has a significant amount of funds available, this node could potentially open many 2-party payment channels. Such well connected nodes could operate similar to a “hub”, but they would need to carefully manage the deposit with each user. Imagine in the following figure that user D typically receives few funds from A, B and C, but suddenly is supposed to receive many funds. H would need to shift the deposited ether with costly on-chain transactions and anticipate the behavior of its users.

2-party payment channel hubs. H opens with each user an independent 2-party payment channel. This is problematic, because if D is supposed to receive many funds, the hub would need to switch the allocated collateral with an expensive on-chain transaction.

In the case of a mass exit, the 2-party payment channel hub also suffers from a mass exit of its users.

Lightning, Raiden and TumbleBit enabled nodes can operate 2-party payment channel hubs.

N-Party Payment hubs

Instead of building a payment channel network, the Liquidity.Network is a network of off-chain n-party payment hubs. In a payment hub, the deposit allocated to the hub, can be used freely with all members of the hub. One hub can for example host more than 100'000 users, and thus significantly reduces the costs of setting up and maintaining the off-chain payment capability.

Transmitting funds from one user to the other, does not require each user to provide a deposit (as can be seen in our demo). More importantly, once funds are off-chain, they can be forwarded off-chain without additional deposit of the users. Technically, funds can just stay off-chain and be sent around.

We will be releasing more details as we move along with the implementation. For an early bird access, please register on our website http://liquidity.network