Revive: Rebalancing Off-Blockchain Payment Networks

1 revive : Rebalancing O - blockchain Payment NetworksRami KhalilDepartment of Computer ScienceETH Zurich, GervaisDepartment of Computer ScienceETH Zurich, the transaction throughput of decentralized blockchainledgers such as Bitcoin and Ethereum has been an ongoing chal-lenge. Two-party duplex Payment channels have been designedand used as building blocks to construct linked Payment Networks ,which allow atomic and trust-free payments between parties with-out exhausting the resources of the a Payment channel, however, is depleted ( , becausetransactions were mostly unidirectional) the channel would needto be closed and re-funded to allow for new transactions. Users areenvisioned to entertain multiple Payment channels with di erententities, and as such, instead of refunding a channel (which incurscostly on-chain transactions), a user should be able to leverage hisexisting channels to rebalance a poorly funded the best of our knowledge, we present the rst solution thatallows an arbitrary set of users in a Payment channel network tosecurely rebalance their channels, according to the preferencesof the channel owners.

2 Except in the case of disputes (similar toconventional Payment channels), our solution does not require on-chain transactions and therefore increases the scalability of existingblockchains. In our security analysis, we show that an honest par-ticipant cannot lose any of its funds while Rebalancing . We nallyprovide a proof of concept implementation and evaluation for theEthereum CONCEPTS Security and privacy Distributed systems security;Secu-rity protocols; Computer systems organization Peer-to-peer architectures;KEYWORDSB lockchain; Payment channels; O -chain; Ledger; Ethereum; Smartcontracts;1 INTRODUCTIONP ermissionless blockchains such as Bitcoin and Ethereum, whereany participant can choose to join and leave at any moment, haveallowed to replace a trusted third party with a network of mutuallymistrusting peers.

3 Besides the transfer of monetary value, Ethereumsupports the execution of smart contracts, Turing complete codewhich is executed in consensus among all peers of the of the main costs of the decentralization of permissionlessblockchains is their performance. In its current state, Bitcoin forexample only supports up to 7 transactions per second clearlyinsu cient to grow to a mainstream Payment system. Becausethe simple re-parameterization of permissionless blockchains hasshown to not solve the scalability performance beyond 100 transac-tions per second [1], and alternative consensus mechanisms typ-ically introduce di erent trust assumptions [2 5], second layerpayment channels [6 9] have been channels aim to establish direct peer-to-peer paymentchannels that allow two parties to privately maintain and update atwo-party ledger.

4 The bene t is that their individual transactionsare not required to be written to the blockchain , while keeping aguarantee of being able to claim their rightful funds in the globalblockchain ledger at any given time. Payment channels have a fewlimitations, but should improve the transaction throughput of adecentralized ledger to the network bandwidth of the two peersparticipating in a Payment Networks [6,8] allow to perform payments betweenparties that are not immediately connected by a Payment linked payments utilize a chain of Payment channels as in-termediate links between two parties that wish to transact witheach other o -chain, without having to open a new Payment chan-nel or conduct an on-chain transaction. Several contributions aimto improve the performance characteristics of Payment [7], for example, aims to address the worst-case completiontime of an o -chain linked-transaction.

5 Flare [9] proposes routingstrategies that aim to optimize the amount of time taken on averageto nd a Payment fundamental aw of existing Payment channels howeverremains the inability to refund a Payment channelwithoutper-forming transactions on the blockchain . Once a Payment channel isdepleted, the channel needs to be closed and re-funded, requiring atleast two expensive on-chain transactions. Before refunding a chan-nel, users might rst opt to choose more expensive channel routes,which will increase the transaction costs over Payment channels(each hop in a Payment network receives a relay fee).This this work, we propose to the best of our knowledgethe rst Rebalancing scheme for o -chain Payment Networks . Oursolution enables a set of members in a Payment network to shiftbalances between their Payment channels safely.

