# Self-Balancing Semi-Hierarchical PCNs for CBDCs

Marco Benedetti, Francesco De Sclavis, Marco Favorito, Giuseppe Galano,
Sara Giammusso, Antonio Muci, Matteo Nardelli∗ Technical Report
CFC.CRYPTO.CS/2024/1
Applied Research Team (ART) - IT Department - Bank of Italy†

###### Abstract

We introduce a family of PCNs (Payment Channel Networks) characterized by a
semi-hierarchical topology and a custom set of channel rebalancing strategies.
This family exhibits two interesting benefits, if used as a platform for
large-scale, instant, retail payment systems, such as CBDCs: Technically, the
solution offers state-of-the-art guarantees of fault-tolerance and integrity,
while providing a latency and throughput comparable to centralized systems;
from a business perspective, the solution perfectly suits the 3-tier
architecture of the current banking ecosystem (central banks / commercial
banks / retail users), assigning a pivotal and peculiar role to the members of
each tier. Furthermore, the cryptographic privacy of payments for retail
users—typical of PCNs such as the public Lightning Network—is largely
(possibly fully) retained. We study the system by simulating a scaled-down
version of a hypothetical European CBDC, exploring the trade-offs among
liquidity locked by market operators, payment success rate, throughput,
latency, and load on the underpinning blockchain.

11footnotetext: E-mail address of the authors are in the form
<EMAIL_ADDRESS>except for
<EMAIL_ADDRESS>The views expressed in this
paper are those of the authors and do not necessarily reflect those of the
Bank of Italy.

##  I Introduction

Retail instant payment systems—such as credit/debit card circuits or Central
Bank Digital Currencies (CBDCs)—manage a very high load of transactions, in
the order of $10^{4}$–$10^{5}$ TPS (see Sect. V-A). Centralized systems are
often deployed to ingest and settle all such transactions timely.

Performance is not all though: In the special case of CBDCs, further business
and technical requirements are put into place111For the case of the digital
euro, see e.g. [1, 2], such as the possibility to set a cap on the amount of
liquidity users can amass (wallet cap), strong privacy guarantees for all
payment data, small or no fees for citizens (“free for basic use”), and the
possibility to be usable by unbanked people.

Finally, retail instant payment systems have to be embedded into—and play nice
with—the pre-defined, multi-tier structure of the existing banking and payment
infrastructure: a pyramid that sees the Central Bank(s) at the top, a set of
authorized intermediaries (such as commercial banks and similar financial
institutions) in the middle, and retail users (such as citizens and merchants)
at the bottom—providing each actor with clear and strong incentives to adopt
and use the system itself222 For an introduction to this three-tier structure,
see[3]..

We ask: Can a blockchain-based payment system address all these concerns and
requirements while bringing to the table tangible benefits in comparison to a
centralized solution?

In this work, we move the first steps towards tentatively answering such a
question in the positive (for a CBDC).

First essential point: Most blockchains are well-known for their limited
throughput, so on-chain settlement of retail payments is very difficult to
achieve. We forgo such a perspective entirely and embrace the off-ledger
paradigm, whereby scalability is achieved by an additional “payment channel
network”, or PCN (called $2^{nd}$ layer) built on top of the actual blockchain
(see Sect. II). In the wild, $2^{nd}$ layer networks—e.g., the Lightning
Network [4]—evolve freely, as peer-to-peer systems: They are unstructured and
adopt best-effort payment routing strategies. Unfortunately, their anatomy (i)
is not coherent with the 3-tier structure of the monetary system, (ii) is
oblivious to most of the business requirements of a CBDC, and (iii) provides a
level of scalability that—albeit significant w.r.t. the underpinning
blockchains—is still insufficient for a large-scale retail instant payment
system.

We address these issues by devising a family of PCNs with a partially
constrained topology, called “Semi-Hierarchical Payment Channel Networks”, or
SH-PCNs (Sect. III), endowed with a set of custom balancing strategies (Sect.
IV). SH-PCNs are designed to play nice with the financial ecosystem and to
exhibit performances akin to a retail payment system.

Assuming SH-PCNs allow us to achieve the required throughput and latency with
sufficient reliability (a question we ponder in Sect. VI-B), we can shift our
attention to the benefits of using a distributed, blockchain-based, 2-layer
solution: Blockchains introduce tools capable of increasing integrity,
availability, fault-tolerance, and verifiability of monetary exchanges; at the
$2^{nd}$ (retail) layer, they (i) accommodate, by design, levels of privacy
similar to that of cash; (ii) naturally handle wallet caps; (iii) give the
central bank (CB) and the market control on the transaction fees for retail
users.

We do not model a full-scale SH-PCN system just yet, but a scaled-down
version. This reduced model is still capable of exhibiting the key dynamics we
want to investigate, such as the trade-offs among the liquidity locked in
channels, the success rate of payments, their latency, and the transactional
demand on the underlying $1^{st}$-layer blockchain (see Sect. VIII).

Our preliminary results suggest that the performance of SH-PCN is satisfactory
for retail payments; that SH-PCNs map naturally onto the banking/payment
ecosystem; and that the most typical CBDC-specific requirements are naturally
met.

In the following sections, we provide a description of the solution that
carefully combines the technical, PCN-oriented angle with the business, CBDC-
oriented perspective.

Figure 1: Structure and main features of a Semi-Hierarchical Payment Channel
Network (SH-PCN), plus three sample payment routes: One Point-of-Sale payment
from retail user $c_{4}$ (a citizen) to merchant $m_{2}$; one Peer-to-Peer
transaction from $c_{2}$ to $c_{3}$; one eCommerce route from $c_{1}$ to a
foreign merchant $m_{1}$. As usual with source-based onion-routed protocols,
no actor (other than the payer and payee) has full information about any of
these payments.

##  II The Payment Channel Network (PCN) model

In a PCN, two nodes create a bilateral _payment channel_ by “pre-funding” it,
i.e., by locking some amount of liquidity, called _channel capacity_ , into a
2-of-2 multisig UTXO, using a single _on-chain_ funding transaction; the sum
of nodes’ balance in the channel can never exceed the payment channel
capacity.

After the channel is created (i.e., the funding transaction is confirmed), the
nodes can exchange multiple, instant, off-chain payments, which update the
balances of nodes and eliminate the need to constantly execute on-chain
transactions.

The safety of payments within the channel is ensured through the previously
described pre-funding and a cryptographic mechanism called _channel
revocation_ : If a cheating attempt by one party is detected, the other is
entitled to claim the entire channel capacity both as compensation and as a
penalty for the attempted cheating. For a comprehensive description of how
PCNs work and how they relate to the underpinning blockchain, we refer the
reader to [4, 5].

