Second generation of Bitcoin scaling

In the last post we discussed different Blockchain scalability approaches including Perun’s virtual channels. Despite its usefulness, Perun’s protocol leverages the smart contract language of Ethereum. In other words, Perun can be deployed only on Blockchains which allow execution of Turing-complete programs. This limitation, however, prevents Perun from being deployed over Blockchains with less expressive scripting languages, such as Bitcoin. In this post we summarize a new solution for building virtual channels over such Blockchains as well.

The concept of off-chain solutions in Blockchain networks follows the idea of lifting computation “off-the-chain” in order to reduce Blockchain interaction and thereby improving Blockchain scalability. In order to achieve this, all off-chain solutions rely on the security of the underlying Blockchain, i.e., the Blockchain provides a trust anchor that honest parties can rely upon in case a dispute occurs during the off-chain computation.

Prominent examples for off-chain solutions are payment channels, which allow two parties to issue payments between each other with only few on-chain operations. Perun’s virtual channels enhance these regular payment channels by further reducing the amount of required Blockchain interactions, guaranteeing faster and more flexible payments.

In order to achieve security in Perun’s protocol, however, the underlying Blockchain is required to support Turing-complete smart contracts, which can act as a judge when it comes to a dispute between protocol participants. This drawback makes the previous virtual channel solution inapplicable to all Blockchain networks that support only limited scripting languages as the available scripting functionalities are simply not powerful enough to settle disputes.

In this post, we present a virtual channel construction that supports any UTXO-based Blockchain and requires only the minimal scripting functionalities of signature verification and timelocks. In order to simplify the description, we will explain the construction with regard to Bitcoin.

Since virtual channels are based on regular payment channels, we will first briefly recall one of the most prominent payment channel constructions over Bitcoin, namely the lightning network.

Payment Channels over Bitcoin

A payment channel in the lightning network consists of three phases:

1. Channel Opening: In this phase both users, let’s call them Alice and Bob, lock their coins in the channel. This involves publishing a transaction to the Blockchain which is called the funding transaction.
2. Payment: In this phase, Alice and Bob can make off-chain transactions and update their balances. This usually involves exchanging transactions referred to as commit transactions, which can later be posted on the Blockchain in order to release the coins locked in the channel. Furthermore, the parties invalidate previous commit transactions via a mechanism called revocation.
3. Channel Closing: Alice and Bob can close their channel on-chain and release the locked coins by publishing the latest commit transaction on the Blockchain.

However, as Bitcoin’s scripting language is limited, lightning channels have an additional phase called punishment. In this phase, if one of the users, let’s say Bob, tries to cheat (i.e., by trying to publish an invalidated commit transaction), Alice can punish Bob and earn all the coins that are locked in the channel. The punishment mechanism in lightning is based on revocation and state duplication, i.e., each user, in this case Alice and Bob, has a distinct commit transaction.

An extension of simple payment channels are so-called payment channel networks (PCNs), which consist of multiple payment channels that are all connected with each other, thereby building a network of channels. Lightning supports this extension (hence the name lighting network). A PCN allows two parties who are not connected directly through a channel to make transactions via some parties, called intermediaries. For instance, Alice and Bob who both have a channel with Ingrid can make transactions to one another. This, however, requires Ingrid to be involved in each transfer between the end users. This drawback of PCNs can be mitigated by using virtual channels.

Virtual Channels over Bitcoin

We now explain our construction for virtual channels that work over UTXO Blockchains with limited scripting languages such as Bitcoin. We first recall the usual setting for virtual channels. Consider two parties, Alice and Bob, want to build a virtual channel between each other and assume that both maintain a regular payment channel with a third party, which we call Ingrid. A virtual channel has basically the same structure as a regular payment channel, i.e., it consists of a funding and commit transactions, and it is composed of the same three phases, namely opening, payment and closing. Conceptually, the only difference to a regular payment channel is that the funding transaction is never published to the Blockchain in case all involved parties behave honestly. This structural similarity of regular and virtual channels, makes it possible to transform a virtual into a regular channel by simply publishing its funding transaction on the Blockchain.

Let us now describe the three phases of a virtual channel’s lifetime in a bit more detail:

