Lightning Network too slow? Researchers propose new solution Sprite to improve payment channel efficiency

The concept of Lightning Network was officially launched in early 2015. It is regarded as one of the best solutions to Bitcoin's scaling challenges. After a year of development, Lightning Network is not far from its official release.

However, a new paper recently released by a group of researchers proposes an entirely new payment framework that is said to be able to process transactions faster than the Lightning Network.

The concepts proposed by the Lightning Network, such as payment channels, are closely related to the debate on Bitcoin expansion. Although this issue started with the debate on block capacity, it is ultimately related to the transaction volume processed by the entire network within a certain period of time.

Directly increasing block capacity is one way to increase transaction throughput, and off-chain payments are also possible. Two or more parties conduct transactions through a dedicated payment channel, and only the last transaction is broadcast on the blockchain.

The new paper, “Sprites: Faster Payment Channels Than Lightning,” calls the Lightning Network’s design “unnecessarily complex” and claims that Sprite channels could reduce the processing time of the highest-volume transactions when worst-case latency is present in the transaction channel.

Payment channel optimization

The worst-case scenario mentioned here is the focus of Sprite's solution, and similar situations include disputes between parties involved in the payment channel.

Andrew Miller, an assistant professor at the University of Illinois at Urbana-Champaign and one of the authors of the paper, said:

In the event of a dispute… the time you have to wait for your funds to be returned is determined by a timelock. In the context of Lightning and Raiden, this timelock is much larger than the payment channel. We have found a way to allow interlinked payments to be processed in multiple channels, and the timelock length remains the same, no matter how long the channel is.

A primary goal of the Lightning Network is to facilitate cross-channel payments between parties that can’t directly establish a channel, so a way to reduce latency would be an important advantage.

(Picture from the paper: channel delay, Lightning Network on the left, Sprite on the right)

Soft Fork Obstacles

However, the mechanism for deploying Sprite micropayment channels cannot yet be written directly into the Bitcoin scripting language (as it is possible on the Ethereum blockchain).

That is to say, in order to deploy this system in the Bitcoin network, new Bitcoin code must be added through a soft fork, just like other schemes such as Segregated Verification (SegWit).

Miller said:

Sprite can be deployed via a soft fork, but this solution is not currently proposed as a soft fork.

However, the paper has been published, and he believes that other researchers may find better ways to implement the Sprite system without changing the Bitcoin script language.

At the same time, Miller also revealed that the authors of this paper have begun to contact the Lightning Network team, and they have also provided feedback and solution analysis.

Additionally, they hope that the Raiden Network (Ethereum’s version of the Lightning Network) can adopt Sprite’s technology in the future.

Patrick McCorry, a cryptocurrency researcher at Newcastle University in the UK and another author of the Sprites paper, said:

I would find it a bit strange if Raiden didn’t deploy Sprite: they don’t have to worry about backwards compatibility issues (compared to Bitcoin), so it’s more likely that they would choose to adopt Sprite, after all, there is no need to soft fork.

Ultimately, Miller said, developing solutions for bitcoin first and then moving on to other altcoins is likely to hinder development because researchers will have to deal with the complexity of bitcoin’s code.

We recommend that if you have new ideas, you can first test them with virtual code or Ethereum, because this method is simpler, and then make them backward compatible and deploy them to Bitcoin.

If payment channels were first proposed by Ethereum, I think they would have immediately figured out how to use them.