Systematic Interpretation of Fiber: A Grand Experiment of Grafting Lightning Network onto CKB

On August 23, CKB officially released the CKB-based Lightning Network solution - Fiber Network. Once the news spread, it quickly sparked heated discussions in the community, causing the price of CKB to rise by nearly 30% in one day. The reason why the news caused a strong response is mainly because the Lightning Network has a strong narrative charm, and CKB's Fiber has upgraded the solution of the traditional Lightning Network and made many improvements to the latter.

For example, Fiber can natively support multiple types of assets, such as CKB, BTC, stablecoins, etc., and CKB's handling fees are much lower than BTC and the response speed is fast, so Fiber can make a breakthrough in UX. In terms of privacy and security, Fiber has also made a lot of optimizations.

In addition, Fiber and BTC lightning networks can be interconnected to form a larger P2P network. In previous offline activities, CKB officials even stated that they would set up 100,000 physical nodes in Fiber and lightning networks to promote the improvement and progress of P2P payment networks. There is no doubt that this is an unprecedented and grand story.

If CKB's official vision can be realized in the future, it will be a huge benefit to the lightning network, CKB, and even the Bitcoin ecosystem. According to mempool data, more than 300 million US dollars of funds are currently placed in the BTC lightning network, the number of nodes is about 12,000, and nearly 50,000 payment channels have been built between each other.

On spendmybtc.com, we can also see that more and more merchants are supporting lightning network payments. As long as BTC is increasingly recognized, the rise of off-chain payment solutions such as lightning network and Fiber will surely increase day by day.

In order to systematically interpret Fiber's technical solutions, Geek Web3 wrote this research report on Fiber's overall solution. As a lightning network implementation solution based on CKB, Fiber's principles are generally consistent with Bitcoin's lightning network, but many details have been optimized.

Fiber's overall architecture includes the following four core parts: payment channels, WatchTower, multi-hop routing, and cross-domain payment. Let's start by explaining the most important "payment channel".

The cornerstone of Lightning Network and Fiber: payment channel

The essence of a payment channel is to move all transfers/transactions off-chain for processing, and then submit the final status to the chain for "settlement" after a while. Since transactions are completed instantly off-chain, they can often get rid of the performance limitations of main chains such as BTC.

Suppose Alice and Bob jointly open a channel. They first build a multi-signature account on the chain and deposit some money into it. For example, Alice and Bob each deposit 100 yuan as their respective balances in the off-chain channel. Then both parties can make multiple transfers in the channel. When exiting the channel, the final balance will be synchronized to the chain, and the multi-signature account will pay both parties, which is "settlement".

For example, both parties start with 100 yuan each, then Alice transfers 50 yuan to Bob, then Alice transfers 10 yuan to Bob, and then Bob transfers 30 yuan to Alice, and finally the balances of both parties become: Alice-70, Bob-130. It is not difficult to find that the total balance of the two people remains unchanged. The example of pushing and pulling the abacus beads back and forth in the above picture can well explain this.

If one party exits the channel, the current balance Alice: 70/Bob: 130 is synchronized to the chain, and the 200 yuan in the multi-signature account is transferred to the two people according to their respective balances to complete the settlement. The above process looks simple, but in practice, many complex situations must be considered.

First, you don’t actually know when the other party wants to exit the channel. Take the example above. Bob can exit after the second transfer is completed, or after the first transfer. The payment channel does not force this requirement and allows participants to exit freely. To achieve this, it is necessary to assume that someone may exit at any time, and either party may submit the final balance to the chain for settlement.

Therefore, there is a "commitment transaction" setting."Commitment transaction" is used to declare the latest balance of both parties in the channel. A corresponding "commitment transaction" will be generated when each transfer occurs.If you want to exit the channel, you can submit the latest "commitment transaction" to the chain to withdraw the money you deserve from the multi-signature account.

We can write down this conclusion:Commitment transactions are used to settle the balances of both parties in the channel on the chain. Either party can upload the latest commitment transaction to the chain at any time and then exit the channel.

But there is an important malicious scenario here: Bob can submit expired balances and commitment transactions to the chain.For example, after Commit Tx3 in the figure above is generated, Bob's balance is 130, but in order to make a profit for himself, Bob submits the expired Commit Tx2 to the chain and declares that his balance is 160, and this balance status is not real-time. This is a typical "double payment".

