Header Ads

An intermediate layer to charge payment channels

The Lightning Network or other versions of payment channel networks are considered to be the necessary and outstanding future of scaling Bitcoin. A paper by Christian Decker now brings an intermediate layer into play that can break the last limits of scalability ...


It may be that you can scale Bitcoin as it is a bit further. But at some point, one will give up basic system features to further increase capacity. To avoid this, some scientists and developers have developed the concept of offchain payment channels: Transactions are no longer made "on the blockchain" where they need space, but "offchain" in so-called payment channels.

If you are unfamiliar with the concept, we recommend this article about Lightning, which describes how to set up such a payment channel. Roughly speaking, you can think of payment channels as a remittance slip that you never throw in, but when you change the amounts. The two parties in such a channel update an unconfirmed transaction.

Actually, such payment channels only connect two parties. But by connecting them to a network, like the Lightning network, theoretically an unlimited number of people can interact through multiple "hops". Again, there is an article for those who would like to know more about how the channels create a network. Imagine it a bit like the old mail riders who have changed their horses at the stations.

Limits of Lightning and Co.

There are still no such networks of payment channels, and it is still unclear whether they are economically meaningful enough to ever form on free markets. However, Christian Decker, Blockstream employee and possibly the first "Doctor Bitcoin", is already exploring the potential limitations of the Lightning network and looking for solutions to overcome them. Together with Conrad Burchert and Roger Wattenhofer, both at ETH Zurich, Decker has now published a new paper.

First, the researchers explain what difficulties Lightning and other offchain networks currently have: First, scalability is still limited. "Even with a larger blocksize, the blockchain capacity is estimated to only reach 800 million users of micropayment channels, as they need a certain number of onchain transactions to open and close those channels." Nationwide micropayment applications, such as the Internet of Things they might need would drive the blockchain to their limit as each channel needs multiple blockchain transactions.

Second, both parties to a payment channel must freeze credits in a shared account. "These traded funds should be sufficient to have enough capacity for spikes in transaction volume. There is a conflict of interest between the two goals of including small amounts of credit in a channel, but staying flexible at the same time for those tips. "

Most of those who have read the topic are likely to agree that these problems are difficult to eradicate. However, Decker and his co-authors find a solution that can break both problems.

Layer-2 becomes Layer-3

"Payment channels will not appear on the blockchain except in case of disagreement," the authors said, "users will be able to enter the system with a single blockchain transaction and then open many channels without further blockchain contact . "

Instead of requiring a channel per channel, one transaction should be sufficient to participate in multiple channels. How is this possible? The trick is that the funds are not frozen with a single partner - the one to open the channel - but with a group of partners. You do not transfer your credits to a multisig address that you share with a party, but to one in which there are many parties in it. So all the channels that all participants have at this address can be open to all, and if things go well, you can access dozens, if not hundreds, of channels with a single transaction.

The researchers call their innovation "Channel Factories." These are "a new layer between the blockchain and the payment network, giving us a three-tier system."

Between Blockchain and Payment Channels should therefore be another layer. It's a little bit like an airport. The previous idea was that the passengers start a direct flight in their garden to hope to get to their destination with a few changes. Now the passengers go to the airport to pick one of many flights.


Almost limitless capacity

This architecture also solves another problem of off-chain networks, such as Lightning: A user can form either a few - or just one - payment channel, making him dependent on large hubs with many channels. But if he builds many channels, he has to freeze money in each channel. For this reason, there is evidence that the Lightning network is likely to have a centralized topology. With the channel factories of Decker and Co., a single transaction could give a user access to many different channels, potentially helping to keep the network decentralized - unless the factories are considered centers themselves already high complexity of offchain solutions like Lightning. Presumably, they are not planned for direct deployment in the near future, but as a later optimization, when the first knots and threads of the Lightning network have already established. The profit from them can be immense, at least in the calculations of Christian Decker and Co.: If three parties already team up to use three payment channels together, the necessary space on the blockchain falls by 50 percent. On the other hand, assuming that 20 parties unite to use 100 channels, the channel factories save as much as 90 percent. Assuming that the input signatures can be aggregated using Schnorr signatures, the savings even increase to 96 percent. In other words, there may be the possibility of using the third layer to settle all transactions of this world, both humans and machines, on a single blockchain. Of course, the concept, at least in the paper, is described rather rudimentarily. Scientists outline the mechanisms that can be used to build a layer of channel factories, but remain very vague when it comes to the topology of the entire network. Even economic issues are not an issue. But that's not the point at this point. More importantly, there seems to be a way to overcome the limitations of Lightning.
Powered by Blogger.