System Interpretation of Fiber: A Grand Experiment of Grafting Lighting Network onto CKB

On August 23rd, the official CKB released the Fiber Network, a Lighting Network solution based on CKB. This news quickly sparked hot discussions in the community, causing the CKB price to pump nearly 30% in one day. The reason why the news caused a strong reaction is mainly due to the powerful narrative charm of Lighting Network, and CKB’s Fiber has made many improvements to the traditional Lighting Network solution.

For example, Fiber can natively support multiple asset types, such as CKB, BTC, stablecoins, etc., and CKB’s transaction fees are much lower than BTC’s and its response speed is faster. This allows Fiber to make breakthroughs in terms of UX. Fiber has also made many optimizations in terms of privacy and security.

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

If the official vision of CKB is realized in the future, it will be a huge Favourable Information for both Lighting Network, CKB, and the BTC ecosystem. According to the mempool data, there is currently over 300 million USD funds locked in BTCLighting Network, with approximately 12,000 Nodes and nearly 50,000 payment channels established between them.

And on spendmybtc.com, we can also see more and more merchants supporting the Lighting Network for payment. As long as the recognition of BTC becomes stronger, the momentum of the rise of off-chain payment solutions such as Lighting Network and Fiber will undoubtedly increase day by day.

With the aim of systematically interpreting the technical solution of Fiber, “Geek Web3” wrote this research report on the overall solution of Fiber. As a Lightning Network implementation based on CKB, Fiber’s principles are largely consistent with Bitcoin Lightning Network, but with many optimizations in detail.

The overall architecture of Fiber includes four core components: payment channels, WatchTower, multi-hop routing, and cross-domain payments. Now let’s explain the most important ‘payment channels’.

The Foundation of Lighting Network and Fiber: Payment Channels

The essence of payment channels is to move transfers/transactions off-chain for processing and then submit the final state to on-chain for settlement after a period of time. Since transactions are completed instantly off-chain, they can often bypass the performance limitations of mainchain cryptocurrencies such as BTC.

Assuming Alice and Bob jointly open a channel, they first build a multi-signature account on-chain, deposit some money into it, such as 100 yuan each for Alice and Bob, as their respective balances in the off-chain channel. Next, both parties can make multiple transfers in the channel. When exiting the channel, the final balance is synchronized to on-chain, and the multi-signature account pays both parties, which is called “Settlement”.

For example, at the beginning, both parties have 100 yuan each. Then Alice transferred 50 yuan to Bob, and then Alice transferred another 10 yuan to Bob. Afterwards, Bob transferred 30 yuan back to Alice. Finally, the balances of both parties became: Alice - 70 yuan, Bob - 130 yuan. It is easy to see that the sum of the two parties’ balances remains unchanged. The abacus beads moving back and forth in the example in the figure can explain this well.

If one party exits the channel, synchronize the current balance Alice: 70/Bob: 130 to on-chain, transfer the 200 dollars in the multi-signature account to each person according to their respective balances, and complete the Settlement. The above process may seem simple, but there are many complex situations to consider in practice.

**First of all, you actually don’t know when the other party wants to exit the channel. **Taking the example above, Bob can exit after the second transfer is completed, or even after the first transfer, and the payment channel will not enforce this, allowing 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 on-chain for Settlement.

So there is a setting for ‘commitment transactions’. ‘Commitment transactions’ are used to declare the latest balances of both parties in the channel, and a corresponding ‘commitment transaction’ will be generated for each transfer. If you want to exit the channel, you can submit the latest ‘commitment transaction’ to on-chain and withdraw your due money from the multi-signature account.

We can draw the conclusion: Commitment transactions are used for on-chain settlement of balances between both parties in the channel, and either party can put the latest commitment transaction on-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 on-chain, such as in the Commit Tx3 generated in the above figure, Bob’s balance is 130. However, in order to profit himself, Bob submits the expired Commit Tx2 to the on-chain, claiming that his balance is 160. This balance status is not real-time, which is a typical case of ‘Double Spending’.

In order to prevent such double spending scenarios, there should 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 one truly understand the payment channel. In the design of the channel, if either party submits the expired state and Commit Tx to the on-chain, it will not only fail to achieve the desired result, but will also have all the funds taken away by the other party.

Here, the concepts of ‘asymmetric commitment transaction’ and ‘revoke Secret Key’ are used, which are very important. Let’s first explain the ‘asymmetric commitment transaction’. Taking the previous Commit Tx3 as an example, the following diagram is an illustration of the commitment transaction:

This commitment transaction is constructed by Bob and then sent to Alice for her own handling. As shown in the figure, this is a BTC transfer, declaring that 70 dollars from the multi-signature account will be given to Alice, and 130 dollars will be given to Bob, but the unlocking conditions for the money are ‘asymmetric’, with more stringent restrictions on Alice and more advantageous to Bob.

