=Paper=
{{Paper
|id=Vol-3791/paper23
|storemode=property
|title=Impact of Layer-1 Characteristics on Scalability of Layer-2 Semi-Hierarchical Payment Channel Networks
|pdfUrl=https://ceur-ws.org/Vol-3791/paper23.pdf
|volume=Vol-3791
|authors=Marco Benedetti,Francesco De Sclavis,Giuseppe Galano,Sara Giammusso,Antonio Muci,Matteo Nardelli
|dblpUrl=https://dblp.org/rec/conf/dlt2/BenedettiSGGM024
}}
==Impact of Layer-1 Characteristics on Scalability of Layer-2 Semi-Hierarchical Payment Channel Networks==
https://ceur-ws.org/Vol-3791/paper23.pdf
Impact of Layer-1 Characteristics on Scalability of Layer-2
Semi-Hierarchical Payment Channel Networks⋆
Marco Benedetti1 , Francesco De Sclavis1 , Giuseppe Galano1,2 , Sara Giammusso1 ,
Antonio Muci1 and Matteo Nardelli1
1
Bank of Italy
2
University of Pisa
Abstract
Assessing the scalability of a payment channel network is crucial as it directly impacts the efficiency and user
experience of blockchain-based payment systems used in high volumes transaction environments, such as Central
Bank Digital Currencies (CBDCs). In this work, we present an analysis of the interaction between a Layer-2
Semi-Hierarchical Payment Channel Networks (SH-PCNs) and its Layer-1 blockchain technology. In particular,
we focus on how blockchain features, such as latency, throughput and congestion, affect the payment success
rate within a SH-PCN, in a scenario in which routing nodes try to keep the state of their channels balanced by
exchanging off-ledger and on-ledger liquidity, a technique known as submarine swaps. We use a Parallel Discrete
Event Simulator (PDES) for SH-PCNs, in which we incorporate a blockchain component to simulate the dynamics
of a limited block size and non negligible block time. We simulate various scenarios, defined by: the total
amount of liquidity locked in the channels, constant and variable payment load, blockchain congestion conditions
and channel rebalancing strategies adopted by nodes. The experiments reveal how blockchain parameters like
congestion rate significantly influence PCN performance metrics such as payment success rate. We conclude
that, when designing a PCN for scalability, it’s important to take into account that Layer-1 characteristics affect
the optimal allocation of liquidity that is needed to match the target performances.
1. Introduction
The groundbreaking introduction of blockchains to support the exchange of crypto-assets has also
generated a huge hype regarding its adoption for supporting world-wide efficient retail payments and,
as such, for the design of Central Bank Digital Currencies (CBDCs). Today, retail instant payment
systems manage a very high load of transactions, in the order of 104 –105 transactions per second (e.g., [1,
Sect. IV-A]), to be settled within 10 seconds [2]. Besides performance, CBDCs may also include further
business and technical requirements, such as privacy guarantees, small or no fees for citizens, a cap on
the amount of liquidity users can amass, and the possibility to be usable by unbanked people.
In our previous works [1, 3, 4], we started to investigate whether a blockchain can be an appropriate
technological choice to implement a (hyphotetical) CBDC. As expected, ingesting and settling a realistic
transaction load in a timely manner is challenging, especially in a fully decentralized system that
uses a blockchain to store its global state. Therefore, in [1], we embraced the off-ledger paradigm,
whereby scalability is achieved by an additional payment channel network (PCN), a second layer built
on top of the actual blockchain [5]. It results a two-layered system where the first (wholesale) layer,
i.e., the blockchain, exhibits high integrity, availability, fault-tolerance, and verifiability of monetary
exchanges; and the second (retail) layer, i.e., the PCN, accommodates fast-payments, cash-like levels of
privacy, and handles wallet caps. To sustain the payment load and map technical PCN roles with the
business roles of the 3-tier banking system of the current monetary system [6], we explored a family of
DLT’24: 6th Distributed Ledger Technology Workshop, May 14–15, 2024, Torino, Italy
⋆
All views are those of the authors and do not necessarily reflect the position of Bank of Italy.
Envelope-Open marco.benedetti@bancaditalia.it (M. Benedetti); francesco.desclavis@bancaditalia.it (F. De Sclavis);
giuseppe.galano2@bancaditalia.it (G. Galano); sara.giammusso@bancaditalia.it (S. Giammusso);
antonio.muci@bancaditalia.it (A. Muci); matteo.nardelli@bancaditalia.it (M. Nardelli)
Orcid 0009-0004-1318-3878 (F. De Sclavis); 0009-0008-3251-6606 (G. Galano); 0009-0009-9355-3416 (S. Giammusso);
0000-0002-9519-9387 (M. Nardelli)
© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
1
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
PCNs with a partially constrained topology, called “Semi-Hierarchical Payment Channel Networks” (SH-
PCNs)—see Sect. 2.2. Besides opening and closing channels, PCNs send transactions to the underlying
blockchain every time the channel should be reconfigured, e.g., to balance its capacity (see Sect. 2.3).
Therefore, some operations in the PCN need to wait for the transaction confirmation on the blockchain
before completing. In [1], we conducted our analysis on PCNs with a strong—yet commonly adopted
(e.g., [7, 8, 9, 10])—simplifying assumption on the interaction between the first and second layer: i.e.,
we assumed that each on-ledger request from the PCN would be satisfied with a constant delay by the
blockchain. We all know that in real life, things turn out very different.
Several approaches assume that on-chain transactions can be satisfied (i.e., included in a block) after
a constant, predictable delay equal to the block time of the blockchain (e.g., [9, 7, 8, 10]). To the best
of our knowledge, so far, there is no tool for investigating how different working conditions of the
blockchain influence performance of second layer systems, such as a PCN.
In this paper, we investigate the interaction between blockchain and PCNs, by specifically focusing
on its impact on the payment success rate, i.e., the probability that a payment is successfully forwarded
from the sender to the recipient in the network. To extensively evaluate such a subtle but pivotal
interaction, we resort to simulations. In particular, we extend the itCoin PCN simulator1 , our Parallel
Discrete Event Simulator (PDES) [11], to introduce a model of the blockchain and of its interaction
with the PCN. Basically, our PDES is a porting of CLoTH [12], an open-source sequential simulator of a
Lightning Network (LN) implementation2 widely used in recent works (e.g., [13, 14, 15]), on ROSS [16].
The resulting simulator represents a valuable tool to gain interesting insightful regarding the impact of
layer 1 on layer 2, where we can readily see the effect of blockchain working conditions (e.g., congestion)
on performance achievable off-ledger by the PCN. The key contributions of this paper are as follows.
• We present a model of the blockchain suited to explicitly represent its interaction with a layer-2
PCN (Sect. 3). Driven by the use case needs, we consider the blockchain as a single entity of the
system that stores incoming transactions and periodically feeds them in a new block. Different
representations, serving different purposes, can be easily taken into account;
• We run an extensive set of experiments, aiming to investigate how the blockchain impacts
performance of the PCN in terms of channel rebalancing, locked liquidity in channels, and
payment success rate, when different blockchain parameters change, e.g., its congestion rate
(Sect. 4).
2. Background
2.1. Permissioned Blockchain for Central Bank Digital Currency
In [4] we consider a Bitcoin-like permissioned blockchain for a CBDC, where a set of known miners
validates transactions to be added to the blockchain. Each miner is operated by one member of
a federation of independent, geographically distributed, trusted actors3 , that are called validators.
Validators run a Byzantine fault tolerant consensus protocol and collectively publish a new valid block
every target block time, which in our examples is set to one minute. As in most approaches that
require geographically distributed Byzantine consensus among a dozen of nodes, also the blockchain
we consider suffers from scalability issues. Therefore, in [1], we explore the possibility to exploit
Layer-2 solutions to safely exchange instant payments off-ledgers, and in particular a specific topology
of PCN [17], that we call Semi-Hierarchical PCNs, or SH-PCN for short.
2.2. Semi-Hierarchical Topologies in Payment Channel Networks
In a PCN, two nodes create a bilateral payment channel 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
1
The source-code of the simulator is available at https://github.com/bancaditalia/itcoin-pcn-simulator
2
https://github.com/lightningnetwork/lnd
3
We target settings where the number of trusted actors is expected to be between 4 and ≈ 20.
2
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
Technical Business Size (magnitude) Sample Sub-network Channel Rebalancing
Tier role entities actual / simulated SH-PCN topology capacities strategy
Central Structured, “infinite”
1 RSP, MH 101 / 100 N/A
Banks hierarchical capacity
Commercial Free-form, Allocated & Just-in-time
LSP 🔵 Banks / 104 / 101 🔵 organised optimised by rebalancing via
2
CS ⚫ Financial 103 / n.a. ⚫ by market market submarine
Institutions operators operators swaps
End-Users: Retail users: Just-in-time
106 / 103 🔴 m1 m2 Fixed topology Fixed capacity
3 payers, merchants 🔴 (reverse)
108 / 105 🟡 (Policy decision) (Policy decision)
payees citizens 🟡 c1 c2 c3 c4 waterfall
Figure 1: Main features of a SH-PCN, plus three sample payment routes: One Point-of-Sale payment from retail
user 𝑐4 (a citizen) to merchant 𝑚2 ; one Peer-to-Peer transaction from 𝑐2 to 𝑐3 ; one eCommerce route from 𝑐1 to a
foreign merchant 𝑚1 .
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 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. A comprehensive description
of PCNs can be found in [5, 17].
The most popular PCN implementation, i.e., the Lightning Network (LN), does not constraints how
PCN node should open channels with one another. Therefore, different network topologies can be
build or can emerge, ranging from star-like to scale-free (as appears to be the LN, e.g., [18, 19]). Each
topology is characterized by its peculiarities in terms of efficiency, fault-tolerance, security, and privacy
(e.g., [18, 20]). In [1], we investigate a special family of PCNs, named Semi-Hierarchical PCN (SH-PCN,
for short), and analyze how such a network topology can sustain a real payment traffic.
To understand the rationale behind a SH-PCN, we briefly introduce the business roles of a monetary
system that we imagine to be mapped on different technical roles in the PCN. The current monetary
system—which is the target deployment environment for our solution—is based on a 3-tier banking
system [6], where: the CB is at the top; a set of authorized intermediaries (e.g., commercial banks)
are in the middle; retail users (e.g., citizens and merchants) are at the bottom. Fig. 1 represents how
these (business) roles are mapped onto different (technical) roles in the SH-PCN, i.e., monetary hubs,
lightning service providers, custodian services, and end users. The hierarchical anatomy of the banking
system is reflected in the (semi) hierarchical topology of the network. In a nutshell, these technical
roles are the following.
• Monetary Hubs (MHs) operate nodes with considerable liquidity, which are largely/fully
interconnected. They are managed by a Central Bank (CB) or a set of CBs.
• Lightning Service Providers (LSPs) freely open channels towards each other, forming a “small
world”-like network. They are managed by authorized intermediaries, and offer service to EUs
by opening channels with them.
• In addition to off-chain liquidity, EUs can own one or more accounts at Custodian Services
(CSs), e.g., banks or exchange. CSs are connected to the LSP network. The monetary interactions
between EUs and CSs happen out-of-band and via LSPs.
• End-Users (EUs) access the network connecting to one or more LSPs. EUs only open channels
with authorized LSP(s).
Our SH-PCN is a composition of various graph models, each representing the connections (i) between
different categories of nodes, and (ii) within the same tier:
1. MHs are interconnected in a clique (each channel has capacity of €500 million), and guarantee
network connectivity;
3
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
2. Links between MHs and LSPs are generated by dividing the LSPs into one subset per MH. Then, a
channel is established from each MH to every LSP in its subset. The subset sizes are log-normally
distributed (𝜇 = 0 and 𝜎 = 1); a range of channel capacities for this subnetwork is explored in the
experiements.
3. Links between LSPs are modeled using a Watts-Strogatz graph [21] (𝑘 = 4 and 𝑝 = 0.1); also in
this subnetwork, experiments explore various channel capacities.
4. Channels between LSPs and EUs are modeled just like in (3), albeit with fixed capacities, which
represent the cap on users’ wallets (€3000). Channels linking LSPs with merchants vary based on
the merchant’s size: small (S), medium (M), and large (L) merchants are assigned capacities of
€5k, €50k, and €500k, respectively.
2.3. Channel Rebalancing Techniques in the SH-PCN
Forwarding a payment updates the channel balance, as the payments requires one end to give funds
to the other end of the channel. Therefore, the performance of SH-PCNs subject to a load degrades
over time: Channels become more and more unbalanced, thus preventing them to participate in the
routing of an increasing percentage of payments. Rebalancing techniques improve channel lifetimes
while minimizing locked liquidity (e.g., [8, 9]). In [1], we describe three rebalancing techniques: an
on-chain solution, i.e., submarine swap, and two off-chain solutions, i.e., waterfall and reverse waterfall.
Submarine swaps between LSP/MH nodes. A submarine swap is an exchange of a given amount
of some on-chain asset with the same amount of the off-chain form of the same asset. Hash Time
Locked Contract (HTLCs) guarantee the atomicity of the transaction. Since submarine swaps involve
on-chain transfer, they take time (at least the confirmation time of the HTLC) and possibly require a
fee. Importantly, the transactional capacity of the blockchain limits the number of submarine swaps
per unit of time that can be perform in a PCN. This is the focus of this paper, where we investigate the
impact of the layer-1 blockchain on layer-2 PCN.
Waterfall rebalance. The waterfall [22] 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 𝑃 to be received
raises the user balance 𝐵 above the channel capacity 𝐶 (wallet cap). This is achieved by automatically
depositing the amount 𝐷 = max (𝐵 + 𝑃 − 𝐶, 𝐿𝐷 ), where 𝐿𝐷 is the minimum amount the user is willing
to deposit, to a linked CS account. When the LSP receives a payment to forward but the end user’s
channel does not have enough outbound liquidity, the LSP notifies the user about the incoming payment,
and delays the payment forwarding until the expiration of a timeout. The user requests a real-time
deposit to their CS, and sends the deposit via the same LSP, thus rebalancing the channel. If the channel
is successfully rebalanced within the timeout, the LSP forwards the payment to the user; otherwise, the
payment fails.
Reverse waterfall rebalance. This 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 its current state. If there are insufficient funds in the channel to cover the amount 𝑃,
users could request a withdrawal, thus taking out some money from their CS account. The withdrawal
amount is 𝑊 = max (𝐿𝑊 − 𝐵, 𝑃 − 𝐵), where 𝐿𝑊 represents a minimum amount the user is willing to
keep in its wallet for future use. Once the withdrawal has transferred liquidity from the linked CS to
the channel, the user can send the payment.
3. Simulating Blockchain and its PCN
3.1. PCN Simulator Architecture
In [1, 11], we described a parallel PCN simulator architecture that we used to analyze the performance
of PCNs in the context of CBDCs. The simulator extends CloTH [12], an open source sequential discrete
event simulator for PCNs that implements source-based path finding and the mechanism of HTLC.
We rebuilt CLoTH on ROSS [16], a general purpose framework for parallel discrete event simulations
4
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
that facilitates the simulation of large-scale networks using multiprocessing and a distributed memory
architecture. We presented simulation results regarding payment success rate, payment completion time,
and liquidity costs in different generated SH-PCN topologies (see Fig. 1), which mimic a hypothetical
CBDC implemented within a three-tier banking system. In our simulations, the payment load is
independently generated by each EU, and is designed in a way that globally it achieves an emerging
network behavior that follows real-world payment statistics [23]. A detailed description of the PCN-
related part of the simulator can be found in [1, 24].
3.2. Extending the PCN Simulator with a Blockchain Component
A missing piece in the previously described parallel simulator architecture is the detailed analysis of the
interaction between the PCN (as a second-layer solution) and its underlying layer-1 blockchain. Indeed,
in several scenarios users interact with the underlying blockchain through on-chain transactions, in
order to ensure liquidity or security of payment channels. These include: (i) opening of channels, in
which the channel capacity gets locked; (ii) closing of channels, that distributes the locked funds to the
parties according to the final state of their off-chain transactions; (iii) channel splicing, an advanced
feature that allows users to adjust the amounts of funds locked in a payment channel without closing it;
(iv) dispute resolutions, in case there is a disagreement between parties about the state of the channel;
(v) settlement of HTLCs, that are primarily off-chain interactions but may lead to on-chain transactions
in cases when one party is unreachable and does not cooperate to the HTLC consolidation; and (vi)
submarine swaps, that enable users to transfer funds between on-chain and off-chain wallets without
closing existing channels.
Specifically, the impact that block time and block size limitations can have on the simulation results
is a crucial aspect that warrants further exploration. These two parameters have a direct impact on
transaction latency and on the overall blockchain throughput. The former (transaction latency) refers
to the time taken for a transaction to be confirmed and added to the blockchain and can significantly
influence the payment success rate and liquidity efficiency of PCNs. The latter (blockchain throughput)
refers to the number of transactions processed per unit of time and may become a bottleneck especially
when multiple channel actions need to be performed simultaneously. This limitation can lead to
increased transaction fees and delayed channel operations, thereby affecting the PCN’s ability to handle
high volumes of transactions efficiently.
For these reasons, we introduce a lightweight model of the blockchain, in which we abstract away
all details related to its network, consensus, and application protocol. In particular, we focus on the
ability of the blockchain to receive transactions, collect them in a transaction pool (mempool), and
periodically publish a new block. We model the blockchain as a single process that manages the chain
data structures and mempool. The chain represents the sequence of all confirmed blocks, whereas the
mempool includes transactions waiting to be included in a block. The blockchain process creates a
new block every block time , that is a simulation parameter we set equal to 1 minute in Sect. 4. The
blockchain throughput is controlled by two parameters, called block size and congestion rate ,
representing respectively the number of transactions that can be included in a block and the percentage
of the block size that cannot be used during the simulation. We introduce the congestion rate in
order to account for on-chain transactions that are not in the scope of the simulation. We consider that
the simulation can use 1 - congestion rate of the blockchain space, as we consider the remaining size
of the block to be filled by other blockchain transactions (e.g., wholesale on-chain payments).
Algorithm 1 reports the pseudo-code of the blockchain process. The blockchain process reacts in
response to two simulation events: BC_TX_BROADCAST notifies that a new transaction has been submitted
to the blockchain, BC_TICK event sets the blockchain timing and ensures that a new block is added to
the chain when expected. A new BC_TICK event is triggered according to an exponential distribution
having block time as mean. In the simulation of the blockchain component, we made two simplifying
assumptions. First, on-chain transactions and blocks are received by the blockchain miner and PCN
nodes respectively after a (small) network delay, and no delays are introduced by gossiping algorithms
for information dissemination. We extract network latencies from a gamma distribution Γ(6.4, 4.35)
5
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
Algorithm 1 Blockchain Process
Require: MEMPOOL → []
Require: BC → [] ▷ Blockchain
upon event BC_TX_BROADCAST do ▷ New transaction tx received
tx ← received transaction
if tx is valid then
Add tx to MEMPOOL
end if
upon event BC_TICK do ▷ Time to forge a new block
B → [] ▷ New block
while B is not full and MEMPOOL is not empty do
Get tx from MEMPOOL
Add tx to B
end while
Add B to BC
Notify sender and receiver of all tx s in B
Trigger new BC_TICK event according to exp(block time)
estimated on the average daily AWS network latencies4 among European regions. Second, the mempool
is a first-in-first-out (FIFO) queue, and the sooner the blockchain receives a transaction, the sooner it
will be included in a block. We do not implement fee estimations when sending transactions and a
transaction selection algorithm based on fees when selecting transactions from the mempool.
3.3. Submarine Swaps in a Constrained Layer1 Environment
As described in Sect. 2.3, we implement three channel rebalancing channels: i.e., submarine swaps,
waterfall rebalance, and reverse waterfall rebalance. Only the first one requires on-chain transactions,
since the others can be performed entirely in the off-chain layer (i.e., in the PCN). In this section, we
briefly describe the simulation of submarine swaps in an environment with a blockchain having limited
throughput and high latency.
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; When a node prepares to forward a payment, it checks the unbalancedness
of the incoming channel. The incoming channel would result in having an increase in the local balance
of the node if the payment is successfully forwarded. The unbalanceness of the incoming channel
is defined as the ratio between the local balance and the channel capacity : an unbalancedness
greater than 0.5 means that the channel liquidity is more concentrated on the side of the local node,
and the upcoming payment is going to make things even more unbalanced. If the unbalancedness
exceeds the Submarine Swaps Threshold (or simply Swap Threshold), the node attempts to initiate
a submarine swap for the incoming channel. The happy path process is the following: (i) the node
sends a SWAP_REQUEST to the channel counterparty; (ii) the counterparty initiates the swap sending a
PREPARE_HTLC transaction to the blockchain; (iii) once the prepare transaction is confirmed, the node
sends a submarine off-ledger payment to the counterparty, via the channel that parties aim at balancing;
when the submarine payment is completed, the unbalancedness of the channel is reduced; and (iv)
upon receipt of the submarine payment, the node learns the secret preimage used by the counterparty
to lock the funds on the blockchain and can broadcast the CLAIM_HTLC transaction to the blockchain.
Algorithm 2 summarizes how a submarine swap is simulated.
In the simulation of the submarine swap component we made two simplifying assumptions. First, a
node receiving a swap request always accepts the swap and forwards the prepare HTLC transaction.
4
Source: https://www.cloudping.co
6
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
Algorithm 2 Submarine Swap simulation algorithm
Require: Swap Threshold >0.5
upon event Forward Payment do
if Incoming Channel Unbalancedness ≥ Swap Threshold then
Forward Submarine Swap Request
end if
upon event Swap Request do
Broadcast Prepare HTLC
upon event Blockchain Transaction tx Received do
if tx is of type Prepare HTLC then
Send submarine payment
else if tx is of type Claim HTLC then
Delete swap
end if
upon event Receive Payment Success do
Broadcast Claim HTLC
Second, we do not handle submarine swap timeouts.
4. Evaluation
We generate and simulate 10 random SH-PCNs whose size is proportional to 4 countries—France,
Germany, Italy, and Spain—with 4 MHs, 40 LSPs, and 404k EUs (400k customers, 4k merchants). We
consider a block time of 1 minute [4] and we scale down the block size proportionally to the number
of users, resulting in 4 transactions per block. For each SH-PCN, we simulate a stream of payments for
24 hours of simulated time. In the following, we present and analyze the mean and standard deviation
of the simulation results.
We present three main sets of experiments. First, we analyze the impact of the rebalancing policy on
the payment success rate in a setting of constant payment generation rate. Second, we investigate what
happens when the payment generation rate changes over time. Finally, we investigate the impact of
blockchain congestion on the performance of the PCN.
4.1. Effect of Rebalancing Strategies on Payments
As detailed in Sect. 3, performing submarine swaps involves on-chain transactions and different policies
can be devised to trigger such an operation. Note that performing submarine swaps too soon leads to
a higher volume of locked liquidity for the same payment success rate; conversely, performing them
too late would results in a reduced payment success rate—as it increases the probability of having an
unbalanced channel that is not ready to forward a payment.
In this section, we evaluate the effect of the threshold-based policy to trigger swaps presented
in Sect. 3.3. We consider a constant global load of 2 payments per second and a fixed blockchain
congestion rate equal to 50%, i.e., PCN-related transactions can occupy up to 50% of the block size .
The congestion rate accounts for on-chain transactions that are not in the scope of the simulation.
Fig. 2 reports the payment success rate and the number of submarine swaps per minutes as the policy
threshold changes; we evaluate also the effect of different total network liquidity configurations, i.e.,
the liquidity locked in all MH-LSP and LSP-LSP channels of the network5 . First of all, we observe
a general trend whereby higher network liquidity results in higher payment success rate; this is a
rather straightforward result as higher channel capacity ensures their ability to forward payments.
Moreover, when a higher liquidity is locked, the PCN overall performs a sensibly lower number of
5
We configure the network so that MH-LSP channels lock twice the liquidity of LSP-LSP channels.
7
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
100% 1.0
Payment Success
0.8
Minute (SPM)
99%
Rate (PSR)
Swaps per
0.6
98%
Network Liquidity (€) 0.4
PSR SPM
97% 800k 800k
1.6M 1.6M
0.2
4M 4M
60% 70% 80% 90% 95% 98%
Swap Threshold
Figure 2: Effect of different submarine swap thresholds on the payment success rate and the overall number of
swaps per minute performed by the PCN.
Transactions
Transactions
per minute
per minute
400 400
300 300
200 200
100 100
0 0
100% 100%
Payment Success
Payment Success
98% 98%
Rate
Rate
95% 95%
Swap Threshold Swap Threshold
60% 60%
92% 80%
92% 80%
90% 90%
90% 90%
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Hour of the Day Hour of the Day
(a) Network Liquidity: 800k (b) Network Liquidity: 1.6M
Figure 3: Varying load of payments. Impact on payment success rate when different thresholds and network
liquidity configurations are considered. The rolling average value of payment success rate in a window of
15 minutes over the entire 24 hours of simulated time is presented.
submarine swaps. This depends also on the stream of payments we are considering: although they
cover 24 hours, they do not move enough balance to trigger channel replenishing operations (i.e.,
submarine swaps). Three further observations can be made. First, submarine swaps enables the PCN
to sustain continuous payments while keeping a high payment success rate. Independently from the
amount of locked liquidity, Fig. 2 shows that at least a swap every 15-20 minutes must be performed
to obtain 100% of success rate even with 4M of network liquidity. Second, the threshold-based policy
help prevent the no-balance available errors in payment forwarding. Specifically, we can see that when
the swap threshold increases up to 90%, the payment success rate increases (with network liquidity
of 800k) or stays fixed to 100% (with liquidity greater or equal to 1.6M). Interestingly, higher values
of the threshold result in a lower payment success rate: this is due to dynamics of the system where
performing a swaps takes much more time than the payment time-out (set to 10 s to let us consider
the payment as “instant” [2]). Third, low values of the threshold reduce the payment success rate,
e.g., see the success rate with swap threshold equal to 60% and network liquidity equal to 1.6M. This
sounds counter-intuitive, although we can observe that lower values of the threshold increase the
number of on-chain transactions that more quickly fill the blockchain mempool. Such a high volume of
requests delays swap requests, which cannot terminate in time to prevent insufficient funds errors in
the payment forwarding.
Fig. 3 summarize results from a second set of experiments, where we change the payment load over
8
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
100%
Payment Success Rate
99%
98%
97%
96% Network Liquidity (€)
800k
1.6M
95%
4M
10% 20% 30% 40% 50% 60% 70% 80% 90%
Congestion Rate
Figure 4: Effect of different blockchain congestion rate on the success of payment in the PCN.
time (as depicted in the upper part of the figure). By comparing Fig. 3a and Fig. 3b, we readily see that
increased network liquidity requires fewer swaps (as seen before). When liquidity is 800k, even with
a 90% of swap threshold, the payment success rate decreases as soon as the overall rate of payments
starts to increase. Lower thresholds worsen performance. The situation is sensibly better with 1.6M of
network liquidity. When the threshold is 90% or 80% the network can withstand up to 300 transactions
per minute with basically no impact on the payment success rate. Note that when the threshold is 60%,
the variability of performance is high indicating that the system is not able of correctly managing the
load; observe how the success rate decreases even when the payment rate is constant in the left-hand
side of Fig. 3b.
4.2. Effect of Blockchain Congestion on PCN Performances
In the previous section, we showed how the PCN performance depends on the blockchain: rebalancing
a channel on-chain imposes long waiting times that can also result in payment failures. In this set of
experiments, we investigate the impact of different blockchain congestion ratio on PCN performance.
In particular, we fix the global load at 2 transactions per second and the swap threshold to 80%, and
we analyze the effect of different congestion rate of the blockchain on payment success rate. Fig. 4
summarizes results. We observe that, as expected, higher blockchain congestion prevents the PCN to
timely perform submarine swaps, which can be included in a block after some block time . As also
previously discussed, higher network liquidity requires fewer swaps; hence, the payment success rate
stays high even with high blockchain congestion. With 1.6M of network liquidity, the PCN can tolerate
up to a blockchain congestion of 60-70% before a noticeable decrement in the payment success rate.
5. Related Work
5.1. Lifespan of Payment Channels
Although PCNs represent an interesting approach to improve scalability of blockchains, they are not free
of drawbacks. As also shown in Sect. 4, channels get unbalanced while forwarding payments. Shabgahi
et al. [9] propose a model to predict the expected time for a channel to get unbalanced, considering its
centrality and its initial balance. Basically, two main approaches emerged to replenish channels and
extend their lifespan, namely via on-chain transactions or via in-place rebalancing (e.g., by introducing
ad-hoc routing strategies). Approaches that resort to on-chain transactions (e.g., [7, 8, 9]) usually do not
explicitly model the limits imposed by the blockchain and, often implicitly, assume that the blockchain
9
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
can always satisfy rebalancing requests in a constant time interval (as we also did in [1]). To the best of
our knowledge, Papadis and Tassiulas [10] propose the most detailed model of rebalancing through
on-chain transactions. This model is then used to define a reinforcement learning based policy that
proactively performs submarine swaps aiming to maximize profit from blockchain and PCN fees. The
authors elegantly capture the different timescale at which rebalancing decisions and user transactions
are performed. Nonetheless, for sake of tractability, they also assume that the blockchain introduces a
constant delay to confirm all on-chain transactions.
We acknowledge that studying the constraints imposed by a blockchain subject to varying loads is
complicated; it cannot be easily captured analytically. Therefore, we resort to simulations.
5.2. Simulating Blockchains and PCNs
Although deeply intertwined, to date there are no simulators that focus on the blockchain-PCN interac-
tion. We first briefly look at blockchain simulators, and then summarize the key tools for simulating
PCNs and, in particular, the LN.
5.2.1. Simulators of Blockchains
The popularity of blockchains as well as its complexity lead to the development of a rather large number
of simulators (e.g., [25, 26, 27]), with nearly half of them available in open-source (e.g., [28, 29, 30, 31, 32]).
They model a wide range of blockchain features ranging from network, consensus, data, execution and
application layers. Paulavičius et al. [33] and Albshri et al. [34] present an extensive literature review on
blockchain simulators, and provide an interesting comparison among them along different dimensions,
including the supported features. Differently from our approach that relies on an established PDES, all
of these simulators are sequential discrete event simulators. They do not exploit advanced simulation
features, such as load distribution, optimistic event scheduling, which might turn out to be very useful
when simulating large networks. To the best of our knowledge, all of these simulators do not explicitly
consider second layer systems, and they do not easily allow modeling and evaluating other systems
that depends on blockchain to operate.
5.2.2. Simulators of PCNs
In this context, simulations have been widely used, e.g., to evaluate policies related to channel design,
rebalancing, routing, and privacy of PCNs. Although several PCN simulators exist (e.g. [35, 36, 37]),
a clear comparison among them is lacking. Research efforts typically build their own simulator to
evaluate specific features, therefore most of them—unfortunately—appear not to be actively maintained
(e.g., [35, 38]). One of the LN developer open-sourced a simulator6 that focuses on the LN gossiping
protocol. Beres et al. [35] develop a simulator specifically focused on fee and profitability7 , to empirically
study LN’s transaction fees and privacy provisions. Also Kappos et al. [39] develop a custom simulator
to investigate the privacy of LN. Simulations are used to investigate the rouging problem, as well.
Engelmann et al. [40] do it by considering channels characterized with economic-technical constraints.
Zhang et al. [41] evaluate their routing algorithm, which is aimed to minimize the transaction fee of a
payment path, subject to the timeliness and feasibility constraints. The source code of all these simulators
is not public. Conversely, Brânzei et al. [42] disclose their custom sequential simulator, which is used to
investigate the Bitcoin ecosystem economics taking into account off-ledger transactions and miner fees
as incentives for honesty. Rebello et al. [36] introduce an open-source PCN simulator that implements
the official LN message protocol in OMNET++. Recently, Conoscenti et al. [12] proposed CLoTH, an
open-source simulator that reproduces the code of LND, with specific regards to routing and HTLC
mechanisms. Different research works use CLoTH for evaluating their contributions (e.g., [13, 14, 15]).
6
https://github.com/rustyrussell/million-channels-project
7
https://github.com/ferencberes/LNTrafficSimulator
10
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
6. Conclusion
In this paper, we investigated how a blockchain impacts on a second layer PCN built on top of it. To
this end, we extended our PDES for SH-PCNs to incorporate the dynamics of the layer-1 blockchain
having limited block size and not negligible block time. Then, we conducted an extensive evaluation
and showed how blockchain parameters—such as its congestion rate—significantly influence PCN
performance (e.g., in terms of payment success rate).
As future work, we will further develop our simulator by implementing key PCN features (e.g.,
routing, channel rebalancing techniques, network load). We also plan to conduct experiment on very
large scale networks, up to a scale of 1:1 with the population of the euro area.
References
[1] M. Benedetti, F. D. Sclavis, M. Favorito, G. Galano, S. Giammusso, A. Muci, M. Nardelli, Self-
balancing semi-hierarchical payment channel networks for central bank digital currencies, in:
Proc. of 2024 IEEE PerCom Workshops, 2024, pp. 530–536. doi:10.1109/PerComWorkshops59983.
2024.10503409 .
[2] European Central Bank, What are instant payments?, https://bit.ly/3RolNlO, 2023. Accessed:
2023-11-10.
[3] M. Benedetti, F. De Sclavis, M. Favorito, G. Galano, S. Giammusso, A. Muci, M. Nardelli, PoW-
less Bitcoin with Confidential Byzantine PoA, in: Proc. of 2023 IEEE Int. Conf. Blockchain and
Cryptocurrency (ICBC), 2023, pp. 1–3. doi:10.1109/ICBC56567.2023.10174972 .
[4] M. Benedetti, F. D. Sclavis, M. Favorito, G. Galano, S. Giammusso, A. Muci, M. Nardelli, Certified
Byzantine Consensus with Confidential Quorum for a Bitcoin-derived Permissioned DLT, in:
Proc. of the 5th Distributed Ledger Technology Workshop, 2023, pp. 1–17. Available at https:
//ceur-ws.org/Vol-3460/papers/DLT_2023_paper_1.pdf.
[5] A. Gangwal, H. R. Gangavalli, A. Thirupathi, A survey of layer-two blockchain protocols, J. Netw.
Comput. Appl. 209 (2023) 103539. doi:10.1016/j.jnca.2022.103539 .
[6] F. S. Mishkin, The economics of money, banking, and financial markets, Pearson education, 2007.
[7] P. Li, T. Miyazaki, W. Zhou, Secure balance planning of off-blockchain payment channel networks,
in: Proc of IEEE INFOCOM ’20, 2020, pp. 1728–1737. doi:10.1109/INFOCOM41043.2020.9155375 .
[8] V. Sivaraman, S. B. Venkatakrishnan, M. Alizadeh, G. Fanti, P. Viswanath, Routing cryptocurrency
with the spider network, in: Proc. of HotNets ’18, ACM, 2018, p. 29–35. doi:10.1145/3286062.
3286067 .
[9] S. Z. Shabgahi, S. M. Hosseini, S. P. Shariatpanahi, B. Bahrak, Modeling Effective Lifespan of
Payment Channels, 2022. ArXiv:2301.01240.
[10] N. Papadis, L. Tassiulas, Deep reinforcement learning-based rebalancing policies for profit maxi-
mization of relay nodes in payment channel networks, 2023. ArXiv:2210.07302.
[11] G. Galano, S. Giammusso, M. Nardelli, Modeling central bank digital currency over payment
channels: A parallel ross- based approach, in: Proc. of 38th ACM SIGSIM Conference on Principles
of Advanced Discrete Simulation (SIGSIM PADS ’24), ACM, 2024. doi:10.1145/3615979.3656052 .
[12] M. Conoscenti, A. Vetrò, J. C. De Martin, CLoTH: A Lightning Network Simulator, SoftwareX 15
(2021) 100717. doi:10.1016/j.softx.2021.100717 .
[13] K. Asgari, A. A. Mohammadian, M. Tefagh, Dyfen: Agent-based fee setting in payment channel
networks, 2022. ArXiv:2210.08197.
[14] V. Davis, B. Harrison, Learning a scalable algorithm for improving betweenness in the lightning
network, in: Proc. of the 2022 Int. Conf. on Blockchain Computing and Applications (BCCA), 2022,
pp. 119–126. doi:10.1109/BCCA55292.2022.9922233 .
[15] T. Dasaklis, V. Malamas, Lightning network’s evolution: Unraveling its present state and the
emergence of disruptive digital business models, 2023. Preprints.org:202305.0523.v1.
[16] C. D. Carothers, D. Bauer, S. Pearce, ROSS: A high-performance, low-memory, modular Time
11
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
Warp system, Journal of Parallel and Distributed Computing 62 (2002) 1648–1669. doi:10.1016/
S0743- 7315(02)00004- 7 .
[17] J. Poon, T. Dryja, The bitcoin lightning network: Scalable off-chain instant payments, 2016.
[18] E. Rohrer, J. Malliaris, F. Tschorsch, Discharged payment channels: Quantifying the lightning
network’s resilience to topology-based attacks, in: Proc. of 2019 IEEE European Symposium on
Security and Privacy Workshops (EuroS&PW), 2019, pp. 347–356. doi:10.1109/EuroSPW.2019.
00045 .
[19] I. A. Seres, L. Gulyás, D. A. Nagy, P. Burcsi, Topological analysis of Bitcoin’s Lightning Network,
in: Mathematical Research for Blockchain Economy, Springer, 2020, pp. 1–12. doi:10.1007/
978- 3- 030- 37110- 4_1 .
[20] G. Avarikioti, Y. Wang, R. Wattenhofer, Algorithmic channel design, in: Proc. of 29th Int.
Symposium on Algorithms and Computation (ISAAC 2018), volume 123 of Leibniz International
Proceedings in Informatics (LIPIcs), Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl,
Germany, 2018, pp. 16:1–16:12. doi:10.4230/LIPIcs.ISAAC.2018.16 .
[21] D. J. Watts, S. H. Strogatz, Collective dynamics of ‘small-world’ networks, Nature 393 (1998)
440–442. doi:10.1038/30918 .
[22] ECB, A stocktake on the digital euro, https://bit.ly/412yK8a, 2023.
[23] ECB Surveys, Study on the payment attitudes of consumers in the euro area (SPACE), https:
//bit.ly/412qbdE, 2022.
[24] M. Benedetti, F. De Sclavis, M. Favorito, G. Galano, S. Giammusso, A. Muci, M. Nardelli, Self-
Balancing Semi-Hierarchical PCNs for CBDCs, 2024. ArXiv:2401.11868.
[25] E. Androulaki, G. O. Karame, M. Roeschlin, T. Scherer, S. Capkun, Evaluating user privacy in
Bitcoin, in: Financial Cryptography and Data Security, Springer, Springer Berlin Heidelberg, 2013,
pp. 34–51. doi:10.1007/978- 3- 642- 39884- 1_4 .
[26] I. Eyal, E. G. Sirer, Majority is not enough: Bitcoin mining is vulnerable, Commun. ACM 61 (2018)
95–102. doi:10.1145/3212998 .
[27] A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, S. Capkun, On the security
and performance of proof of work blockchains, in: Proc. of 2016 ACM SIGSAC Conference on
Computer and Communications Security (CCS ’16), ACM, New York, NY, USA, 2016, p. 3–16.
doi:10.1145/2976749.2978341 .
[28] A. Deshpande, P. Nasirifard, H.-A. Jacobsen, eVIBES: Configurable and interactive ethereum
blockchain simulation framework, in: Proc. of 19th Int. Middleware Conference (Posters), Middle-
ware ’18, ACM, New York, NY, USA, 2018, p. 11–12. doi:10.1145/3284014.3284020 .
[29] A. Miller, R. Jansen, Shadow-Bitcoin: Scalable simulation via direct execution of Multi-Threaded
applications, in: Proc. of 8th Workshop on Cyber Security Experimentation and Test (CSET 15),
USENIX Association, Washington, D.C., 2015.
[30] M. Alharby, A. van Moorsel, Blocksim: A simulation framework for blockchain systems, SIGMET-
RICS Perform. Eval. Rev. 46 (2019) 135–138. doi:10.1145/3308897.3308956 .
[31] C. Faria, M. Correia, BlockSim: Blockchain simulator, in: 2019 IEEE Int. Conf. on Blockchain,
2019, pp. 439–446. doi:10.1109/Blockchain.2019.00067 .
[32] D. K. Gouda, S. Jolly, K. Kapoor, Design and validation of blockeval, a blockchain simulator,
in: 2021 Int. Conf. on COMmunication Systems & NETworkS (COMSNETS), 2021, pp. 281–289.
doi:10.1109/COMSNETS51098.2021.9352838 .
[33] R. Paulavičius, S. Grigaitis, E. Filatovas, A systematic review and empirical analysis of blockchain
simulators, IEEE Access 9 (2021) 38010–38028. doi:10.1109/ACCESS.2021.3063324 .
[34] A. Albshri, A. Alzubaidi, B. Awaji, E. Solaiman, Blockchain simulators: A systematic mapping
study, in: 2022 IEEE Int. Conf. on Services Computing (SCC), 2022, pp. 284–294. doi:10.1109/
SCC55611.2022.00049 .
[35] F. Beres, I. A. Seres, A. A. Benczur, A cryptoeconomic traffic analysis of bitcoin’s lightning network,
2019. ArXiv:1911.09432.
[36] 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,
12
Marco Benedetti et al. CEUR Workshop Proceedings 1–13
2022, pp. 1–2. doi:10.1109/INFOCOMWKSHPS54753.2022.9798003 .
[37] R. Yu, G. Xue, V. T. Kilari, D. Yang, J. Tang, CoinExpress: A fast payment routing mechanism in
blockchain-based payment channel networks, in: Proc. of Int. Conf. on Computer Communication
and Networks (ICCCN), 2018, pp. 1–9. doi:10.1109/ICCCN.2018.8487351 .
[38] G. Di Stasi, S. Avallone, R. Canonico, G. Ventre, Routing payments on the Lightning Network,
in: Proc. of IEEE iThings and GreenCom and CPSCom and SmartData ’18, 2018, pp. 1161–1170.
doi:10.1109/Cybermatics_2018.2018.00209 .
[39] 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, Berlin, Heidelberg,
2021, pp. 167–186. doi:10.1007/978- 3- 662- 64322- 8_8 .
[40] F. Engelmann, H. Kopp, F. Kargl, F. Glaser, C. Weinhardt, Towards an economic analysis of routing
in payment channel networks, in: Proc. of 1st Workshop on Scalable and Resilient Infrastructures
for Distributed Ledgers (SERIAL), ACM, 2017, pp. 1–6. doi:10.1145/3152824.3152826 .
[41] Y. Zhang, D. Yang, G. Xue, CheaPay: An optimal algorithm for fee minimization in blockchain-
based payment channel networks, in: Proc. of the 2019 IEEE Int. Conf. on Communications (ICC),
2019, pp. 1–6. doi:10.1109/ICC.2019.8761804 .
[42] S. Brânzei, E. Segal-Halevi, A. Zohar, How to charge lightning: The economics of Bitcoin transaction
channels, 2022. ArXiv:1712.10222.
13