The largest PCN in existence is the public Lightning Network (LN). Recent
studies (e.g., [6, 7]) show that the topology of the LN exhibits the
characteristics of a small-world and scale-free network. As shown in [8], such
scale-free topologies are sub-optimal in terms of locked liquidity. And while
an alternative star-like network configuration would help decrease liquidity
inefficiencies, it would also reduce fault-tolerance, security, and privacy of
payments [6].

##  III Structure of a Semi-Hierarchical PCN

The current monetary system—which is the target deployment environment for our
solution—is based on a _three-tier banking system_. The pyramid sees the CB at
the top, a set of authorized intermediaries (such as commercial banks and
similar financial institutions) in the middle, and retail users (such as
citizens and merchants) at the bottom. For an introduction to this three-tier
architecture, see[3].

These different (business) roles will be mapped onto various different
(technical) roles in the PCN subclass we study, and the hierarchical anatomy
of the banking system will be reflected into the (semi) hierarchical topology
of the network.

In SH-PCNs, we make a distinction among four classes of technical nodes,
managed by four types of business actors, organized into 3 tiers: Monetary
Hubs (MHs) at the top, Lightning Service Providers (LSPs) and Custodian
Services (CSs) in the middle, and End-Users (EUs) at the bottom, as
represented in Fig. 2.

  * •

Monetary Hubs. Tier-1 nodes typically managed by a CB (or a set of CBs in the
same monetary area): At the on-chain layer, they are fully responsible for the
operation of the ledger where transactions to open/close channels are stored
and where (CB) liquidity is locked. At the off-ledger layer, they operate
nodes with considerable liquidity, which are largely (or fully)
interconnected, and which act as _Routing Service Providers_ (RSPs) for LSPs
in Tier-2. Thus, MHs act as business-to-business entities and do not interact
with EUs;

  * •

Lightning Service Providers. Tier-2 nodes acting as the core, distributed
“service providers” of the system. LSPs freely open channels towards each
other, forming a “small world”-like network, ensuring that fault tolerance and
the other benefits of distributed networks are achieved. Disconnected LSP sub-
networks, if they exist, are linked via RSP(s). From a business perspective,
this role is assigned to banks and other financial institutions, which are
properly supervised and own large amounts of liquidity. LSPs offer their
service to EUs by opening channels with them, thus providing them with
connectivity and reachability within the payment network.

  * •

Custodian Services. In addition to off-chain CB liquidity in the SH-PCN, EUs
generally own one or more accounts at Tier-2 CSs, such as banks or exchanges,
which allow EUs to deposit/withdraw retail CBDC to/from their personal
accounts333These account-based ledgers are managed by a (centralized) system
entirely decoupled from the PCN, under the responsibility of the CS., which
amass “commercial bank money”. The CSs are connected to the LSPs network. The
EU does not necessarily have direct channels opened with CSs, as their
monetary interactions happen either out-of-band (see Sect. IV-B and IV-C) or
through LSP intermediaries.

  * •

End-users. Tier-3 nodes managed by “end-users” (i.e., citizens and merchants):
They access the network connecting to one or more LSPs in a _non-custodial_
way, thereby preserving the privacy of their payments. Crucially (from a
business perspective) we have that (i) EUs do not open channels with each
other444This is not a technical limitation, but a policy option: If end users
were allowed to access the Layer 1 blockchain to freely open channels among
them, the level of privacy of payments would quickly approach full anonimity.,
and (ii) EU channels—with a known capacity—are only opened with one or more
authorized LSP(s): We can place a cap on the maximum amount of retail CBDC
present in the user wallet, without sacrificing privacy.

So, Tier-1 is the domain of CBs; Tier-2 is where market operators act; EUs
live at Tier-3, in a hierarchy where MHs only connect to LSPs and EUs only
connect to LSPs and CSs. The number of EUs is much larger than the number of
LSPs/CSs, which in turn are many more than the MHs.

##  IV Automated Channel Rebalancing Techniques

Absent any dynamics in network topology (see Sect. V-C), the performance
(success rate, throughput, latency) of SH-PCNs subject to most types of
sustained loads of payments among end users degrades over time: Channels
become more and more unbalanced, hence unable to participate into the routing
of an increasing percentage of payments.

To avoid such progressive occlusion, we define 3 rebalancing techniques, aimed
at improving channel lifetimes while minimizing locked liquidity. We make the
hypotheses that (i) LSPs and routing nodes try to keep their channels balanced
by proactively issuing trustless “ _submarine swaps_ ” between on-chain and
off-chain liquidity; (ii) end users rebalance their channels in real-time,
when needed, by withdrawing funds from—or depositing funds to—their trusted
CS(s)555These regulated entities are the points where AML/CFT activities can
be performed, possibly issuing Suspect Transactions Reports (STRs) to the CB.
.

###  IV-A Submarine swaps between two LSP/MH nodes

A _submarine swap_ is a transaction that exchanges a given amount of some on-
chain digital asset with the same amount of the off-chain form of the same
asset (e.g., $x$ bitcoin are moved from $A$ to $B$ on the blockchain and
“simultaneously” $x$ bitcoin go from $B$ to $A$ in the Lightning Network).

Submarine swaps can be trustless: At no point during the process either party
has access to the other party’s fund, and no third party takes temporary
custody of the asset. The swaps are atomic, with a binary outcome: Either the
two parties successfully exchange their assets, or the swap fails.

Figure 2: Atomic submarine swap functionality

To implement the trustless requirement of a submarine swap, both the on-chain
and the off-chain transactions rely on Hash-Time Locked Contracts (HTLCs).
Fig. 2 represents two LSPs that share an unbalanced channel, with almost all
liquidity held at the LSP1 end. LSP1 wants to rebalance the channel by
transferring assets on the payment channels with LSP2, who in turn should move
the same amount of assets on-chain to LSP1. They proceed as follows. LSP2,
sender of the on-chain transaction, generates a preimage, whose hash serves as
the foundation for constructing both the on-chain and off-chain HTLCs, and
moves funds to the on-chain HTLC (step 1). LSP2 also generates an off-chain
invoice using the same hash and asks LSP1, sender of the off-chain
transaction, to pay the invoice. After the chain confirms the locking of funds
in the on-chain HTLC, LSP1 can safely pay the invoice (step 2). To claim the
off-chain funds, LSP2 has to reveal the preimage to LSP1 (step 3), who in turn
can use it to complete the process, by claiming the funds from the on-chain
HTLC (step 4). At any time, if any of the two parts misbehaves, the other can
get its funds thanks to the unlocking conditions of the HTLCs.

