# SoK: Payment Channel Networks

Kartick Kolachala, Mohammed Ababneh, Roopa Vishwanathan  New Mexico State
University
Las Cruces, USA
{kart1712, mababneh<EMAIL_ADDRESS>
###### Abstract

Payment Channel Networks (PCNs) have been proposed as an alternative solution
to the scalability, throughput, and cost overhead associated with on-chain
transactions. By facilitating offchain execution of transactions, PCNs
significantly reduce the burden on the blockchain, leading to faster
transaction processing, reduced transaction fees, and enhanced privacy.
Despite these advantages, the current research in PCNs presents a variety of
research challenges that require further exploration.
In this paper, we survey the recent work in several aspects of PCNs, such as
pathfinding and routing, virtual channels, state channels, payment channel
hubs and rebalancing. This survey aims to provide the reader with a detailed
understanding of the current state-of-the-art in PCN research, highlighting a
few important advancements. Additionally, we highlight the various unresolved
issues in the area of PCN research.
Specifically, this paper seeks to answer the following crucial question: _What
are the various interesting and non-trivial challenges in PCN research that
require immediate attention from the academic and research community?_ By
addressing this question, we aim to identify the most pressing problems and
future research directions that interested readers can immediately work on.
Through this analysis, we hope to inspire researchers and practitioners to
tackle these challenges to make PCNs more secure and versatile.

###### Index Terms:

Payment channel network, Blockchain, Layer-2

##  I Introduction

(a) Payment channel opening

(b) Alice sending 30 coins

(c) Local balances get updated

(d) Posting final balances to blockchain

Figure 1: Payment channel operations

Cryptocurrencies and cryptocurrency based transactions have become increasing
popular. Currently, the total market value of all cryptocurrencies in use has
surpassed 2.5 Trillion USD. The cyrptocurrency market is increasing at a rate
of $\approx$ 8.00% every year [1]. This rise in popularity can be attributed
to the following reasons: 1) cryptocurrency transactions can be carried
without the presence of a trusted entity. Fiat currency based transactions on
the other hand, require the presence of a trusted financial organization such
as a bank. 2) cryptocurrency transactions do not subject the user to any
limits on the number and type of transactions. Fiat currency based
transactions are limited in their amount and number, depending on several
factors such as the currency, geographical location, etc. [2].
Each transaction posted to the Bitcoin blockchain takes around 7 seconds to be
validated [3, 4]. The procedure of validation involves verifying that the
transaction posted to the blockchain contains all the required fields and the
signature of the user creating the transaction tuple is valid. Once the
validation procedure is successfully completed, the transaction is included in
a block that would be mined on the blockchain at some time in the future. The
process of mining the block successfully takes $\approx$ 2 hours [5] (as of
June $13^{th}$ 2024). This delay in the transactions and blocks getting
confirmed is termed as the blockchain scalability problem [6]. In contrast,
Visa, a company which globally processes transactions using fiat currencies,
processes around 24,000 transactions per second [7]. Due to the delay in
transaction processing caused by the blockchain scalability problem,
blockchain-based transactions cannot process payments instantaneously.
As an alternative to processing transactions by posting to the blockchain,
payment channels have been proposed. Two parties with the intent of processing
payments between them open a payment channel by creating a transaction tuple
called the funding transaction. This funding transaction contains the initial
deposits from both the parties. These initial deposits are also called as the
initial balances of the parties in the payment channel. The sum aggregate of
these initial balances is called as the channel capacity. The funding
transaction contains the signatures of both the parties involved in the
payment channel making it a 2-2 multi signature transaction. This means that
the funds in the funding transaction cannot be spent without the signatures of
both the parties. This funding transaction is validated and included in a
block. Once this block has been successfully mined and confirmed on the
blockchain, the payment channel is opened between the two parties. The two
parties can now be involved in an unlimited number of transactions with each
other as long as the amount of a single transaction does not exceed their
local balances.

An example of a payment channel is given in Figure 1(a). Two users (also
called nodes) Alice and Celia deposit 50 coins each into a 2-2 multi signature
transaction. This transaction is posted to the blockchain, upon which it is
validated and included in a block. The block is mined and confirmed, at which
time a payment channel is said to open between Alice and Celia. The sum
aggregate of the individual balances of Alice and Celia, which is the channel
capacity, is 100 coins. Alice making a payment of 20 coins to Celia is shown
in the Figure 1(b) and the updated balances of Alice and Celia are shown in
Figure 1(c). After the payment has been made, the channel capacity between
Alice and Celia still remains constant at 100 coins. In this manner, Alice and
Celia can be involved in an unlimited number of payments between each other.
Each payment made in the payment channel in an off-chain manner contains the
signatures of both Alice and Celia. When either Alice or Celia decide to close
the payment channel, they post their final balances to the blockchain and the
payment channel is closed as shown in Figure 1(d).

For each off-chain transaction in the payment channel, both the parties
involved in the payment channel create a commitment. This commitment is
essentially an agreement for the new balances signed by both the parties.
Exchanging of commitments signifies that both the parties have agreed to the
change in their respective balances. Each pair of commitments (for each
transaction), contains a unique sequence number called the revocation sequence
maturity number. For each new transaction made in the payment channel, the
sequence number of the prior transaction is invalidated by revocation keys of
both the parties. These revocation keys are created by both the parties before
opening of the payment channel. If a malicious party in the payment channel
broadcasts an older balance to the blockchain, the honest party in the channel
has a certain time period during which it can contest this behavior on the
blockchain. Before this time period expires, the honest party in the payment
channel will broadcast the revocation of this old state signed by both the
parties. The broadcasting of this revocation to the blockchain prevents the
malicious party from stealing funds of the honest party.
The idea of a payment channel that exists between two parties can be extended
to a number of nodes, creating a network of payment channels, called a payment
channel networks or PCN. The advantage of PCNs is, they enable users that are
not connected by a direct payment channel to make payments between each other
in an off-chain manner. An example PCN is shown in Figure 2. In the figure,
consider Alice who intends to make a payment to Hector, with whom she does not
share a payment channel. The naive way to process this transaction would for
Alice to open a payment channel with Hector, which involves Alice making an
expensive blockchain write for the channel opening. Each payment channel
opening costs 2.4 USD for blockchain writes [8, 9, 10]. If Alice intends to
send an amount of 1 coin to Hector, it may not be economical for her to open a
direct payment channel. Alice can make use of the PCN and make a payment to
Hector by forwarding the payment along the path Alice $\rightarrow$ Celia
$\rightarrow$ Michael $\rightarrow$ Rajiv $\rightarrow$ Charlie $\rightarrow$
Garcia $\rightarrow$ Hector. This process of using intermediate nodes in a PCN
to forward to the payment to the intended destination is called as routing in
payment channel networks.

Figure 2: Payment channel network

Motivation and timeliness of PCN research: A significant advantage of PCNs is
their capability to facilitate micro-payment transactions, with minimum
amounts as low as $10^{-7}$ BTC [11]. In contrast, the average transaction
cost for a single on-chain transaction on the BTC blockchain is approximately
$4.612$ USD as of June 2024 [12] 111Opening a payment channel requires two
inputs (for funds from both the parties) and one output (the funds are locked
in a single 2-2 multi signature address). Where as making a payment by posting
it to the blockchain requires one input (from the party that intends to make
the payment) and two outputs (one to the receiver and one to the
validator/miner for his fees/reward). This difference makes the transaction
cost associated with opening a payment channel cheaper than making a payment
using a blockchain write., regardless of the transaction amount. This cost can
be avoided by using the off-chain PCNs, which incurs no additional fees.
Additionally, transactions on the BTC blockchain take around 2 hours to be
confirmed as of June 13, 2024 [5], whereas PCNs can process transactions
instantly. An example of a real-world PCN is the Lightning Network
($\mathsf{LN}$) on the Bitcoin blockchain [13], which has a 24-hour trading
volume of $63,200 and a market capitalization of $7 million [14] as of June
2024. These figures reflect $\mathsf{LN}$’s size and growth.

Contributions:
1) We qualitatively compare the recent work in several aspects of PCNs, viz.
pathfinding and routing, virtual channels, state channels, payment channel
hubs and rebalancing using several relevant properties (metrics) along with
providing a reasoning why these metrics have been chosen for comparison.
2) In this paper, we point out the open problems in all the areas that we
survey and we also discuss why solving those problems is a hard research
challenge.

Outline: In Section II, we start with describing the concept of pathfinding
and routing in PCNs and qualitatively compare work published in that area. In
Section III, we describe virtual channels which have been proposed to address
issues with multi-hop routing in PCNs, and compare work in this area. In
Section III, we describe and compare state channel protocols, which are a more
generalized adaptation of virtual channels and can facilitate the execution of
arbitrary applications between nodes in the PCN (not just payments). In
Section V, we cover payment channel hubs, which are similar to virtual
channels and state channels, but facilitate a different use case for payments
in PCNs. All of the aforementioned PCN mechanisms consume one common resource:
the local balance of a node in a PCN. In Section IV, we discuss rebalancing,
which addresses the important function of replenishing channel funds in the
PCN. In Section VII, we present the reader with the current research gaps in
all of the aforementioned areas and in Section IX, we conclude the paper.

