Author: Faust & Nickqiao, Geek Web3; Original link: System Interpretation of Fiber: A Grand Experiment of Integrating Lightning Network into CKB
On August 23, the CKB team released a Lightning Network solution based on CKB — Fiber Network. This news quickly sparked heated discussions in the community, causing the CKB price to rise nearly 30% in a single day. The strong reaction to the news is mainly due to the powerful narrative appeal of the Lightning Network, and Fiber's upgrades to the traditional Lightning Network, which made many improvements.
For example, Fiber can natively support multiple types of assets, such as CKB, BTC, stablecoins, etc., and the transaction fees on CKB are much lower than those on BTC, with faster response times, allowing Fiber to achieve breakthroughs in UX. Additionally, Fiber has made numerous optimizations in terms of privacy and security.
Moreover, Fiber and the BTC Lightning Network can interconnect, forming a larger P2P network. In previous offline events, the CKB team even stated that they would set up 100,000 physical nodes in Fiber and the Lightning Network to promote the improvement and advancement of the P2P payment network. Undoubtedly, this is an unprecedented grand story.
If the CKB team's vision is realized in the future, it will be a huge boon for both the Lightning Network and CKB, as well as the Bitcoin ecosystem. According to mempool data, currently, over $300 million is allocated in the BTC Lightning Network, with approximately 12,000 nodes, creating nearly 50,000 payment channels among them.
On spendmybtc.com, we can also see an increasing number of merchants supporting Lightning Network payments. As the recognition of BTC grows stronger, the momentum for the rise of off-chain payment solutions like the Lightning Network and Fiber will undoubtedly increase day by day.
With the aim of systematically interpreting Fiber's technical solution, Geek Web3 has written this research report on the overall Fiber scheme. As a Lightning Network implementation based on CKB, Fiber's principles are largely consistent with those of the Bitcoin Lightning Network, but many optimizations have been made in various details.
The overall architecture of Fiber includes the following four core components: payment channels, Watchtower, multi-hop routing, and cross-domain payments. Below, we will first explain the most important "payment channels."
The Cornerstone of the Lightning Network and Fiber: Payment Channels#
Payment channels essentially move transfers/transactions off-chain, and after a period, the final state is submitted on-chain for "settlement." Since transactions are completed off-chain in real-time, they can often escape the performance limitations of main chains like BTC.
Suppose Alice and Bob jointly open a channel. They first create a multi-signature account on-chain and deposit some money into it, for example, Alice and Bob each deposit 100 units as their respective balances in the off-chain channel. Next, both parties can conduct multiple transfers within the channel, and when exiting the channel, they synchronize the final balances on-chain, with the multi-signature account making payments to both parties, i.e., "settlement."
For instance, if both start with 100 units, Alice transfers 50 to Bob, then Alice transfers another 10 to Bob, and later Bob transfers 30 back to Alice, the final balances become: Alice — 70, Bob — 130. It is easy to see that the total balance of both remains unchanged; the example of the abacus beads moving back and forth illustrates this point well.
If one party exits the channel, the current balances Alice: 70/Bob: 130 are synchronized on-chain, and the 200 units in the multi-signature account are distributed according to their respective balances, completing the settlement. The above process seems simple, but many complex situations must be considered in practice.
First, you actually do not know when the other party wants to exit the channel. In the previous example, Bob could exit after the second transfer or even after the first transfer, and the payment channel does not enforce any mandatory exit; it allows participants to exit freely. To achieve this, it must be assumed that someone may exit at any time, and either party may submit the final balance on-chain for settlement.
Thus, there is a setting for a "commitment transaction," which is used to declare the latest balances of both parties in the channel, and a corresponding "commitment transaction" is generated every time a transfer occurs. If you want to exit the channel, you can submit the latest "commitment transaction" on-chain to withdraw your entitled funds from the multi-signature account.
We can note this conclusion: commitment transactions are used for on-chain settlement of the balances of both parties in the channel, and either party can submit the latest commitment transaction to exit the channel at any time.
However, there is an important malicious scenario: Bob can submit an outdated balance and commitment transaction on-chain. For example, after the generation of Commit Tx3 in the above image, Bob's balance is 130, but to profit himself, Bob submits the outdated Commit Tx2 on-chain, claiming his balance is 160, which is not the real-time balance. This is a typical "double spending."
To prevent such double spending scenarios, there must be corresponding punitive measures, and the design of these punitive measures is precisely the core of the entire 1-to-1 payment channel. Understanding this part is essential to truly grasp payment channels. In the design of the channel, if either party submits an outdated state and Commit Tx on-chain, they will not only fail to achieve their goal but will also have all their funds taken by the other party.
This involves the concepts of "asymmetric commitment transactions" and "revocation keys," both of which are very important. We will first explain "asymmetric commitment transactions." Taking the previous Commit Tx3 as an example, the following image illustrates the commitment transaction:
This commitment transaction is constructed by Bob and then sent to Alice for her to handle. As shown, this is a Bitcoin transfer, declaring that 70 units from the multi-signature account go to Alice and 130 units to Bob, but the unlocking conditions are "asymmetric," with Alice facing stricter limitations, which is more favorable to Bob.
After Alice receives the commitment transaction constructed by Bob, she can attach her signature to satisfy the 2/2 multi-signature requirement. Then Alice can proactively submit the "commitment transaction" on-chain, allowing her to exit the channel; if she does not do this, she can continue to transfer funds within the channel.
Here we need to note: this commitment transaction is actively constructed by Bob, and the conditions are unfavorable to Alice. Alice can only accept or reject it, so we need to find a way to give Alice some autonomy. In the design of the payment channel, only Alice herself can put the "unfavorable" commitment transaction on-chain to trigger it because the commitment transaction requires a 2/2 multi-signature, and after Bob constructs the transaction locally, he only has his signature, not Alice's.
Alice can "only receive Bob's signature but not send her own signature to him," which is akin to a contract that is unfavorable to you, requiring dual signatures from you and another party. The other party signs first and then gives you the document, and you can prevent the other party from obtaining your signature. If you want the contract to take effect, you sign and then publicize it; if you do not want it to take effect, you do not sign or publicize it. Clearly, in the above case, Alice has a way to restrict Bob.
Now we come to the key point: every time a transfer occurs in the channel, a pair of commitment transactions will appear, with two similar mirrored versions, as shown below. Alice and Bob can each construct commitment transactions favorable to themselves, declaring the amounts they should receive upon exit, and then send the transaction content to each other for processing.
Interestingly, these two commitment transactions declare the "amount received upon exit" as the same, but the withdrawal conditions differ, which is precisely the origin of the earlier mentioned "asymmetric commitment transactions."
As explained earlier, each commitment transaction requires a 2/2 multi-signature to take effect. The commitment transaction constructed locally by Bob, which is favorable to him, does not meet the 2/2 multi-signature requirement, while the commitment transaction that satisfies the 2/2 multi-signature is held by Alice, and Bob cannot submit it; it can only be submitted by Alice, thus forming a check and balance. The reverse is also true.
In this way, Alice and Bob can only actively submit commitment transactions that are unfavorable to themselves. As long as one party submits the Commit Tx on-chain and it takes effect, the channel will be closed. Returning to the earlier "double spending" scenario, what happens if someone submits an outdated commitment transaction on-chain?
Here we need to mention something called the "revocation key." If Bob submits an outdated commitment transaction on-chain, Alice can use the revocation key to withdraw the funds that Bob is entitled to.
Looking at the following image, suppose the latest commitment transaction is Commit Tx3, and Commit Tx2 is outdated. If Bob submits the outdated Tx2 on-chain, Alice can use the revocation key of Tx2 to withdraw Bob's funds (Alice must act within the time lock range).
For the latest Tx3, Alice does not have its revocation key; she can only obtain the revocation key for Tx3 after the future Tx4 appears. This is determined by the characteristics of public-private key cryptography and UTXO, and due to space constraints, this article will not delve into the implementation principles of revocation keys.
We can remember this conclusion: as long as Bob dares to submit an outdated commitment transaction on-chain, Alice can use the revocation key to take Bob's money as a punishment. Conversely, if Alice acts maliciously, Bob can punish her in the same way. In this way, the 1-to-1 payment channel can effectively prevent double spending, as long as the participants are rational individuals, they will not dare to act maliciously.
Regarding payment channels, Fiber based on CKB has significantly optimized compared to the Bitcoin Lightning Network, enabling native support for transfers/transactions of multiple asset types, such as CKB, BTC, and RGB++ stablecoins, while the Lightning Network can only natively support Bitcoin. Even with 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)
(Image source: Dapangdun)
Additionally, since the L1 main chain that Fiber relies on is CKB, the fees for opening and closing channels are much lower, and it does not grind away a lot of fees from users like the BTC Lightning Network, which is a clear advantage in UX.
24/7 Security: Watchtower#
The revocation key mentioned earlier has a problem: channel participants need to constantly monitor each other to prevent the other party from sneakily submitting outdated commitment transactions on-chain. But no one can guarantee being online 24 hours a day; what if the other party acts maliciously while you are offline?
To address this, both Fiber and the Bitcoin Lightning Network have designed Watchtower, which helps users monitor on-chain activities around the clock. If someone in the channel submits an outdated commitment transaction, the Watchtower will handle it promptly to ensure the safety of the channel and funds.
The specific explanation is as follows: For each outdated commitment transaction, Alice or Bob can pre-construct the corresponding penalty transaction (using the revocation key to handle the outdated commitment transaction, with the beneficiary declared as themselves) and then send the plaintext of the penalty transaction to the Watchtower. Once the Watchtower detects that someone has submitted an outdated commitment transaction on-chain, it will also submit the penalty transaction on-chain for targeted punishment.
To protect the privacy of channel participants, Fiber only allows users to send the "hash of the outdated commitment transaction + plaintext of the penalty transaction" to the Watchtower, so the Watchtower initially does not know the plaintext of the commitment transaction, only its hash. Unless someone actually submits the outdated commitment transaction on-chain, the Watchtower will see the plaintext and then promptly submit the penalty transaction on-chain. In this way, unless someone truly acts maliciously, the Watchtower will not see the transaction records of channel participants (even if it does, it can only see one of them).
Here we need to mention the optimization of Fiber compared to the Bitcoin Lightning Network. The aforementioned penalty mechanism related to the revocation key is called "LN-Penalty," and the Bitcoin Lightning Network's LN-Penalty has obvious drawbacks: the Watchtower must store all the hashes of outdated commitment transactions and the corresponding revocation keys, which can create significant storage pressure.
As early as 2018, the Bitcoin community proposed a solution called "eltoo" to address this issue, but it requires a Bitcoin fork to support the SIGHASH_ANYPREVOUT opcode. The idea is that when an outdated commitment transaction is on-chain, the latest commitment transaction can punish it, allowing users to only store the latest commitment transaction. However, the SIGHASH_ANYPREVOUT opcode has yet to be activated, and the solution has not been implemented.
Fiber has implemented the Daric protocol, modifying the design of the revocation key so that the same revocation key applies to multiple outdated commitment transactions. This can significantly reduce the storage pressure on the Watchtower and user clients.
The Traffic System in the Network: Multi-hop Routing and HTLC/PTLC#
The payment channels discussed earlier are only suitable for 1-to-1 transaction scenarios, while the Lightning Network supports multi-hop payments, meaning that transfers can occur between two parties that do not have a direct channel by routing through intermediate nodes. For example, if Alice and Ken do not have a channel, but Ken has a channel with Bob, and Bob has a channel with Alice, Bob can act as an intermediary between Alice and Ken, allowing them to transfer funds. "Multi-hop routing" refers to establishing a transfer path through multiple intermediaries.
"Multi-hop routing" enhances the flexibility and coverage of the network. However, the sender needs to be aware of the status of all public nodes and channels. In Fiber, all public channels and network structures are completely transparent, and any node can access the network information held by other nodes. Since the state of the entire network in the Lightning Network is constantly changing, Fiber will use Dijkstra's shortest path algorithm to find the shortest routing path, minimizing the number of intermediaries and establishing a transfer path between the two parties.
However, there is a need to address the trust issue with intermediate nodes: how do you ensure they are honest? For instance, if Alice wants to transfer 100 units to Ken through the intermediary Bob, Bob could potentially withhold the funds. To prevent intermediaries from acting maliciously, HTLC and PTLC are used to solve such problems.
Suppose Alice wants to pay Daniel 100 units, but they do not have a channel established. Alice discovers that she can pay Daniel through the two intermediaries Bob and Carol. In this case, HTLC is introduced as the payment channel. First, Alice initiates a request to Daniel, who then sends Alice a hash r, but Alice does not know the plaintext R corresponding to r.
Next, Alice constructs payment terms through HTLC in her channel with Bob: Alice is willing to pay Bob 102 units, but Bob must reveal the key R within 30 minutes; otherwise, Alice will withdraw her funds. Similarly, Bob creates an HTLC with Carol: Bob will pay Carol 101 units, but Carol must reveal the key R within 25 minutes; otherwise, Bob will withdraw his funds.
Carol follows suit and creates an HTLC in her channel with Daniel: Carol is willing to pay 100 units, but Daniel must tell her the plaintext R within 20 minutes; otherwise, the funds will be returned to Carol.
Daniel understands that the key R requested by Carol is actually what Alice wants because no one else cares about the content of R. Therefore, Daniel cooperates with Carol, tells her the content of R, and receives 100 units from Carol, allowing Alice to achieve her goal of paying Daniel 100 units.
The subsequent events are easy to imagine: Carol tells Bob the key R and receives 101 units; Bob then tells Alice the key R and receives 102 units. Observing everyone's gains and losses, we can see that Alice loses 102 units, while Bob and Carol each net 1 unit, and Daniel receives 100 units. The 1 unit earned by Bob and Carol is the fee they extracted from Alice.
Even if someone in the above payment path gets stuck, for example, if Carol does not inform Bob of the key R, Bob will not incur a loss: after a certain time, Bob can withdraw the constructed HTLC. The same applies to Alice.
However, the Lightning Network also has issues: the path should not be too long. If the path is too long with too many intermediaries, it will reduce the reliability of the payment. Some intermediaries may go offline or may not have enough balance to construct a specific HTLC (for example, in the previous case, each intermediary must have over 100 units). Thus, adding an intermediary to the path increases the likelihood of errors.
Additionally, HTLC may leak privacy. Although onion routing can somewhat protect privacy by encrypting the routing information at each hop, so that everyone except the original sender Alice only knows their immediate neighbors and not the complete path, HTLC is still prone to correlation inference. From a bird's-eye view, we can see the following path:
Suppose Bob and Daniel are two nodes controlled by the same entity, and they receive many HTLCs from various users daily. They notice that every time Alice and Carol send HTLCs, the keys they want to know are always the same, while the downstream node Eve connected to Daniel always knows the content of the key R. Therefore, Daniel and Bob can infer that there is a payment path between Alice and Eve because they are always associated with the same key, allowing them to deduce the relationship between Alice and Eve and apply surveillance.
To address this, Fiber adopts PTLC, which improves privacy on the basis of HTLC. Each PTLC in the payment path uses a different key for unlocking, making it impossible to determine the correlation between them by merely observing the keys requested by PTLC. By combining PTLC with onion routing, Fiber can become an ideal solution for privacy payments.
Furthermore, the traditional Lightning Network has a scenario known as "replacement cycling attack," which can lead to the theft of assets from the intermediaries in the payment path. This discovery even led developer Antoine Riard to withdraw from Lightning Network development. To date, the Bitcoin Lightning Network has not implemented fundamental measures to address this issue, which has become a pain point.
Currently, the CKB team has improved the transaction pool layer to allow Fiber to address the aforementioned attack scenarios. Since the replacement cycling attack and its solutions are quite complex, this article will not delve further into the explanation. Interested readers can refer to the following article from BTCStudy and the relevant materials from CKB:
https://www.btcstudy.org/2023/10/24/how-does-a-lightning-replacement-cycling-attack-work/
Overall, Fiber has made significant improvements over the traditional Lightning Network in both privacy and security.
Cross-Domain Atomic Payments Between Fiber and the Bitcoin Lightning Network#
Using HTLC and PTLC, Fiber can achieve cross-domain payments with the Bitcoin Lightning Network, ensuring the "atomicity of cross-domain actions," meaning that all steps related to cross-domain actions either succeed entirely or fail entirely, with no partial success or failure.
With the guarantee of cross-domain atomicity, it can ensure that cross-domain actions do not lead to property losses, allowing Fiber to interconnect with the Bitcoin Lightning Network. For example, payment paths can be established in a hybrid network composed of Fiber and the Lightning Network, allowing direct transfers from Fiber to users in the BTC Lightning Network (the receiving end is limited to BTC), and also allowing exchanges of equivalent Bitcoin in the BTC Lightning Network using CKB and RGB++ assets.
To briefly explain the principle: suppose Alice runs a node in the Fiber network, while Bob runs a node in the Bitcoin Lightning Network. If Alice wants to transfer some money to Bob, she can achieve this transfer through a cross-domain intermediary, Ingrid. Ingrid will run nodes in both the Fiber and BTC Lightning Networks, acting as an intermediary in the transfer path.
If Bob wants to receive 0.001 BTC, Alice can negotiate the exchange rate with Ingrid, exchanging 7550 CKB for 0.001 BTC. Then Alice sends 7551 CKB to Ingrid in Fiber, and Ingrid sends 0.001 BTC to Bob in the BTC Lightning Network, keeping 1 CKB as a fee.
The specific operational method is essentially establishing a payment path between Alice, Bob, and Ingrid, i.e., Alice → Ingrid → Bob, and HTLC will be used. The reasoning is similar to what was discussed earlier; for Bob to receive the money, he must tell Ingrid the content of the key R. Once Ingrid obtains the key R, she can unlock the funds that Alice locked in the HTLC.
It is important to note that these two cross-domain actions occurring in the BTC Lightning Network and Fiber are atomic, meaning that either both HTLCs are unlocked, and the cross-domain payment is successfully executed, or neither is unlocked, and the cross-domain payment fails, preventing situations where Alice pays but Bob does not receive the funds. (In fact, the intermediary Ingrid could choose not to unlock Alice's HTLC after knowing the key R, but this would harm Ingrid as the intermediary, not the user Alice, so Fiber's design is safe for users.)
This method allows for transfer actions between different P2P networks without requiring trust in third parties and requires almost no modifications.
Other Advantages of Fiber Compared to the BTC Lightning Network#
As mentioned earlier, Fiber supports native CKB assets and RGB++ assets (especially stablecoins), giving it great potential in instant payment scenarios, making it more suitable for everyday small payment needs.
Additionally, the Bitcoin Lightning Network has a major pain point: liquidity management issues. You may recall that we mentioned at the beginning that the total balance in a payment channel is fixed; if one party's balance is exhausted, they cannot transfer funds to the other party unless the other party transfers money to them first, at which point they need to inject new funds or open a new channel.
Moreover, in complex multi-hop networks, if certain intermediate nodes lack sufficient balance to transfer funds outward, it may lead to the failure of the entire payment path. This is one of the pain points of the Lightning Network, and the solutions typically involve providing efficient liquidity injection solutions to ensure that most nodes can inject funds at any time.
However, in the BTC Lightning Network, the steps for injecting liquidity, opening, or closing channels are all conducted on the BTC chain. If the BTC network fees are extremely high, it will negatively impact the UX of payment channels. Suppose you want to open a channel with a capacity of $100, but the operation to establish the channel costs $10 in fees; this would grind away 10% of your funds at initialization, which is unacceptable to most people. The same applies to liquidity injection tasks.
In this regard, Fiber has a significant advantage. First, the TPS of CKB is much higher than that of BTC, and fees can reach the level of cents; second, to address the issue of insufficient liquidity leading to the inability to transfer funds, Fiber plans to collaborate with other teams to launch new solutions that will free liquidity injection tasks from on-chain operations, addressing UX and cost issues.
Thus, we have systematically outlined the overall technical architecture of Fiber, and the comparative summary with the Bitcoin Lightning Network is shown in the above image. Due to the numerous and complex knowledge points involved in Fiber and the Lightning Network, a single article may not cover all aspects. In the future, we will launch a series of articles on the topics of the Lightning Network and Fiber, so stay tuned.