After receiving the commitment transaction constructed by Bob, Alice can attach her own signature to satisfy the 2/2 multisig. After that, Alice can actively submit the “commitment transaction” to the chain, so she can exit the channel. If she does not do so, she can continue to transfer in the channel.

Here we need to pay attention: This commitment transaction is actively constructed by Bob, with conditions that are unfavorable to Alice, who can only accept/reject. We need to find a way to leave some autonomy to Alice. In the design of payment channels, only Alice can trigger the “unfavorable to herself” commitment transaction on-chain, because the commitment transaction requires a 2/2 multi-signature, and after Bob constructs the transaction locally, only his signature is available, without 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 not in your favor, requiring both you and the other party to sign, the other party signs first and then gives the document to you, and you can prevent the other party from getting the signature. If you want the contract to take effect, sign it and make it public, if you don’t want it to take effect, don’t sign it or make it public. Obviously, in the above case, Alice can limit Bob.

Then comes the key point: After each transfer occurs in the channel, a pair of commitment transactions will appear, with two similar mirrored versions, just like the following. Alice and Bob can each construct commitment transactions that are beneficial to themselves, declaring the amount they should receive when the balance is settled/withdrawn, and then send the transaction content to the other party for processing.

Interestingly, **the “exit proceeds” specified in both commitment transaction statements are the same, but the withdrawal conditions are different, which is the origin of the previous “asymmetric commitment transactions”.

As we explained earlier, every committed transaction requires a 2/2 multisig to take effect. Bob’s locally constructed committed transaction, which is favorable to himself, does not meet the 2/2 multisig requirement, while the committed transaction that meets the 2/2 multisig requirement is held by Alice. Bob cannot submit it and can only be submitted by Alice, thus forming a check and balance. The same logic applies in reverse.

As a result, Alice and Bob can only voluntarily submit a commit transaction that is unfavorable to them, and as soon as one of the two parties commits the Commit Tx on-chain and takes effect, the channel will be closed. Going back to the “Double Spending” scenario mentioned at the beginning, what happens if someone submits an expired commitment transaction to the chain?

Here we need to mention something called “撤销Secret Key”. If Bob submits an expired commitment transaction to the chain, Alice can use the revoked Secret Key to withdraw the money Bob deserves.

Let’s take a look at the following diagram. Suppose the latest committed transaction is Commit Tx3, Commit Tx2 has expired, and if Bob submits the expired Tx2 on-chain, Alice can use the revocation Secret Key of Tx2 to withdraw Bob’s money (Alice needs to act within the time lock range).

And for the latest Tx3, Alice does not have the revocation Secret Key. Only after Tx4 appears in the future, Alice can obtain the revocation Secret Key of Tx3. This is determined by the characteristics of public-private key cryptography and UTXO, and the implementation principle of revocation Secret Key will not be explained in detail in this article due to the length.

We can remember the conclusion: As long as Bob dares to submit expired promised transactions on the chain, Alice can use the revocation Secret Key to take Bob’s money as punishment. Conversely, if Alice behaves badly, Bob can also punish her in the same way. In this way, the 1-to-1 payment channel can effectively avoid Double Spending, as long as the participants are rational and dare not behave badly.

Regarding the payment channel, Fiber based on CKB has significant optimization compared to BTCLighting Network. It can natively support the transfer/trading of multiple types of assets, such as CKB, BTC, and RGB++ Stable Coin, while Lighting Network can only natively support BTC. After the launch of Taproot Asset, BTCLighting Network still cannot natively support non-BTC assets, only indirectly supporting Stable Coin.

(Image source: Dapangdun)

In addition, **as the Layer1 mainchain relied on by Fiber is CKB, the cost of opening and closing channels is much lower, and it will not erode users’ fees as much as BTCLighting Network, **which is its obvious advantage in UX.

24/7 Security: WatchTower

There is a problem with the revocation of Secret Key mentioned above: channel participants should always monitor each other to prevent the other party from secretly submitting expired commitment transactions to the chain. But no one is guaranteed to be online 24 hours a day, what if the other person is doing evil when you are offline? **

Both Fiber and BTCLighting Network have designed WatchTower to monitor on-chain activities for users 24/7. Once someone submits an expired commitment transaction in the channel, WatchTower will handle it promptly to ensure the security of the channel and funds.

The specific explanation is as follows: For each expired commitment transaction, Alice or Bob can pre-construct the corresponding penalty transaction (use the revocation Secret Key to handle the expired commitment transaction, and claim to be the beneficiary), and then send the plaintext of the penalty transaction to the WatchTower. Once the WatchTower detects that someone has submitted the 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 ‘expired promise transaction hash + punishment transaction plaintext’ to WatchTower. In this way, WatchTower does not initially know the plaintext of the promise transaction, only its hash. Unless someone actually submits the expired promise transaction to on-chain, WatchTower will see the plaintext and then immediately submit the punishment transaction to the chain. As a result, unless someone really behaves badly, WatchTower will not see the transaction records of the channel participants (even if they do see it, they can only see one of them).

