Brick: Asynchronous Payment Channels

Abstract

Off-chain protocols (channels) are a promising solution to the scalability and privacy challenges of blockchain systems. Current proposals, however, require synchrony assumptions to preserve the safety of a channel, leaking to an adversary the exact amount of time needed to control the network for a successful attack. In this paper, we introduce Brick, the first off-chain construction that remains secure under network asynchrony and concurrently provides correct incentives. The core idea is to incorporate the conflict resolution process within the off-chain channel by introducing a rational watchtower committee. Hence, if a party wants to close a channel unilaterally, it can only get the committee's approval for the last valid state. Brick provides sub-second latency because it does not employ heavy-weight consensus. Instead, Brick uses consistent broadcast to announce updates and close the channel, a light-weight abstraction that is powerful enough to preserve safety and liveness to honest parties. Furthermore, we consider the permissioned model of blockchains, where the additional property of auditability might be desired for regulatory purposes. We introduce Brick+, an off-chain construction that provides auditability on top of Brick without conflicting with its privacy guarantees. We formally define the properties our state channel construction should fulfill, and prove that both Brick and Brick+ satisfy them. We also design incentives for Brick such that honest and rational behavior aligns for both the committee and the parties of a channel.1 This censoring ability is encompassed by the chain-quality property [19] of blockchain systems which is rightly bound to the synchrony of the network. 2 Liveness states that a transaction will be eventually included on-chain as long as it is provided to all honest parties for a long enough time period [19].

SoK: Communication Across Distributed Ledgers

“…We observe strong similarities with optimistic fair exchange protocols [35,34,62]. Specifically, watchtowers take action to enforce the commitment, if one of the parties crashes or synchrony assumptions do not hold, i.e., after a pre-defined timeout [105,38,128,37]. This construction was first introduced and applied to off-chain payment channels [89].…”

“…Model 3: Hybrid (Watchtowers) As an additional measure of security, TTPs can be introduced as a fallback to timelocks in case CCC participants experience crash failures, e.g. in form of a watchtower [105,38,128,37] that recovers otherwise potentially lost assets. This is specifically useful in the case of atomic swaps using Hased Timelock Contracts (HTLCs) [20, 93,3,144], when either party crashes after the hashlock's secret has been revealed.…”

Hashcashed Reputation with Application in Designing Watchtowers

“…Unlike Pisa, in DCWC, a watchtower gets paid only when it catches a fraud. In another research work, Avarikioti et al presented BRICK [35], a protocol that detects and prevents fraud before it appears on the blockchain. To this end, BRICK employs a committee of third parties called Wardens.…”

Cross-chain payment protocols with success guarantees

“…Herlihy et al [14] represent a cross-chain payment as a deal matrix M where M i, j characterises a transfer of some asset from participant i to participant j. They offer a timelock 2 protocol that requires synchrony, and a certified blockchain protocol that requires partial synchrony and a certified blockchain. However, the synchronous solutions of [24] and [14] do not consider clock drift, and for their partially synchronous solutions no success guarantees are established.…”