In order to prevent such double-spending scenarios, there must be corresponding punishment measures. The design of punishment measures happens to be the core of the entire 1-to-1 payment channel. Only by understanding this part can we truly understand the payment channel. In the design of the channel, if any party submits the expired status and Commit Tx to the chain, not only will they not get what they want, but all the funds will be withdrawn by the other party.

Here are used "asymmetric commitment transactions" and "revoke keys", these two concepts are very important. Let us first explain "asymmetric commitment transactions". Take the previous Commit Tx3 as an example, the following figure is a schematic diagram of a commitment transaction:

This commitment transaction is constructed by Bob and then sent to Alice for the other party to handle.As shown in the figure, this is a Bitcoin transfer, stating that 70 yuan in the multi-signature account will be given to Alice and 130 yuan will be given to Bob, but the unlocking conditions of the money are "asymmetric", and the restrictions faced by Alice are more stringent, which is more favorable to Bob.

After Alice receives the commitment transaction constructed by Bob, she can attach her own signature to meet the 2/2 multi-signature, and then Alice can actively submit the "commitment transaction" to the chain, so that she can exit the channel.If she does not do this, she can continue to transfer money in the channel.

Here we should pay attention to: This commitment transaction was actively constructed by Bob, and the conditions are unfavorable to Alice. Alice can only accept/reject it. We need to find a way to leave Alice some autonomy. In the design of the payment channel, only Alice can trigger the "unfavorable" commitment transaction on the chain. This is because the commitment transaction needs to gather 2/2 multi-signatures. After Bob constructs the transaction locally, he only has his own signature, not Alice's signature.

And Alice can "only receive Bob's signature, but not send her own signature to him." This is like a contract that is unfavorable to you, which requires you and others to sign it together. The other party signs first and then gives you the document, and you can prevent the other party from getting the signature. If you want the contract to take effect, sign it and then publicize it. If you don't want it to take effect, don't sign it or publicize it. Obviously in the above case, Alice has a way to restrict Bob.

Then we get to the point: After each transfer in the channel, a pair of commitment transactions will appear, with two mirror-like versions, as shown below. Alice and Bob can each construct a commitment transaction that is beneficial to them, in which they declare the balance/amount they should receive upon exit, and then send the transaction content to the other party for processing.

Interestingly, the two commitment transactions declare the same "amount received upon exit", but the withdrawal conditions are different, which is the origin of the "asymmetric commitment transaction" mentioned above.

As we explained earlier, each commitment transaction must be 2/2 multi-signatures to take effect. The commitment transaction that Bob constructs locally and is beneficial to him does not meet the 2/2 multi-signature requirement, while the commitment transaction that meets the 2/2 multi-signature requirement is held by Alice, and Bob cannot submit it. It can only be submitted by Alice, which forms a check and balance. The same principle applies in reverse.

In this way, Alice and Bob can only actively submit commitment transactions that are not beneficial to them. As long as one of the two parties submits the Commit Tx to the chain and it takes effect, the channel will be closed. Going back to the "double payment" scenario mentioned at the beginning, what will happen if someone submits an expired commitment transaction to the chain?

Here we have to mention something called "revoke key". If Bob submits the expired commitment transaction to the chain, Alice can withdraw the money that Bob deserves through the revocation key.

Let's look at the picture below. Assuming that the latest commitment transaction is Commit Tx3, and Commit Tx2 is expired, if Bob submits the expired Tx2 to the chain, Alice can withdraw Bob's money through the revocation key of Tx2 (Alice must act within the time lock).

As for the latest Tx3, Alice does not have its revocation key.Only after Tx4 appears in the future can Alice obtain the revocation key of Tx3. This is determined by the characteristics of public-private key cryptography and UTXO. Due to the length of this article, we will not explain the implementation principle of the revocation key in depth.

We can remember the conclusion: as long as Bob dares to submit the expired commitment transaction to the chain, Alice can use the revocation key to take Bob's money as a punishment. Conversely, if Alice does evil, Bob can also punish her in this way. In this way, the 1-to-1 payment channel can effectively avoid double payment. As long as the participants are rational people, they dare not do evil.