Due to the reliance on on-chain transactions, a submarine swap takes time (at
least the confirmation time of the HTLC in step 1) and possibly requires a fee
(depending on the policy enacted by the MH). Moreover, the transactional
capacity of the underlying blockchain limits the number of submarine swaps per
unit of time that can be performed by the SH-PCN.

###  IV-B Waterfall666The terms “waterfall” / “reverse waterfall” are lifted
from [2]. We present a PCN-oriented, fully compliant implementation of the
processes they designate. rebalance

The _waterfall_ mechanism allows end-users—in particular those having high
inbound traffic (e.g., merchants)—to always be able to get paid, even if the
amount $P$ to be received raises the user balance $B$ above the channel
capacity limit $C$ (i.e., the wallet cap). This is achieved by automatically
depositing the amount $D=\max{(B+P-C,L_{D})}$, where $L_{D}$ is a minimum
amount that the user is willing to deposit, to a linked CS account.

Figure 3: Waterfall functionality implementation in a PCN

Fig. 3 illustrates the waterfall functionality. When the LSP receives a
payment to forward (step 1), but the end user’s channel does not have enough
outbound liquidity, the LSP _notifies_ the user about the incoming payment
(step 2), and delays the payment forwarding until the expiration of a timeout.
The user requests a real-time deposit to their CS (step 3), which in turn
sends the deposit via the same LSP, thus rebalancing the channel (step 4). If
the channel is successfully rebalanced within the timeout, the LSP forwards
the payment to the user (step 5); otherwise, the payment fails. Messages
exchanged in steps 2 and 3, in bold, are not part of the LN specification, but
are specific to our protocol. From a business perspective, this mechanism
implements a deposit of retail CBDC liquidity from the wallet of an EU into an
account held by the same EU at some CS, in commercial bank money, triggered
when the CBDC wallet is about to overflow the cap.

###  IV-C Reverse waterfall rebalance

The _reverse waterfall_ functionality allows retail users—in particular those
having high outbound traffic (e.g., citizens)—to automatically fund a payment
channel before making transactions too large for the current state of that
channel. Fig. 4 illustrates the reverse waterfall functionality.

Figure 4: Reverse waterfall functionality implementation in a PCN

If there are insufficient funds in the payment channel to cover the payment
amount $P$, users could request a withdrawal (step 1), thus taking out some
money from their CS account (step 2). The withdrawal amount is
$W=\max{(L_{W}-B,P-B)}$, where $L_{W}$ represents a minimum amount that the
user is willing to keep in its wallet for future use. Once the withdrawal has
successfully transferred liquidity from the linked CS to the payment channel,
the user can send the payment (step 3). The message exchanged in step 1 is not
part of the LN specification, but is specific to our protocol. From a business
perspective, this mechanism implements a withdrawal of commercial bank money
from the account of an EU at their CS, which is returned as CBDC liquidity put
into the wallet of the same EU; this process is triggered when the CBDC wallet
has insufficient funds to operate.

##  V The real world and our small-scale model

###  V-A Patterns of real-world retail payments

Retail payment systems manage a very high load of transactions. A commercial,
global-scale example is VISA, which recently disclosed that its network can
execute more than $65,000$ transactions per second at its
peak777https://usa.visa.com/solutions/crypto/deep-dive-on-solana.html.

For a public retail payment system, such as a prospective CBDC for the euro
area, we can refer to the “ _Study on the payment attitudes of consumers in
the euro area_ ” (SPACE) by the ECB [9]. The study reports a survey among a
randomly selected sample of the population across $19$ euro area countries.
Participants were requested to document their point-of-sale (POS), peer-to-
peer (P2P), and online transactions in a one-day diary. The survey also
includes recurring payments that are out of the scope of our investigation.
The key results of SPACE 2022 are summarized in Table I.

In addition, we consider the Annex 1 of the ECB’s “ _Market Research on
Potential Technical Approaches for a Digital Euro_ ” [1], which states that,
on average, individuals within the euro area engage in two financial
transactions per day, encompassing various payment methods and interaction
points. The “Large” adoption case considered in this report assumes that 70%
of the eurozone population will use the CBDC for 35% of all transactions. This
implies approximately 2,000 TPS on average. Peak values may be larger by an
order of magnitude.

These numbers—in the $10^{3}$–$10^{5}$ range—corroborate our working
hypothesis about the need of an off-ledger layer to face retail payments. And,
they provide us with a clear reference point to designing proportioned scaled-
down models.

The aforementioned SPACE report, as seen in Table I, provides us with further
interesting information about real-world payments, which we can use to
assemble a believable small-scale model: the distribution of transaction
amounts, the proportion among Point-of-Sale, eCommerce, and Peer-to-Peer
payments, and the tendency of retail payments to be domestic (within the same
country) rather than cross-border.

Finally, it is worth recalling that a payment is defined as “instant” in this
context if it completes within 10 seconds [10].

TABLE I: Statistics on non-recurring payments. ECB SPACE 2022.

Type |  N. (%) | Distribution (%) of Range Amount (€)
---|---|---
$<5$ | $[5,10)$ | $[10,20)$ | $[20,30)$ | $[30,50)$ | $[50,100)$ | $>100$
PoS | $80$ | $21$ | $17$ | $21$ | $13$ | $13$ | $10$ | $5$
Online | $17$ | $10$ | $11$ | $20$ | $15$ | $17$ | $16$ | $11$
P2P | $3$ | $(14)^{*}$ | $(11)^{*}$ | $(22)^{*}$ | $(16)^{*}$ | $(14)^{*}$ | $(11)^{*}$ | $(12)^{*}$

∗ Unfortunately, the frequencies of amount ranges in the P2P scenario are not
available in SPACE; these values have been estimated by the authors.

###  V-B Size of our small-scale model

We study a network on a scale $\sim$1:1000 relative to the actual population
of the euro area (344 million citizens). Our network thus consists of 300k
individuals (retail users) at Tier 3.

We incorporate a merchant every 100 people, and a service provider every 10k
end-users, in line with the 6.4k inhabitants per bank branch in the EU [11],
for a total of 3k merchants and 30 service providers in Tier 2. We model 3
countries, representative of different scales found in the euro zone: a small
country (such as Cyprus, with $\sim$1M citizens), one medium-size country
(such as Finland, $\sim$6M), and a large country (such as Italy, $\sim$60M).
Each user and each intermediary is associated with one of these countries, and
the distribution of nodes among countries is proportional to their population.