Here we want to mention the optimization of Fiber compared to BTCLighting Network. The penalty mechanism related to revoking Secret Key mentioned above is called ‘LN-Penalty’, and LN-Penalty of BTCLighting Network has obvious disadvantages: WatchTower needs to store all expired commitment transaction hashes and corresponding revoking Secret Keys, which will cause significant storage pressure.

As early as 2018, the BTC community proposed a solution called “eltoo” to solve the above problems, but it requires BTCfork to support the SIGHASH_ANYPREVOUT opcode. The idea is that when the expired commitment transaction is placed on the chain, the latest commitment transaction can punish it, so users only need to keep the latest commitment transaction. However, the SIGHASH_ANYPREVOUT opcode has not been activated so far, and the solution has not been implemented.

And **Fiber implements the Daric protocol, modifying the design of revoking Secret Key to make the same revoking Secret Key applicable to multiple expired commitment transactions. This can greatly reduce the storage pressure on WatchTower and user clients.

Traffic Systems in Networks: Multi-hop Routing and HTLC/PTLC

The previously mentioned payment channel is only suitable for 1-to-1 transaction scenarios, while the Lighting Network supports multi-hop payments, i.e., routing through intermediate Nodes, allowing transfer between two parties who do not have a direct channel established, such as Alice and Ken not having a channel, but Ken having a channel with Bob, and Bob having a channel with Alice, Bob can act as the intermediate Node between Alice and Ken, allowing transfer interaction between Alice and Ken. And “multi-hop routing” refers to building a transfer path through multiple middlemen.

“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 and network structure are completely open. Any node can obtain the network information held by other nodes. Since the state of the entire network in the Lighting Network is constantly changing, Fiber uses the Dijkstra’s shortest path algorithm to find the shortest routing path, minimizing the number of middlemen, and then establishes a transfer path between the two parties.

However, the issue of credit for the middleman Node needs to be addressed: how do you ensure that they are honest? For example, as mentioned earlier, there is a middleman Bob between Alice and Ken. Now, Alice wants to transfer 100 yuan to Ken, and Bob can potentially withhold the money at any time. Measures need to be taken to prevent the middleman from acting maliciously, and HTLC and PTLC are used to solve such problems.

Assuming Alice wants to pay Daniel 100 bucks, but they don’t have a channel established between them. Alice finds that she can make the payment to Daniel through two middlemen, Bob and Carol. In this case, HTLC is introduced as the payment channel. First, Alice initiates a request to Daniel, and then Daniel sends Alice a hash r, but Alice doesn’t know the PlaintextR corresponding to r.

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

Carol, as usual, creates an HTLC in the channel with Daniel: Carol is willing to pay 100 bucks, but Daniel has to tell her the Plaintext of R within 20 minutes, otherwise the money will be returned to Carol.

Daniel understands that the key R that Carol asks for is actually what Alice wants, because no one but Alice cares what R’s content is. So Daniel would cooperate with Carol and tell her what R was about, and get 100 bucks from Carol, so that Alice would achieve her goal: give Carol 100 bucks.

Afterwards, it’s not hard to imagine: Carol tells Bob the key R and gets 101 dollars; Bob then tells Alice the key R and gets 102 dollars. We observe the gains and losses of everyone, and it can be seen that Alice loses 102 dollars, Bob and Carol net 1 dollar, and Daniel gets 100 dollars. The 1 dollar earned by Bob and Carol is the transaction fee they took from Alice.

Even if someone in the payment path above gets stuck, such as Carol failing to disclose the key R to downstream Bob, Bob will not suffer any loss: Bob can withdraw the constructed HTLC after a period of time. The same applies to Alice.

However, the Lighting Network also has its issues: the path should not be too long, as having too many middlemen in the path will drop the reliability of the payment: Some middlemen may be offline, or their balances may not be sufficient to construct specific HTLCs (for example, in the previous case, each middleman needs to have at least 100+ RMB). Therefore, adding an additional middle Node in the path will increase the probability of errors.

In addition, **HTLC may leak privacy. Although onion routing can protect privacy properly, **such as encrypting the routing information of each hop, except for the initiator Alice, everyone only knows the adjacent upstream and downstream parties, not the complete path, **but in fact, the association of HTLC can still be inferred. **Let’s take a god’s-eye view of the following path.