Regarding the payment channel, CKB-based Fiber has been greatly optimized compared to the Bitcoin Lightning Network. It can natively support the transfer/transaction of multiple types of assets, such as CKB, BTC and RGB++ stablecoins, while the Lightning Network can only natively support Bitcoin.After the launch of Taproot Asset, the Bitcoin Lightning Network still cannot natively support non-BTC assets, and can only indirectly support stablecoins.

（Image source: Dapangdun）

In addition, because the Layer1 main chain that Fiber relies on is CKB, the operations of opening and closing channels consume much lower fees, and will not cost users a lot of fees like the BTC Lightning Network, which is its obvious advantage in UX.

24/7 security: WatchTower

The revocation key mentioned above has a problem:Channel participants must monitor each other at all times to prevent the other party from secretly submitting expired commitment transactions to the chain. But no one can guarantee 24 hours online. What should you do if the other party does something evil when you are offline?

In this regard, Fiber and Bitcoin Lightning Network both have WatchTower designs, which will help users monitor on-chain activities around the clock.Once someone in the channel submits an expired commitment transaction, WatchTower will handle it in a timely manner to ensure the security of the channel and funds.

The specific explanation is as follows: For each expired commitment transaction, Alice or Bob can construct the corresponding penalty transaction in advance (use the revocation key to process the expired commitment transaction, and declare the beneficiary as themselves), and then send the plaintext of the penalty transaction to WatchTower. Once WatchTower detects that someone has submitted an expired commitment transaction to the chain, it will also submit the penalty transaction to the chain for targeted punishment.

In order to protect the privacy of channel participants, Fiber only allows users to send "the hash of the expired commitment transaction + the plaintext of the penalty transaction" to WatchTower, so that WatchTower does not know the plaintext of the commitment transaction at first, but only knows its hash. Unless someone actually submits the expired commitment transaction to the chain, WatchTower will see the plaintext and then submit the penalty transaction to the chain immediately afterwards. In this way, unless someone really does evil, WatchTower will not see the transaction records of channel participants (even if it sees it, it can only see one of them).

Here we have to mention the optimization of Fiber compared to Bitcoin Lightning Network. The above-mentioned penalty mechanism related to revocation keys is called "LN-Penalty", and LN-Penalty of Bitcoin Lightning Network has obvious disadvantages: WatchTower needs to save all expired commitment transaction hashes and corresponding revocation keys, which will cause considerable storage pressure.

As early as 2018, the Bitcoin community proposed a solution called "eltoo" to solve the above problem, but it requires Bitcoin fork to support SIGHASH_ANYPREVOUT operation code. The idea is that when the expired commitment transaction is on the chain, the latest commitment transaction can punish it, so that users only need to save the latest commitment transaction. However, the SIGHASH_ANYPREVOUT operation code has not been activated yet, and the solution has been delayed.

Fiber implements the Daric protocol and modifies the design of the revocation key so that the same revocation key can be used for multiple expired commitment transactions. This can greatly reduce the storage pressure on WatchTower and user clients.

Transportation system in the network: multi-hop routing and HTLC/PTLC

The payment channel mentioned above is only applicable to the scenario of 1-to-1 transactions, while the Lightning Network supports multi-hop payments, that is, routing through intermediate nodes, so that two parties who have not directly established a channel can transfer money. For example, Alice and Ken do not have a channel, but Ken and Bob have a channel, and Bob and Alice have a channel. Bob can serve as an intermediate node between Alice and Ken, allowing Alice and Ken to interact with each other in transfers. And "multi-hop routing" refers to building a transfer path through multiple intermediaries.

"Multi-hop routing" can enhance the flexibility and coverage of the network. However, the sender needs to know the status of all public nodes and channels. In Fiber, all public channels, that is, the network structure, are completely public, and any node can obtain the network information held by other nodes. Since the state of the entire network in the lightning network is constantly changing, Fiber will use the Dijkstra shortest path algorithm to find the shortest routing path, so that the number of middlemen is as small as possible, and then set up a transfer path between the two parties.