At Tier 1, each country has a (node representing its) national Central Bank
(NCB). NCBs live in the same monetary area and are interconnected. Cross-
national payments are assumed to be a fraction of the national payments,
namely 5%. Overall, there are $3$ countries (CBs), $3\cdot 10^{1}$ service
providers (financial institutions), $3\cdot 10^{3}$ merchants, and $3\cdot
10^{5}$ citizens.

The number of payments per second is also scaled 1:1000, proportionally to the
population: Given the average 2,000 TPS from Sect. V-A, we simulate 2 TPS for
24 hours, or $172,800$ payments, which move $9.75$M units of value. When we
study a peak load, we move an order of magnitude up, to 20 TPS (for 12 hours),
thus to $950,000$ payments ($53.2$M in value).

In our model, we scaled down the number of users, and this brought about a
proportional reduction in both the number of payments per second they
generate, and in the size of the routing network. We do _not_ scale quantities
that do not vary with the size of the population: The cap on end-user wallets
is taken as-is from what has been hypothesized in [12], [13] and [14], i.e.,
€3000; the distribution of payment amounts is harmonized with the figures in
Table I; the definition of “instant” payment still requires completion within
10s [10].

###  V-C Simplifying assumptions

We adopt several simplifying assumptions to facilitate the initial study of
our SH-PCN under high load. We assume that:

  * •

the topology of the SH-PCN is static, i.e., after the initial setup, no new
channels are opened, nor are existing ones closed, during the time window of
interest;

  * •

each EU, whether a person or a merchant, has only a single channel, with a
single LSP;

  * •

LSPs are connected to their reference MH/RSP in such a way that full
connectivity is ensured;

  * •

the LSP of an EU also acts as their reference, trusted CS (the roles of LSP
and CS are collapsed on the same actor);

  * •

EUs, LSPs, RSPs, CSs and EUs are always online;

  * •

fees are not imposed to route payments; so the best payment route is the
shortest path between the payer and the payee (and not the one occasioning the
smallest fee);

  * •

the blockchain introduces a constant delay (modeled on the speed of actual
permissioned fault-tolerant systems, such as [15]) when on-chain transactions
are needed.

##  VI Modeling and simulating SH-PCNs

In order to study how SH-PCNs behave if used to support a retail payment
system akin to the one described in Sect. V, given the rebalancing strategies
from Sect. IV, we model the entire system, and we simulate its execution over
a full business day, under different load and liquidity conditions.

Our architecture is composed of 4 logical sub-models:

  * A.

The SH-PCN topology model and generator (Sect. VI-A), tasked with creating
realistic SH-PCNs; the network it creates is given as input to:

  * B.

The SH-PCN runtime model and simulator (Sect. VI-B), which simulates the
working of actual PCNs to great detail; this simulator is set in motion by an
incoming stream of payment requests, generated by:

  * C.

The load model and generator for retail payments (Sect. VI-C), which outputs
24 hours worth of simulated payments, according to Sect. V-B; as the PCN
evolves under the payment load, it is analyzed and updated by:

  * D.

The PCN realtime rebalancer (Sect. VI-D), which monitors the PCN and applies
the strategies from Sect. IV to keep the system running at full success rate.

Sub-models (A) and (C) are inspired to the structure, throughput, and
functioning of actual European payment systems/patterns, although we operate
at a reduced scale (Sect. V-B) and under simplifying assumptions (Sect. V-C).

###  VI-A SH-PCN topology model and generator

We designed a generator of random SH-PCN instances, such as the one in Figure
1. The generator takes as an input a list of parameters—such as the number of
entities to place in each tier, the constraints on their inter-connections,
the capacity of channels among different actors, etc—and generates one random
SH-PCN instance with the given features (in a human-friendly JSON format).
While the generator is capable of constructing 1:1 networks, using the
parameters from Section V-A, we use the small scale variant from Section V-B
to generate the SH-PCN we experiment on in Section VII.

Our SH-PCN random model is a composition of various random graph models, each
representing the connections between different categories of nodes and within
the same category:

  1. 1.

Central banks are interconnected in a clique formation, with each link having
a capacity of €500 million.

  2. 2.

The interconnections between LSPs are modeled using a Watts-Strogatz graph
model [16], using an average degree $k=4$ and a rewiring probability $p=0.1$;
the capacities associated with channels in this subnetwork are not fixed: A
range of different values for such capacities is explored in the experimental
section.

  3. 3.

The links between CBs and LSPs are generated by dividing the LSPs into
distinct subsets, each corresponding to a CB/country. Subsequently, a channel
is established from each CB to every LSP in its respective subset. The subset
sizes is log-normally distributed (with $\mu=0$ and $\sigma=1$); the capacity
of such CB-LSP channels is not fixed: The simulation explores a range of
possibilities.

  4. 4.

The creation of channels between LSPs and end users, encompassing both
citizens and merchants, is approached similarly to the CB-LSP connections,
albeit with fixed capacities, which represent the cap on users’ wallets (CBDC
requirement). Specifically, channels connecting LSPs with citizens have a
capacity of €3000. In contrast, channels linking LSPs with merchants vary
based on the merchant’s size: small (S), medium (M), and large (L) merchants
are assigned channels with capacities of €5k, €50k, and €500k, respectively.

Overall, here is a summary of the submodels in a SH-PCN:

Connection Type | Random Graph Model | Capacity
---|---|---
Among CBs | Clique | €500M
CBs to LSPs | Log-normal ($\mu=0$, $\sigma=1$) | several
Among LSPs | Watts-Strogatz ($k=4$, $p=0.1$) | several
LSPs to Citizens | Log-normal ($\mu=0$, $\sigma=1$) | €3000
LSPs to Merchants | Log-normal($\mu=0$, $\sigma=1$) | €5$\cdot 10^{3/4/5}$
(S / M / L)

###  VI-B SH-PCN runtime model and simulator

Several PCN simulators exist in the literature (see e.g. [17, 18, 19, 20,
21]). No one dominates the others along all dimensions, as different authors
rely on the simulation of specific features of the PCN protocol, but not
others. For our purposes, we selected CLoTH [21], which stands out as an open-
source sequential Discrete Event Simulation (DES) engine that reproduces the
code of a mainstream lightning node
implementation888https://github.com/lightningnetwork/lnd, particularly
focusing on routing and on the HTLC mechanics.

