Layer 2 is a popular solution to the blockchain scalability problem, which, unlike implementing alternative consensus schemes and side chains, avoids the risk of forking the blockchain. A main approach in layer 2 is to open off-chain channels where two parties communicate for transactions and smart contracts outside of the underlying layer 1 blockchain. The most prominent examples of payment channels include the lightning network on Bitcoin and Raiden on Ethereum.
Payment channels can be unidirectional or bidirectional, depending on the flow direction of the payments. In unidirectional channels, the payment is only from one party to another, not the other way around. It works like a top-up card, where you deposit some money off-chain, and transfer a certain amount within the fund limit to the receiver with your signature. When closing the channel, or the channel going depletion, the final balance information is updated on-chain hence completing the payments.
In bidirectional channels, both parties make a deposit to the channel at opening (this procedure is called funding). The problem with using a unidirectional channel is that every transaction between the parties is authenticated, therefore a malicious party is able to claim previous transactions where the balance is in favor of oneself. The lightning network solved this problem by preventing any user to redeem older states, i.e., when a new transaction is signed in a bidirectional channel, the players reveal a piece of secret information to the previous transaction for revocation.
Off-chain bidirectional payment channels with a multi-hop protocol form a payment channel network (PCN) to handle off-chain payments between two players who have no direct channel themselves. If Alice wants to send coins through an intermediary Ingrid, a crucial difficulty is the lack of trust between Alice and Ingrid. Ingrid receives a fee for doing the favor, but she worries that Alice might refuse to pay after she pays Bob. Similarly, Alice couldn’t simply give the money to Ingrid and pray that Ingrid would not take the money and disappear. This is why Hash Time Lock Contract (HTLC) was invented. In an HTLC between Alice and Ingrid, there are two locks, a time lock and a hash lock. Ingrid gets the coins if she can solve the hash lock puzzle, which requires the pre-image of a predefined hash digest (chosen by the receiver Bob) before timeout; while Alice gets the coins in the contract after the end of the time lock if Ingrid fails to provide a correct pre-image in time.
In payment channel network protocols with HTLC-like schemes, the collateral that the parties have to pay as a cost is often defined as the product of the deposited fund and the total time. Therefore, a considerable amount of assets are locked in the channels, which poses a non-negligible negative influence on the liquidity. For instance, 30 percent of the lightning network locks approximately 890BTC of collateral with a value of 39M USD (value estimated by the time the paper on sleepy channels was written). In addition, the network topology of a payment channel network is mostly hidden for protecting the anonymous relationship and balance privacy of the players. So routing in PCN, that is finding a payment path with minimal fees and optimized efficiency, is challenging in general.
To mitigate the routing problem, payment channel hub (PCH) is a promising alternative. In a PCH, a trusted tumbler plays a centralized role to forward the payments from a sender to a receiver. One of the first PCH schemes was proposed by Heilman et al. at NDSS 17, which is unidirectional, unlinkable, privacy-enhanced and Bitcoin-compatible. Here, the trust between Alice and the tumbler is a reversed version of the HTLC, in which the sender Alice needs to solve a hash puzzle to prove that she has paid the tumbler. Perun proposed by Dziembowski et al. at S&P19 presented a PCH scheme for constructing virtual channels. Perun is implemented on Ethereum with Turing-complete smart contracts. A more recent PCH protocol is A2L designed by Tairi et al. at S&P21. A2L gives the first PCH construction that requires minimal properties of the blockchain with only digital signatures and time-locks.
PCN players are expected to monitor the channel state regularly and frequently to detect fraud in time. However, in practice, this might bring an unbearable cost for the players, and fund loss is likely to happen if the frauds are overlooked accidentally. Especially, when an intermediary in a payment path goes offline for a long time, it greatly decreases the efficiency and success rate of the transactions. One solution is to hire watchtowers to supervise the channels for players when they are offline, and resolve possible disputes with the snapshots stored by the watchtowers. We will talk more about watchtowers later. Another approach is to build virtual channels based on payment channels. Virtual channels are off-chain channels that allow players with no direct payment channel to communicate off-chain without an intermediary. Only the opening and closure of virtual channels require the participation of an intermediary node. Perun presented such virtual channels with smart contracts. Later at S&P21, a Bitcoin-compatible virtual channel scheme was proposed by Aumayr et al. to remove the dependency on smart contracts. An interesting question here is whether it is possible to build virtual channels based on virtual channels.
A generalization of payment channels is studied to deploy off-chain smart contracts, those are called state channels or generalized channels, e.g., the general state channel networks presented at CCS18 by Dziembowski et al.. State channels can be extended in a virtual multi-party setting as studied by Dziembowski et al. in this Eurocrypt19 paper. Hydra, proposed by Chakravarty et al. at FC21 takes advantage of the extended UTxO model to reuse the on-chain smart contract system. The studies on state channels and virtual channels are fewer compared with those on lightning networks and PCN protocols.
In the following, we will discuss several highlighted topics in the research of payment channel networks.
Hash Time Lock Contracts
HTLC is a vital component in the implementation of lightning network and cross-chain atomic swap protocols. The core idea is that the players deposit a certain amount of collateral in the channel and claim the money under conditions in order to prevent fraud. However, HTLC has vulnerabilities that jeopardize the security and privacy of the network under a malicious exploit. In this section, we will talk about security issues, including bribery attacks, DoS and congestion attacks. Then we discuss the improvements on HTLC for multi-hop multi-party use cases.
Bribery Attack
Bribery attack is a common threat to blockchain users by encouraging dishonest strategies with malicious incentives. In the honest case, when Alice sends coins to Bob through Ingrid, we have two HTLCs for Alice with Ingrid, and, Ingrid with Bob. When claiming the money, Ingrid receives the pre-image of the hash lock from Bob before the expiration of the second contract, then Ingrid gets redeemed from Alice by forwarding the correct pre-image to her before timeout. To include a transaction on-chain, transaction fees are paid to miners so they pack the transactions and mine a block. In a bribery attack, Alice refuses to pay Ingrid even if Ingrid shows the correct pre-image. Alice achieved so by bribing the miners such that they ignore Ingrid’s transaction and leave it unpacked till timeout. The fund loss of Ingrid incentivizes the miners and Alice to collude and gain. This attack breaks the atomicity principle of the payment channel network.
The idea of such a bribery attack originated from this EuroS&PW19 paper on temporary censorship attacks by Winzer et al.. The authors presented three types of briberies on smart contracts. The bribery per miner strategy is the most expensive one with a quadratic collateral to the number of participants, it requires paying all the miners a fixed amount of money. Pay per block is less costly but there is a risk that the other miners who are not paid choose not to cooperate. Pay-per-commit ignores the honest transaction through a public commit by a high-mining power miner to a malicious mining strategy. Such bribery to miners is studied in HTLC by Tsabery et al. in the SP21 paper MAD-HTLC. It considered the incentives of the miners to act in an evil strategy, and provided a game-theoretical analysis of the participants with sub-game perfect equilibrium. An improved HTLC protocol MAD-HTLC is proposed to punish the briber, which gives the confiscated coins to the miner if the sender intends to bribe. A similar idea was proposed in a concurrent paper by Nadahalli et al. at FC21 with a timelocked bribing. HE-HTLC, proposed by Wadhwa et al., further extended the bribery attacks in MAD-HTLC by considering a reversed bribery, meaning that the miners bribe Alice for her to trust and collude. Then at FC22, the incentives for the bribery attacks in MAD-HTLC are generalized in Suborn by Avarikioti et al., the aim is to adjust the transaction fees to disincentivize bribes.
DoS Attack
Similar to bribery, an attacker can ignore or exclude an honest transaction by disabling the network with DoS or congestion attacks. For instance, in the flood&loot attack presented by Harris et al. at AFT20, an attacker floods the payment channel network by starting many small transactions all at once, such that the system doesn’t have enough power to take care of the honest transactions before timeout. Such an attack is dangerous for lightning network, because the attack gets loot by disabling merely 85 channels. Congestion attack proposed by Mizrahi et al. at FC21 takes advantage of the Max HTLC limit in the protocol, sending transactions to the attacker itself, to block the channels with high liquidity.
Atomicity
Another often-mentioned HTLC vulnerability is the partial atomicity problem, which leads to the wormhole attack presented at NDSS19 by Malavolta et al.. Although HTLC maintains the atomicity in one-hop transactions, a malicious attacker can take advantage of the multi-hop transaction by participating in two or more nodes in the multi-hop path. Then, once the pre-image is known to the attacker, all the nodes between the attacker’s nodes are skipped and they lose coins to the attacker.
Multi-Hop Multi-Party HTLCs
Improved HTLC schemes have been proposed to overcome the vulnerabilities of HTLC and to provide advanced properties. For instance, at the conference CCS17 by Malavolta et al., concurrency and privacy are formalized in the universal composability framework and two protocols were designed to achieve the properties. In addition, they presented an improved multi-hop HTLC contract, which protects the privacy of the players in a payment path with multiple intermediaries. For each player, he or she only knows who is directly talking to in the path, but has no idea about the identity of the sender and receiver in the payment. In atomic cross-chain swap exchanges, players from different blockchains trade their tokens in a fair and trustless way. Narayanam et al. constructed an HTLC contract for multi-party cross-chain exchange at AFT22. What I find interesting is that such an HTLC contract allows multiple players to own and trade assets jointly with the help of MPC. It is called MP-HTLC.
Security and Privacy Topics in PCN
In this section, we will focus on the vulnerabilities of current PCN protocols in security and privacy. Being a communication network, PCN protocols suffer from typical attacks on network topology. In addition, the economic incentives in PCN play a significant role in the participants of the protocol.
Privacy Attacks
In FC21, Kappos et al. defined four types of privacy notions in payment channel networks.
Private channels. When two users share a channel, other participants in the network have no idea about the existence of the channel and identity information.
Third-party secrecy. The balance of the channel is kept secret from any third party.
On-path relationship anonymity. For an honest but curious participant on a payment path, the payment relationship should be anonymous. In lightning network, this might be a vulnerable problem because of its centrality.
Off-path payment privacy. Nodes outside the payment path should know nothing about the payment value.
The attacks on privacy we discuss here are mostly on the second and third properties. There is a timing attack by Rohrer et al. at AFT20 for finding the sender and receiver in a payment path by exploring the related transaction amounts in the payment path and the decreasing deadline in the time locks of the HTLC. Channel balance is also a frequent attacking target. Revealing the balance might lead to unfair fees and malicious attacks on the network. For instance, a lockdown attack by Pérez-Solà at FC20 showed that, using a DoS attack, it is possible to freeze the balances in many channels, so that the critical nodes in the network are blocked thus paralyzing the PCN. Later, a probing attack is proposed by Biryukov et al. at FC22, the authors show geometric strategies to optimize the success probability and attack speed in probing the balance in the channels. A probing attacker sends invalid transactions or transactions to another address owned by the attacker, to find out if the balance of a channel player is larger or smaller than the probing value. This strategy is more efficient than a default binary search. Also, it works when there are multiple channels between the attacker and the probed node.
Due to privacy concerns, the network topology is unknown in the lightning network and many other PCN networks, which raises new challenges like routing issues in the next subsection. The question studied in Sigmetric20 paper by Tang et al. answers whether it is possible to achieve a tradeoff between privacy and utility/efficiency.
Routing Issue
When Alice sends Bob coins through the network, she prefers a path that every channel in the path contains enough balance for the transfer and the total transaction fee of the path is as small as possible. This task is difficult because of the unknown network topology, potentially depleted channels, and constantly changing channel balances. A simple strategy is to try many channels and detect one that happens to work.
An early routing algorithm as used in SlientWhispers by Malavolta et al. at NDSS17 and SpeedyMurmurs by Roos et al. at NDSS18 are based on landmarks. The idea of a landmark routing protocol is to calculate a path between sender and receiver through an intermediary node called a landmark. In more detail, landmarks are selected nodes that are well-known to every other node in the network. FSTR routing proposed at DSN20 by Lin et al. is based on the fund skewness properties, which considers the imbalance in the channels. This is at the cost of privacy.
To reduce the unsuccessful probability of a transaction in a routing procedure, it is possible to split the transaction value into smaller portions and transfer them through multiple paths, so that the balances in the paths are more likely to match the transaction. Spider by Sivaraman et al. at NSDI20 presented a multi-path routing protocol to packetize the transactions. Later on, in Boomerang designed by Bagaria et al. at FC20 and Spear by Rahimpour et al. at FC21, a redundant payment path strategy is studied. To show the idea with an example, say, instead of sending 4 coins through 4 channels each with one coin, the sender sends 8 coins through 8 channels each with one coin, and the protocol terminates when 4 out of 8 coins are received. It is ensured by verifiable secret sharing that the remaining 4 coins won't be stolen in the channels. Spear is an improved scheme on boomerang, it has lower latency and smaller computation because it doesn't use the cryptographic primitives as those in boomerang. Lastly, presented at AFT20 by Tochner et al., an attacker can strategically influence and explore the pattern that transactions are routed in the network. Through a DoS attack, an attacker is able to hijack some routes like in the Bitcoin hijacking attack by Apostolaki et al. at S&P17 and forces the payment to go through the routes preferred by the attacker. The gain of the attacker might be the liquidity locked in the network, or transaction fees through attacker's network (even though the fee is higher than others thus not preferable when not attacked).
Rebalancing
In payment channel networks, the initial collaterals in each channel might deplete after a while, because one party pays more to the other. When a channel depletes, a naive solution is to close the channel and reopen a new one on-chain. For instance, Loop on the lightning network achieves such a goal. However, it takes time and money to do so. A better solution is rebalancing, as first proposed in Revive by Khalil et al. at CCS17. The idea is as follows. When Alice's balance ran out in channel 1, and she has enough balance in channel 2 with another party, she can make a transfer to herself into channel 1 to top-up through channel 2 without going on-chain. Revive has several practical problems, first, a delegate is required to handle the rebalance process, in addition, it requires the cooperation of other participants in the network, lastly, it is difficult to route the rebalancing path in a large network with unknown topology. What's worse, the rebalanced amount by Revive is bounded by the smallest channel balance in the path. Hide&seek by Avarikioti1 et al. at FC22 studied a linear programming problem in scheduling the rebalancing amount and direction to achieve minimum cost. Cycle by Hong et al. at DSN22 proposed to constantly rebalance to make sure that channels don't go depletion. To avoid a cyclic path to rebalance, Shaduf by Ge et al. at NDSS22 gives a non-cycle rebalancing protocol, it doesn't require the rebalancing path to form a cycle. This process is done by binding two channels together for moving the coins between them, and declaring such a binding on-chain.
Of course, there is another question to answer, how much money should the players deposit in the channel during the opening phase? Li et al. give a balance planning service at infocom20 called PnP to decide the initial balance to put in the channel.
Watchtowers
Lastly, we come back to the solutions to deal with offline users or intermediaries in payment channel networks. If a user doesn't want to keep an eye on the channel all the time, it is recommended to hire a watchtower to detect potential fraud. Watchtower has been designed in the lightning network, but it encounters a lack of incentives for the watchtowers to work properly, because the watchtowers are only paid when they find fraud, but they don't expect to gain a lot because most of the users are honest. So McCorry presented Pisa at AFT19 and proposed to pay watchtowers regularly. A drawback is that this scheme is vulnerable to bribery attacks. Also, it is not friendly to Bitcoin because it relies on smart contracts. The second problem is fixed by Mirzaei et al. at FC21 with FPPW to make the watchtower service compatible with Bitcoin. Outpost, proposed by Khabbazian et al. at AFT19, is one of the first watchtowers that is lightweight (meaning that the watchtower doesn't need to store too much data) and compatible with Bitcoin. Cerberus by Avarikioti et al. at FC20 and Brick by Avarikioti et al. at FC21 are schemes with incentives and penalty on watchtowers to encourage them to work properly. And punish the watchtowers if they play evil. Fail-safe watchtower by Liu et al. at AsiaCCS20 considers attacks like DoS on the watchtower and improved the scheme to protect the service against such attacks. Lastly, Aumayr et al. at CCS22 presented sleepy channel for users to go offline without hiring watchtowers.
Improved PCN Protocols
In the final section of this post, I want to give a quick overview on several improved PCN protocols.
PCN protocols to improve certain properties, such as (global) atomicity, path restriction (for a certain network topology), interoperability(whether smart contracts are required), per party collateral, privacy and so on. Per party collateral is linear in the lightning network, as well as Anonymous Multi-Hop Locks (AMHL) by Malavolta et al. at NDSS19. Recent protocols can achieve constant per party collateral, including Sprites by Miller et al. at FC19, Atomic Multi-Channel Updates (AMCU) by Egger et al. at CCS19, Blitz by Aumayr et al. at Usenix security22, and Thora by Aumayr et al. at CCS22. Collateral is defined by the payment amount multiplied by the locktime, and it reflects the liquidity of a scheme. Large collaterals make the system vulnerable to griefing attacks, where the attacker’s aim is to spoil the network by freezing as many collaterals as possible. Path restriction tells whether a protocol is applicable to other topologies like a star shape. I hope to mention that AMCU is vulnerable to channel closure attacks as discussed by Jourenko et al. in a scheme called payment trees at FC21. It is worth mentioning that Blitz is without HTLC contracts, which means that it is suitable for blockchains without HTLC. Also, it solves the staggered collateral problem in multi-hop HTLCs, which is, the locktime in MP-HTLC is often too long, because you have to leave out enough time for each user to react after one receives the secret.
📹 Video
The video presentation of this essay is available on YouTube as well, delivered by Yunwen at Cryptape Blockchain Research Panorama. The talk is in Chinese.
✍🏻 Yunwen Liu
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.