Figure 1 - uploaded by Vibhaalakshmi Sivaraman
Content may be subject to copyright.
Bidirectional payment channel between Alice and Bob. A blue shaded block indicates a transaction that is committed to the blockchain.

Bidirectional payment channel between Alice and Bob. A blue shaded block indicates a transaction that is committed to the blockchain.

Source publication
Preprint
Full-text available
With the growing usage of Bitcoin and other cryptocurrencies, many scalability challenges have emerged. A promising scaling solution, exemplified by the Lightning Network, uses a network of bidirectional payment channels that allows fast transactions between two parties. However, routing payments on these networks efficiently is non-trivial, since...

Contexts in source publication

Context 1
... are the building blocks of a payment channel network. A bidirectional payment channel allows a sender (Alice) to send funds to a receiver (Bob) and vice versa. To open a payment channel, Alice and Bob jointly create a transaction that escrows money for a fixed amount of time [47]. Suppose Alice puts 3 units in the channel, and Bob puts 4 ( Fig. 1). Now, if Bob wants to transfer one token to Alice, he sends her a cryptographically-signed message asserting that he approves the new balance. This message is not committed to the blockchain; Alice simply holds on to it. Later, if Alice wants to send two tokens to Bob, she sends a signed message to Bob approving the new balance (bottom ...
Context 2
... 1). Now, if Bob wants to transfer one token to Alice, he sends her a cryptographically-signed message asserting that he approves the new balance. This message is not committed to the blockchain; Alice simply holds on to it. Later, if Alice wants to send two tokens to Bob, she sends a signed message to Bob approving the new balance (bottom left, Fig. 1). This continues until one party decides to close the channel, at which point they publish the latest message to the blockchain asserting the channel balance. If one party tries to cheat by publishing an earlier balance, the cheating party loses all the money they escrowed to the other party ...
Context 3
... just balance information to differentiate paths. As a result, Waterfilling's performance degrades at low capacity compared to Spider which takes into account queuing delays. Size of Successful Payments. Spider's benefits are most pronounced at larger transaction sizes, where packetization and congestion control helps more transactions complete. Fig. 10 shows success ratio as a function of transaction size. We use mean channel sizes of 4000e and 16880 e for the synthetic and real topologies, respectively. Each shaded region denotes a different range of transaction sizes, each corresponding to about 12.5% of the transactions in the workload. A point within a range represents the ...
Context 4
... the transactions in the workload. A point within a range represents the average success ratio for transactions in that interval across 5 runs. Spider outperforms LND across all sizes, and is able to route 5-30% more of the largest transactions compared to LND. Impact on Latency. We anticipate Spider's rate control mechanism to increase latency. Fig. 11 shows the average and 99 th percentile latency for successful transactions on the Lightning topology as a function of transaction size. Spider's average and tail latency increase with transaction size because larger transactions are multiplexed over longer periods of time. However, the tail latency increases much more than the average ...
Context 5
... merchant nodes receive more. To simulate this, we add 5 DAG payment graphs ( §7.1) to circulation payment graphs, varying the relative weight to generate effectively 5%, 20% and 40% DAG in the total demand matrix. We run all schemes on the Lightning topology with a mean channel size of 16880e; results on the synthetic topologies are in App. E.3. Fig. 12 shows the success ratio and normalized throughput. We immediately notice that no scheme achieves the theoretical upper bound on throughput (i.e., the % circulation demand). However, throughput is closer to the bound when there is a smaller DAG component in the demand matrix. This suggests that not only is the DAG itself unroutable, it ...
Context 6
... and (ii) a traffic demand (X + Y ) containing 20% DAG for 2000s followed by the circulation X for 1000s after that. Here, each sender sends 200e/s of unit-sized transactions in X. We observe a time series of the normalized throughput over the 3000s. The mean channel size is 4000e and 16990e for the synthetic and real topologies respectively. Fig. 13 shows that Spider achieves 100% throughput (normalized by the circulation demand) at steady state for the pure circulation demand on all topologies. However, when the DAG component is introduced to the demand, it affects the topologies differently. Firstly, we do not observe the expected 80% throughput for the circulation in the ...
Context 7
... reallocates funds between its payment channels to equalize their available balance. The frequency of rebalancing for a router, is defined by the number of successful transaction-units (in e) between consecutive rebalancing events. In this model, the frequency captures the on-chain rebalancing cost vs. routing fee trade-off for the router. Fig. 14 shows the success ratio and normalized throughput achieved by different schemes when rebalancing is enabled for the traffic demand with 20% DAG from Fig. 12, or Fig. 13. Spider is able to achieve 90% success ratio even when its routers rebalance only every 10,000e routed while LND is never able to sustain more than 85% success ratio ...
Context 8
... of successful transaction-units (in e) between consecutive rebalancing events. In this model, the frequency captures the on-chain rebalancing cost vs. routing fee trade-off for the router. Fig. 14 shows the success ratio and normalized throughput achieved by different schemes when rebalancing is enabled for the traffic demand with 20% DAG from Fig. 12, or Fig. 13. Spider is able to achieve 90% success ratio even when its routers rebalance only every 10,000e routed while LND is never able to sustain more than 85% success ratio even when rebalancing for every 10e routed. This is because LND deems a channel unusable for 5 seconds every time a transaction fails on it due to lack of funds and this ...
Context 9
... splitting. This implies that when using Spider, routers need to pay for only one on-chain transaction typically costing under 1e [7] for every 10,000e routed. Thus, for a router to break even, it would have to charge 1e for every 10000e routed. This translates into significantly lower routing fees for endusers than today's payment systems [12]. Fig. 14 also captures the same result in the form of the best offloading or number of off-chain PCN transactions per blockchain transaction achieved by each algorithm. Transactions that fail on the PCN as well as rebalancing transactions are counted towards the transactions on the blockchain. Spider is able to route 7-8 times as many ...
Context 10
... of Paths. We vary the type of paths that Spider uses by replacing edge-disjoint widest paths with edge-disjoint shortest paths, Yen's shortest paths [61], oblivious paths [49] and a heuristic ap- Figure 15: Performance of Spider as the type of paths considered per sender-receiver pair is varied. Edgedisjoint widest outperforms others by 1-10% on the Lightning Topology without being much worse on the synthetic topologies. ...
Context 11
... sender-receiver pair is varied. Edgedisjoint widest outperforms others by 1-10% on the Lightning Topology without being much worse on the synthetic topologies. proach. For the widest and oblivious path computations, the channel size acts as the edge weight. The heuristic picks 4 paths for each flow with the highest bottleneck balance/RTT value. Fig. 15 shows that edge-disjoint widest paths outperforms other approaches by 1-10% on the Lightning Topology while being only 1-2% worse that edge-disjoint shortest paths on the synthetic topologies. This is because widest paths are able to utilize the capacity of the network better when there is a large skew (Fig. 7b) in payment channel ...
Context 12
... Topology while being only 1-2% worse that edge-disjoint shortest paths on the synthetic topologies. This is because widest paths are able to utilize the capacity of the network better when there is a large skew (Fig. 7b) in payment channel sizes. Number of Paths. We vary the maximum number of edge-disjoint widest paths Spider allows from 1 to 8. Fig. 16 shows that, as expected, the success ratio increases with an increase in number of paths, as more paths allow Spider to better utilize the capacity of the PCN. While moving from 1 to 2 paths results in 30-50% improvement in success ratio, moving from 4 to 8 paths has negligible benefits (¡5%). This is because the sparseness of the ...
Context 13
... for the flow. As a result, we use 4 paths for Spider. Scheduling Algorithms. We modify the scheduling algorithm at the per-destination queues at the sender as well as the router queues in Spider to process transactions as per First-In-FirstOut (FIFO), Earliest-Deadline-First (EDF) and Smallest-Payment-First (SPF) in addition to the LIFO baseline. Fig. 17 shows that LIFO achieves a success ratio that is 10-28% higher than its counterparts. This is because LIFO prioritizes transactions that are newest or furthest from their deadlines and thus, most likely complete especially when the PCNs is overloaded. Spider's rate control results in long wait times in the sender queues themselves. ...
Context 14
... the total amount of flow going through an edge is at most the total amount of flow in C * , which is ν(C * ). Next, to see that no balanced routing scheme can achieve a throughput greater than ν(C * ), assume the contrary and suppose there exists a balanced routing scheme SCH with a throughput Figure 19: Model of queues at a payment channel between nodes u and v. x uv and y uv denote the rates at which transaction-units for v arrive into and get serviced at the queue at u respectively. c uv is the capacity of the payment channel and q uv denotes the total number of transaction-units waiting in u's queue to be serviced. ...
Context 15
... (13) and (14) model how the queue sizes and fraction of packets marked, respectively, evolve at the routers. For a router u in payment channel (u, v), by definition y u,v is the rate at which transactions are serviced from the queue q u,v , while transactions arrive at the queue at a rate of x u,v ( Figure 19). Hence the net rate at which q u,v grows is given by the difference x u,v −y u,v . ...
Context 16
... without having to first estimate ∆. To see this, let˜xlet˜ let˜x u (t) = p∈P:(u,v)∈p x p (t) and˜x and˜ and˜x v (t) = p ∈P:(v,u)∈p x p (t) denote the rate of transaction arrival at u and v respectively. Similarly, let˜ylet˜ let˜y u (t) and˜yand˜ and˜y v (t) be the rate at which transactions are serviced from the queue at each of the routers (see Fig. 21 for an illustration). Eq. (32) can now be rewritten as˜xas˜ as˜x u (t)∆ + ...
Context 17
... i u (t) and i v (t) are the amount of funds that are currently locked at routers v and u respectively (Fig. 21). Since the funds used when servicing transactions at router u require ∆ seconds on average to become available at v, by Little's law the product of the average service rate˜yrate˜ rate˜y u (t) and average delay ∆ is equal to the average amount of pending transactions i u (t) at v. Thus, Eq. (34) follows from Eq. (33). However, each of ...
Context 18
... are the building blocks of a payment channel network. A bidirec- tional payment channel allows a sender (Alice) to send funds to a receiver (Bob) and vice versa. To open a payment channel, Alice and Bob jointly create a transaction that escrows money for a fixed amount of time [22]. Suppose Alice puts 3 units in the channel, and Bob puts four (Fig. 1). Now, if Bob wants to transfer one token to Alice, he sends her a cryptographically-signed message asserting that he approves the new balance. This message is not committed to the blockchain; Alice simply holds on to it. Later, if Alice wants to send two tokens to Bob, she sends a signed message to Bob approving the new balance (bottom ...
Context 19
... 1). Now, if Bob wants to transfer one token to Alice, he sends her a cryptographically-signed message asserting that he approves the new balance. This message is not committed to the blockchain; Alice simply holds on to it. Later, if Alice wants to send two tokens to Bob, she sends a signed message to Bob approving the new balance (bottom left, Fig. 1). This continues until one party decides to close the channel, at which point they publish the latest message to the blockchain asserting the channel balance. If one party tries to cheat by publishing an earlier balance, the cheating party loses all the money they escrowed ...

Similar publications

Preprint
Full-text available
With the innovation of distributed ledger technology (DLT), often known as blockchain technology, there has been significant growth of digital tokens in the form of cryptocurrencies, stablecoins, and central bank digital currencies. As the number of DLT networks increases, each with varying design characteristics, the likelihood that transacting pa...