CLoTH features a straightforward simulation run-time and is used in several
papers (see e.g., [22, 23]). However, it lacks support for parallel
processing. We tested its serial engine and realized it does not perform
adequately when very large networks and large payment volumes are to be
analyzed.

Therefore, we developed a CLoTH-like simulator within ROSS [24], a Parallel
DES. ROSS operates on a distributed-memory architecture, and can run on
multiprocessor systems. We exploit its native advanced features, e.g.,
parallel execution, optimistic event scheduling, and load distribution.

CLoTH on ROSS. Within ROSS, we implement and reuse the same events and states
as CLoTH: Fig. 5 contains the event diagram of our PCN simulator. The elements
and edges in black are part of the core CLoTH simulation. Elements in color
represent extensions to CLoTH that we introduce: One for dynamic load
generation—in green; two for the waterfall and reverse waterfall
functionalities—respectively in red and blue; one for the submarine swap
functionality—purple.

For each event, we implemented all the relevant ROSS callbacks: the event
handler, the reverse event handler used in optimistic simulations, and the
commit event handler that is used to permanently update the state of LPs.
These handlers call the appropriate (and properly wrapped) CLoTH code.

Figure 5: Event diagram of our ROSS-based, CLoTH-like PCN simulator.

Executing a payment. When the payment request is received, a new FIND PATH
event is scheduled for the payment process (or a withdrawal if the payer does
not have enough liquidity to execute the payment, see Sect. VI-D). The FIND
PATH computes the path between the sender and the receiver of the payment. If
a path cannot be found, the payment fails. Otherwise, the payment follows the
same life-cycle as in CLoTH, going through the sequence SEND PAYMENT, FORWARD
PAYMENT (if the payment traverses more than one edge), RECEIVE PAYMENT,
FORWARD SUCCESS (if any) and RECEIVE SUCCESS for a successful payment.
Conversely, a non-successful payment goes through FORWARD FAIL (if any) and
RECEIVE FAIL. A payment may fail due to an insufficient balance to forward it
along the path selected by the sender. Once a RECEIVE FAIL notifies the
failure to the sender, the payment can be re-tried by scheduling a new FIND
PATH event. This loop is allotted 10 seconds, after which the process is
aborted and the payment fails definitely.

From SH-PCN nodes to ROSS processes. ROSS uses two structures to represent
processing units:

  * •

A _Logical Process_ (LP), which serves as the fundamental computation unit.
LPs manage their own event queue, receive messages, process the events they
contain, and optionally send additional messages to other LPs.

  * •

A _Physical Process_ (PE), which are the actual processes of the distributed
MPI architecture, to which LPs run on. PEs orchestrate the parallel simulation
and manage the communication with other PEs for the LPs they host.

In our simulation we have an LP for each node in the SH-PCN (all included:
Tier 1, 2, and 3 nodes are simulated). We include a single auxiliary LP for
each PE that orchestrates the payment generation for its own LPs (see Sect.
VI-C).

Parallelizing the simulation. In ROSS, simulations can be executed
sequentially or in parallel, using either a conservative or an optimistic
approach. We employ an optimistic simulation, whereby ROSS activates a
synchronization mechanism called “Time Warp”, which uses a detection-and-
recovery protocol to synchronize the computation: Any time an LP detects out-
of-order events, it rolls those events back and re-executes them.

Load distribution is crucial in a distributed-memory PDES. Co-locating chatty
LPs on the same PE significantly improves performance, as messages can be
exchanged in memory instead of relying on inter-process communication. For our
PCN simulation we devise a domain-specific mapping strategy.

First, we construct a weighted graph of nodes, where edges are labeled with an
estimated communication frequency. Then, in order to achieve a balanced
distribution of citizens, merchants and intermediaries among partitions, we
assign weights to each node. Following the approach outlined in [25], we
partition the resulting graph using METIS [26], which minimizes the sum of the
weights of the edge traversing partitions and equalizes the total node weights
among partitions.

###  VI-C Model and generator for retail payments

The payment generator schedules a GENERATE PAYMENT event (green in Fig. 5)
with a frequency that depends on a target global payment rate. As detailed in
Sect. V-B, the global rate in the small scale model is between 2 and 20 PPS
(Payments Per Second). Such global rate is apportioned to PEs, in such a way
that each PE generates a local load that is proportional to the number of
retail users co-located on the PE itself. Then, the payment generator creates
a single random payment between two users that are randomly selected according
to the SPACE model described in Sect. V.

We assume that geographically close users exhibit a greater tendency to
transact with each other, hence users predominantly conduct domestic
transactions within their own country, while cross-border ones occur
infrequently.

The load generator selects the payment sender first, which is always a retail
user. Then, it selects a random payment scenario according to the SPACE
distribution of payment contexts (POS, eCommerce, P2P) and to the static
cross-border payment probability. Depending on the selected payment scenario,
the generator selects a random receiver among merchants (for POS and eCommerce
payments) or retail users (for P2P payments). Finally, the payment generator
chooses the transaction amount according to the SPACE conditional probability
distribution of amounts (see Table I).

###  VI-D PCN real-time rebalancer

The rebalancer applies the strategies described in Sect. IV to the payment
system simulated via our custom blending of CLoTH and ROSS, described in Sect.
VI-B. The technical implementation of the strategies is as follows.

Waterfall. Whenever a payment that is about to be received by an EU would
result in the channel balance exceeding its cap, the payment is notified to
the receiver using the NOTIFY PAYMENT event, and the processing of the FORWARD
PAYMENT event is delayed. Upon receiving the notification, the payee initiates
another transaction, i.e., a _deposit_ , to transfer the excess liquidity to a
CS. The deposit process is triggered by the FIND PATH event, using a delay
that takes into account the roundtrip time for the deposit request. Then, FIND
PATH computes the (best) path between the sender of the deposit (receiver of
the payment) and their CS. If the deposit is completed before the original
payment expires, the FORWARD PAYMENT can be completed and the payment can be
received successfully. Otherwise a FORWARD FAIL event is generated. See the
red state/links in Fig. 5.

Reverse Waterfall. When a payment is generated, and the sender has an
insufficient balance, the simulation initiates a new transaction, i.e., a
_withdrawal_ , from the sender’s associated CS to the sender itself, using a
FIND PATH event. The original payment is placed in a queue of payments
awaiting withdrawals, that is managed by the sender. Once the withdrawal is
successfully received (RECEIVE PAYMENT event), the sender of the original
payment triggers it creating the respective FIND PATH event. See the blue link
in Fig. 5.

