A main approach to solve the scalability problem in Bitcoin is to use off-chain transaction channels that allow parties to transfer funds while communicating directly, and only occasionally to settle the accumulated transfers that they have done on the blockchain [LightningOriginal]. In this manner, space on the blockchain (which is highly constrained) will be used to aggregate the result of multiple transactions that occurred over channels.
Transaction channels are created between a pair of participants by locking money into a “joint account”. The money is transfered between the participants by exchanging signed transaction messages that change the way funds in this account are allocated. The channel is closed by the participants when sending the latest transaction to the blockchain, which finalizes this allocation. Channels can be chained together securely to allow users to transfer funds to others that they are not directly connected to, and thus form fast payment networks that provide near instant payments that require few interactions with the blockchain.
The implication of this construction is that transaction channels necessitate locking liquidity for extended periods of time. These liquidity costs are balanced against the costs of fees that must be paid whenever channels are opened or closed—an operation that requires transactions on the blockchain. Intuitively, increasing liquidity costs by locking more funds into the channel lowers the fees that will be paid, as channels will need to be reset less often.
In this paper we take the first steps to study and optimize the costs of payment networks. We study both game-theoretic formation of channels, and globally optimal solutions.
We show that hub topologies can be highly efficient in terms of costs minimization, which increases the concern that large monopolistic players will arise and out-perform decentralized networks. We show this by exploring cost-optimal topologies and liquidity allocations, and by proving that a hub topology provides a 2-approximation to the optimal maintenance cost of any topology. We further show that this approximation is tight.
Using a model for the expected lifetime of symmetric channels (when both parties transfer coins in the same rate in both directions) from [DBLP:journals/corr/abs-1712-10222] we derive the optimal liquidity allocation for any topology and routing algorithm.
We solve the problem of building cost-optimal spanning tree networks for symmetric demands.
Finally, we explore a game theoretic model for the network formation of payment channels by defining a game in which participants connect to the network and seek to minimize their costs. We study the equilibrium points in the restricted setting of trees for this game, and prove an unbounded price of anarchy for this setting.
Our results open the field for further explorations of the costs of payment networks, and highlight the need for further study of more general cases (such as non-symmetric demands).
1.1 Payment Networks Basics
Payment channels are based on exchanging signed messages that describe how to allocate funds between pair of agents. For example, let us assume that Alice and Bob opened a payment channel by locking 0.5 BTC each. When Alice wants to transfer 0.1 BTC to Bob, she signs a message containing the new channel balance (of 0.4 BTC for Alice, 0.6 BTC coins for Bob, as described in figure 1, transaction 1). She sends the message to Bob, that transmits the message to the blockchain at will. Bob will usually not do so immediately, but rather hold on to this message and replace it with newer allocations after more transfers are made.
While transaction channels themselves are limited to exchanges between pairs of individuals, further developments like the Lightning network[LightningOriginal] allow users to securely route payments over longer paths and thus can allow the construction of a well connected network that can be used to transfer money quickly and with relatively little interaction with the blockchain. For example, let us assume that Alice wants to transfer money to Charlie. Instead of opening a shared payment channel or transacting directly via the blockchain, she can first transfer money to Bob via their shared payment channel, and ask Bob to send money to Charlie via another payment channel (as described in figure 1, transaction 2). In order to avoid the risk of having an intermediate node accept money without forwarding the payment, paths are composed using HTLCs (Hash time lock contracts) that release funds only if a secret—initially known only to the sender—is released. More details can be found in [LightningOriginal].
When the most recent state of a channel allocates all funds in the joint account to one of the agents, it is no longer possible to transfer money to that agent using the channel. Further transfers must either use the blockchain directly, or the channel must go through a “reset”; recording the channel balance on the blockchain, and opening a new channel (alternatively funds can be added to the channel by the participant that lacks liquidity, but this too requires a blockchain transaction). As we have already mentioned, blockchain records incur a constant fee.
1.2 Related work
The original Lightning Network paper [LightningOriginal] suggests a BGP-like routing method. The implementation of the Lightning network (off-chain network over the Bitcoin blockchain), uses source routing, based on channel usage fees. The Raiden network [Raiden], like other P2P networks, implements a Kademila-based routing system, in order to minimize the number of hops. Another idea for scaling transactions over Ethereum, is the Perun payment hub [dziembowski2019perun]. The idea is based on a network in the structure of a hub, that will be efficient in the number of routing hops per transaction. The paper implements a secured method for shortcutting several hops, based on smart contracts.
Several recent papers [avarikioti2019payment] [avarikioti2019ride] [ersoy2019profit] discuss the same question of payment channels creation game as we did. However, while those papers choose a transaction-series/single-channel based model, we differ with a network traffic rates model. A recent paper [avarikioti2018payment] discussed the same question of global fees optimization in payment channels network design, but again it uses the same transaction-series model.
Two recent papers [beres2019cryptoeconomic] [rincon2020identifying] present a real data-driven analysis of lightning routing, fees and topology. We differ from them by presenting a theoretical model to this problem, rather than analyzing real-world data.
Some recent works [routingHash1, routingHash2, herrera2019difficulty] refer to other side-effects of routing (such as privacy and memory demands), and present efficient algorithms for the routing problem. The Fulgor and Rayo paper [malavolta2017concurrency], that describes two of the major methods for the remaining privacy and concurrency in off-chain networks, assumes that routing path is being chosen by the transactor, in order to minimize the fee per transaction.
The topology of off-chain networks, has been studied in [adkinsinefficacy]. Measures such as the connectivity of the network and routing availability are the main focus. Algorithms for balancing edges (using “smart routing” of transactions) have been presented and simulated in [balancingAlgorithm]. Some mathematical analysis of the expected channel lifetime over off-chain channels, has been conducted [DBLP:journals/corr/abs-1712-10222]. We build upon and extend their model.
An economic model of the routing problem in Lightning, has been studied in [minimalPathArticle], but we differ from this research in the basic model: The authors assume the cost of transmitting transactions is linearly related to the volume of payments and therefore the payoff can be formulated as a linear optimization problem. As far as we are aware, we are the first to explore cost minimization in this setting.
A recent paper [khalil2017revive] presents an instance local solution to the channel resets problem, which is re-balancing a group of channels by transacting in cycles. We differ from this paper, by our approach of optimizing topology and liquidities, rather than re-balancing a liquidities in some specific channels.
The Plasma paper [poon2017plasma] presents a generalization of payment channels to general state that is managed by local consensus protocols.
A few papers [magnanti1984network] [diaz2002survey] [minoux1989networks] discuss the problem of optimizing communication networks from the perspective of cut-capacities, Gomory-Hu trees and submodular optimization. We use a similar approach in our paper.
2 The Model
We now present our model of off-chain payment networks. We first define the state of a channel, and how transactions affect it, then define a payment network and a routing policy, and finally, a probabilistic model for transaction demand.
The State of a Channel
Let be a payment channel between two participants: Alice and Bob. The payment channel state is a pair , denoting the internal allocation of funds between the participants (Alice holds coins, and Bob holds coins). The sum is called the liquidity of the channel, and the amounts must be non-negative.
The liquidity of the channel, remains constant during its lifetime. Transactions, however, change the internal balance. Given a channel between Alice and Bob, with state , a transaction of coins from Alice to Bob changes the state to . The transaction is feasible if and only if , i.e., it cannot reach or exceed the liquidity boundaries.
Although transfers in one direction are still possible when liquidity is fully shifted to one of the channel’s sides, we assume the channel has to always be ready for transfers in both directions (otherwise we may be forced to use a blockchain transaction which takes very long). Therefore, we assume channels are reset whenever liquidity has fully shifted.
The Cost of Payment Channels
We model the cost of locking liquidity in the channel as coins per second, where reflects the interest rate in the economy. We further denote the blockchain fee required to write a record by . This fee is paid whenever a channel reset occurs. 111There may in fact be added costs for writing more-complex transactions to the blockchain that both transfer and reset the channel.
We denote by the rate of blockchain records per second that are used to maintain channels. The cost of a channel (per time unit) is then .
We are now ready for definitions pertaining to more complex networks:
Definition 1 (Payment Network).
A payment network is described by a graph , and a liquidity allocation . denotes the set of transactors, is the set of payment channels, and is the liquidity of channel . We denote the sum of all channels’ liquidities as . Transactions are transfered over paths in the graph. A transaction of coins via the path , changes the state of channel (for every ), to be . Transactions must be feasible for all channels along the path.
Given a payment network, it is important how payments are routed (as this may in turn affect the volume of payments going through individual channels).
Definition 2 (Routing Policy).
A routing policy over a graph is a function such that is a legal path in between and with no cycles. For every there holds is the reverse of .
This definition refers to a state-independent symmetric routing protocol. We restrict our attention to protocols that do not depend on direction or state, since this is the current way payment networks are implemented in Bitcoin (routing is independent of channel state as state changes too quickly to allow for global routing adjustments to occur).
Finally, we will define the demand matrix, which defines a probabilistic model for transaction requests:
Definition 3 (The Demand Matrix).
Let be a payment channel network, and let denote the Demand Matrix for transactions. Every second, transfers to an amount of coins, from a Poisson process with mean .
The demand matrix along with the topology and routing protocol effectively set the number of transfers on each channel and will later allow us to derive the maintenance costs of the network.
2.1 Symmetric Networks
We are particularly interested in symmetric-demand networks, in which each pair of participants transact at the same expected rate in both directions, since such payments often cancel out and represent an optimistic case for transaction channels’ lifetimes.
We thus assume that transaction amounts are all identical (for convenience, we assume all transfers are for 1 unit of money), and that furthermore, transaction rates are symmetric: .
The symmetric demands assumption, creates only balanced channels for every routing policy. That is because the traffic components over a channel, are identical in both directions. Under this model, each channel is simulating a random walk process. Every time a transaction through the channel is infeasible (due to liquidity constraints), we reset the channel, and pay a constant blockchain fee.
Let be an off-chain transaction channel. Let [seconds] be the random variable of the channel lifetime after
[seconds] be the random variable of the channel lifetime afterresets of the channel. Let [coins] be the constant fee for blockchain record. We define , the average rate of records per second, to be:
The blockchain cost per second is then .
Let [seconds] be the random variable of channel ’s lifetime after blockchain records. For every , Let . Therefore:
From the Strong law of large numbers[probBook], since are identically distributed, independent and have finite expected value, the series of arithmetic means is converging almost surely to . We will prove that converges almost surely to . Let us denote:
From convergence almost surely . From the basic laws of calculus, we know that on there holds
Since is a positive constant random variable, . Therefore:
From that we deduce . Meaning that is converging almost surely to . We know that because a channel reset requires at least one transaction. Therefore: which implies for all .
Let us denote a constant random variable . We know has finite expected value, and that for all . According to the Lebesgue dominated convergence theorem [probBook], Since converges almost surely to , we deduce:
The next corollary follows immediately:
From this formula we will be able to compute the blockchain records cost for every network and routing policy.
The Expected Lifetime Of Balanced Channels
We recall a derivation from [DBLP:journals/corr/abs-1712-10222] that finds the optimal liquidity allocation and expected channel lifetime, in a balanced channel:
Lemma 2 (From [DBLP:journals/corr/abs-1712-10222]).
Let us have a channel between Alice and Bob, with transfers of one coin occurring at a Poisson rate of from Alice to Bob in each time slot, from Bob to Alice (a symmetric channel). The liquidity of the channel is . The allocation that maximizes the expected time for the next reset is an equal allocation, and the expected value of channel life time is: .
The Rate of Transfer Through a Channel
In off-chain networks, every channel services multiple source-target transfers based on the routing policy. We define the rate over an edge (this rate is the same in both directions since our networks are symmetric):
Let be a routing policy over a network , with a symmetric demands matrix . We denote for a channel , the balanced channel Poisson rate of as the following:
This is essentially the total single-directional traffic over an edge, as derived from the routing policy. We rely here on the fact that the sum of Poisson random variables is a Poisson variable with rate equal to the sum of their rates.
3 Hub Is 2-Approximation for Cost Optimal Network
Let be an off-chain network, with a routing policy , and liquidity allocation . Let be a hub topology centered at an arbitrary vertex of , . There exists a routing policy and liquidity allocation for , such that for every series of transactions, the number of channel resets is at most twice the number of channel resets in , and the required liquidity is at most doubled: .
The proof is based on duplicating original channel traffic in into two channels in , by transferring the transaction throughout hub. For every node , let us denote all the channels in that is connected to. We define to be:
We can now calculate the total amount of liquidity in :
Any channel’s liquidity in the original graph, is added at most twice. Now we will define the hub routing policy . Let to be a pair of nodes. Let be the path in the original routing policy in (between and ). The path in the new routing policy over is:
We remove all routing hops of the form from the new path . This is simply an elimination of the loop hops (trips back and forth to the hub). We will show that the number of channel resets is at most twice the original number of resets. We can look at each hub channel as a “superposition” of all the original channels in that was connected to, . This is also a superposition in the liquidity, since new liquidity is the sum of all -channels liquidities. Therefore, we can split the original hub channel , into imaginary channels that represent the original channels of . We split the total liquidity into the liquidities of imaginary channels of . We simulate the action of each transaction over the imaginary channels in , by changing their balances.
Each channel that was originally between and now has a share of the liquidity in and in . Every time that an imaginary channel has to be reset (in the simulation), we will perform a reset over that channel only in this both edges. It means that the hub’s channel balance, summing the balances of all imaginary channels, will reset only the imaginary channel’s balance component. This simulation fully implements a hub payment channel. In that way, for every series of transactions, the number of resets is the sum of all original channels reset numbers or less (due to the loops we’ve removed).
When applying these partial resets, we can calculate the number of reset events over all the hub channels. It is bounded by the sum of imaginary channels reset events, for every in . As a result, since every original channel can be summed at most twice (in two hub channels that connects to it’s endpoints), the total number of resets in is at most twice the total number of resets in . This result holds for every set of transactions, and therefore for all transaction demands.
For any transaction demands, a hub over an arbitrary node is a 2-approximation for the optimal maintenance cost network.
This corollary raises the concern that centralized topologies (such as a hub) will be used widely in off-chain networks due to their maintenance-cost efficiency, although they go against the decentralized nature of blockchain technologies.
4 Optimizing Networks’ Maintenance Costs
In this section we will tackle the optimization problem seeking to minimize the rate of blockchain record fees per second (for a given amount of total liquidity).
4.1 Optimizing Liquidities Over a Network
Here we derive the optimal allocation of the liquidity between the channels in any network, that minimizes the network’s maintenance cost.
Let be a symmetric payment network, with a set of vertices , and edges. Network channels have a transaction rate in both directions for every edge . The optimal liquidity allocation for (with total liquidity ) is: .
Let . The chain record fees we wish to minimize are:
with a condition of .
We use Lagrange multipliers to optimize. Let us define by the condition :
If we differentiate and equate the derivatives to zero, we get
By that we get (for every ).
Since we conclude (for every ).
We know , which means we have to normalize the ’s. We have:
The optimal blockchain record fees per second for the network, with liquidity sum of is: .
4.2 Cost Minimizing Spanning Trees
Given a demand matrix for transactions, we wish to understand what the minimal cost payment network topology is. While solving this problem for general topologies is left open in this work, we are able to solve a more restricted case of tree topologies. The routing policy in a spanning tree is unique, because there is a unique path between every pair of vertices. This will allow us to more easily derive the best tree topology.
First, we will calculate channels transaction rates, for a certain demand matrix and spanning tree. In order to do that, we reiterate the definition of cut-capacities from [optComunicationTrees]:
Let be a network, a capacity matrix, and a graph cut. We define the cut’s -capacity to be:
Now we can calculate the transactions rate over a spanning tree channel:
The Poisson rate of a channel , in a spanning tree network and demands matrix , equals the -capacity of the cut between the two connectivity components of .
Once we can calculate the transaction rates in spanning trees, we adapt our setting to one that was defined originally by T.C Hu in 1974 [optComunicationTrees]. In Hu’s problem, we are given a demands matrix , denoting the communication requirements between pairs of nodes. Hu finds a spanning tree , that minimizes where is the communication traffic over the tree’s edge . The communication rate over a tree channel, is similarly calculated according to lemma 4.
The Gomory-Hu tree (cut-tree) [gomoryHu], can be calculated in polynomial time, and in addition to other properties, the tree is assured to minimize the sum of the tree’s channels traffic, .
Unlike Hu’s problem, we are interested in minimizing . In this section, we will prove that the Gomory-Hu tree is also an optimal spanning tree for our problem. We will dive into the theory of submodular functions, in order to understand the properties of the Gomory-Hu tree.
4.3 Submodular Optimization of Induced Record Fees
It is known [submodular] that the cut capacity function for non-negative capacity function over the edges , is a symmetric submodular function. The Gomory-Hu tree exists for every symmetric submodular function [submodular], when the definition is being adapted to a general function:
Theorem 2 (Queyranne, Maurice [submodular]).
Let be a ground set, and let be a symmetric submodular function. Given in define the minimum cut between and as . Then, there is a Gomory-Hu tree that represents . That is, there is a tree and a liquidity function such that for all . Moreover, a minimum cut in T induces a minimum cut according to for every .
Since the cut capacity function is submodular and symmetric, the Gomory-Hu tree that minimizes the sum of cut-capacities (created between the connectivity components of for every channel ), is assured to exist. However, we wish to optimize , and unlike the regular -cut capacity function, we cannot claim that is submodular (although it is symmetric). 222In fact, a counter example to the submodularity of exists and is provided in the full version. Quite surprisingly, we show that the Gomory-Hu tree for the regular cut function minimizes .
Let be a non-decreasing function. Let be a Gomory Hu tree for a submodular symmetric non-negative function and a vertices set . Then minimizes the value of when is one connectivity component of (which creates a cut).
We will use a property according to Adolphson and Hu [adolphsonAndHu].
For two spanning trees , there is a one-to-one mapping between and , which satisfies the following condition: For every , is in the path between in . Let be a Gomory-Hu tree. For every edge there is a unique edge that represents a cut separating (since it is on the unique path between them in ). From the property of Gomory-Hu tree,
Thus, . Since is a one-to-one mapping
Since is non decreasing, we can apply over this equation:
Having that, every spanning Tree will have greater or equal value of , compared to the Gomory-Hu Tree. ∎
The main corollary (Gomory-Hu tree is optimal spanning tree network), is derived from the lemma with :
Let be a complete graph with non-negative transaction Poisson rate over the edges . Let be a regular Gomory-Hu tree over the weight function . Then is the optimal spanning tree over the value of blockchain record fees per second, and it can be calculated in polynomial time.
5 Towards Global Optimization
5.1 The Cost of a Symmetric Network
The first step in exploring the global optimization of the maintenance cost, is to explore the connection between the different ingredients of that cost.
We showed in corollary 3, that the of a payment network is linear in , for every topology including the optimal. Therefore, we can denote the network’s optimal , as follows: , Where is the optimal RPS rate with sum of liquidity.
Now, we can calculate the liquidity that minimizes the network’s maintenance cost.
Let be a payment network, with liquidity sum. Let us denote as the liquidity interest rate per second, as a single blockchain record fee, and as the optimal blockchain records per second rate (when ). When optimizing the value of , the optimal maintenance cost of the network is proportional to:
According to our definition of channel costs, when summing the liquidity and blockchain records over all the channels in , the full maintenance cost is:
We can derive this equation, and find the minimum point (via the sign of the second derivative):
By placing into , we get the following relation:
5.2 Tightness of Hub 2-Approximation
The results of the previous section allow us to prove the tightness of the hub 2-approximation, that we showed in section 3.
For every , there exists a set of transaction demands , in which the optimal maintenance cost per second, is at least times lower than in every hub.
The full proof appears in the full version. The example that achieves a factor of 2- is based on a setting in which agents are paired together transacting only with each other. In a minimal cost network each such pair would form a channel between them, but in a hub, users are forced to route through two hops, incurring twice the cost.
6 Greedy Games for Payment Networks
In this section we explore a ”network formation” model that considers that players wish to minimize their individual costs. We begin by showing that the results of a greedy liquidity allocation, are about the same.
6.1 Greedy Liquidity Allocation
We analyze how individual channels optimize liquidity:
The minimal maintenance cost per second for a balanced channel with transactions Poisson rate, interest rate for locked coins, and cost for a single Blockchain record, is: .
6.2 Tree Topology Greedy Game
In contrast to the liquidity allocation process, the greedy development of the network topology, is much more interesting. Each one of the players has an effect over the routing of other players. We will study a game, in which each player (node) wished to optimize his own costs, with restriction to the spanning tree topology. First, we define a player’s share in channel fees:
Let be a payment network. is a channel with maintenance cost per second, and balanced transaction Poisson rate. Let us assume that player is transferring in rate over the channel . Therefore, the share of player in the maintenance cost of is:
The player’s fees are proportional to their relative part in the transaction rate. The motivation for this definition is that fees are charged as a fixed amount per transfer, that needs to cover the total cost of the channel. We can now derive the total maintenance cost per second for a single player:
Let denote the transaction rate of player over channel . The maintenance cost per second for player is then:
It is clear from the formula, that a player’s costs depend on the routing policy. However, over a spanning tree topology, the routing is unique.
The Tree Topology Greedy Game, is a game between the agents in , assuming a certain demands matrix . The goal of every player , is to minimize his maintenance costs per second, .
The game starts with an initial spanning tree . In every turn, each player can reconnect a single edge that is incident on its vertex. Such re-connections are restricted to maintain the spanning tree topology.
An equilibrium point in the spanning tree greedy game, is a spanning tree , in which every player cannot reduce his maintenance costs by a legal move (of reconnecting a channel in the tree).
6.3 The Unbounded Price of Anarchy
The spanning tree topology game has unbounded price of anarchy. In other words, for every there exists an equilibrium point in the spanning tree greedy game, , in which there holds where is the optimal maintenance cost spanning tree.
Let us build a series of equilibrium trees, , with vertices, for every integer . The demands matrix is the following: , , and . All the other transaction requirements equal zero. For every , we can build a chain spanning tree - a cyclic ring along the nodes index, with removing the edge between and . It creates 3 channels with transactions rate, and zero transactions rate for all the other channels. Now, let us describe the equilibrium spanning tree of by the set of edges :
This is a simple chain from to . By a quick calculation, we can see that using this spanning tree network, 2 channels will have transactions rate ( and ). All the other channels will have a transaction rate of . Therefore, the ratio of maintenance cost per second, between and the optimal spanning tree, according to corollary 7, is at least:
Since this expression is converging to infinity, for every value of there exists , such that . We will complete the proof by showing that is an equilibrium for every .
It is clear that the nodes from the series has no interest to reconnect a channel connected with them, since their costs are fully payed by the remained nodes. and are symmetric, as well as and . It is clear these two pairs don’t benefit from reconnecting, with both external nodes or with each other.
A precise examination shows that all the agents have no interest for structure change. Therefore, is an equilibrium for every . ∎
7 Simulation Results
In this section we provide simulation results of more complex payment networks. Real-world transaction networks exhibit scale-free structure, and behave according to power-laws, e.g., in the distribution of degrees of vertices, and in transaction rates and amounts [beguvsic2018scaling]. One interesting question is whether in such cases, hubs perform better than a 2-approximation to optimal networks.
We compare three network structures in our simulations: the optimal maintenance cost spanning tree (Gomory-Hu tree) derived with our algorithms, hub topologies (around an optimal node), and a complete graph topology. The latter two lie on two extremes: a centralized hub around a major transactor, or a channel between every pair of agents.
We simulated a network with 100 agents. We created the demand matrix in a scale-free graph model: generating a random scale-free graph [li2005towards] between the agents (with a certain power-law coefficient), and setting a non-zero transaction rate for every pair of connected nodes. The non-zero transaction Poisson rates, were also generated from a power-law distribution for different power-law exponents.
We checked the ratio of expected blockchain records per second (RPS) between agents in each of the three scenarios (a complete graph, a hub, and an optimal spanning tree).
As we can see in figure 3, a complete graph topology is becoming more efficient as the transaction demands’ centrality grows. This is because with a more centralized transaction demand graph, routing over a complete graph is closer to hub-routing. Moreover, it seems that in the majority of cases, a hub network achieves better results than the tight 8 RPS approximation (2-approximation in the total maintenance cost). Further simulations show that transaction-rates’ power-law coefficient has no affect over efficiency.
In the full version, we present additional simulation results in the same scale-free model, including simulations of the greedy game, and the price of anarchy. We show that power-law coefficients of the degree and transaction rates have no major affect on the probability of stability of optimal spanning trees, or on the price of anarchy.
8 Discussion and Future Work
In this paper we defined a model for the maintenance cost of payment networks, and provided results on liquidity allocation when transaction demands are symmetric, and for optimal spanning trees. We further showed that spanning trees (and in particular hubs) provide a constant approximation for any optimal graph and routing system. One of the weaknesses of our model is in the assumption of balanced channels. Some channels in payment networks might be unbalanced, and therefore their lifetime may be closer to a linear factor of the liquidity they hold, which will imply blockchain costs will be higher. Similarly, the question of different routing algorithms for asymmetric demands matrices, remains open and should be the focus of future work.
Another aspect that is still open, is the theory of online algorithms for balancing channels. Although some articles presented algorithms for this problem [balancingAlgorithm]
, they have not proposed a closed model for effectiveness estimation. These balancing algorithms can reduce the channels lifetime significantly, and the analytical estimation question still remains open.