6 Rather than to en-act previously mandatory on-chain channel closing and re-opening,our solution allows participants to safelyRevivea channel by real-locating o -chain the funds they have assigned to their paymentchannels. Rebalancing is naturally limited by certain restrictions onhow much can be reallocated, because we do not shift the depositsmade within a Payment channel but rather the credits that partic-ipants are entitled to. In our security analysis, we show that anhonest participant is guaranteed not to lose any of its funds main contributions of our work are as follows: To the best of our knowledge,Reviveis the rst rebalanc-ing scheme for Payment channels, that allows a user to510152025 Number of Payment Channels02004006008001000 Gas Costs (in 1000)Flawless revive Instance (Free)Disputed revive Instance (Upper Bound)Disputed revive Instance (Lower Bound)Naive Transactions (2 Per Channel)Naive Transactions (1 Per Channel)Disputed revive Instance (Schnorr Signatures Estimate)Figure 1:Revivereduces the costs of refunding paymentchannels (within the green area).

7 This gure shows the gascosts needed to(i)naively execute Rebalancing transactions(current practise),(ii)useReviveto perform a rebalancingwhile incurring the cost of dispute, and(iii)useReviveinthe best case without dispute (which is free).utilize any other of his channels for Rebalancing a particularchannel. If all participants of the Rebalancing are responsive ( hon-est), Rebalancing increasesthe transaction scalability of permissionless blockchains byreducing the frequency at which on-chain channel refund-ing is necessary. Simultaneously,Revivereduces the costsof Payment channels because it de-incentivises routing pay-ments through costly Payment routes when rebalancingof lower-priced channels and routes is feasible. Reviveis Payment channel agnostic, , it can be appliedto di erent underlying Payment Networks .

8 We expect mostpayment channels that operate using smart contracts to beviable candidates, such as Raiden [8]. We provide an implementation and evaluation ofRevivefor the Ethereum network , using the Sprites[7] our estimates,Reviveo ers users the opportunity to decreasethe costs of performing a Rebalancing of their Payment channelswhen compared to naively executing transactions that aim to di-rectly achieve a similar goal on the blockchain . We highlight thepossible savings our protocol can provide within the context of theEthereum blockchain in Figure 1 (we report the total costs). At best,our protocol providesfreerebalancing, and at worst, the disputepenalty is incurred, which is still lower than the fees associatedwith withdrawing from and refunding every involved channel us-ing two on-chain transactions.

9 The details behind the reasoning ofour estimates can be found in Section remainder of the paper is organized as follows. In Sec-tion 2, we provide the necessary background on permissionlessblockchains and Payment channel Networks . In Section 3 we presenttheReviveprotocol, while we analyze its security in Section 4. WediscussRevive s usability in Section 5. Our implementation andevaluation is presented in Section 6. We overview related work inthe area and contrast it to our solution in Section 7. We concludethe paper in Section BACKGROUNDIn this section, we provide the necessary background on permis-sionless blockchains such as Bitcoin and Ethereum, and discussexisting Payment channel Decentralized LedgersWith the inception of Bitcoin [10] in the year 2008 by a pseudonymSatoshi Nakamoto, for the rst time in history, the era of decentral-ized banking began.

10 Bitcoin allows mutually mistrusting peers totrade, without relying on a traditional trusted third party, such asa bank. Inspired by Bitcoin, other blockchains such as Ethereumsurfaced. Similar to Bitcoin, Ethereum is a decentralized databaserepresented as a chain of blocks ( , records), where each blockpoints to its predecessor in the chain. Ethereum, however extendedBitcoin s transaction language to a Turing complete programminglanguage to ease the development of so-called smart contracts ( for more details).The blockchain s main intention is to provide an electronic pay-ment solution that solves the double-spending problem. In thephysical world, it is not trivial to copy a monetary bill, while it istrivial to copy an electronic coin . The blockchain allows to verifywhether a coin has already been spent by a peer, and as such al-lows to solve the double-spending problem.