1. Channel Opening: A virtual channel is funded by the two underlying payment channels, i.e., by the channels between Alice — Ingrid and Bob — Ingrid. In order to open a virtual channel, Alice, Bob and Ingrid have to jointly generate a funding transaction, such that the inputs to the funding transaction are outputs of the commit transactions of the channels Alice — Ingrid and Bob — Ingrid. Once this virtual channel funding transaction is generated, Alice and Bob can create commit transactions that spend the funding transaction and start issuing off-chain payments to each other.
2. Payment: A payment in a virtual channel works in exactly the same way as in regular payment channels, i.e., Alice and Bob simply exchange signatures on commit transactions in order to make a payment.
3. Channel Closing: In order to close a virtual channel, Alice, Ingrid and Bob have to make sure that (1) the virtual channel’s funding transaction cannot be published to the Blockchain anymore and (2) the coin distribution between Alice and Bob from the virtual channel is reflected in the underlying channels. In order to make sure that both of these conditions hold, Alice, Ingrid and Bob have to update their respective channels to a new state which represents the correct coin distribution from the virtual channel. Since an update involves the generation of a new commit transaction and revocation of the old one, the virtual channel’s funding transaction cannot be published anymore after the update of the underlying channels.

Virtual Channels — An Example

Let’s assume that Alice and Ingrid maintain a payment channel in which they own 5 coins each and the same holds for the channel between Bob and Ingrid. Now let’s assume that Alice and Bob want to open a virtual channel, in which each of them deposits 5 coins. The three phases as described above then work as follows:

1. Channel Opening: Alice — Ingrid and Bob — Ingrid update their respective payment channels such that the new commit transaction has an output containing 5 coins from Alice (Bob respectively) and 5 coins from Ingrid which can be spent only with signatures of all three parties. As a next step, the three parties jointly generate a funding transaction, which takes as inputs the outputs of the newly generated commit transactions. Note that the funding transaction includes inputs worth 20 coins (10 coins from channel Alice — Ingrid and 10 coins from channel Bob — Ingrid). The virtual channel’s funding transaction contains two outputs: (1) 10 coins can be spent with signatures of Alice and Bob and (2) 10 coins can be spent with a signature of Ingrid.
   Once the funding transaction is generated, Alice and Bob create a commit transaction which spends output (1) of the newly generated funding transaction in such a way that Alice and Bob each own 5 coins.
2. Payment: As already mentioned, issuing payments in a virtual channel works exactly like in regular payment channels. Assume Alice wants to pay 1 coin to Bob, then Alice and Bob exchange signatures on commit transactions that now let Alice spend 4 and Bob 6 coins.
3. Channel Closing: Assume the final state of the virtual channel is that Alice owns 3 coins and Bob owns 7 coins and both parties want to close the channel now. In order to do so, the channels Alice — Ingrid and Bob — Ingrid have to be updated in such a way that the underlying channels reflect the end balance of the virtual channel. In more detail, Alice — Ingrid update their channel such that Alice owns 3 coins and Ingrid owns 7 coins and Bob — Ingrid update their channel such that Ingrid owns 3 coins and Bob owns 7 coins.
   Note that Ingrid did not lose any coins but merely moved some of her coins from one channel to the other.

Handling Malicious Behavior

The main technical challenge in our virtual channel construction is to deal with malicious behavior of one or even two colluding parties. The difficulty here arises from the fact that Alice does not have any control over the channel between Bob and Ingrid and vice versa. The only party that is part of both channels is Ingrid, who acts as a mediator between Alice and Bob. In other words, Ingrid has to guarantee Alice and Bob respectively that in case a dispute happens, she will identify the malicious and compensate the honest party. In order to make such a guarantee, Ingrid has to lock coins as collateral during the virtual channel creation, which will be refunded to her if no malicious behavior occurs (this is output (2) in the funding transaction of the previous example.).

But in which scenario would a malicious party (let’s say Bob) even cheat?

Clearly, if the state of the virtual channel is financially advantageous to Alice, Bob has an incentive to close the virtual channel without having its coin distribution reflected in the underlying payment channels. The only way Bob can accomplish this is by publishing an outdated state of his channel with Ingrid to the Blockchain. This would prevent Alice and Ingrid from publishing the funding transaction of the virtual channel and hence, the virtual channel would be maliciously closed such that Alice has no way to receive her correct balance from the virtual channel anymore.

If such a case happens, we need to ensure that Alice can punish Ingrid, and likewise, Ingrid can punish Bob such that Ingrid and Alice get financially compensated. The same technique can then be applied in case Bob colludes with Ingrid, such that Alice can still punish Ingrid and receive financial compensation.