Prior work: Prior works by Khojasteh _et al._ [15] and Erdin _et al._ [16]
survey the work done only in the area of pathfinding and routing protocols and
their privacy aspects in PCNs. Whereas, in this paper we cover the entire
spectrum of PCN research: rebalancing, virtual channels and state channels,
pathfinding and routing. Apart from this [15, 16] do not provide any
information about the open problems in PCNs, which we do in our work. The SoK
by Gudgeon _et al._ [17], surveys several layer-2 protocols, whereas, we focus
exclusively on PCNs. Furthermore [17] was published in 2020 and does not cover
most of the recent work published in PCNs.

TABLE I: Comparison of Pathfinding and Routing Protocols in PCNs. Protocols |  Concurrency |  Privacy |  Topology privacy |  Avoids source routing |  Decentralized |  Atomicity |  Disjoint graphs |  Fees
---|---|---|---|---|---|---|---|---
MPCN-RP [18] |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  $\checkmark$ |  ✗ |  $\checkmark$ (flat)
Eckey _et al_ [19] |  ✗ |  ✗ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗ |  ✗
Vein [20] |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  $\checkmark$ (dynamic)
Auto tune [21] |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  $\checkmark$ (flat)
Kadry _et al._ [22] |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗
FSTR [23] |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗
SilentWhispers [24] |  ✗ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗ |  ✗ |  ✗
Blanc [25] |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗ |  ✗
SpeedyMurmurs [26] |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗ |  ✗ |  ✗
Spider [27] |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗
Flash [28] |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  $\checkmark$ |  ✗ |  ✗
Coinexpress [29] |  $\checkmark$ |  ✗ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗ |  ✗
Webflow [30] |  ✗ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗ |  ✗ |  ✗
Robustpay [31] |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  $\checkmark$ |  ✗ |  $\checkmark$ (flat)
Robustpay+ [32] |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  $\checkmark$ |  ✗ |  $\checkmark$ (flat)
RACED [33] |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗
Cheapay [34] |  ✗ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗ |  ✗ |  $\checkmark$ (flat)
Auroch [35] |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗ |  $\checkmark$ (dynamic)
Yang _et al._ [36] |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗ |  ✗ |  ✗ |  ✗
SPRITE [37] |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗ |  ✗

##  II Pathfinding and Routing

Motivation: One of the areas in PCNs which has garnered significant attention
from the academic community is pathfinding and routing. It is defined as the
process of finding a path comprising of several nodes from a sender to a
receiver in a PCN along which the payment intended to be sent by the sender
can be forwarded to the receiver and forwarding the payment along that path.
Intuitively, it may seem that well-known pathfinding and routing protocols
from the networks domain can be easily applied to PCNs. Unfortunately, there
are several problems with this.

Even though PCNs are decentralized and distributed peer-peer networks,
pathfinding and routing protocols of traditional networks cannot be applied to
solve the pathfinding and routing problem in PCNs, because of fundamental
differences between intent and the network features: 1) _Transfer of data and
transfer of money_ : The intent behind traditional network’s pathfinding and
routing protocols is to transfer data between connected devices. In PCNs, the
intent to transfer money between users in a decentralized and distributed
manner. 2) _Change in bandwidth and change in monetary state_ : When data is
transferred between connected devices using network pathfinding and routing
protocols, the bandwidth, which is represented by the link weights between the
nodes does not change. However, transfer of money between users in a payment
channel permanently alters the state of the sender and receiver involved by
subtracting and adding money from and to their link weights respectively. 3)
_Latency and routing fees_ : The cost of sending data in network pathfinding
and routing protocols is measured in terms of latency, which is defined as the
time delay experienced in transferring data from one device to another. The
delay in data transfer is experienced by the receiver and the cost of the
delay is usually paid by the sender. The cost of sending payments in a PCN is
measured in terms of money, called as routing fees. This encourages greedy
behavior and makes the PCN prone to several attack vectors. Due to these
reasons, pathfinding and routing in PCNs is a fundamentally different and a
hard research challenge.

The properties in Table I represent the fundamental principles of fiat
currency transactions and on-chain payment mechanisms, which we want reflected
in off-chain payments. These properties are generally agreed upon in the
literature by several works such as [33, 35, 37, 25, 26, 24] as common
evaluation metrics for pathfinding and routing protocols in PCNs. Fulfilling
these properties while providing efficient pathfinding and routing is a non-
trivial challenge, and necessitates the design of new pathfinding and routing
protocols. Several elegant pathfinding and routing protocols have been
proposed in the literature. In Table I, we present a qualitative comparison of
these routing protocols with respect to the properties they achieve.
Ideal properties:
1) Concurrency: Concurrency is achieved when a pathfinding and a routing
protocol enables the nodes to forward more than one payment simultaneously.
2) Privacy: Privacy is maintained when a node’s identity is known only to its
immediate neighbors and not to the entire network.
3) Topology Privacy: Topology privacy is preserved when no single node has
knowledge of the entire network topology.
4) Avoids Source Routing: Source routing is avoided when the sender does not
determine the path to the receiver.
5) Decentralization: Decentralization is achieved when there are no
centralized or trusted entities responsible for constructing paths for
senders.
6) Atomicity: Atomicity is ensured when the payment is routed all the way from
the sender to the receiver or the payment is not routed at all.
7) Disjoint Graph Applicability: A pathfinding and routing protocol is
considered applicable to disjoint graphs if it functions even when the network
graph consists of islands.
8) Fees: Routing fees is the amount a node charges for forwarding the payment
to the next node along a path from the sender to receiver. This fees can be
charged in two ways. Flat/fixed fees means that the fees charged for routing
payments remains the same irrespective of the transaction amount being routed.
If the fees charged by a node varies according to the transaction amount, it
is referred to as dynamic fees, typically a percentage of the amount being
transacted.

##  III Virtual channels

(a) Virtual channel example [38, 39]

(b) Multi-hop virtual channel (the dots between Jill and Alice depict several
intermediate nodes)

(c) Recursive virtual channel

Figure 3: Different types of virtual channels TABLE II: Comparison of Virtual Channel Protocols Protocol |  BC |  Validity |  Fee |  Privacy |  Off-chain dispute resolution |  Recursive |  Multihop
---|---|---|---|---|---|---|---
Perun [38] |  TC |  Limited |  ✗ |  ✗ |  ✗ |  ✗ |  ✗
Jourenko _et al._ [40] |  UTXO |  Limited |  ✗ |  ✗ |  ✗ |  $\checkmark$ |  ✗
Aumayr _et al._ [41] |  UTXO |  Limited |  $\checkmark$ (fixed) |  ✗ |  ✗ |  ✗ |  ✗
Elmo [42] |  UTXO |  Unlimited |  ✗ |  ✗ |  ✗ |  $\checkmark$ |  ✗
Donner [43] |  UTXO |  Unlimited |  $\checkmark$ (time based) |  $\checkmark$ |  ✗ |  $\checkmark$ |  ✗
Jia _et al._ [44] |  UTXO and TC |  Limited |  $\checkmark$ (fixed) |  ✗ |  ✗ |  ✗ |  ✗
Eckey _et al._ [45] |  TC |  Limited |  ✗ |  ✗ |  ✗ |  $\checkmark$ |  ✗
Generalized state channels [46] |  TC |  Limited |  ✗ |  ✗ |  ✗ |  $\checkmark$ |  ✗

Transactions in PCNs are routed from the sender to the receiver using a path
of intermediate nodes. This pathfinding and routing mechanism requires the
nodes along the payment path to be available for a transaction to be
processed. Nodes, however, sometimes can choose to go offline or there can be
network/service disconnections. This might cause the transaction to fail.
Virtual channels, which are built on top of existing payment channels, provide
a solution to this problem. Virtual channels facilitate payments between a
pair of nodes using an intermediate node. The intermediate node has individual
payment channels open with the other two nodes. The intermediary and the pair
of nodes lock coins with each other in their respective payment channels to
establish a virtual channel. Once the virtual channel has been established,
the two nodes can be involved in a unlimited number of payments. These
payments can be processed even if the intermediate node goes offline.
The first virtual channel construction, Perun, was proposed by Dziembowski _et
al._ in [38]. Assume there are two users, Alice and Bob, along with an
intermediary as depicted in Figure 3(a). Alice establishes a payment channel,
$\alpha_{A}$, with the intermediary by locking $Y_{A}$ coins as collateral;
the intermediary contributes $Y_{I}$ coins into this channel. Similarly, Bob
locks $Z_{B}$ coins into his channel, $\alpha_{B}$, with the intermediary,
which also deposits $Z_{I}$ coins from its possession. This marks the
completion of the opening phase, effectively locking the coins belonging to
Alice and Bob. Following this, Alice and Bob create a virtual channel to
facilitate transactions between them. The virtual channel will include coins
deducted from both Alice’s and Bob’s payment channels. Specifically, $X_{A}$
coins will be subtracted from $Y_{A}$ on Alice’s side and deposited into the
virtual channel, while $X_{B}$ coins will be subtracted from $Z_{B}$ and will
be deposited from Bob’s side. Now Alice and Bob can be involved in an
unlimited number of payments without the intermediary being online.
The idea of a virtual channel between a pair of nodes involving a single
intermediary/intermediate node has been extended to establishing a virtual
channel recursively over several hops involving several intermediaries,
leading to the construction of a recursive virtual channel [40, 42, 43]. An
example of a recursive channel is shown in the Figure 3(c). In the figure
Trent and Alice are a pair of nodes who intend to establish a virtual channel
between them. They do in three steps as follows; 1) Trent and Hu construct a
virtual channel $V_{1}$ with Rajiv as an intermediary. 2) Hu and Alice
construct a virtual channel $V_{2}$ with Jill as an intermediary. 3) Trent and
Alice establish a virtual channel between them $V_{3}$.