Submarine Swap. A submarine swap is initiated by either an LSP or an RSP in
response to a FORWARD PAYMENT event when a payment about to be forwarded would
result in the channel balance exceeding a predefined _unbalancedness_
threshold (e.g., $80\%$ of its capacity). The simulation then has the LSP
generate a FIND PATH event towards its channel counterparty, with a delay of 1
block time, as outlined in the purple line of Fig. 2. The off-chain payment
simulates the submarine leg of the swap, depicted in steps 2 and 3 of Fig. 2,
while the block time delay of the event simulates the on-chain HTLC
preparation of step 1. See the purple link in Fig. 5.

##  VII Experimental Evaluation

Payments in PCNs can fail for a number of reasons, the main one being the
insufficient capacity of some link along the route chosen by the payer/source.
When a route fails, another one is tried, until success—or until some failure
criterion is met, e.g., a timeout expires. As the load on the system
increases, the probability of failure is expected to increase, both because
channels may become unbalanced and because there is an increasing resource
contention from multiple in-flight concurrent payments with partially
overlapping routes.

In this context—fully captured by our simulation—we show (a) under which
conditions our rebalancing strategies are able to keep the payment success
rate at 100% under a constant load; (b) that payments remain “instant” in all
cases; (c) how the system reacts to a sudden 10x increase in the number of
payments per seconds; (d) how the trade-off between liquidity locked in
channels and their rebalancing plays out.

###  VII-A Payment Success Rate

Figure 6: Percentage of payments routed instantly by the SH-PCN ($y$ axis) as
a function of the liquidity in the network/channels ($x$ axis). Log-log scale.

We present our SH-PCN with a constant transaction load as per Sect. VI-C,
exerted for 24 hours (simulation time).

Figure 6 shows the success rate of payments as a function of the _total amount
of liquidity_ Tier 1 and 2 operators are willing to lock into the system. By
“total amount”, we mean the sum of the capacity of all the channels among Tier
2 operators, plus the channels between Tier 1 and Tier 2999The other
capacities are not accounted for, because: Capacities from Tier 2 to Tier 3
(i.e., wallet caps) are set by policy and are not subject to adjustments for
performance reasons; channels within Tier 1 nodes are practically infinite
(managed by CBs); channels among Tier 3 entities do not exist in our setting..

The success rate is non-zero ($\sim$16%) even for zero total liquidity,
because there is a fraction of payments that happens between retail customers
of the same Tier 2 entity, which can be routed successfully without traversing
internal Tier 2 links.

As the liquidity of the network grows, so does the percentage of payments
successfully regulated within “instant” timespans. In our small-scale model, a
fully self-rebalancing network (green line) achieves a 100% success rate after
approximately 600k units of total network liquidity. If we disable the
rebalancing tool internal to Tier 2 (submarine swaps) and keep active the Tier
2-3 rebalancing (waterfall, direct and inverse), we are in a scenario where
payments can always be started and received, but they can possibly fail to be
routed due to inner channels becoming permanently (almost) unbalanced. In this
case (blue line), to reach the same success rate, we need to inject hundreds
of times more liquidity into the network ($\sim$60M units). Finally, the
removal of all rebalancing mechanisms results—as expected—in a failure of the
system to even approach a 100% success rate (orange line).

###  VII-B Instant-ness of Payments

Figure 7: Time-to-completion of payments: Cumulative distribution.

Figure 7 reports the cumulative distribution of completion times for retail
transactions, averaged over a full day of simulated payments, i.e., the curve
represents the amount of payments that succeed within a given amount of time.
Any capacity beyond the 400k threshold identified in Sect. VII-A produces
essentially the same results. The bumpiness of the curve hinges on our
simulation being time discrete, with events introducing delays as in Fig. 5.
We observe how all payments complete within at most 3 seconds, well under the
10 second cutoff that identifies instant payments in our context.

###  VII-C Adaptive Rebalancing

Figure 8: In the top chart we plot the number of (reverse) waterfall events
per minute during a 12h stress test (from 7am to 7pm) under peak load. The
(much smaller) number of submarine swaps per minute requested by the Layer 2
payment network to Layer 1 in order to keep itself balanced is reported in the
bottom chart, for three different levels of total routing liquidity.

All the experiments shown so far have been performed under a constant load of
transactions, equal to the average expected throughput for a payment system at
our scale, according to the payment model described in Sect. V-B. Actual
payment systems must be able to sustain peaks that may increase the volume of
payments by an order of magnitude over the nominal average throughput (the
“Christmas day” effect). To show how our SH-PCN responds to one such
occurrence, we simulate a day where from 7am to 7pm the load on the system
suddenly increases by an order of magnitude.

Figure 8 shows the system response: All the rebalancing mechanisms start
working harder to maintain the entire payment network sufficiently well
balanced, even under pressure.

As expected, the number of submarine swaps, for a given routing liquidity
grows substantially under pressure. And, channels of larger capacity require
fewer swaps, according to an approximately linear inverse relation.

In addition, Fig. 8 shows that—as expected—the number of (reverse) waterfall
events is independent of the network liquidity and of the number of submarine
swaps (it only depends on the load). Also, it is much higher than the number
submarine swaps, because the capacity/cap for retail wallets is much smaller
than the average channel size.

The payment success rate (not shown in the chart) stays at 100% at all times
during the peak window; our simulated small-scale system is capable of
maintaining satisfactory throughput, latency, and performance, also under
load.

###  VII-D The cost of keeping a channel well balanced

We have seen the inverse correlation between channel capacity and swaps per
unit of time, at the channel level. At system level, the inverse correlation
is between the total routing liquidity and the transactional demand on Layer
1.

This technical trade-off engenders a related economical trade-off: Submarine
swaps have an economic cost in the form of Layer-1 transaction fees, which are
set by Tier 1 actors (i.e., CBs); at the same time, the cost for Tier 2 market
operators to keep central bank liquidity locked into channels is again decided
by Tier 1 actors, i.e., CBs. The resulting economic dynamics are out of scope
for the present work, and we will not investigate in any detail the policy
options for the CB. We just show that, once the cost parameters have been set
by Tier 1, the market can optimize (statically, or even dynamically under the
current transaction load) the network liquidity at Tier 2. In particular, the
sum of (a) the cost of liquidity—that increases monotonically with the
capacity of channels, plus (b) the cost of actuating submarine swaps—that
increases monotonically with the number of swaps executed, is a convex
function with a global minimum point. If the minimum is to the left of the
point where the system reaches 100% success rate (gray area in Fig. 10), it
means swaps are so cheap compared to borrowing liquidity that the actual lower
bound for the network capacity is given by the minimum liquidity necessary to
sustain a 100% success rate (approx. 600k in our example). Conversely, if the
minimum is to the right of the point where submarine swaps are no longer
needed (because the initial channel capacity suffices to support all payments
in the 24 hours), it means liquidity is so cheap compared to executing swaps,
that the optimal value for network liquidity is the minimum value sufficient
to process all payments without swaps ($\sim 30$M in our example).

