Assessing the scalability of a payment channel network is crucial as it directly impacts the eficiency 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, afect 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 of-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 afect the optimal allocation of liquidity that is needed to match the target performances.
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 eficient 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 [
In our previous works [
CEUR Workshop Proceedings
ceur-ws.org
ISSN1613-0073
PCNs with a partially constrained topology, called “Semi-Hierarchical Payment Channel Networks”
(SHPCNs)—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 [
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., [
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) [
In [
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 1The source-code of the simulator is available at https://github.com/bancaditalia/itcoin-pcn-simulator 2https://github.com/lightningnetwork/lnd 3We target settings where the number of trusted actors is expected to be between 4 and ≈ 20. Tier 1 RSP, MH 3 110068 // 110035 c1 m1c2 c3 m2 c4 (PFioxleicdytdoepcoilsoigoyn) (PFoixleicdycdaepcaisciiotyn) 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, of-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 [
The most popular PCN implementation, i.e., the Lightning Network (LN), does not constraints how
PCN node should open channels with one another. Therefore, diferent network topologies can be
build or can emerge, ranging from star-like to scale-free (as appears to be the LN, e.g., [
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 diferent 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 [
• 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 ofer service to EUs by opening channels with them. • In addition to of-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
diferent 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;
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 [
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., [
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 of-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 [
Reverse waterfall rebalance. This functionality allows retail users—in particular those having high outbound trafic (e.g., citizens)—to automatically fund a payment channel before making transactions too large for its current state. If there are insuficient 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.
In [
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 of-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 of-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 of-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 eficiency 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 afecting the PCN’s ability to handle high volumes of transactions eficiently.
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)
Require: MEMPOOL → [] Require: BC → [] upon event BC_TX_BROADCAST do tx ← received transaction if tx is valid then
Add tx to MEMPOOL end if upon event BC_TICK do
B → [] 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 txs in B Trigger new BC_TICK event according to exp(block time) ▷ Blockchain ▷ New transaction tx received ▷ Time to forge a new block ▷ New block 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.
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 of-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 of-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. 4Source: https://www.cloudping.co
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.
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 [
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.
As detailed in Sect. 3, performing submarine swaps involves on-chain transactions and diferent 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 efect 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 efect of diferent 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 5We configure the network so that MH-LSP channels lock twice the liquidity of LSP-LSP channels. 100% s ce ) 99% s c R Su S
P t ( 98% en te ym aR aP 97%
Network Liquidity (€)
PSR SPM
800k
1.6M
4M
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” [
Fig. 3 summarize results from a second set of experiments, where we change the payment load over
100% s s e cc 98% tnSu tea95% e R aym 92% P 100% 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.
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 diferent 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 efect of diferent 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.
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. [
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.
Although deeply intertwined, to date there are no simulators that focus on the blockchain-PCN
interaction. 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., [
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.