Partnered With:

Lightning network channel based on Statechain

Read this article in 13 Minutes

Statechain was proposed to be combined with the Lightning network from the start, and now it may be time.

原文标题：《基于 Statechain 的闪电网络通道》

Original article by SHINOBI

Last year I wrote about Mercury Wallet developed by the Commerceblock team; Function, which is a kind of statechain; CoinSwap The double realization. It introduces both a new hybrid currency tool and the first wallet to implement a new two-layer extension scheme called statechain. The team made a few changes to Ruben Somsen's original statechain proposal, making it so that there were no ANYPREVOUT/Eltoo sighash flag statechain also works, and incorporates a new CoinSwap design that lets users mix coins multiple times without having to interact on the chain.

background

A quick summary for those of you who haven't read my previous article: statechain is an off-chain mechanism used to transfer money for free between anyone who is completely off-chain. The original owner of the money works with a statechain operator to construct an ECDSA-MPC address, the private key of which is split in half, with one half in the user's hand and the other in the operator's, and then they work together to construct and sign a withdrawal transaction with a time lock. And then the user sends money to that address.

No party controls the private key in its entirety, and the user is holding a pre-signed transaction, so can unilaterally get the money back once the time lock is unlocked. When the user wishes to transfer the asset, they notify the operator, who works with the recipient of the payment to create a new set of private key fragments (but with the same property as the original private key fragment), then generates another transaction with a shorter time lock and signs it; Finally, the operator deletes the fragment of the previous private key.

As a result, the fragment of the private key now held by the operator will only be able to combine with the fragment of the private key held by the new owner of the funds, so as long as they delete the old private key fragment, they will not be able to spend the funds with the old owner. In addition, the newer the transaction, the shorter the time lock, so the new owner can always withdraw the money faster than the old owner. This mechanism limits the number of times statechain funds can be transferred and must be withdrawn when they are due (or risk being withdrawn by the old owner).

Lightning Channel based on statechain

Commerceblock is now writing a new BLIP (Bitcoin Lightning network upgrade proposal) that would implement something Somsen proposed in his initial proposal: a lightning channel over a chunk of statechain money.

One of the drawbacks of statechain itself is that the entire UTXO is transferred together each time. But what if statechain's withdrawal transaction transfers money not to an ordinary user's address, but to a lightning channel? A portion of the statechain funds can then be transferred through the initial balance distribution of the channel, which can then initiate a regular flash payment.

The process also starts with a user creating a statechain fund. The creator and the operator of Statechain go through the usual process of creating a shared private key and signing a block transaction with a time lock; The creator (Alice) then finds a channel counterparty (Bob) willing to accept statechain's money. Together, Alice and Bob create their own common public key by following the same process that Alice and the operator used to split the private key. Both men then share their public and personal public key fragments with the Statechain operator. This allows the operator to question them, have them each sign and certify that they agree to cooperate in closing statechain at the latest balance, rather than waiting for the statechain withdrawal time lock to expire.

From here, with Bob's authorization, Alice and the Statechain operator can sign a transaction, spend statechain money directly into a multi-signature lightning channel, and handle the creation of the lightning network channel. This channel is Alice's and Bob's channel).

At this point, the Statechain address remains in the hands of Alice and the operator, but the transaction that opened the lightning channel is now in Bob's hands and has a shorter time lock than the original withdrawal transaction, This ensures that the transaction can take effect before Alice unilaterally closes the Statechain. Then, Alice and Bob make a final update with the operator, using their shared public keys to create a withdrawal transaction with the operator that spends statechain funds into the Alice-Bob channel. A regular statechain transfer makes Alice and Bob's shared public keys the new owner of the statechain), and the withdrawal transaction has a shorter time lock. Now Alice and Bob can announce that they have a lightning channel.

(Note: The purpose of this agreement is to create a channel between the current owner and the intended payer based on a sum of statechain funds, allowing the current owner to divide the statechian funds and pay only part of the funds to the intended payer. At the end of the agreement, the associated Statechain will no longer belong to the original owner (in this case, Alice), because the fragment of the private key matching Alice has been destroyed by the operator; Instead, the Alice-Bob channel.

(Translator's Note: The drawback, or lack thereof, is that Alice can't actually transfer the channel (or her remaining balance) to Carol, because that would require transferring to Carol all the records of Alice and Bob's interactions in the channel. Otherwise Alice and Bob could conspire to defraud Carol; However, there is no mechanism designed to ensure that Alice transfers all the data, which would require Alice/Bob to submit a promise every time a lightning payment is initiated. However, based on the principles outlined above, you could also consider making it a multi-party coinpool rather than a two-party lightning channel.)

Increased the utility of statechain

The proposal would greatly improve statechain's utility by easing its already stringent liquidity requirements. Whenever someone wants to receive statechain money and finds that the face value does not match the payment, the sender can fix the problem by opening a lightning channel with the TA until one of them spends the rest of their money (or the money in the channel belongs to one of them). Complete another transfer of all statechain funds. Such possibilities not only improve the utility of statechain, but also the utility of Lightning networks (if the protocol is properly supported).

The rebalancing of balances within the channel is a necessary function for nodes in a lightning network, whether you are a routing node or just an edge node sending and receiving transactions. When all the money in the channel is moved to one end of the channel, the channel loses its ability to send payments in one direction or another (if all the money is on your side, you can't collect payments through the channel; If all the money goes to your opponent, you won't be able to use that channel). So, you need to move money from one channel to another, rebalancing your own channel by causing imbalances in the others. Eventually, this dynamic ends with a channel somewhere having to exchange money across the lightning network and chain.

Statechain allows liquidity to move as it does up the chain, but without creating a chain footprint or paying a fee for it. Suppose you have a depleted channel, all the balance is on your opponent's side, you have run out of capacity to spend, and at the same time you have a Statechain fund. Well, you can transfer the Statechain money to anyone who will accept it, and if you can't spend all the Statechain money, you can build a lightning channel on top of it, which can also be used to rebalance your normal lightning channel.

This will allow for increased efficiency in terms of the number of channels that your channel needs to go through to rebalance (don't forget, when you rebalance your channel, it unbalances every channel that money flows through), and in the best case, you can send money directly to the same opponent, thereby rebalancing your channel. If you want to close one channel and open another with someone else, you can even rebalance all the balances in that channel to a new one you set up with your new opponent based on statechain.

Statechain and the future of the Lightning Network

Discussing their future plans, Commerceblock's Nicolas Gregory said: "Our plan is to establish a standard approach that combines statechain and Lightning Network technologies to help Lightning Network rebalance down the chain through the use of the state channel. The current set of specifications will be a cornerstone of this goal."

From the very beginning, statechain was proposed to be integrated with Lightning to solve one of its own problems: the need to transfer the value of the entire UTXO when making payments. This also provides a degree of flexibility to the Lightning network, which does not have its own approach to liquidity management.

Now that the Lightning network is in a healthy stage of early growth, and a reliable statechain implementation has been around for more than a year, it's time to consider combining the two. The Lightning Network, as a network, is a system for automating transfers between any two parties that are not directly connected. As to the inner workings of the channels in the network diagram, it is strictly irrelevant to the sender and the receiver; As long as the two parties building the channel get by themselves.

Both Statechain and Lightning Channel offer many benefits to each other, and what we need to do is develop a standardized way for the two to interact.