Figure 9: Daily cost of locked liquidity and of submarine swaps for different
network capacities. The sum of these components (total cost of channel
management) reaches a minimum at $\sim 800$k. We assume the CB lends
money101010This seemengly arbitrary number is the annual Marginal Lending
Facility (MLF) of the European Central Bank (ECB) as of Sept. 20, 2023.at
$4.75\%$, and charges $0.1$ monetary units for each Layer 1 transaction.

The only remaining, interesting case is represented in Fig. 10: Here, the
optimal amount of liquidity to invest by Tier 2 actors for the purpose of
routing retail payments is $800k$, which falls in the non-trivial range
$[600k;30M]$. This is where our small-scale SH-PCN requires the smallest
running costs.

##  VIII Related Work

The PCN topology affects the ability to successfully route payments, network
resilience (against both attacks and random failures), and the privacy of
payments. The unstructured topology of LN led to a small-world and scale-free
network, with a few highly-connected nodes that route most of the payments
(e.g., [6, 7]). Avarikioti et al. [8] show that this topology is not optimal:
when all transactions are known a-priori, a star topology can minimize the
locked capital and maximize profits. Such a central node reduces the average
path length and thereby the routing failures due to unavailable balance, at
the price of weakening fault-tolerance, security, and privacy (e.g., [27,
28]). Rohrer et al. [6] show how the LN can be subjected to channel exhaustion
or node isolation attacks. Conversely, we resort to (semi) hierarchical
topologies, which promise to combine the benefits of both previous topologies.

A key problem is to determine the initial capacity of channels: The bigger the
channel capacity, the higher the number of routed transactions, the higher the
liquidity costs (e.g., interest charges, opportunity costs). To route a
transaction, a channel moves liquidity, getting progressively imbalanced over
time (thus reducing the success probability of routing). We believe that
adopting rebalancing techniques is a key pillar for highly loaded networks,
which otherwise would need large initial investments to open channels.
Shabgahi et al. [29] propose a model to predict the expected time for a
channel to get unbalanced, considering the channel centrality and its initial
balance. To extend the channels lifespan, they can be either replenished with
on-chain transactions (e.g., [30]) or rebalanced in-place (e.g., [31, 32,
33]). Centralized approaches to rebalance channels requires nodes to disclose
their individual contribution in the channel, thus violating privacy (e.g.,
[34]). Avarikioti et al. [32] enhance the protocol using privacy preserving
techniques. Li et al. [35] propose to divide time in epochs and to use a
randomly selected committee of nodes to estimate the channels’ capacity needed
to route the expected payments in the next epoch. This approach incurs in a
large number of on-ledger transactions. Awathare et al. [31] propose a
decentralized protocol that leverages network cycles to perform circular
payments and rebalance capacity. Focusing on relay nodes, Papadis et al. [36]
use reinforcement learning to proactively perform submarine swaps aiming to
maximize profit from fees. In this paper, we study the impact of the initial
channel capacity as well as the benefits of three different approaches for
automatic rebelancing of channels. Although we rely on reactive solutions, we
study their feasibility by considering constraints imposed by the layer-1
blockchain. Interestingly, Miller et al. [37] propose an alternative to LN,
enabling incremental deposits and withdrawal through extended off-chain
contracts (i.e., with no impact on-ledger). Nonetheless, this approach is not
compatible with LN. We postpone as a future work the compatibility analysis of
our automated rebalancing techniques with this approach.

So far, a rather large number of LN simulators exist (e.g., [17, 18, 19, 20,
21]), even though a clear comparison among them is lacking. CLoTH [21] is an
open-source simulator of LND, the most popular LN implementation, which has
been used in different recent research works (e.g., [22, 23]). Aiming to
analyze very large-scale networks, we integrate CLoTH functionalities in ROSS,
a general-purpose PDES (see Sect. VI-B).

##  IX Conclusion and Future Work

We introduced a class of self-rebalancing semi-hierarchical PCNs, and showed
experimentally—on a small-scale model based on the payment patterns and
structure of the euro area—that they seem to (a) ensure good performances (in
terms of latency, throughput, and success rate of payments) and (b) suit the
existing 3-tier banking/payment architecture naturally.

As a future work, we will move towards removing one by one the simplifying
assumptions listed in Sect. V-C, up to the point of presenting and studying a
simulation at scale $1:1$, exhibiting a rich set of behaviors and dynamics.

Finally, we will study and characterize the strenght of the privacy enjoyed by
the retail payer and payee in this system, and compare it to public PCNs such
as the Lightning Network.