In our virtual channel construction, we introduce a novel punishment mechanism which satisfies the above described criteria. In a nutshell, we need to ensure that a party can publish the funding transaction of the virtual channel on the Blockchain at any time (and consequently transform it into a regular payment channel). Assume Alice attempts to post the funding transaction of the virtual channel by closing her underlying channel, then Ingrid and Bob have a limited amount of time to close their channel such that the funding transaction of the virtual channel can be posted. If, however, the channel Bob — Ingrid is not closed in a timely manner, Alice receives all the funds in her channel with Ingrid, which, in essence, punishes Ingrid. In other words, Ingrid should never collude with Bob in order to steal Alice’s coins as she will get punished for it.

Why Lightning Channels are not ideal

As already mentioned, channels in the lightning network consist of one funding transaction and two distinct commit transactions per state update, i.e., both channel participants have a different commit transaction for the same channel state. This so-called state duplication, however, leads to a problematic situation when constructing virtual channels on top of lightning channels. Recall that the funding transaction of a virtual channel is funded by the two underlying payment channels, i.e., by a commit transaction of channel Alice — Ingrid and Bob — Ingrid, respectively. If now there are two commit transactions per channel, the virtual channel cannot consist of just one unique funding transaction, but rather of a total of four funding transactions (all possible combinations of commit transactions from the underlying channels). Consequently, upon opening a virtual channel, Alice, Ingrid and Bob have to prepare all four corresponding funding transactions as they do not know in advance which of these commit transactions will actually be published.

Due to this reason, in our virtual channel construction, we use channels which do not rely on state duplication. These channels have been introduced by Aumayr et al. as an instantiation of so-called generalized channels.

Benefits of the virtual channel technology

Due to the fact that a virtual channel can be created, maintained and closed entirely off-chain, i.e., without requiring any on-chain transaction, it proves to be an immensely versatile tool in practice as it allows for fast and cheap microtransactions between two parties.

As compared to existing channel technologies such as the lightning network, virtual channels do not require intermediaries to be involved in all transfers between end users, but just during the creation and closure of the virtual channel. This can be particularly useful in a so-called payment channel hub, a payment system where multiple parties can pay each other off-chain through one joint intermediary, the hub. Instead of involving the hub in each single transfer between the parties, which can result in a huge burden for the hub, parties can simply create virtual channels with the hub as intermediary, thereby relieving the burden on the hub.

The same idea of unburdening intermediaries via virtual channels can be utilized to construct a combination of PCNs and virtual channels. Consider a specific path in a PCN that is used by many parties at the same time to issue payments. Intermediaries on this path would be involved in every single transaction, putting a high burden on them. Instead, the end points of this path can simply create a virtual channel, thereby skipping the intermediaries.

Use cases for virtual channels

Payment solutions

Perun virtual channels provide true peer-to-peer payments to businesses such as payment service providers and can be used both for blockchain systems as well as centralized payment systems or a combination of both. Payment service providers play the role of operators of payment hubs and manage the connections between users and are responsible to resolve conflicts between users. True micropayments are currently not possible with existing payment solutions such as Paypal or VISA.

Energy/mobility

Especially in fast paced environments where thousands of IoT devices exchange transactions on a subsecond basis, virtual channels provide a versatile tool for use cases of the future. Companies for example in the energy and automotive industry will have to come together to solve emerging problems such as the growing energy demand. This requires newly decentralized systems such as smart grids to load balance energy grids and incentivize users to charge their cars when excess energy is available. Further the integration of local grids and communication between them will become necessary and makes these types of energy systems even more complex and requires technologies such as virtual channels to offer a fast, reliable and secure experience without a central trusted operator.

E-Commerce and market places

In tandem with the digital transition, more and more goods are being acquired and exchanged entirely in digital form. This includes, for example, collectibles in online games that can be acquired and traded on digital trading platforms. The decentralized approach provides more security and transparency, since the involvement of several operators makes it possible, for example, to trace the duplication of objects using the blockchain and to restrict it via majority voting. Virtual channels in this scenario can further decrease transaction costs and provide fluid interactions and trades via marketplaces.

In the next blog post we will dive deeper into these exciting use cases and show examples where the Perun channel technology can help businesses create scalable and efficient blockchain solutions.

Thanks for reading!

Stay tuned for more exciting posts on off-chain solutions and visit our website perun.network or check out Github. You can also follow us on LinkedIn and Twitter for more information about our recent activities.