A multihop virtual channel is constructed by establishing a single virtual
channel between a pair of users over a path comprising of several intermediate
nodes. An example of multihop virtual channel is shown in the Figure 3(b).
Rajiv and Alice establish a single virtual channel $V$ between them.

Motivation: We have already described how PCNs offer a solution to the
blockchain scalability problem by facilitating instantaneous payments in an
off-chain manner. PCNs however, have few limitations: 1) The path generated in
a PCN to process a payment between a sender and a receiver usually contains
one or several intermediate nodes. All the nodes along the path are required
to be available to route the payment until the receiver. This may not be
possible at all times since, nodes can be disconnected from the network due to
various reasons such as power outages, DoS attacks, etc. In a virtual channel,
once the coins of the intermediary(ies) are locked, it can choose to remain
offline without affecting the transaction processing. 2) Each node along the
path from the sender to the receiver charges a fees called as routing
fees/forwarding fees for forwarding the payment to the next node along the
path. The sender has to pay all the nodes their respective forwarding fee
along the path. This increases the overall cost of routing the payment.
Virtual channels provide a solution to this problem, since they do not charge
fees on a per transaction basis. Instead, the fees is charged based on a time
epoch basis (the time for which the coins of the intermediary/intermediaries
are locked in the virtual channel) or a fixed fee can be agreed in advance by
all the parties involved in the virtual channel construction. 3) The time
taken to route a payment from a sender to a receiver is directly proportional
to the path length. A longer path would result in an increase in the overall
pathfinding and routing time. Virtual channels do not process payments through
a path comprising of several intermediate nodes, hence the overall
transactions’ pathfinding and routing time does not depend on the number of
intermediate nodes between the sender and the receiver.

Virtual channels should not add an unnecessary burden to users, and should
mirror the operations of payment channels as closely as possible, with the
added benefit of no on-chain transactions at all, while maintaining comparable
security/privacy properties. We now give the properties desired from an ideal
virtual channel, and compare the works in this area in Table II on the extent
to which they achieve these properties.
Ideal properties:
1) BC: BC is the blockchain on which the corresponding virtual channel
protocol can be deployed. TC is a blockchain that supports a Turing complete
programming language, such as Ethereum, and UTXO is a blockchain that supports
the UTXO based scripting mechanism such as Bitcoin. Ideally, a virtual channel
protocol should be deployable on any blockchain without the need for any
additional programming/scripting requirements. The virtual channel protocol
should not require any modifications to the existing consensus mechanisms of
the underlying blockchains.
2) Validity: This determines the validity of the virutal channel. A limited
validity means that the virtual channel is valid for a predetermined time
period (which is decided by parties involved in the virtual channel).
Unlimited validity means that the virtual channel can stay open until the
parties involved decide to initiate closing. This provides better and
efficient transaction processing between users who intend to have frequent
payments made between each other.
3) Fee: This metric determines if the virtual channel takes into account the
fees charged by the intermediate node(s) involved in the channel’s
establishment. The fixed fee model implies that a predetermined, fixed fee is
paid to the intermediate node(s) which is agreed upon by all the parties in
the virtual channel and the time based fee model implies that a fixed fee is
paid to the intermediary which depends on the time for which the virtual
channel stays open. Having an well-defined fee structure will motivate the
intermediary/intermediaries to participate in virtual channel creation.
4) Privacy: Similar to payment channels, we want privacy of nodes for virtual
channels, which is said to be achieved when the identities of the nodes in the
virtual channel protocols are not known to anyone except for their immediate
neighbors.
5) Offchain dispute resolution: This metric determines if the transaction
disputes in a virtual channel require a blockchain write.
6) _Recursive_ : A virtual channel is said to be recursive or hierarchical if
it can facilitate payments between a sender and a receiver across a path
comprising of several intermediate nodes by recursively constructing virtual
channels on top of existing virtual channels from sender to receiver. We give
an example of a recursive virtual channel in Figure 3(c). 7) _Multihop_ : A
virtual channel is said to be multihop if it can facilitate payments between a
sender and a receiver across a path comprising of several intermediate nodes
by constructing a single virtual channel from the sender to the receiver,
without establishing virtual channel between any pair of intermediate nodes
along the path. We give an example of a multihop virtual channel in Figure
3(b).

(a) State channel opening

(b) Chess game using state channel

(c) State channel close

Figure 4: State channel example with a chess game decentralized application (DApp) TABLE III: Comparison of State Channel Protocols Protocol |  BC |  General/purpose state channels |  Security |  Graceful exit |  Off-chain dispute resolution
---|---|---|---|---|---
Pisa [47] |  TC |  ✗ |  $\checkmark$ |  ✗ |  ✗
Hydra [48] |  UTXO |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗
Sprites [49] |  UTXO |  $\checkmark$ |  $\checkmark$ |  $\checkmark$ |  ✗
Aumayr _et al._ [50] |  UTXO, TC |  ✗ |  $\checkmark$ |  $\checkmark$ |  ✗
Origami [51] |  TC |  ✗ |  $\checkmark$ |  $\checkmark$ |  ✗
Forcemove [52] |  TC |  ✗ |  $\checkmark$ |  ✗ |  ✗

##  IV State channels

A state channel is an off-chain protocol that can facilitate execution of an
arbitrary decentralized application, also called as DApp (such as a two player
game) between two users in a decentralized and distributed network. An example
of a state channel is given in Figure 4(a). Let us consider two users Alice
and Celia who intend to play a game of chess. They initially interact with the
chess game application deployed on the blockchain by a third party service
provider. Both Alice and Celia deposit 30 coins each from their possession
into a 2-2 multi signature transaction (step 1). Upon locking the funds, the
chess game is instantiated between Alice and Celia by the DApp (step 2). Alice
and Celia engage in a series of moves for the chess game (step 3, step 4) and
let us assume Alice eventually wins (step 5) as shown in Figure 4(b). Alice
gets paid 15 coins as the prize money in Figure 4(c). In this game, Alice and
Celia countersign each other’s moves until there is a winner or a draw. In the
event of malicious activity by one party (such as undoing a prior move), the
honest party will broadcast all the moves to the blockchain for dispute
resolution.
Motivation: State channels allow the already existing payment channels to
facilitate execution of arbitrary applications such as games, e-commerce, etc.
This leads to the PCN becoming more versatile. State channels should be
deployable on any blockchain regardless of the underlying
programming/scripting requirements and should be able to facilitate the
execution of any decentralized application between the parties involved, while
maintaining comparable security properties (in comparison to payment channels)
and should ideally be able to resolve disputes without accessing the
blockchain. We now give the properties desired from an ideal state channel,
and compare the works in this area on the extent to which they achieve these
properties. We give a qualitative comparison of various state channel
protocols in Table III. We describe the metrics used for comparison below.
Ideal properties:
1) Blockchain: This is the blockchain on which the corresponding state channel
protocol can be deployed. TC is a blockchain that supports a Turing complete
programming language and UTXO if a blockchain that supports a UTXO based
scripting.
2) General purpose state channels: This is the ability of the state channel to
facilitate the execution of any application in an off-chain manner by using a
single application-agnostic instance of state channel on the blockchain.
3) Security: Security is achieved by a state channel protocol if no honest
party loses funds because of malicious behavior by other parties in the
protocol.
4) Graceful exit: A state channel protocol is said to employ graceful exit if
it has clear and well-defined mechanisms for nodes joining or leaving the
state channel.
5) Off-chain dispute resolution: This metric indicates if a dispute that
occurs between the parties involved in the state channel can be resolved
without accessing the blockchain.

##  V Tumblers