## References

  * [1] ECB Market Research, “Market research on possible technical solutions for a digital euro,” https://www.ecb.europa.eu/paym/intro/news/html/ecb.mipnews230113.en.html, 2023\.
  * [2] ECB, “A stocktake on the digital euro,” https://www.ecb.europa.eu/paym/digital_euro/investigation/profuse/shared/files/dedocs/ecb.dedocs231018.en.pdf, 2023\.
  * [3] F. S. Mishkin, _The economics of money, banking, and financial markets_. Pearson education, 2007.
  * [4] J. Poon and T. Dryja, “The bitcoin lightning network: Scalable off-chain instant payments,” 2016.
  * [5] A. Gangwal, H. R. Gangavalli, and A. Thirupathi, “A survey of layer-two blockchain protocols,” _J. Netw. Comput. Appl._ , vol. 209, p. 103539, 2023\.
  * [6] E. Rohrer, J. Malliaris, and F. Tschorsch, “Discharged payment channels: Quantifying the lightning network’s resilience to topology-based attacks,” in _Proc. of IEEE EuroS &PW’19_, 2019, pp. 347–356.
  * [7] I. A. Seres, L. Gulyás, D. A. Nagy, and P. Burcsi, “Topological analysis of bitcoin’s lightning network,” in _Mathematical Research for Blockchain Economy_. Springer, 2020, pp. 1–12.
  * [8] G. Avarikioti, Y. Wang, and R. Wattenhofer, “Algorithmic channel design,” in _Proc. of ISAAC ’18_ , vol. 123. Schloss Dagstuhl-Leibniz-Zentrum für Informatik, 2018, pp. 16–1.
  * [9] ECB Surveys, “Study on the payment attitudes of consumers in the euro area (SPACE),” https://www.ecb.europa.eu/stats/ecb\\_surveys/space/html/ecb.spacereport202212~783ffdf46e.en.html, 2022\.
  * [10] “European central bank. what are instant payments?” https://www.ecb.europa.eu/paym/integration/retail/instant_payments/html/index.en.html, accessed: 2023-11-10.
  * [11] “Banking in europe: Ebf facts & figures 2022,” https://www.ebf.eu/wp-content/uploads/2022/12/Banking-in-Europe-EBF-Facts-and-Figures-2022.-FINAL.pdf, accessed: 2023-11-10.
  * [12] U. Bindseil, “Tiered CBDC and the financial system,” _Available at SSRN 3513422_ , 2020.
  * [13] U. Bindseil and F. Panetta, “Central bank digital currency remuneration in a world with low or negative nominal interest rates,” _VoxEU,[Internet], dostupno na: https://voxeu. org/article/cbdc-remuneration-world-low-or-negative-nominal-interestrates,[15.4. 2022.]_ , 2020.
  * [14] B. Meller and O. Soons, “Know your (holding) limits: CBDC, financial stability and central bank reliance,” https://www.dnb.nl/media/iwsban0s/working_paper_no-771.pdf, 2023.
  * [15] M. Benedetti, F. D. Sclavis, M. Favorito, G. Galano, S. Giammusso, A. Muci, and M. Nardelli, “Certified byzantine consensus with confidential quorum for a bitcoin-derived permissioned dlt,” in _Proc. of the 5th Distributed Ledger Technology Workshop_ , 2023, available at https://ceur-ws.org/Vol-3460/papers/DLT_2023_paper_1.pdf.
  * [16] D. J. Watts and S. H. Strogatz, “Collective dynamics of ‘small-world’networks,” _nature_ , vol. 393, no. 6684, pp. 440–442, 1998\.
  * [17] F. Beres, I. A. Seres, and A. A. Benczur, “A cryptoeconomic traffic analysis of bitcoin’s lightning network,” 2019, arXiv:1911.09432.
  * [18] G. Di Stasi, S. Avallone, R. Canonico, and G. Ventre, “Routing payments on the lightning network,” in _Proc. of IEEE iThings and GreenCom and CPSCom and SmartData ’18_ , 2018, pp. 1161–1170.
  * [19] G. A. F. Rebello, G. F. Camilo, M. Potop-Butucaru, M. E. M. Campista _et al._ , “PCNsim: A flexible and modular simulator for payment channel networks,” in _Proc. IEEE INFOCOM Workshops ’22_ , 2022, pp. 1–2.
  * [20] 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 _Proc. of ICCCN ’18_ , 2018, pp. 1–9.
  * [21] M. Conoscenti, A. Vetrò, and J. C. De Martin, “CLoTH: A Lightning Network Simulator,” _SoftwareX_ , vol. 15, p. 100717, 2021.
  * [22] K. Asgari, A. A. Mohammadian, and M. Tefagh, “Dyfen: Agent-based fee setting in payment channel networks,” 2022, arXiv:2210.08197.
  * [23] V. Davis and B. Harrison, “Learning a scalable algorithm for improving betweenness in the lightning network,” in _Proc. of BCCA ’22_. IEEE, 2022, pp. 119–126.
  * [24] “Ross,” https://ross-org.github.io, 2022.
  * [25] A. Gill, M. Lalith, S. Poledna, M. Hori _et al._ , “High-performance computing implementations of agent-based economic models for realizing 1:1 scale simulations of large economies,” _IEEE Trans. Parallel Distrib Syst._ , vol. 32, no. 8, pp. 2101–2114, 2021.
  * [26] G. Karypis and V. Kumar, “A fast and high quality multilevel scheme for partitioning irregular graphs,” _SIAM J Sci Comput._ , vol. 20, no. 1, pp. 359–392, 1998.
  * [27] G. Kappos, H. Yousaf, A. Piotrowska, S. Kanjalkar _et al._ , “An empirical analysis of privacy in the lightning network,” in _Financial Cryptography and Data Security_. Springer, 2021, pp. 167–186.
  * [28] C. Sguanci and A. Sidiropoulos, “Mass exit attacks on the lightning network,” 2022, arXiv:2208.01908.
  * [29] S. Z. Shabgahi, S. M. Hosseini, S. P. Shariatpanahi, and B. Bahrak, “Modeling Effective Lifespan of Payment Channels,” 2022, arXiv:2301.01240.
  * [30] V. Sivaraman, S. B. Venkatakrishnan, M. Alizadeh, G. Fanti, and P. Viswanath, “Routing cryptocurrency with the spider network,” in _Proc. of HotNets ’18_. ACM, 2018, p. 29–35.
  * [31] N. Awathare, Suraj, Akash, V. J. Ribeiro, and U. Bellur, “Rebal: Channel balancing for payment channel networks,” in _Proc. of MASCOTS ’21_ , 2021, pp. 1–8.
  * [32] Z. Avarikioti, K. Pietrzak, I. Salem, S. Schmid _et al._ , “Hide & seek: Privacy-preserving rebalancing on payment channel networks,” in _Financial Cryptography and Data Security_. Springer, 2022, pp. 358–373.
  * [33] Z. Hong, S. Guo, R. Zhang, P. Li _et al._ , “Cycle: Sustainable off-chain payment channel network with asynchronous rebalancing,” in _Proc. of IEEE/IFIP DSN ’22_ , 2022, pp. 41–53.
  * [34] R. Khalil and A. Gervais, “Revive: Rebalancing off-blockchain payment networks,” in _Proc. of ACM SIGSAC CCS ’17_. ACM, 2017, p. 439–453.
  * [35] P. Li, T. Miyazaki, and W. Zhou, “Secure balance planning of off-blockchain payment channel networks,” in _Proc of IEEE INFOCOM ’20_ , 2020, pp. 1728–1737.
  * [36] N. Papadis and L. Tassiulas, “Deep reinforcement learning-based rebalancing policies for profit maximization of relay nodes in payment channel networks,” 2023, arXiv:2210.07302.
  * [37] A. Miller, I. Bentov, S. Bakshi, R. Kumaresan, and P. McCorry, “Sprites and state channels: Payment networks that go faster than lightning,” in _Financial Cryptography and Data Security_. Springer, 2019, pp. 508–526.