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

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.

1. 1.

   The rational investor’s preference is to obtain and use money now rather than later.

2. 2.

   The reference implementation can be found at https://github.com/amiller/sprites, Sprites: 0x85DF43619C04d2eFFD7e14AF643aef119E7c8414, Manager: 0x62E2D8cfE64a28584390B58C4aaF71b29D31F087.

3. 3.

   The intermediary nodes in a path can also be incentivized to participate in the route if the sender allocates an extra fee that will be shared among them.

4. 4.

   https://github.com/amiller/sprites.

5. 5.

   Representative Lightning transaction https://www.blockchain.com/btc/tx/c9e6a9200607871e18fcfdd54dcb0da17ac8eca005101b82c8a807def9885d3e.

Authors and Affiliations

1. University of Illinois at Urbana-Champaign, Urbana, IL, USA

   Andrew Miller & Surya Bakshi

2. Cornell Tech, New York, NY, USA

   Iddo Bentov

3. VISA Research, Palo Alto, CA, USA

   Ranjit Kumaresan

4. King’s College London, London, UK

   Patrick McCorry

Corresponding author

Correspondence to Andrew Miller .

Editors and Affiliations

1. Cheriton School of Computer Science, University of Waterloo, Waterloo, ON, Canada

   Ian Goldberg

2. Tandy School of Computer Science, University of Tulsa, Tulsa, USA

   Tyler Moore

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.

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.

Full size image

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.

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

Full size image

Reprints and permissions

© 2019 International Financial Cryptography Association

Policies and ethics