The world of finance and decentralized applications has undergone a revolution with the advent of blockchain technology, resulting in the emergence of various blockchain platforms. This underscores the necessity for conducting exchanges between different blockchains to facilitate blockchain interoperability. However, the challenges linked to the scalability of individual blockchains pose negative implications during inter-chain exchanges. A prominent solution to tackle the scalability challenge in a blockchain, particularly in terms of throughput, is a Payment Channel Network. However, creating such a solution for facilitating inter-blockchain exchange presents significant challenges, as it demands atomic state updating on two different blockchains. In this paper, we introduce a novel, fully distributed mechanism for establishing cross-chain payment channels (CCPC), designated as Tombolo protocol, designed to operate seamlessly across different blockchains. Furthermore, we provided the sequence of steps that the user should follow to facilitate further exchange without contacting either of the involved blockchains. Additionally, we showcase its resilience against malicious behaviour, specifically in situations where a participant attempts to close the channel using an outdated state or becomes inactive during exchanges. Furthermore, we have demonstrated the viability of Tombolo by implementing it on an Ethereum Virtual Machine-based blockchain using Solidity v0.8.0 based smart contracts. Through comprehensive experimentation and evaluation, we illustrate that CCPC can be established with approximately 2.5 times the gas utilization and around twice the time overhead compared to Raiden, a state-of-the-art intra-chain channel.

Cryptocurrency networks are a promising infrastructure for pseudonymous online payments. However, low throughput has prevented their widespread acceptance. A promising solution to scale throughput is the Payment channel network (PCN), exemplified by the Lightning Network (LN), that uses a network of off-chain bidirectional payment channels between parties that wish to transact often. Since payments use the shortest paths with sufficient funds over this network, channel balances get exhausted in the direction transactions flow and eventually become unidirectional. This results in transactions failing and consequently a lower transaction success ratio. Our observations on the production LN show that over 63% of the channels lose over 80% of the channel balance in one direction over time, which makes the success ratio of a real-world workload drop from 71% to 29%. A unidirectional channel along a path results in a failure message back to the source that recomputes the path, excluding the failed channel and reattempts the transaction, thus adding to the completion latency even for those transactions that do complete.We propose REBAL, a distributed re-balancing mechanism, and a new routing scheme to address the above issues. REBAL maximizes the extent to which channels can be re-balanced across the entire network. REBAL addresses the completion latency issue by re-routing transactions from intermediate nodes around a unidirectional channel rather than propagating the failure back to the source.Our comprehensive evaluation of REBAL shows that the success ratio improves from 30.18% to 79.54% and success volume from 3.98% to 29.99% for a real-world workload derived from the Ripple network, without adversely impacting the transaction latency. Even at very high transaction rates, REBAL outperforms Lightning Network Daemon (LND- a Golang implementation of LN) (12%) with a success ratio of 43.76%.

A Blockchain system such as Ethereum is a peer to peer network where each node works in three phases: creation, mining, and validation phases. In the creation phase, it executes a subset of locally cached transactions to form a new block. In the mining phase, the node solves a cryptographic puzzle (Proof of Work-PoW) on the block it forms. On receiving a block from another peer, it starts the validation phase, where it executes the transactions in the received block in order to ensure all transactions are valid. This execution also updates the blockchain state, which must be completed before creating the next block. A long block validation time lowers the system's overall throughput and brings the well known Verifier's dilemma into play. Additionally, this leads to wasted mining power utilization (MPU).