Sprites and State Channels: Payment Networks that Go Faster Than Lightning

Abstract

Bitcoin, Ethereum and other blockchain-based cryptocurrencies, as deployed today, cannot support more than several transactions per second. Off-chain payment channels, a “layer 2” solution, are a leading approach for cryptocurrency scaling. They enable two mutually distrustful parties to rapidly send payments between each other and can be linked together to form a payment network, such that payments between any two parties can be routed through the network along a path that connects them.

We propose a novel payment channel protocol, called Sprites. The main advantage of Sprites compared with earlier protocols is a reduced “collateral cost,” meaning the amount of money $\times$ time that must be locked up before disputes are settled. In the Lightning Network and Raiden, a payment across a path of $\ell$ channels requires locking up collateral for $\varTheta (\ell \varDelta )$ time, where $\varDelta$ is the time to commit an on-chain transaction; every additional node on the path forces an increase in lock time. The Sprites construction provides a constant lock time, reducing the overall collateral cost to $\varTheta (\ell + \varDelta ).$ Our presentation of the Sprites protocol is also modular, making use of a generic state channel abstraction. Finally, Sprites improves on prior payment channel constructions by supporting partial withdrawals and deposits without any on-chain transactions.

Appendix

1.1 A.1 Acknowledgements

This work is funded in part by NSF grants CNS-1801321 and CNS-1617676 and a gift from DTR Foundation.

1.2 A.2 Further Discussion

Supporting Fees. Participants who act as intermediaries in a payment path contribute their resources to provide a useful service to the sender and recipient. The intermediaries’ collateral is tied up for the duration of the payment, but the sender and recipient would not be able to complete their payment otherwise. Therefore the sender may provide a fee along with the payment, which can be claimed by each intermediary upon completion of the payment. To achieve this, each conditional payment along the path should include a slightly less amount than the last; the difference can be pocketed by the intermediary upon completion. The following example provides a $\$1$ fee to each intermediary, $P_2$ and $P_3$.

1.3 A.3 Details of the Linked Payments Construction

In the body of the paper (Sect. 4) we presented the update function and auxiliary smart contracts (Figure 5) for the state channel protocol $\varPi _{\mathsf {Linked}}$. In Fig. 6 we define the local behavior of the parties.

Fig. 6.

Construction for $\varPi _{\mathsf {Linked}}$ with the $\varPi _{\mathsf {State}}$ primitive. (Local portion only. See Fig. 5 for the smart contract portion.) Portions of the update function $U_{{\mathsf {Linked}},\$X}$ that are delegated to the underlying $U_{\mathsf {Pay}}$ update function (Fig. 5) are in bold to help readability.

1.4 A.4 Local Protocol for the State Channel Construction

In the body of the paper (Figure 3) we presented the smart contract portion of the state channel protocol. In Fig. 7 we define the local behavior of the parties.

Reaching Agreement Off-Chain. The main role of the local portion of the protocol is to reach agreement on which inputs to process next. To facilitate this we have one party, $P_1$, act as the leader. The leader receives inputs from each party, batches them, and then requests signatures from each party on the entire batch. After receiving all such signatures, the leader sends a $\mathtt {COMMIT}$ message containing the signatures to each party. This resembles the “fast-path” case of a fault tolerant consensus protocol [3]; However, in our setting, there is no need for a view-change procedure to guarantee liveness when the leader fails; instead the fall-back option is to use the on-chain smart contract.

Fig. 7.

Construction of a general purpose state channel parameterized by transition function U. (Local portion only, for the smart contract see Fig. 3.)