Payment Channel Networks on UTXO Blockchains

This post was originally a talk delivered at Bitcoin Singapore 2024. Yunwen Liu is a cryptographer at Cryptape. She completed her Ph.D at COSIC, KU Leuven. She published 20+ research papers in venues including Eurocrypt and Journal of Cryptology. She has served on the program committees of Eurocrypt 2022 and ToSC 2022/2023.

Thank you for joining my talk. I’ll be discussing payment channel networks (PCNs) in UTXO blockchains, in particular, how to design a payment channel network on the Nervos blockchain.

First, let’s address the fundamental question: Why do we need a payment channel network for a blockchain?

The main reason is scalability, and the second is transaction cost. Sending transactions on-chain means that you have to pay transaction fees for each transaction, and the cost could be too large for micropayments. That’s why two users who frequently engaging in transactions with each other prefer depositing coins in a channel to enable off-chain transactions to circumvent high on-chain cost. Interoperability is another reason. Currently, various payment channels operate on different blockchains, but they are not well connected, like isolated islands with different currencies and languages. For UTXO blockchains, such as the Bitcoin and CKB, we aim to build an interoperable cross-chain transaction system, allowing payments on the second layer across different blockchains, without submitting transactions on-chain every time.

Now, why PCNs on Nervos CKB?

As a UTXO-based blockchain, CKB inherits advantages of the UTXO model, while empowering functionalities not possible in Bitcoin. CKB is stateful, with a Turing-complete virtual machine to run general smart contracts. Moreover, CKB supports any signature schemes or hash functions, so users can choose based on their preferences. Such freedom enables seamless interaction with other blockchains, regardless of the cryptographic primitives they use. We are confident that CKB is the best platform to build a PCN that connects layer two ecosystems.

Then, what are the design goals for PCN on CKB?

We aim to realize three functionalities in CKB PCN. First, users can open and close a payment channel supporting user-defined tokens. This empowers users with a versatile selection of tokens, so they can make better decisions based on their specific applications. Second, in the network, users can make multi-hop transactions with parties not directly linked. Third, we implement cross-chain payments through payment channels, a pivotal feature fostering interoperability with other blockchains, including Bitcoin.

With these goals in mind, I will briefly discuss the factors considered for designing PCN on CKB.

First, what kind of channel do we want?

Given our support for user-defined tokens, we need a place in the UTXO to put token contracts. Therefore, a simple 2-of-2 multisig address is not enough. Additionally, we support Dual funding, which introduces implementation complexities. To enable more PCN functionalities, such as rebalancing or watchtowers, we may need to define channel contracts. Consequently, both channel contracts and token contracts are stored in the UTXO. In contrast to a PCN project named Perun, where channel and assets are stored in different UTXOs but bond together with contracts, I find this approach challenging for compatibility with Bitcoin lightning network, mostly because of implementation complexity.

Another consideration is to choose adaptor signature over HTLC in atomic multi-hop payment path and atomic cross-chain channel payment. Despite HTLCs’ popularity, adapter signatures are preferred for several reasons.

First, HTLC faces various attacks. The figure below shows the wormhole attack on HTLC. Using HTLC also poses a risk of privacy leakage, because all channels share the same preimage. Plus, compatibility issue arise when attempting to connect with some blockchains that do not support HTLC.

Wormhole attack on HTLC

Adaptor signature can avoid the above-mentioned problems, thus is preferred for its security and privacy. Although, despite our continued support for HTLC in our PCN due to legacy reasons, it is up to the users to choose their preferred schemes. A challenging open question is that how can we make a universal solution to ensure compatibility with channels using different lock protocols.

But is adaptor signature the final answer?

Maybe not. Diving deeper, considering collateral time in multi-hop payments, both HTLC and adaptor signature-based protocols are not optimal. I will share some observations on this issue.

The discussion on staggered collateral comes from the Griefing Attack in the lightning network. An attacker exploits these attacks to freeze the liquidity of the intermediate nodes, by locking their collaterals in the HTLC contract. When the payment path is long, the attacker locks only one coin in the contract, while the intermediate nodes collectively lock many coins, leading to an unfair situation. Collateral, defined as the number of coins times their lock duration. The number of coins in a payment path is proportional to the number of nodes, meaning that more hops, more collaterals locked. Lightning network has a staggered collateral, because the time lock duration is proportional to path length. In the worst case, the collaterals may stay locked up to about one week.

How to fix it? We will cover three solutions and their pros and cons.

The first solution is to reduce the number of hops. For instance, in a payment channel hub, there is a node called Tumbler that facilitates transactions by maintaining channels with many users. The second solution is to open virtual channel for two nodes that are not directly linked, exemplified by Perun.

Are they the solution to our problems? I would say, no.

Payment channel hubs have disadvantages. To give one example, if all channels connect to one single hub, a centralized node might lead to numerous privacy problems. Avoiding a highly centralized payment channel network is imperative.

Another issue is, what if a channel is depleted? Without loop in the hub, we cannot use rebalancing to top up off-chain, which is less efficient. Of course, in practice, there can be multiple Tumblers, each one consisting of a hub, interlinking payments across hubs. But this will increase the number of hops required.

Notice that to reduce the collateral time, we need to make channels update all together. And this can be achieved by smart contracts. In Sprites protocol, a global smart contract called preimageManager coordinates simultaneous channel openings by verifying if Preimage of hash has been published on-chain before timeout T. This is a neat solution. However, implementing preimageManager requires smart contracts, not compatible for Bitcoin. Another downside is that it doesn’t use onion routing to protect the path information, posing privacy concerns.

If we don’t want to use smart contracts, Blitz protocol that only uses bitcoin scripts comes as an alternative. It relies on auxiliary transactions for atomic state updates. When all channels initiate their payment transactions, they expect them to be confirmed on-chain after time T under normal conditions. If there is a malicious action, the sender can create an enable-refund transaction to trigger revoke procedure before time T and this will refund the coins to the sender of each channel. Otherwise, all payment channels update simultaneously after the time lock. In this protocol, if all users are honest, they must wait for time T to finalize the transaction, which is not favorable.

The table below summarizes the pros and cons of protocols for multi-hop payment we investigated in the design procedure. While I will not go into all the details, I aim to share my insights gained from our analysis.

A summary of the pros and cons of the protocols for multi-hop payments we've investigated

We observed that HTLC and adaptor signature-based protocols are not optimal in terms of collateral. In technical level and in implementations, it is non-trivial to achieve constant lock time for multi-hop transactions. Although CKB supports smart contracts, compatible with all the protocols shown above, it takes considerable implementation effort to deploy such protocols in a PCN network. We have to consider the full picture and make tradeoffs, considering efficiency, implementation cost, and compatibility with other components in the channel.

I think it is an interesting question to ask, how to make an adaptor signature-based protocol with constant lock time.

To conclude, we are designing a PCN on Nervos CKB to connect the payment channel network ecosystems. And we’ve discussed several factors influencing the design and shaping our choices of components in the PCN. As an example, we showed why constant lock time is non-trivial to achieve in PCNs. While we haven’t covered all design factors in this talk, like atomicity, off-chain smart contracts, anonymity, routing, etc., our PCN promises a secure, private, and efficient layer two ecosystem empowered by CKB.