TABLE IV: Comparison of Tumblers Protocol | BC |  | Relationship
---
anonymity
| Privacy against
---
aborts
Time epochs |  | Dynamic
---
corruption
Atomicity |  | Value
---
privacy
| Variable
---
amount
BOLT [53] | TC | $\checkmark$ | ✗ | ✗ | ✗ | $\checkmark$ | $\checkmark$ | $\checkmark$
Nocust [54] | TC | $\checkmark$ | ✗ | $\checkmark$ | ✗ | $\checkmark$ | ✗ | $\checkmark$
MIXCT [55] | TC | $\checkmark$ | ✗ | $\checkmark$ | ✗ | $\checkmark$ | $\checkmark$ | $\checkmark$
A2L [56] |  | UTXO and
---
TC
$\checkmark$ | ✗ | $\checkmark$ | ✗ | $\checkmark$ | $\checkmark$ | ✗
Blindhub [57] |  | UTXO and
---
TC
$\checkmark$ | ✗ | $\checkmark$ | ✗ | $\checkmark$ | $\checkmark$ | $\checkmark$
Teechain [58] | TC | $\checkmark$ | ✗ | ✗ | ✗ | $\checkmark$ | $\checkmark$ | $\checkmark$
Accio [59] | TC | $\checkmark$ | $\checkmark$ | $\checkmark$ | ✗ | $\checkmark$ | $\checkmark$ | $\checkmark$
Turbo [60] | TC | $\checkmark$ | ✗ | $\checkmark$ | ✗ | ✗ | ✗ | ✗
Boros [61] | TC | ✗ | ✗ | $\checkmark$ | ✗ | $\checkmark$ | ✗ | $\checkmark$
Tumblebit [62] | UTXO | $\checkmark$ | ✗ | $\checkmark$ | ✗ | $\checkmark$ | ✗ | ✗

Motivation: A payment channel hub is a layer-2 mechanism that facilitates
transaction processing between a sender/receiver pair that do not have a
payment channel open between them. The intermediary which facilitates payments
is called a tumbler. The tumbler has multiple payment channels open with
several nodes in the network to facilitate payments. The hubs can potentially
be useful in facilitating micropayments between a buyer and seller, without
either of them needing to open a payment channel with each other.

Payment channel hubs can be classified into two types: on-chain and off-chain.
Early hubs, also called hubs or mixers, were on-chain [63, 64, 65, 66, 67, 68,
69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80], but they all suffered from
scalability issues due to having to post each transaction on the blockchain.
This led to the development of offchain payment channel hubs for specific
blockchains, e.g., Bolt [53] for Zcash, Nocust [54] and MixCT [55] for
Ethereum. The most general-purpose payment channel hubs are Tumblebit [62],
$A^{2}L$ [56], and Blindhub [57].

A payment channel hub should be able to facilitate payments between a sender
and receiver, who do not have a payment channel open between them such that
the hub cannot link a given transaction amount to a particular sender/receiver
pair. Furthermore, the payment channel hub should also guarantee the
fundamental property of atomicity (ensuring that the payment is sent to the
receiver or it does not go through at all). We now give the properties desired
from an ideal payment channel hub, and compare the works in this area on the
extent to which they achieve these properties. We give a qualitative
comparison of off-chain payment channel hubs in the Table IV. We describe the
comparison metrics below:
Ideal properties:
1) Blockchain: BC is the blockchain on which the corresponding Tumbler
protocol can be deployed. TC is a blockchain that supports a Turing complete
programming language, such as Ethereum, and UTXO is a blockchain that supports
the UTXO based scripting mechanism such as Bitcoin.
2) Relationship anonymity: It ensures that the relationship between a sender
and a receiver for a given transaction should not be known to the tumbler.
3) Privacy against aborts: Tumbler should not be able to deduce the identities
of a sender/receiver in case of a transaction abort, regardless of which party
is responsible for the abort.
4) _Time epochs_ : The tumbler processes transactions in discrete fragments of
time called epochs, i.e., transactions only take place during a time epoch. A
payment channel hub that supports transaction processing based on time epochs
is not efficient because nodes cannot process payments between time epochs,
which can be of arbitrary length. The duration between time epochs depends on
several factors such as the unit of the time epoch (absolute time or relative
time measured in terms of block height), number of users that will most likely
involved in the next time epoch, etc. 5) Dynamic corruption: The payment
channel hub should be able to handle the deviation of any party from the
protocol at any point during its execution. i,e the set of adversaries should
not be static during the protocol execution.
6) Atomicity: Atomicity ensured when a payment is routed all the way from the
sender to the receiver or the payment is routed at all.
7) Value privacy: Value privacy is ensured by a payment channel hub, when,
given a transaction amount, the tumbler cannot link it to a sender/receiver
pair.
8) Variable amount: The tumbler should be able to process transactions of any
value.

TABLE V: Comparison of Rebalancing Protocols Protocol |  BC |  Trusted entity |  Graph compatability |  Privacy
---|---|---|---|---
Revive [81] |  TC |  $\checkmark$ (C) |  Cycles only |  ✗
Hide & Seek [82] |  UTXO |  $\checkmark$ (D) |  Cycles only |  $\checkmark$
Subramanian _et al._ [83] |  TC and UTXO |  ✗ |  Agnostic |  $\checkmark$
Cycle [84] |  TC |  ✗ |  Cycles only |  $\checkmark$
Rebal [85] |  UTXO |  ✗ |  Cycles only |  $\checkmark$
Shaduf [86] |  TC |  ✗ |  Agnostic |  $\checkmark$
Chen [87] _et al._ |  UTXO |  ✗ |  Cycles |  ✗
Musketeer [88] |  UTXO |  ✗ |  Cycles |  ✗

##  VI Rebalancing

Motivation:Rebalancing in payment channel networks involves redistributing the
balance within an existing payment channel or across multiple channels to
maintain or improve the network’s liquidity and usability. This is done to
ensure that both parties in the channel have sufficient funds on their
respective sides to send and receive payments. Rebalancing is crucial to
payment channel networks. If the link weights of nodes become zero/depleted as
a result of being involved in transactions, it will prevent them from taking
part in further payments until those link weights are replenished. Such nodes
are called as dormant nodes in the network. A PCN which has a large number of
such dormant nodes experiences an overall reduction in transaction throughput
and an overall reduction in liquidity. Hence, the link weights of the nodes in
the PCN need to be rebalanced to prevent failure of transactions due to lack
of liquidity. A rebalancing protocol should be be able to replenish the link
weight of dormant nodes in the PCN irrespective of the PCNs topology, while
not having to employ any trusted entity and should not compromise privacy of
nodes. We now give the properties desired from an ideal virtual channel, and
compare the works in this area on the extent to which they achieve these
properties. We give a qualitative comparison of rebalancing protocols in Table
V. We describe the metrics as follows:
Ideal properties:
1) Blockchain: This is the blockchain on which the corresponding rebalancing
protocol can be deployed. As it can be inferred from the Table, the protocols
can either be deployed on the Ethereum or the Bitcoin blockchains.
2) Trusted entity: This metric determines the nature of trust required among
parties to deploy the rebalancing protocol. A centralized trust (C) indicates
the presence of a single trusted entity and distributed trust (D) indicates
the distribution of trust across various entities.
3) Graph compatibility: This indicates the nature of the topology of the
network on which a rebalancing protocol can be deployed. Cycles indicate that
the rebalancing protocol can only deployed on cyclic graph and agnostic
indicates that the rebalancing protocol can be deployed irrespective of the
network topology.
4) Privacy: Privacy is said to be achieved when sensitive information such as
the local balance and the identities of nodes are not known to anyone except
for their immediate neighbors.

##  VII Research Gaps & Open Problems

In this section, we highlight the gaps in research published until now in the
areas of pathfinding and routing, virtual channel construction, payment
channel hubs, and state channels. This section provides an overview of the
current research problems in these areas along with a discussion on why is
developing a solution to these problems an interesting research challenge.

###  VII-A Gaps in pathfinding and routing for PCNs

We now identify the gaps in research in pathfinding and routing protocols for
payment channel networks.

1) Super node liquidity validation in PCNs: A super node is a highly connected
node (it has payment channels open with numerous other nodes in the network)
and also has a high liquidity in those channels. These super nodes aid other
nodes in pathfinding and routing of payments. These super nodes are called as
a trampoline nodes in $\mathsf{LN}$ [89, 90, 91, 92]. Several other works in
the literature refer to super nodes as routing node, routing helper, landmark
node, routers, etc [25, 24, 27, 37, 33]. One of the main problems with the
super nodes is that the sender has no way to know whether the super node
possess the local balance (liquidity) to route the payment of the sender. The
local balance of a super node or any node in a PCN is a private value and
should not be known to any node except for its immediate neighbor. Currently,
if a super node does not have enough liquidity to route the payment of a
sender, the transaction fails and it has to be retried by the sender. In
$\mathsf{LN}$, one of the most widely used PCN, this is a significant problem.
Sometimes the sender might have to keep retrying for $\approx$ 1 hour to have
a successful payment [93]. The main goal of PCNs is to facilitate
instantaneous payments and these transaction retries render such payments
almost impossible. It might greatly benefit the sender if the it has a
mechanism to validate whether a super node has enough liquidity (balance) to
route its payment without violating any privacy concerns in the network.
Achieving this is hard because the local balance a node has with its immediate
neighbors in a PCN is considered private information and the sender has to
know whether the super node possess enough liquidity without comprising
privacy.