However, the credit problem of the middle node must be solved here: How do you guarantee that he is honest? For example, as mentioned earlier, there is a middleman Bob between Alice and Ken. Alice now wants to transfer 100 yuan to Ken, and Bob may withhold the money at any time. There must be a way to prevent the middleman from doing evil, and HTLC and PTLC are used to solve such problems.

Suppose Alice wants to pay Daniel 100 yuan, but there is no channel between them. Alice finds that she can pay Daniel through two middlemen, Bob and Carol. Here, HTLC is introduced as a payment channel. First, Alice makes a request to Daniel, and then Daniel sends Alice a hash r, but Alice does not know the plaintext R corresponding to r.

After that, Alice constructs payment terms through HTLC in the channel with Bob: Alice is willing to pay Bob 102 yuan, but Bob must tell the key R within 30 minutes, otherwise Alice will withdraw the money. Similarly, Bob creates an HTLC with Carol: Bob will pay Carol 101 yuan, but Carol must tell her the key R within 25 minutes, otherwise Bob will withdraw the money.

Carol does the same thing and creates an HTLC in the channel with Daniel: Carol is willing to pay 100 yuan, but Daniel must tell her the plaintext of R within 20 minutes, otherwise the money will be taken back by Carol.

Daniel understands that the key R that Carol asked for is actually what Alice wants, because no one except Alice cares what the content of R is.So Daniel will cooperate with Carol, tell her the content of R, and get 100 yuan from Carol, so Alice achieves her goal: giving Carol 100 yuan.

It is not difficult to imagine what happens next: Carol tells Bob the key R and gets 101 yuan; Bob tells Alice the key R and gets 102 yuan. We observe the gains and losses of everyone and can see that Alice lost 102 yuan, Bob and Carol made a net profit of 1 yuan, and Daniel got 100 yuan. The 1 yuan earned by Bob and Carol is the handling fee they collected from Alice.

Even if someone in the above payment path is stuck, for example, Carol did not tell the downstream Bob the key R, Bob would not suffer any loss: Bob can withdraw the constructed HTLC after a period of time. The same is true for Alice.

But the Lightning Network also has problems: the path should not be too long. If the path is too long and there are too many middlemen, the reliability of the payment will be reduced:Some middlemen may be offline, or the balance may not be enough to build a specific HTLC (for example, in the previous case, each middleman must have at least 100 yuan). Therefore, each additional intermediate node in the path will increase the possibility of error.

In addition,HTLC may leak privacy. Although onion routing can appropriately protect privacy,for example, encrypting the routing information of each hop, except for the original initiator Alice, everyone only knows the adjacent upstream and downstream, not the complete path,but in fact, HTLC is still easy to infer the correlation. Let's look at the path below from a bird's eye view

Assume that Bob and Daniel are two nodes controlled by the same entity, and receive HTLCs from many people every day. They find that every time Alice and Carol send HTLCs, the key they want to know is always the same, and Eve, the next customer connected to Daniel, always knows the content of key R. Therefore, Daniel and Bob can guess that there is a payment path between Alice and Eve, because they are always related to the same key, thereby inferring the relationship between Alice and Eve and imposing surveillance.

In response to this, Fiber uses PTLC, which improves privacy on the basis of HTLC. Each PTLC in the payment path is unlocked with a different key. Simply observing the key requested by PTLC cannot determine the correlation between them. By combining PTLC with onion routing, Fiber can become an ideal solution for privacy payments.

In addition, the traditional lightning network has a "replacement cycling attack" scenario, which can allow the assets of the middleman in the payment path to be stolen. This discovery even caused developer Antoine Riard to withdraw from the development of the lightning network. So far, the Bitcoin lightning network has not taken any fundamental measures to solve this problem, which has become a pain point.

Currently, CKB officials have made improvements at the transaction pool level to allow Fiber to solve the above attack scenarios. Since the replacement transaction cycle attack and its solution are quite brain-burning, this article does not intend to continue to take up space to explain it. Those who are interested can read the following article from BTCStudy and read the relevant information of CKB officials.

Overall, Fiber has made significant improvements over the traditional lightning network in terms of both privacy and security.

Cross-domain atomic payment between Fiber and Bitcoin Lightning Network

Using HTLC and PTLC, Fiber can realize cross-domain payment with Bitcoin Lightning Network, and can guarantee the "atomicity of cross-domain behavior", that is, all steps related to cross-domain are either fully successful or fully failed, and there will be no partial success and partial failure.

