Since the advent of Bitcoin  in 2008, decentralized cryptocurrencies have gained great popularity over the last 10 years. The key innovation behind decentralized cryptocurrencies is the combination of consensus mechanisms and hash-linked chain of blocks. The use of consensus algorithms such as POW  and PBFT  makes it possible for all of its participants to maintain one single ledger without relying on any trusted third parties. The hash-linked chain of blocks, which is also called blockchain, boosts the computational requirements for adversaries trying to temper the block contents. Each miner running the POW consensus algorithm is required to solve a computationally expensive hash puzzle. The one who solves that puzzle was given the right to append a new block to the blockchain. Inspired by Bitcoin, other cryptocurrencies allowing users to develop and deploy their smart contracts, which are written in a Turing-complete programming language and support arbitrary complexity, have emerged. The most prominent cryptocurrency that supports the execution of smart contracts is Ethereum , which uses Solidity as the developing language of its smart contracts.
However, the deployment of globally consensus mechanism such as POW leads to serious scalability problem for decentralized cryptocurrencies. In its current state, Bitcoin can only support up to 67 transactions per second while Ethereum supports up to 20 transactions per second  and there is no order of magnitude growth of throughput with simple re-parameterization . Such a low transaction throughput is far from enough to support the widespread use of decentralized cryptocurrencies. In contrast, Visa processes up to 47,000 transactions per second .
Recently many attempts have emerged to mitigate the scalability problem of decentralized cryptocurrencies such as alternative consensus mechanisms [13, 25, 32], sharding [39, 26, 21], usage of trusted execution environment [24, 40], sidechain [2, 23], and payment channels/networks [7, 33, 29], etc. In particular, payment channels allow two parties to perform micropayments privately without broadcasting all of them to the blockchain, thus improving the scalability of cryptocurrencies significantly. To open a payment channel, two parties need to broadcast a funding transaction together with their deposits to the blockchain. After that, the payment channel is opened and the two parties can perform off-chain transactions securely without involving the blockchain. The funding capacity of the opened payment channel is equal to the total deposits of these two parties. The off-chain transactions change the distribution of funds among the two parties. At any point, each party can decide to close the payment channel by committing the final distribution of funds to the blockchain and get their cash back to their accounts.
Payment channels can be extended to payment networks. Instead of conducting an on-chain transaction or establishing an expensive payment channel, one could utilize the so-called routed payment, which routes the payment over multiple existing intermediary payment channels, to transfer coins to others. Efforts have been made to realize more efficient payment networks. For example, Sprites  reduces the worst-case collateral time for off-chain payments. Others [34, 28, 27, 35, 15] focus on improving aspects like concurrency, security, and privacy for the routing process.
Different from routing packets in traditional data networks such as TCP/IP network, routing transactions in a payment network faces more challenges. For example, routing a payment through multiple payment channels requires that each channel in the path has enough capacity for that payment. Moreover, it also requires each intermediary channel to lock a portion of that channel’s available collateral until the payment is settled. This, however, may lead to deadlock in a concurrent situation . Another problem is that intermediary nodes in a payment path may charge fees for routing a payment. Obviously, the longer the routing path, the more serious the above problems.
In this paper, we propose a novel off-chain system to shorten the payment path for the payment network. First, we propose the notion of channel hub, which is an extension of the payment hub . The participants of channel hub vary from individual nodes to payment channels. It allows coins to be directly transferred from one payment channel to another within the same channel hub. Thus, the channel hub can be viewed as a shortcut device for the underlying payment network. Compare with traditional node-level payment hub , the channel hub does not require additional collaterals and allows deposits in the established payment channels to be reused. Besides, it could also benefit more nodes at the same cost.
Second, based on the idea of channel hub, we design a new protocol named Boros to perform secure off-chain cross-channel transfers, which allows coins to be transferred between two parties. The Boros protocol guarantees that an honest party will not bear any financial losses despite strong adversarial capabilities. We not only present the security definition of Boros formally using the Universally Composable framework proposed by Canetti  but also prove its security according to our definition.
Third, we develop a proof-of-concept prototype running on Ethereum to demonstrate the feasibility of the Boros protocol. We measure the execution cost of each operation of the Boros protocol in payment networks of different sizes, and the experiemntal results show that our system can effectively reduce the average payment path length.
Organization of the paper
In Section II, we provide the necessary background and review the related studies on payment channels and payment networks. We introduce the main idea of the Boros protocol in Section III and present its formal security definition using the UC-framework is presented in Section IV (Due to the page limit, formal security proof of the Boros protocol is provided in Appendix A). Section V reports our proof-of-concept implementation and the evaluation results of the Boros protocol on Ethereum. Finally, we conclude this paper in Section VI.
Ii Background and Related Works
Ii-a Payment Channel
Payment channels [7, 33] allow parties to perform transfers privately without involving the blockchain, yet still keeping the ability for honest parties to reclaim its rightful amount of funds at any given time. Rather than committing each individual payment to the blockchain, two parties broadcast a funding transaction together with their deposits to the blockchain to open a payment channel. The funding capacity of the opened payment channel is equal to the total deposits of these two parties. After the payment channel is successfully opened, these two parties can perform off-chain transfers securely without touching the blockchain. The core of a payment channel protocol is to reach a consensus on the latest distribution of funds among the two parties and prevent malicious one from rolling back. Decker et al.  use the blockchain based time locks to invalidate obsolete distribution of funds while the Lightning Network  relies on punishment to enforce the latest distribution. At some point when any of them wishes to reclaim their funds, they broadcast a committing transaction, which contains the final distribution of funds, to the blockchain to close the payment channel and get their cash back to their account. Because all intermediary transfers are maintained only by these two parties and not required to be written to the blockchain, the payment channel can significantly increase the transaction throughput between two parties. The network bandwidth is the only limitation of transaction rate.
There are several improvement proposals on payment channel protocol. Burchert et al.  introduce a new layer called channel factory between the blockchain and the payment network so that it can quickly refund a payment channel. Green et al.  propose Bolt for constructing privacy-preserving payment channels while lowering the storage burden on the payment network. Dziembowski et al.  design Perun to establish a virtual payment channel between two parties that are connected by one intermediary. The virtual payment channel allows these two parties to perform transfers and do not require the intermediary to confirm every individual payment. This can significantly reduce latency and costs while improving privacy since the intermediary cannot observe the individual transfers between the two parties. The state channel  allows off-chain execution of arbitrary complex smart contracts. They also propose a novel technique to recursively build virtual state channel that spans multiple ledgers or virtual state channels.
Ii-B Payment Network
Instead of opening an expensive payment channel or conducting on-chain transactions, two parties without direct connection by a payment channel can utilize existing channels as intermediary links to route coins over the payment network [33, 29].
The most critical challenge when routing a payment through multiple intermediary channels is to enforce atomicity. That is, either the capacity of all intermediary channels in the path is updated or none of them is changed. To securely conduct transfers across multiple payment channels, the Lightning Network  adopts a technique called Hash Time-Lock Contract (HTLC). An HTLC is a conditional contract where the condition is enforced by the blockchain so it does not require trust in any participant in the network. This contract locks a portion of coins that can be released by its receiver only if the condition is fulfilled or returned to its owner if the contract times out. When routing a payment over the payment network, the receiver generates a secret value R and sends the hash value of R, denotes as where , to all intermediary nodes in the path. Each intermediary channel then sets up an HTLC using the hash value to lock a portion of its coins, which is equal to the payment amount plus some optional routing fees. Finally, the receiver discloses the secret value R to finish that payment and release the locked coins at each intermediary channel.
Recent studies have further improved the payment networks. Sprites  reduces the worst-case collateral time for off-chain payments. Malavolta et al.  proposes the first non-blocking protocol for the payment network, where at least one out of a set of concurrent payments can finally complete, and gives an in-depth discussion on the trade-off between privacy and concurrency. Revive 
is the first rebalance scheme for the off-chain payment network, which enables a set of members in a skewed payment channel network to safely shift balances between their payment channels to reach a balanced state. There are also several works that focus on improving efficiency and privacy of the routing process in the decentralized payment network such as Flare, SilentWhispers , and SpeedyMurmurs .
Ii-C Payment Hub
TumbleBit  introduces the concept of payment hub which allows a payer to perform secure off-chain payment to a set of payees within the same payment hub. Payments are performed off-chained with the help of an untrusted intermediary called the Tumbler. It guarantees that no one, not even the Tumbler can violate anonymity and link a payment from its payer to its payee. TumbleBit is fully compatible with Bitcoin protocol. However, TumbleBit requires that the Tumbler opens a directed payment channel with each participant. This, however, would lead to fragmented collaterals and significantly complicate the operation of the payment hub.
Khalil et al.  propose NOCUST, which allows the collaterals of its participants to be centrally managed in bulk and thus significantly reduces the operating costs of the payment hub. A NOCUST payment hub consists of two fundamental components: an on-chain verifier contract and an off-chain operator server. The on-chain verifier contract serves as a trusted financial custodian. It maintains collaterals of all participants of the payment hub and is responsible for resolving disputes. The off-chain operator server executes every transfer and synchronizes with the on-chain verifier contract periodically to keep consistency. NOCUST guarantees that an honest participant can always maintain custody of its funds and its enacted transfers can be finally delivered.
However, the node-level payment hub does not allow reusing the deposits in the established payment channels. If a node wishes to join in a payment hub, it has to come up with additional collaterals instead of reusing existing ones in its payment channels. In this work, we extend the concept of the payment hub to channel hub, whose participants vary from individual nodes to payment channels. It allows transferring coins from one payment channel to another within the same channel hub. After joining a channel hub, the deposit of a payment channel can be used for both cross-channel transfers and traditional in-channel transfers. It is worth noting that compared with the payment hub, the channel hub can benefit more nodes in the same cost. More precisely, both the payment hub and the channel hub require one on-chain transaction for a participant to join in. However, since the participant of the channel hub is payment channel, it allows both parties of the payment channel to benefit from the channel hub.
Iii Main Construction Idea
Iii-a Channel Hub
We adopt the construction of NOCUST  and extend the concept of payment hub to channel hub, which allows transferring coins from one payment channel to another within the same channel hub. Here, we only give a general description of the payment hub and describe the differences between the payment hub and our channel hub. For further details, we refer the reader to .
A payment hub is composed of two basic components: an on-chain verifier smart contract and an off-chain operator server . The off-chain operator server is an interactive server that acts as a financial intermediary, i.e., all off-chain transfers performed within the payment hub need to be relayed and ratified by the operator server. Meanwhile, the operator server maintains a local ledger which contains the balance of its participants and all information related to the transfers performed through . The information in is periodically committed to the global ledger , which is maintained by the on-chain verifier , to keep global consistency. Apart from maintaining the global ledger , the on-chain verifier also serves as a dispute resolver in case of malicious participants or even dishonest operator server to guarantee the balance custody of honest participants and enforce enacted transfers.
The core of the payment hub is a mapping: , where the fixed-length binary string denotes the account of each participant and denotes its balance. The key observation motivating our extension is that the accounts of both individual nodes (known as external account) and payment channels (known as contract account) share the same address space. In other words, both of the external account and the contract account are represented by a fixed-length binary string . Thus, our extension can be simply accomplished by letting denote the contract account of the payment channel and denote its funding capacity. Concretely, we modify the Merklelized interval tree data structure used in NOCUST  so that each leaf of the tree stores the information corresponds to a payment channel , which mainly consists of the channel contract account , the funding capacity , and the last update that channel involved in.
Iii-B Informal Description of Boros Protocol
In this section, we informally describe the basic idea of Boros protocol, which uses the channel hub to perform secure point-to-point cross-channel transfers. The Boros protocol is designed to prevent any honest node from losing funds despite strong set of adversarial capabilities.
Suppose A wishes to transfer coins to B. This can be done by first transferring coins from channel to channel using the channel hub, and then updating the distribution of deposits in channel and , so that and , while the balances of C and D remain unchanged. The key issue is to enforce balance consistency in the whole process.
We first describe the whole process of cross-channel transfer in case all parties are honest. Figure 1 shows the messages flow of the protocol. We assume that both channel and channel have already joined in the same channel hub . The Boros protocol consists of three phases, namely the prepare, capacity transfer, and in-channel update phase.
In the prepare phase, A sends a message to C, indicating that A wishes to transfer his coins from channel to channel while keeping C’s balance on unchanged. The word “pcc” is the abbreviation for “Prepare Cross-Channel transfer”. When C receives , C will check the validity of message and broadcast a message to both A, B, and D, indicating that C agrees with that cross-channel transfer. The word “gcc” is the abbreviation for “Grant Cross-Channel transfer”. The interactions between B and D are handled analogously. At the end of the prepare phase, A, C, B and D should hold the messages and .
In the capacity transfer phase, A and B, on behalf of channel and channel respectively, perform the coin transfer between channel and channel via the channel hub . Here we follow the operations of NOCUST . First, A sends to the off-chain operater server . then checks the validity of , notifies B and waits for B’s receipt. When B is notified by , it will also verify the validity of and then reply with a signed receipt. Upon receiving B’s receipt, confirms the IOU execution and sends to both A and B. At that point, the capacity transfer phase is completed. The funding capacity of channel decreases by and increases by .
In the in-channel update stage, both channel and channel need to update the distribution of balance to keep consistency. Concretely, in channel , A’s balance should be decreased by while C’s balance remains unchanged; in channel , B’s balance should be increased by while D’s balance remains unchanged. Taking channel as an example, in this phase, A sends C a message indicating the result of the capacity transfer phase to C. The word “icu” stands for “In-Channel Update”. When the capacity transfer phase successes, the message will contain information about the decrease on A’s balance. Otherwise, will tell C not to change A’s balance. Upon receiving the , C checks the validity of that message then reply with a confirmation . The interactions between B and D are handled in a similar way and then the whole transfer is completed.
Iii-C Security Properties
In this section, we describe the threat model and the security properties of our protocol.
We assume the presence of irrational adversary willing to lose some or even all of its funds to cause honest parties to bear financial losses.
This irrational adversary may take control of some or even all but one of the participants involved in a cross-channel transfer. The internal state and all of the following communications of the corrupted party are exposed to the adversary. Besides, the adversary may send arbitrary messages on behalf of the corrupted party.
On the other hand, we assume that the communication channels between honest parties and the integrity of the honest parties’ identity can not be corrupted by the adversary.
Against the above threat model, our protocol guarantees the following security properties:
Consensus on channel hub enrollment and withdrawal. Our protocol guarantees that honest parties can always reach a consensus on whether a payment channel has joined in or withdrawn from a channel hub.
Consensus on channel capacity. Our protocol guarantees that honest parties can always learn the funding capacity of their payment channels. That is, an honest party can always learn the result of every cross-channel transfer involving it.
Balance security. Intuitively, balance security guarantees that an honest party will not lose any of his coins despite strong adversarial capabilities, i.e., an honest party will not bear financial losses even when all other participants involved in a cross-channel transfer are malicious.
Iii-D Concise Proof of Misbehavior
We now investigate what happens if some of the parties are malicious. Let’s first consider the prepare phase, whose main purpose is to reach an agreement about the following transfer among A, C, B, and D. That is, all of these four parties should receive both and at the end of this phase. If there exist malicious parties that do not send or reply messages, then there must be someone failed to collect both of these two messages. Now we discuss the following cases: (1) A cannot obtain both of these messages. (2) B fails to collect both of these messages. (3) C or D cannot collect both of these messages.
For case (1), the consequences are obvious. If A cannot collect both and , then he will fail to construct the message in next phase, which leading to the termination of the whole transfer. For case (2), B is quite tolerant since B can still get and from the when he got notified by the channel hub .
The case (3) is much more complicated. In this case, C or D cannot determine whether this transfer is prepared to be performed. In the worst case, they fail to learn whether the transfer is performed or not. In order to eliminate the feasibility of being inconsistent, we do not allow a party to involve in multiple transfers at the same time. Besides, we introduce to denote the maximum transfer duration. When a transfer starts, a party should learn the result before . Otherwise, it will complain to the channel hub. For example, if C cannot get the result of that transfer from A, then he waits until expires and sends a force-reply message to . Once receiving message , informs A about C’s complaint, asking A to provide the result within a fixed time . If A replies with a valid containing right amount of funding capacity of channel in time, then forwards to C such that C can proceed. Otherwise, considers channel as unresponsive and then closes it, refunding their cash according to the result of that cross-channel transfer.
In the capacity transfer phase, coins are transferred from channel to channel via the channel hub . NOCUST  guarantees that an honest party P can always maintain custody of its funds and ensure that its enacted transfers are correctly delivered within the hub. Such guarantees hold for our channel hub under the same attacker model. In a nutshell, NOCUST allows a party P to open the so-called “balance update challenge” and “transfer delivery challenge” to the on-chain verifier contract to enforce secure guarantees. The former challenges against the integrity of P’s balance and the latter challenges against the integrity of an off-chain transfer deliver in the hub. For further details on security analysis, we refer the reader to .
In the in-channel update phase, both channel and channel need to update its distribution of balance to keep consistency. Possible exceptions that may occur in this phase include: (1) A is dishonest and does not send the result to C; and (2) C is malicious and does not reply A with confirmation . For case (1), A is dishonest and deliberately conceals the result of the capacity transfer phase from C, and hence C is unable to determine the funding capacity of channel . As discussed in the prepare phase, in this situation, C simply waits until expires and then complain to . For case (2), C gets from A but doesn’t reply with confirmation . This situation is similar to (1). To resolve this issue, A just waits until expires and then contacts to enforce C’s confirmation.
Iv Formal Description
Universally Composable model
In the UC model , the security of a protocol is defined by comparing the execution of the protocol in the real-world model with an ideal process. In real-world model, the n-party protocol is executed by a set of parties , which is modeled as probabilistic polynomial time (PPT) machine. In real-world there exists an adversary , who can corrupt some of these parties such that the internal state and all the future actions of the corrupted party are totally controlled by the adversary. For simplicity, we only consider static corruption, which means that the adversary must decide which parties to corrupt at the beginning of protocol execution. Both the parties and the adversary receive inputs and output to the environment , which is used to model all factors that are external to the current protocol execution. In the ideal-world, the environment interacts with the ideal functionality via the so-called dummy parties, who simply forward messages from to and back. The counterpart of the adversary in the ideal-world is the simulator . Then we say a protocol is considered secure if the environment can not distinguish whether it is interacting with and running in real-world model or with and ideal functionality in ideal process.
For the sake of simplicity, we assume a synchronous communication model in which all parties proceeds in synchronous round and all parties start simultaneously. In this model, every party can send messages to all other parties and the message sent in round arrives at its destination at the beginning of round . When it comes to the ideal functionalities, we simply assume that the computation of ideal functionalities and communication with ideal functionalities are instantaneous. The synchronous communication model can be achieved by a global clock functionality. For further details, we refer to [17, 20, 16].
The ledger functionality
Following , we model the global ledger as an ideal functionality . The internal state of consists of a public-accessed account space denoted as , where denotes either an external account or contract account, and denotes the balance of account . The ledger functionality provides the following interface:
transfer, which allows to transfers coins from account to via sending message .
To simplify notation, we assume that every ideal functionality has a special account . When we say that the ideal functionality receives a message together with coins from A, we actually mean that upon receiving message , the ideal functionality sends a message to . Similarly, when we say that the ideal functionality sends coins back to A, we actually mean that sends a message to . The transfer interface also allows the simulator to simulate the “irrational” parties who are willing to sacrifice their funds to cause honest parties to lose some or all of their funds. In such cases, we simply let to transfer coins from the account of the irrational party to the honest one. We note that the ideal functionality mentioned above only captures the basic ideal concept of the global ledger for the convenience of exposition. A more accurate and realistic formalization of the global ledger can be found in .
The channel hub functionality
In Figure 2, we outline the ideal functionality of the channel hub . The channel hub functionality maintains a channel space denoted as , where denotes the contract account of channel , and denotes the funding capacity of channel . When we say that a payment channel is marked as joined, we mean that an entry corresponded to channel is added to . Similarly, when we say that a payment channel is marked as withdrawn, we mean that the entry corresponded to channel is removed from . The channel hub functionality provides the join and withdraw interfaces for other ideal functionalities and the interface transfer for parties. (1) join: When triggered by a joining request together with coins from an ideal functionalities, where denotes the funding capacity of the channel , the ideal functionality marks the channel as joined. (2) transfer: Upon receiving an iou request from A and a signed receipt from B, moves coins from channel to . (3) withdraw: a payment channel can withdraw from a channel hub at any time by sending a withdrawal request to . The ideal functionality will eventually send coins back to the contract account of and marks channel as withdrawn.
The contract functionality
In Figure 4, we outline the contract functionality , which is the ideal functionality of the payment channel contract deployed on the blockchain. The contract functionality maintains the set of active contract instance. Each contract instance corresponds to a payment channel. A contract instance is created when a payment channel is opened and removed when the payment channel is closed. The contract functionality provides open, join, withdraw, and close interfaces for parties.
UC definition of security
Let Boros be a protocol with access to the global ledger functionality , the channel hub ideal functionality , and the contract functionality . The output of an environment interacting with Boros and an adversary on security parameter , and auxiliary input is denoted as . In ideal world, we use to denote the output of runing with the ideal functionality and the simulator .
Let be a security parameter and be an auxiliary input, Boros be a protocol runing in the (, , )-hybrid world. We say that protocol Boros realize the ideal functionality if for every adversary there exists a simulator such that for all PPT environments :
where “” denotes computational indistinguishability.
Iv-a Ideal Functionality for Boros
The ideal functionality , as shown in Figure 3, maintains two channel spaces. One of the two channel space consists of payment channels that have not yet joined the channel hub. We denote it as , where denotes the contract account of channel , denotes the funding capacity of channel , and denotes the distribution function of its total funds corresponds to the version number . For example, in channel , we use to denotes A’s balance and to denote C’s balance corresponds to the version number . We note that when it does not affect the clarity of expression, we often omit the superscript. Moreover, we always have and . The monotonically increasing version number is used for tracing every transfer in a payment channel and is initially set to 1. The other channel space, which is denoted as , consists of payment channels that have already joined the channel hub. When we say that a payment channel is marked as joined, we mean that the channel has been moved from channel space to . Similarly, a payment channel is marked as withdrawn means that the channel has been moved from back to .
The ideal functionality offers the following interfaces for the parties: (1) open a payment channel between two parties. When receiving both the opening requests from A and C together with and coins respectively, a payment channel of funding capacity is opened. (2) in-channel transfer. A two-phase process for performing off-chain transfers. When triggered by A with an update request, asks C for the confirmation of that transfer. Once C replies with his confirmation, updates the distribution function for channel and outputs . (3) join a channel hub. A payment channel can join a channel hub only when both parties reach an agreement and the payment channel has not yet joined any channel hub. When triggered by A with a joining request, asks C for the confirmation of that joining. Once C replies with his confirmation, marks as joined and notifies about the result through the message (joined). (4) cross-channel transfers. It can be performed only between two payment channels that have already joined in the channel hub. This process is divided into three phases. In the prepare phase, both channel and should reach an agreement on this transfer. In the capacity transfer phase, if receives both the iou message from A and the receipt from B, then updates its internal state such that the funding capacity of channel decreases by coins and increases by the same amount. We note that at the end of this phase, the distribution function of both channel and remains unchanged. The last phase is triggered by in-channel update requests from A and B respectively. then asks C and D for their confirmation, which finally results in the changing of the distribution function of channel and . (5) withdraw from channel hub. A payment channel can withdraw from the channel hub only when the payment channel has already joined in the channel hub. When receiving the withdrawal request from A or C, finally marks channel as withdrawn and outputs . Our ideal functionality guarantees that an honest party will always manage to withdraw his payment channel from the channel hub in a fixed time. (6) close a payment channel. When triggered by a closing request from A or C, finally refunds A with coins and C with coins within three rounds. Our ideal functionality guarantees that an honest party will always manage to close the payment channel and get refunded in a fixed time.
Now we discuss how our ideal functionality satisfies the security properties mentioned in Section III-C.
Consensus on channel hub enrollment and withdrawal. Once a payment channel joins in or withdraws from a channel hub, the ideal functionality would notify all parties of the results through messages (joined), (withdrawn) or (join-failed). Thus it is straightforward to see that this property always holds.
Consensus on channel capacity. The initial funding capacity of a payment channel is settled and notified by the ideal functionality when successfully opening the channel. Besides, an honest party is guaranteed to be notified by the of the results of capacity transfers through message . Thus, an honest party can always learn the funding capacity of its payment channels.
Balance security. The analysis of balance security consists of two points. One is the consensus on the funding capacity of the payment channel. The other is the consensus on the final distribution function of the payment channel. The former is discussed above. For the distribution function, always guarantees that the distribution function with larger version number always wins when closing the payment channel. Thus, an honest party with the latest distribution function is guaranteed to be paid out with the correct amount of coins when closing a payment channel.
Iv-B The Boros Protocol
Now we formally describe the Boros protocol, which consists of the contract functionality as shown in Figure 4 and the specification of the behavior of all involved parties as shown in Figure 5 and Figure 6.
We firstly discuss those operations that share with traditional payment channels, which are shown in Figure 5. To open a payment channel, A deploys a new instance of contract together with coins. Upon construction, the contract notifies C with the opening request. Once the contract gets a confirmation from C together with coins in round 2, then the payment channel is opened. Otherwise, the contract refunds A with coins and outputs .
Once the payment channel is opened, A and C can perform in-channel transfers without involving the blockchain. Firstly, A sends an update request to C, which contains a new distribution function . When C receives that request, it should check the validity of the capacity of channel , that is, should always be equal to the latest capacity of channel . If this is the case, then C sends a message to the environment , asking if it agrees for an update. If the environment responds with , then C sends A with a confirmation to complete that in-channel transfer. We emphasize that the validity check of channel capacity is necessary since the funding capacity of our payment channel could be changed by cross-channel transfers.
To close a payment channel , A sends a closing request containing his last distribution function to the contract instance . Upon receiving the closing request from A, the contract then forwards that request to C. If next round C replies with his last distribution function , then the contract chooses the latest one, which is denoted as where , and sends coins back to accounts of both A and C according to . Otherwise, the contract sends coins back to accounts of both A and C according to .
Then we discuss those extended operations, which are shown in Figure 6. We start with the joining process. To join a channel hub, A sends a message containing the target channel hub instance , the funding capacity , the latest distribution function of channel , and A’s signature on that message to C. Upon receiving the joining request from A, C sends a message to the environment , asking if it agrees for that joining. If the environment responds with , then C sends the joining request containing both A and C’s signature to the contract . Once the contract receives that signed joining request from C, it sends a joining request together with coins to the channel hub to finish the joining process. Otherwise, the joining procedure is considered failed.
Now we discuss the cross-channel transfer procedure, which is divided into three phases. In the first phase, A sends a message to C, indicating his intention to perform a cross-channel transfer, which moves coins using A’s balance in channel to channel via the channel hub . When C receives from A, he checks if the A’s balance in channel exceeds . If this is not the case, then C rejects the cross-channel transfer request. Otherwise, if C agrees with that transfer, then he attaches his signature on the to produce , which indicates C’s permission on that cross-channel transfer. Then C broadcasts the message to A, B, and D, and goes to the third phase. The interaction between B and D is handled analogously. In the capacity transfer phase, the initiator A sends an iou message to the channel hub . As mentioned in the channel hub functionality , the channel hub forwards the iou request to B, obtains B’s signed receipt, and then executes that transfer. The execution will cause the funding capacity of channel to be decreased by coins and increased by the same amount. If the execution successes, then will notify both A and B about execution result through message . In the in-channel update phase, A sends the result of the second phase to C. The message sent by A should include a new distribution function such that and , and the signed result from the operator server of channel hub . Upon receiving this message, C checks its validity and replies with a confirmation to finish the cross-channel transfer.
Finally, we discuss the withdrawal procedure. To withdraw from the channel hub, A sends a message containing the latest funding capacity and distribution function of channel to the contract . Upon receiving the withdrawal request from A, the contract notifies to C of that withdrawal request. Once receiving a signed reply from C, the contract sends a withdrawal request to the channel hub to finish the withdrawal process.
Iv-C Security Definition
Now we formally state the security of our Boros protocol. Due to the page limit, formal security proof is provided in Appendix A.
Protocol Boros securely realizes functionality in the model.
V Implementation And Evaluation
We implement the Boros protocol on Ethereum and measure the execution cost of each operation in the Boros protocol. Note that our current implementation aims at demonstrating the feasibility of the Boros protocol and we will further optimize it in future work. Moreover, we simulate off-chain payment networks of different sizes and prove that our construction can effectively shorten the average transaction path length.
Ethereum uses gas to measure the amount of computational resource used to execute certain operations. Every instruction executed by the Ethereum Virtual Machine (EVM) costs a certain amount of gas. There is no fixed price of the conversion between gas and Ether. It is up to the sender of a transaction to specify a gas price, which affects the willingness of the miners to process the transaction. A lower gas price results in longer waiting time for a transaction to be mined. The average gas price is typically on the order of about 20 Gwei (or Ether). When we prepar this paper, the exchange rate of the Ether against the US dollar is 1:243.2. That is, .
Our evaluation adopts the following criteria: the number of on-chain transactions, the execution cost measured in gas, Ether, and USD, the number of off-chain messages, and the number of signatures, which is dominant for both message length and computational complexity. Table I shows the execution cost of each operation under these metrics.
|# of Nodes||PN-FW||PH-FW||CH-FW||-FW||-FW||PN-SM||PH-SM||CH-SM||-SM||-SM|