2) Channel verification in a PCN: To be a part of any PCN, nodes will open
payment channels with other nodes in the network. Two nodes open a payment
channel between them by posting a transaction to the blockchain. This
transaction can be posted on the blockchain (as in UTXO based blockchains like
BTC) or this transaction can be posted as a function call to an existing smart
contract (as in blockchains that support smart contracts like ETH). In the
most popular PCN, $\mathsf{LN}$, the channel verification procedure is very
inefficient. It involves the node who intends to verify a channel to request
the block in which the channel opening transaction has been included,
verifying whether the transaction has been successfully executed by the
validator/miner and finally verifying if the channel opening transaction
corresponds to a 2-2 multi signature address on the blockchain. The verifier
performing these steps is inefficient since all these steps will have already
been performed by the miner. According to the current verification process,
any node would need to perform all of these steps for each payment channel it
has open in the network. Consider the following scenario: a node $j$ in the
PCN has payment channels open with $m$ nodes in the PCN. Furthermore, assume
that each neighbor opens $k$ new channels for each time epoch. For this
example, assume the value of the time epoch is 1 block. This would mean that
the total number of channels the node $j$ has to verify a total of $m*k$
channels for every block. This requires the node $j$ to access the blockchain
a total of $m*k$ times to perform channel verification. Finding a way to do
this without blockchain access and in a blockchain agnostic manner in a hard
research challenge.

###  VII-B Gaps in Tumblers

We will now describe the research gaps in tumblers. 1) Privacy against aborts:
In a given a transaction, the tumbler should not be able to correctly identify
the sender/receiver pair involved. Currently, there is only one construction
[59] that guarantees this. However, this construction works only for
blockchains that support Turing complete programming languages. Currently,
there is no such construction for UTXO based blockchains that guarantees
privacy against aborts. This is hard because if the sender aborts a
transaction, the tumbler will know which receiver did not receive the payment.
This is hard because, a tumbler mixes multiple transactions together to ensure
unlikability among payments. Also, a tumbler should enforce atomicity so that
the payment either goes through completely or does not go through at all. In
the case of an abort, an adversary who controls the tumbler might be able to
deduce which receiver amongst the ones involved did not receive a payment and
will be able to link the corresponding transaction amount to that receiver.

2) Time epochs: A tumbler should be able to facilitate payments without having
a predefined time interval or epoch. Currently, the majority of payment
channel hub constructions process payments in discrete epochs to increase the
size of their anonymity sets. An anonymity set refers to a set of users
(senders/receivers) whose identity is indistinguishable from each other. The
size of this set is proportional to the privacy of sender/receiver in the
transaction. When the interval between two consecutive time epochs is
sufficiently large, it will promote more users to take part in the
transactions within a time epoch, which improves privacy. Not having time
epochs results in smaller anonymity sets and hence could possibly weaken
privacy. The trade off is between privacy and flexibility.

3) Dynamic corruption: A tumbler should ideally be resistant to dynamic
corruption. This means the protocol should be resilient to parties deviating
from their ideal execution during the beginning, progress, and ending of the
protocol’s execution. Current tumbler constructions only provide support for
static corruption, which may be unrealistic from a practical standpoint.
Security against dynamic corruption is hard to achieve because the tumbler
mixes several transactions together to preserve anonymity. Since the tumbler
should not be able to link transaction amount to a sender/receiver pair
(ideally), if the sender/receiver becomes malicious during the protocol’s
execution, ideally, that transaction must be aborted to prevent financial loss
to the honest party. However, the tumbler should not be able to link a
transaction to a sender/receiver pair, making security against dynamic
corruption a hard research problem.

###  VII-C Gaps in Virtual Channels

We will now describe the open problems in the area of virtual channels.

1) Blockchain agnostic: A virtual channel should ideally be blockchain
agnostic, meaning it should be deployable regardless of the underlying
scripting or programming language structure supported by the blockchain.

2) Well defined fee structure: The intermediary/intermediaries involved in the
virtual channel construction additionally lock coins apart from the ones
locked in the underlying payment channel. It is necessary to have a well-
defined fee structure for this additional service. Currently, nodes get paid a
routing fees/forwarding fees for every transaction they process. This fee is
dependent on the transaction amount being processed. In the case of virtual
channels, having a well-defined fee structure is difficult due to the
following reasons: 1) The fee structure should take into account the amount of
funds and the time for which these funds of the intermediary/intermediaries
are locked in virtual channel. 2) It also needs to take into account the
routing/forwarding fees an intermediary could have earned by not locking up
the coins in the virtual channel. The fees for an intermediary should be
ideally be more than the routing fees it would have earned in order to
motivate nodes to be involved in virtual channel construction. Currently, no
virtual channel construction has a well-defined fee structure.

3) Off-chain dispute resolution: Ideally a virtual channel protocol should
provide the flexibility to resolve any disputes without accessing the
blockchain. We have seen in Section I, that blockchain writes are expensive.
Having an off-chain dispute resolution is a hard research challenge due to the
following reasons; 1) Any form of layer-2 disputes are usually resolved on the
blockchain. Since underlying consensus in blockchain usually guarantees
resolution of a dispute raised within a specific time period. In an off-chain
scenario, there is no such mechanism which guarantees this. None of the
virtual channel constructions have a provision of off-chain dispute
resolution.

4) Multihop: A virtual channel is said to be multihop if it can facilitate
payments between a sender and a receiver across a path comprising of several
intermediate nodes by constructing a single virtual channel from the sender to
the receiver, without establishing virtual channel(s) between any pair of
intermediate nodes along the path. Currently, no VC construction has this
capability. This is hard because, multihop virtual channel involves designing
a mechanism for sequentially locking coins across a path comprising of several
intermediate nodes. Furthermore, the construction of a multihop virtual
channel should also ensure that any transaction does not effect the overall
balance neutrality (no node apart from the receiver along the path gains or
loses any money). Also, the goals of privacy, atomicity, offchain dispute
resolution need to be enforced.

###  VII-D Gaps in state channel protocols

We will now describe the gaps in the area of state channel protocols.

1) General purpose state channels: An ideal blockchain should be able to
facilitate deployment and execution of several decentralized applications
without requiring the users to access the blockchain for any purpose other
than opening and closing the state channel. Currently, there are two such
constructions [49, 48] which incorporate code reusability into their design.
These two constructions support UTXO based blockchains and have no provision
for offchain dispute resolution.

2) Offchain dispute resolution: Current state channel protocols use an onchain
transaction or a function call to the onchain smart contract in the case of
dispute resolution. An ideal state channel protocol should be able to
facilitate dispute resolutions in an offchain manner. This is a hard research
challenge since disputes on the blockchain are usually resolved by the
underlying consensus mechanisms. In an offchain scenario, there is no such
consensus that guarantees transaction validity. Also, in an offchain protocol
such as the state channel, nodes which are not part of the state channel
protocol do not know any details of the protocol’s execution due to privacy
concerns. Onchain transactions on the hand are publicly accessible.

##  VIII Network Statistics

(a) Minimum accepted value of HTLC payment (msat)

(b) Distribution of base fee (msat)

(c) Distribution of rate fee (msat)

(d) Distribution of node degree

(e) Distribution of HTLC expiration time

Figure 5: $\mathsf{LN}$ statistics