With the guarantee of cross-domain atomicity, it can be guaranteed that cross-domain itself will not cause property loss, so that Fiber and Bitcoin Lightning Network can be interconnected, For example, a payment path can be built in the hybrid network composed of Fiber and Lightning Network, and transfer money directly from Fiber to users in BTC Lightning Network (the receiving end is limited to BTC), and CKB and RGB++ assets can be exchanged for equivalent Bitcoin in BTC Lightning Network in Fiber.

Let's briefly explain the principle: Assume that Alice runs a node in the Fiber network, and Bob runs a node in the Bitcoin Lightning Network. Alice wants to transfer some money to Bob. She can do this through the cross-domain intermediary Ingrid. Specifically, Ingrid will run nodes in the Fiber and BTC Lightning Networks respectively, acting as a middleman in the transfer path.

If Bob wants to receive 1 BTC, Alice can negotiate the exchange rate with Ingrid, such as exchanging 1 CKB for 1 BTC. Alice can send 1.1 CKB to Ingrid in Fiber, and then Ingrid sends 1 BTC to Bob in the BTC Lightning Network, and Ingrid will keep 0.1 CKB as a handling fee.

The specific operation here is actually to establish a payment path between Alice, Bob and Ingrid, that is, Alice—>Ingrid—>Bob, and then HTLC will be used. Similar reasoning has been mentioned before. In order to receive the money, Bob must tell Ingrid the content of the key R. Once Ingrid obtains the key R, she can unlock the money locked in the HTLC by Alice.

It should be noted that these two cross-domain behaviors occurring in the BTC Lightning Network and Fiber respectively are atomic, which means that either both HTLCs are unlocked and the cross-domain payment is successfully executed. Or neither is unlocked, and the cross-domain payment fails, and there will be no situation where Alice gives money but Bob cannot receive it.

(In fact, the middleman Ingrid can choose not to unlock Alice's HTLC after knowing the key R, but it is the middleman Ingrid who is harmed, not the user Alice, so the design of Fiber is safe for users)

This method does not require trusting a third party, and can realize transfers between different P2P networks, with almost no modification.

Other advantages of Fiber compared to BTC Lightning Network

As mentioned earlier, Fiber supports CKB native assets, as well as RGB++ assets (especially stablecoins), which makes it have great potential in instant payment scenarios and is more suitable for daily small payment needs.

In addition, Bitcoin Lightning Network has a major pain point, which is the liquidity management problem. You may remember what we said at the beginning, that the overall balance in the payment channel is fixed. If one party's balance is exhausted, it will not be able to transfer money to the other party unless the other party transfers money to him first. At this time, it is necessary to re-inject funds or open a new channel.

In addition, if it is in a complex multi-hop network, some intermediate nodes have insufficient balances and cannot transfer money outward, which may cause the entire payment path to fail. This is one of the pain points of the lightning network. The solution to this is nothing more than providing an efficient liquidity injection solution to ensure that most nodes can inject funds at any time.

However, in the BTC lightning network, the steps of injecting liquidity and opening or closing channels are all performed on the BTC chain. If the BTC network fee is extremely high, it will have a negative impact on the UX of the payment channel. Suppose you want to open a channel with a capacity of $100, but the operation of establishing the channel costs $10 in fees, then this channel will cost you 10% of your funds when it is initialized, which is unacceptable to most people; the same is true for liquidity injection and other tasks.

Fiber has a very significant advantage in this regard. First, CKB's TPS is much higher than BTC, and the handling fee can reach the cent level; secondly, in order to deal with the problem of insufficient liquidity leading to the inability to transfer funds, Fiber plans to cooperate with Mercury layer to launch a new solution, so that the work of liquidity injection can get rid of on-chain operations and solve UX and cost issues.

So far, we have systematically sorted out the overall technical architecture of Fiber, and its general comparison with Bitcoin Lightning Network is summarized as shown in the figure above. Since Fiber and Lightning Network involve too many and complex knowledge points, a single article may not cover all aspects. In the future, we will launch a series of articles on the topic of Lightning Network and Fiber, so please stay tuned.