Assuming that Bob and Daniel are two Nodes controlled by the same entity, they receive many HTLCs every day. They discovered that every time Alice and Carol send an HTLC, the Secret Key they want to know is always the same, and the downstream node connected to Daniel, Eve, always knows the content of Secret Key R. Therefore, Daniel and Bob can guess that there is a payment path between Alice and Eve, as they are always associated with the same Secret Key, and infer the relationship between Alice and Eve and impose surveillance.

In this regard, Fiber adopts PTLC, which improves privacy on the basis of HTLC. Each PTLC in the payment path is unlocked with a different Secret Key, and simply observing the Secret Key required by PTLC cannot determine their correlation. By combining PTLC with onion routing, Fiber can become an ideal solution for private payments.

In addition, the traditional Lighting Network is vulnerable to a “replacement cycling attack”, which can result in the assets of payment path middleman being stolen. This discovery even led developer Antoine Riard to withdraw from the development work on the Lighting Network. So far, BTCLighting Network has not implemented fundamental measures to address this issue, making it a pain point.

Currently, the CKB official can solve the above attack scenario by improving it at the transaction pool level with Fiber. Since the alternative transaction loop attack and solution are quite complicated, this article does not intend to continue to explain it in detail. If you are interested, you can read the following articles by BTCStudy and read related materials from the CKB official.

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

Cross-domain Atomic Payments between Fiber and BTCLighting Network

By using HTLC and PTLC, Fiber can achieve cross-domain payments with BTCLighting Network, and ensure the ‘atomicity of cross-domain actions’, meaning that all related steps of cross-domain transactions will either all succeed or all fail, with no partial success or failure.

After the cross-domain atomicity is guaranteed, it can ensure that the cross-domain itself will not cause property loss, so Fiber and BTCLighting Network can be interconnected, for example, it can build a payment path in the hybrid network composed of Fiber and Lighting Network, and directly transfer funds from Fiber to users in BTCLighting Network (the receiving end is limited to BTC), and it can also exchange CKB and RGB++ assets in Fiber for equivalent BTC in BTCLighting Network.

Let’s explain the principle simply: Assuming Alice runs a Node in the Fiber network, and Bob runs a Node in the BTCLighting Network. If Alice wants to transfer some money to Bob, it can be achieved by cross-domain intermediary Ingrid. Specifically, Ingrid will run Nodes in both the Fiber and BTCLighting Network and act as the 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 can send 1 BTC to Bob in BTCLighting Network, with 0.1 CKB left as a transaction fee.

Ingrid

It should be noted that the cross-domain transactions that occurred in BTCLighting Network and Fiber are atomic, which means that either both HTLCs are unlocked and the cross-domain payment is successfully executed, or neither are unlocked and the cross-domain payment fails. There will be no situation where Alice gives money but Bob does not receive it.

(In fact, the middleman Ingrid can choose not to unlock Alice’s HTLC after knowing the key R, but this will harm Ingrid as the middleman, not the user Alice, so Fiber’s design is safe for users)

This method does not require trust in a third party and can achieve transfer behavior between different P2P networks with almost no modification.

The advantages of Fiber compared to other advantages of BTCLighting Network

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

In addition, the ** BTCLighting Network has a major pain point, which is the Liquidity management issue. ** You may remember what we said at the beginning, the overall balance in the payment channel is fixed. If one party’s balance is exhausted, it cannot transfer money to the other party unless the other party transfers money to it first. At this time, funds need to be reinjected or a new channel needs to be opened.

In addition, if it is in a complex multi-hop network, some intermediate Nodes with insufficient balance may not be able to transfer funds outward, which may lead to the failure of the entire payment path. This is one of the pain points of the Lighting Network, and the solution to this is nothing more than providing an efficient Liquidity injection plan to ensure that most Nodes can inject funds at any time.

However, in the BTCLighting Network, the steps of injecting Liquidity, opening or closing channels are all done on the BTC chain. If the transaction fees on the BTC network are extremely high, it will have a negative impact on the UX of payment channels. Suppose you want to open a channel with a capacity of $100, but it costs $10 in fees to establish the channel. This means that 10% of your funds are lost when the channel is initialized, which is unacceptable for most people; the same applies to Liquidity injection and other tasks.

Fiber has very significant advantages in this regard. First of all, CKB’s TPS is much higher than BTC’s, and the transaction fees can be as low as cents; secondly, in order to address the problem of insufficient Liquidity leading to the inability to transfer, Fiber plans to cooperate with the Mercury layer to launch a new solution, allowing the work of injecting Liquidity to bypass on-chain operations, solving UX and cost issues.

So far, we have systematically sorted out the overall technical architecture of Fiber, and summarized the general comparison with BTCLighting Network as shown in the above figure. Due to the extensive and diverse knowledge involved in Fiber and Lighting Network themselves, a single article may not cover all aspects. **In the future, we will launch a series of articles on the topics of Lighting Network and Fiber, so stay tuned.