This section introduces a general analysis of the parameters used in
$\mathsf{LN}$, extracted from $\mathsf{LN}$ gossip messages [94]. It offers
views into user behavior and the implications of such behavior for network
performance. Our analysis shows that the nodes prefer to choose the default
value of the $\mathsf{LN}$ parameters. Using standard default values for these
parameters allows nodes to operate smoothly together, reducing the chance of
compatibility issues and enhancing the overall reliability and efficiency of
the $\mathsf{LN}$. We evaluated the analysis on a snapshot of $\mathsf{LN}$
topology from November 27, 2021 [95, 96]. The snapshot includes 18,331 nodes
and 80,918 channels with a mean channel capacity of 4056152.35 satoshi and a
median channel capacity is 1000000 satoshi (this provides us information on
how funds are distributed among $\mathsf{LN}$ channels).
Although not explicitly shown in this chart, nodes with multiple connections
suggest the presence of fewer central nodes compared to the end-users nodes.
Figure 5(a) shows that the majority of the nodes (87.9%) set the
’htlc_minimum_msat’ to a default value of 1000 msat, which indicates that the
$\mathsf{LN}$ supports micropayment transactions. Figure 5(b) shows that
’fee_base_msat’ parameter across all of the nodes has the highest two values
1000 msat as a default value, and 0 msat as the minimum value, which indicates
that most of the nodes do not set the fee_base_msat beyond the default
configuration, and likely to support the network usage. Figure 5(c) shows the
majority of the nodes (51.8%) in $\mathsf{LN}$ use various
’fee_rate_milli_msat’ values. A substantial portion of nodes (35.2%) set their
fee rate to 1 msat to attract more transactions. Also, different nodes have
different fee rate strategies, making $\mathsf{LN}$ a competitive environment.
Figure 5(d) shows that the majority of the nodes (49.5%) have only one
connection that indicates that in $\mathsf{LN}$, many end-users connected to
fewer well-connected nodes. Moreover, 30% of the nodes have no payment
channels, these could be new nodes added to the $\mathsf{LN}$ or they could be
inactive nodes. Figure 5(e) shows that (81.5%) of nodes prefer to set the
’cltv_expiry_delta’ to the default value of 40 blocks, which is the number of
the blocks a node can wait before losing its satoshis from $\mathsf{LN}$.
Moreover, it helps to increase the flexibility of the $\mathsf{LN}$ to include
more nodes along the payment path before reaching the ”locktime max’ parameter
value (2016 blocks). According to the analysis, the nodes generally prefer to
use the default parameter values of the lightning network. Using these default
values can help in developing more effective routing protocols and optimizing
routing fee mechanisms for the nodes.

##  IX Conclusion

In this paper, we qualitatively compared the recent work in various areas of
PCN research: pathfinding and routing, virtual channels, payment channel hubs,
state channels and rebalancing. We have also provided the gaps in research in
these areas along with reasons why fulfilling those gaps is a hard research
challenge. We hope that this paper motivates researchers to build robust
protocols that address these gaps that would go a long way towards building
out and developing the decentralized finance ecosystem.

