SyncPCN/PSyncPCN: Payment Channel Networks without Blockchain Synchrony
O. Ersoy (TU Delft - Cyber Security)
Jeremie Decouchant (TU Delft - Data-Intensive Systems)
Satwik Prabhu Kumble (TU Delft - Data-Intensive Systems)
S. Roos (TU Delft - Data-Intensive Systems)
More Info
expand_more
Other than for strictly personal use, it is not permitted to download, forward or distribute the text or part of it, without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license such as Creative Commons.
Abstract
Payment channel networks (PCNs) enhance the scalability of
block-chains by allowing parties to conduct transactions off-chain, i.e,
without broadcasting every transaction to all blockchain participants.
To conduct transactions, a sender and a receiver can either establish a
direct payment channel with a funding blockchain transaction or leverage
existing channels in a multi-hop payment. The security of PCNs usually
relies on the synchrony of the underlying blockchain, i.e., evidence of
misbehavior needs to be published on the blockchain within a time limit.
Alternative payment channel proposals that do not require blockchain
synchrony rely on quorum certificates and use a committee to register
the transactions of a channel. However, these proposals do not support
multi-hop payments, a limitation we aim to overcome.
In this paper, we demonstrate that it is in fact impossible to
design a multi-hop payment protocol with both network asynchrony and
faulty channels, i.e., channels that may not correctly follow the
protocol. We then detail two committee-based multi-hop payment protocols
that respectively assume synchronous communications and possibly faulty
channels, or asynchronous communication and correct channels. The first
protocol relies on possibly faulty committees instead of the blockchain
to resolve channel disputes, and enforces privacy properties within a
synchronous network. The second one relies on committees that contain at
most f faulty members out of 3f +1 and successively
delegate to each other the role of eventually completing a multi-hop
payment. We show that both protocols satisfy the security requirements
of a multi-hop payment and compare their communication complexity and
latency.