## References

  * [1] “Forbes,” https://bit.ly/3WnCkYE, accessed: 2023-09-18.
  * [2] Nerdwallet, “Xoom limit minimum,” https://bit.ly/3QnPOAu, 2023.
  * [3] ycharts, “Btc transction througput,” https://bit.ly/3AhRlnf, 2023.
  * [4] miamiherald, “Btc transction througput,” https://www.miamiherald.com/software-business/article274817896.html, 2023.
  * [5] “Btc confirmation time,” https://ycharts.com/indicators/bitcoin_average_confirmation_time, accessed: 2024-04-11.
  * [6] C. Link, “Blockchain scalability,” https://chain.link/education-hub/blockchain-scalability, 2023.
  * [7] “Visa,” https://bit.ly/4dszZ5v, accessed: 2023-09-18.
  * [8] Medium, “Btc transction cost,” https://bit.ly/3ygDZqN, 2023.
  * [9] 99BTC, “Btc transction cost,” https://99bitcoins.com/bitcoin/fees/, 2023.
  * [10] coingecko, “Btc transction cost,” https://bit.ly/3WtSzVh, 2023.
  * [11] MIT, “Ln minimum payment,” https://dci.mit.edu/lightning-network, 2023.
  * [12] BTC, “Average tx cost in btc,” https://bit.ly/4djgHQ6, 2023.
  * [13] LND, “Lnd,” https://docs.lightning.engineering, 2023.
  * [14] coinmarket, “Ln trading volume,” https://coinmarketcap.com/currencies/lightning-bitcoin/, 2023.
  * [15] H. Khojasteh and H. Tabatabaei, “A survey and taxonomy of blockchain-based payment channel networks,” in _2021 IEEE High Performance Extreme Computing Conference (HPEC)_. IEEE, 2021, pp. 1–8.
  * [16] E. Erdin, S. Mercan, and K. Akkaya, “An evaluation of cryptocurrency payment channel networks and their privacy implications. arxiv 2021,” _arXiv preprint arXiv:2102.02659_.
  * [17] L. Gudgeon, P. Moreno-Sanchez, S. Roos, P. McCorry, and A. Gervais, “Sok: Layer-two blockchain protocols,” in _Financial Cryptography and Data Security: 24th International Conference, FC 2020, Kota Kinabalu, Malaysia, February 10–14, 2020 Revised Selected Papers 24_. Springer, 2020, pp. 201–226.
  * [18] Y. Chen, Y. Ran, J. Zhou, J. Zhang, and X. Gong, “Mpcn-rp: A routing protocol for blockchain-based multi-charge payment channel networks,” _IEEE Transactions on Network and Service Management_ , vol. 19, no. 2, pp. 1229–1242, 2022.
  * [19] L. Eckey, S. Faust, K. Hostáková, and S. Roos, “Splitting payments locally while routing interdimensionally,” _IACR Cryptol. ePrint Arch._ , vol. 2020, p. 555, 2020.
  * [20] Q. Gong, C. Zhou, L. Qi, J. Li, J. Zhang, and J. Xu, “Vein: High scalability routing algorithm for blockchain-based payment channel networks,” in _2021 IEEE 20th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom)_ , 2021, pp. 43–50.
  * [21] H.-J. Hong, S.-Y. Chang, and X. Zhou, “Auto-tune: An efficient autonomous multi-path payment routing algorithm for payment channel networks,” _Computer Networks_ , vol. 225, p. 109659, 2023.
  * [22] H. Kadry and Y. Gadallah, “A machine learning-based routing technique for off-chain transactions in payment channel networks,” in _2021 IEEE International Conference on Smart Internet of Things (SmartIoT)_ , 2021, pp. 66–73.
  * [23] S. Lin, J. Zhang, and W. Wu, “Fstr: Funds skewness aware transaction routing for payment channel networks,” in _2020 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN)_ , 2020, pp. 464–475.
  * [24] G. Malavolta, P. Moreno-Sanchez, A. Kate, and M. Maffei, “Silentwhispers: Enforcing security and privacy in decentralized credit networks,” in _24th Annual Network and Distributed System Security Symposium, NDSS 2017, San Diego, California, USA, February 26 - March 1, 2017_ , 2017.
  * [25] G. Panwar, S. Misra, and R. Vishwanathan, “Blanc: Blockchain-based anonymous and decentralized credit networks,” in _Proceedings of the Ninth ACM Conference on Data and Application Security and Privacy_ , ser. CODASPY ’19. New York, NY, USA: Association for Computing Machinery, 2019, p. 339–350. [Online]. Available: https://doi.org/10.1145/3292006.3300034
  * [26] S. Roos, P. Moreno-Sanchez, A. Kate, and I. Goldberg, “Settling payments fast and private: Efficient decentralized routing for path-based transactions,” in _25th Annual Network and Distributed System Security Symposium, NDSS 2018, San Diego, California, USA, February 18-21, 2018_ , 2018.
  * [27] V. Sivaraman, S. B. Venkatakrishnan, K. Ruan, P. Negi, L. Yang, R. Mittal, G. Fanti, and M. Alizadeh, “High throughput cryptocurrency routing in payment channel networks,” in _17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20)_ , 2020, pp. 777–796.
  * [28] P. Wang, H. Xu, X. Jin, and T. Wang, “Flash: Efficient dynamic routing for offchain networks,” ser. CoNEXT ’19. New York, NY, USA: Association for Computing Machinery, 2019, p. 370–381. [Online]. Available: https://doi.org/10.1145/3359989.3365411
  * [29] R. Yu, G. Xue, V. T. Kilari, D. Yang, and J. Tang, “Coinexpress: A fast payment routing mechanism in blockchain-based payment channel networks,” in _27th International Conference on Computer Communication and Networks, ICCCN 2018, Hangzhou, China, July 30 - August 2, 2018_. IEEE, 2018, pp. 1–9.
  * [30] X. Zhang, S. Shi, and C. Qian, “Webflow: Scalable and decentralized routing for payment channel networks with high resource utilization,” _CoRR_ , vol. abs/2109.11665, 2021. [Online]. Available: https://arxiv.org/abs/2109.11665
  * [31] Y. Zhang and D. Yang, “Robustpay: Robust payment routing protocol in blockchain-based payment channel networks,” in _2019 IEEE 27th International Conference on Network Protocols (ICNP)_ , 2019, pp. 1–4.
  * [32] ——, “Robustpay+: Robust payment routing with approximation guarantee in blockchain-based payment channel networks,” _IEEE/ACM Transactions on Networking_ , vol. 29, pp. 1676–1686, 2021.
  * [33] K. Kolachala, M. Ababneh, and R. Vishwanathan, “Raced: Routing in payment channel networks using distributed hash tables,” in _Proceedings of the 19th ACM Asia Conference on Computer and Communications Security_ , ser. ASIA CCS ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 1895–1910.
  * [34] Y. Zhang, D. Yang, and G. Xue, “Cheapay: An optimal algorithm for fee minimization in blockchain-based payment channel networks,” in _ICC 2019 - 2019 IEEE International Conference on Communications (ICC)_ , 2019, pp. 1–6.
  * [35] M. Ababneh, K. Kolachala, and R. Vishwanathan, “Auroch: Auction-based multipath routing for payment channel networks,” in _Proceedings of the 19th ACM Asia Conference on Computer and Communications Security_ , ser. ASIA CCS ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 1861–1877.
  * [36] L. Yang, X. Dong, S. Gao, Q. Qu, X. Zhang, W. Tian, and Y. Shen, “Optimal hub placement and deadlock-free routing for payment channel network scalability,” in _2023 IEEE 43rd International Conference on Distributed Computing Systems (ICDCS)_ , 2023, pp. 692–702.
  * [37] G. Panwar, R. Vishwanathan, G. Torres, and S. Misra, “Sprite: Secure and private routing in payment channel networks,” in _Proceedings of the 19th ACM Asia Conference on Computer and Communications Security_ , ser. ASIA CCS ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 1878–1894.
  * [38] S. Dziembowski, L. Eckey, S. Faust, and D. Malinowski, “Perun: Virtual payment hubs over cryptocurrencies,” in _2019 IEEE Symposium on Security and Privacy (SP)_. IEEE, 2019, pp. 106–123.
  * [39] K. Kolachala, E. Simsek, M. Ababneh, and R. Vishwanathan, “Sok: Money laundering in cryptocurrencies,” in _Proceedings of the 16th International Conference on Availability, Reliability and Security_ , ser. ARES ’21. New York, NY, USA: Association for Computing Machinery, 2021.
  * [40] M. Jourenko, M. Larangeira, and K. Tanaka, “Lightweight virtual payment channels,” in _International Conference on Cryptology and Network Security_. Springer, 2020, pp. 365–384.
  * [41] L. Aumayr, M. Maffei, O. Ersoy, A. Erwig, S. Faust, S. Riahi, K. Hostáková, and P. Moreno-Sanchez, “Bitcoin-compatible virtual channels,” in _2021 IEEE Symposium on Security and Privacy (SP)_. IEEE, 2021, pp. 901–918.
  * [42] A. Kiayias and O. S. T. Litos, “Elmo: Recursive virtual payment channels for bitcoin,” _Cryptology ePrint Archive_ , 2021.
  * [43] L. Aumayr, P. Moreno-Sanchez, A. Kate, and M. Maffei, “Breaking and fixing virtual channels: Domino attack and donner,” in _Network and Distributed System Security (NDSS) Symposium_ , 2023.
  * [44] X. Jia, Z. Yu, J. Shao, R. Lu, G. Wei, and Z. Liu, “Cross-chain virtual payment channels,” _IEEE Trans. Inf. Forensics Secur._ , vol. 18, pp. 3401–3413, 2023.
  * [45] S. Dziembowski, L. Eckey, S. Faust, J. Hesse, and K. Hostáková, “Multi-party virtual state channels,” in _Advances in Cryptology–EUROCRYPT 2019: 38th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Darmstadt, Germany, May 19–23, 2019, Proceedings, Part I 38_. Springer, 2019, pp. 625–656.
  * [46] S. Dziembowski, S. Faust, and K. Hostáková, “General state channel networks,” in _Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security_ , 2018, pp. 949–966.
  * [47] P. McCorry, S. Bakshi, I. Bentov, S. Meiklejohn, and A. Miller, “Pisa: Arbitration outsourcing for state channels,” in _Proceedings of the 1st ACM Conference on Advances in Financial Technologies_ , 2019, pp. 16–30.
  * [48] M. M. Chakravarty, S. Coretti, M. Fitzi, P. Gaži, P. Kant, A. Kiayias, and A. Russell, “Fast isomorphic state channels,” in _Financial Cryptography and Data Security: 25th International Conference, FC 2021, Virtual Event, March 1–5, 2021, Revised Selected Papers, Part II 25_. Springer, 2021, pp. 339–358.
  * [49] A. Miller, I. Bentov, S. Bakshi, R. Kumaresan, and P. McCorry, “Sprites and state channels: Payment networks that go faster than lightning,” in _International conference on financial cryptography and data security_. Springer, 2019, pp. 508–526.
  * [50] L. Aumayr, O. Ersoy, A. Erwig, S. Faust, K. Hostáková, M. Maffei, P. Moreno-Sanchez, and S. Riahi, “Generalized channels from limited blockchain scripts and adaptor signatures,” in _Advances in Cryptology–ASIACRYPT 2021: 27th International Conference on the Theory and Application of Cryptology and Information Security, Singapore, December 6–10, 2021, Proceedings, Part II 27_. Springer, 2021, pp. 635–664.
  * [51] L. Negka, A. Katsika, G. Spathoulas, and V. Plagianakos, “Origami: A flexible state channels design for public blockchain systems,” _arXiv preprint arXiv:2304.10313_ , 2023.
  * [52] T. Close and A. Stewart, “Forcemove: an n-party state channel protocol,” _Magmo, White Paper_ , 2018.
  * [53] M. Green and I. Miers, “Bolt: Anonymous payment channels for decentralized currencies,” in _Proceedings of the 2017 ACM SIGSAC conference on computer and communications security_ , 2017, pp. 473–489.
  * [54] R. Khalil, A. Zamyatin, G. Felley, P. Moreno-Sanchez, and A. Gervais, “Commit-chains: Secure, scalable off-chain payments,” _Cryptology ePrint Archive_ , 2018.
  * [55] J. Du, Z. Ge, Y. Long, Z. Liu, S. Sun, X. Xu, and D. Gu, “Mixct: Mixing confidential transactions from homomorphic commitment,” in _European Symposium on Research in Computer Security_. Springer, 2022, pp. 763–769.
  * [56] E. Tairi, P. Moreno-Sanchez, and M. Maffei, “A2l: Anonymous atomic locks for scalability in payment channel hubs,” in _2021 IEEE Symposium on Security and Privacy (SP)_ , 2021, pp. 1834–1851.
  * [57] X. Qin, S. Pan, A. Mirzaei, Z. Sui, O. Ersoy, A. Sakzad, M. F. Esgin, J. K. Liu, J. Yu, and T. H. Yuen, “Blindhub: Bitcoin-compatible privacy-preserving payment channel hubs supporting variable amounts,” in _2023 IEEE Symposium on Security and Privacy (SP)_ , 2023, pp. 2462–2480.
  * [58] J. Lind, O. Naor, I. Eyal, F. Kelbert, E. G. Sirer, and P. Pietzuch, “Teechain: a secure payment network with asynchronous blockchain access,” in _Proceedings of the 27th ACM Symposium on Operating Systems Principles_ , 2019, pp. 63–79.
  * [59] Z. Ge, J. Gu, C. Wang, Y. Long, X. Xu, and D. Gu, “Accio: Variable-amount, optimized-unlinkable and nizk-free off-chain payments via hubs,” in _Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security_ , ser. CCS ’23. New York, NY, USA: Association for Computing Machinery, 2023, p. 1541–1555. [Online]. Available: https://doi.org/10.1145/3576915.3616577
  * [60] J. He, W. Qiu, R. He, S. Zhuo, and W. Jie, “Turbo: A high-performance and secure off-chain payment hub,” in _International Conference on Machine Learning for Cyber Security_. Springer, 2022, pp. 67–75.
  * [61] J. Zhang, Y. Ye, W. Wu, and X. Luo, “Boros: Secure and efficient off-blockchain transactions via payment channel hub,” _IEEE Transactions on Dependable and Secure Computing_ , vol. 20, no. 1, pp. 407–421, 2021.
  * [62] E. Heilman, L. Alshenibr, F. Baldimtsi, A. Scafuro, and S. Goldberg, “Tumblebit: An untrusted bitcoin-compatible anonymous payment hub,” in _Network and distributed system security symposium_ , 2017.
  * [63] G. D. Bissias, A. P. Ozisik, B. N. Levine, and M. Liberatore, “Sybil-resistant mixing for bitcoin,” in _Proceedings of the 13th Workshop on Privacy in the Electronic Society, WPES 2014, Scottsdale, AZ, USA, November 3, 2014_ , G. Ahn and A. Datta, Eds. ACM, 2014, pp. 149–158.
  * [64] J. Bonneau, A. Narayanan, A. Miller, J. Clark, J. A. Kroll, and E. W. Felten, “Mixcoin: Anonymity for bitcoin with accountable mixes,” in _Financial Cryptography and Data Security - 18th International Conference, FC 2014, Christ Church, Barbados, March 3-7, 2014, Revised Selected Papers_ , ser. Lecture Notes in Computer Science, N. Christin and R. Safavi-Naini, Eds., vol. 8437. Springer, 2014, pp. 486–504.
  * [65] P. Fauzi, S. Meiklejohn, R. Mercer, and C. Orlandi, “Quisquis: A new design for anonymous cryptocurrencies,” in _Advances in Cryptology–ASIACRYPT 2019: 25th International Conference on the Theory and Application of Cryptology and Information Security, Kobe, Japan, December 8–12, 2019, Proceedings, Part I 25_. Springer, 2019, pp. 649–678.
  * [66] E. Heilman, F. Baldimtsi, and S. Goldberg, “Blindly signed contracts: Anonymous on-blockchain and off-blockchain bitcoin transactions,” in _Financial Cryptography and Data Security - FC 2016 International Workshops, BITCOIN, VOTING, and WAHC, Christ Church, Barbados, February 26, 2016, Revised Selected Papers_ , ser. Lecture Notes in Computer Science, J. Clark, S. Meiklejohn, P. Y. A. Ryan, D. S. Wallach, M. Brenner, and K. Rohloff, Eds., vol. 9604. Springer, 2016, pp. 43–60.
  * [67] P. Moreno-Sanchez, T. Ruffing, and A. Kate, “Pathshuffle: Credit mixing and anonymous payments for ripple,” _Proc. Priv. Enhancing Technol._ , vol. 2017, no. 3, p. 110, 2017.
  * [68] T. Ruffing, P. Moreno-Sanchez, and A. Kate, “Coinshuffle: Practical decentralized coin mixing for bitcoin,” in _Computer Security - ESORICS 2014 - 19th European Symposium on Research in Computer Security, Wroclaw, Poland, September 7-11, 2014. Proceedings, Part II_ , ser. Lecture Notes in Computer Science, M. Kutylowski and J. Vaidya, Eds., vol. 8713. Springer, 2014, pp. 345–364.
  * [69] T. Ruffing and P. Moreno-Sanchez, “Valueshuffle: Mixing confidential transactions for comprehensive transaction privacy in bitcoin,” in _Financial Cryptography and Data Security - FC 2017 International Workshops, WAHC, BITCOIN, VOTING, WTSC, and TA, Sliema, Malta, April 7, 2017, Revised Selected Papers_ , ser. Lecture Notes in Computer Science, M. Brenner, K. Rohloff, J. Bonneau, A. Miller, P. Y. A. Ryan, V. Teague, A. Bracciali, M. Sala, F. Pintore, and M. Jakobsson, Eds., vol. 10323. Springer, 2017, pp. 133–154.
  * [70] M. Tran, L. Luu, M. S. Kang, I. Bentov, and P. Saxena, “Obscuro: A bitcoin mixer using trusted execution environments,” in _Proceedings of the 34th Annual Computer Security Applications Conference, ACSAC 2018, San Juan, PR, USA, December 03-07, 2018_. ACM, 2018, pp. 692–701.
  * [71] L. Valenta and B. Rowan, “Blindcoin: Blinded, accountable mixes for bitcoin,” in _Financial Cryptography and Data Security - FC 2015 International Workshops, BITCOIN, WAHC, and Wearable, San Juan, Puerto Rico, January 30, 2015, Revised Selected Papers_ , ser. Lecture Notes in Computer Science, M. Brenner, N. Christin, B. Johnson, and K. Rohloff, Eds., vol. 8976. Springer, 2015, pp. 112–126.
  * [72] J. H. Ziegeldorf, F. Grossmann, M. Henze, N. Inden, and K. Wehrle, “Coinparty: Secure multi-party mixing of bitcoins,” in _Proceedings of the 5th ACM Conference on Data and Application Security and Privacy, CODASPY 2015, San Antonio, TX, USA, March 2-4, 2015_ , J. Park and A. C. Squicciarini, Eds. ACM, 2015, pp. 75–86.
  * [73] J. Bonneau, A. Narayanan, A. Miller, J. Clark, J. A. Kroll, and E. W. Felten, “Mixcoin: Anonymity for bitcoin with accountable mixes,” in _Financial Cryptography and Data Security: 18th International Conference, FC 2014, Christ Church, Barbados, March 3-7, 2014, Revised Selected Papers 18_. Springer, 2014, pp. 486–504.
  * [74] G. Maxwell, “Coinswap: transaction graph disjoint trustless trading (2013),” _URL: https://bitcointalk. org/index. php_ , 2013.
  * [75] P. Moreno-Sanchez, T. Ruffing, and A. Kate, “Pathshuffle: Credit mixing and anonymous payments for ripple,” _Proceedings on Privacy Enhancing Technologies_ , 2017.
  * [76] T. Ruffing and P. Moreno-Sanchez, “Valueshuffle: Mixing confidential transactions for comprehensive transaction privacy in bitcoin,” in _Financial Cryptography and Data Security: FC 2017 International Workshops, WAHC, BITCOIN, VOTING, WTSC, and TA, Sliema, Malta, April 7, 2017, Revised Selected Papers 21_. Springer, 2017, pp. 133–154.
  * [77] T. Ruffing, P. Moreno-Sanchez, and A. Kate, “Coinshuffle: Practical decentralized coin mixing for bitcoin,” in _Computer Security-ESORICS 2014: 19th European Symposium on Research in Computer Security, Wroclaw, Poland, September 7-11, 2014. Proceedings, Part II 19_. Springer, 2014, pp. 345–364.
  * [78] S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. McCoy, G. M. Voelker, and S. Savage, “A fistful of bitcoins: characterizing payments among men with no names,” in _Proceedings of the 2013 conference on Internet measurement conference_ , 2013, pp. 127–140.
  * [79] M. Tran, L. Luu, M. S. Kang, I. Bentov, and P. Saxena, “Obscuro: A bitcoin mixer using trusted execution environments,” in _Proceedings of the 34th Annual Computer Security Applications Conference_ , 2018, pp. 692–701.
  * [80] J. H. Ziegeldorf, F. Grossmann, M. Henze, N. Inden, and K. Wehrle, “Coinparty: Secure multi-party mixing of bitcoins,” in _Proceedings of the 5th ACM Conference on Data and Application Security and Privacy_ , 2015, pp. 75–86.
  * [81] R. Khalil and A. Gervais, “Revive: Rebalancing off-blockchain payment networks,” ser. CCS ’17. New York, NY, USA: Association for Computing Machinery, 2017, p. 439–453. [Online]. Available: https://doi.org/10.1145/3133956.3134033
  * [82] Z. Avarikioti, K. Pietrzak, I. Salem, S. Schmid, S. Tiwari, and M. Yeo, “Hide & seek: Privacy-preserving rebalancing on payment channel networks,” in _International Conference on Financial Cryptography and Data Security_. Springer, 2022, pp. 358–373.
  * [83] L. M. Subramanian, G. Eswaraiah, and R. Vishwanathan, “Rebalancing in acyclic payment networks,” in _2019 17th International Conference on Privacy, Security and Trust (PST)_. IEEE, 2019, pp. 1–5.
  * [84] Z. Hong, S. Guo, R. Zhang, P. Li, Y. Zhan, and W. Chen, “Cycle: Sustainable off-chain payment channel network with asynchronous rebalancing,” in _2022 52nd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN)_ , 2022, pp. 41–53.
  * [85] N. Awathare, V. J. Ribeiro, U. Bellur _et al._ , “Rebal: channel balancing for payment channel networks,” in _2021 29th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS)_. IEEE, 2021, pp. 1–8.
  * [86] Z. Ge, Y. Zhang, Y. Long, and D. Gu, “Shaduf: Non-cycle and privacy-preserving payment channel rebalancing,” _Cryptology ePrint Archive_ , 2022.
  * [87] W. Chen, X. Qiu, Z. Cai, B. Tang, L. Du, and Z. Zheng, “Graph neural network-enhanced reinforcement learning for payment channel rebalancing,” _IEEE Transactions on Mobile Computing_ , vol. 23, no. 6, pp. 7066–7083, 2024.
  * [88] Z. Avarikioti, S. Schmid, and S. Tiwari, “Musketeer: Incentive-compatible rebalancing for payment channel networks,” _Cryptology ePrint Archive_ , 2023.
  * [89] Decker, “Trampoline slides,” https://bit.ly/4d79tPw, 2023.
  * [90] LND, “Trampoline payments github,” https://bit.ly/475DJH4, 2023.
  * [91] stacker news, “Rendezvousrouting,” https://stacker.news/items/50354, 2023.
  * [92] Voltage, “What are blinded paths and how do they work?” https://bit.ly/3tX2VBk, 2023.
  * [93] A. tx retries, “Acinq tx retries,” https://bit.ly/4fvJN0A, 2023.
  * [94] LN, “Ln gossip,” https://docs.lightning.engineering/the-lightning-network/the-gossip-network, 2023.
  * [95] “Elias rohrer and julian malliaris and florian tschorsch.” [Online]. Available: https://git.tu-berlin.de/rohrer/discharged-pc-data/tree/master/snapshots
  * [96] E. Rohrer, J. Malliaris, and F. Tschorsch, “Discharged payment channels: Quantifying the lightning network’s resilience to topology-based attacks,” in _2019 IEEE european symposium on security and privacy workshops (EuroS &PW)_. IEEE, 2019, pp. 347–356.