Forward the Original Title ‘系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验’

On August 23, CKB officially released the Fiber Network, a Lightning Network solution based on CKB. This news quickly sparked intense discussion in the community, leading to a nearly 30% surge in CKB’s price within a single day. The strong reaction can be attributed to the compelling narrative of the Lightning Network and the fact that Fiber offers an upgraded solution over the traditional Lightning Network with numerous improvements. For instance, Fiber supports multiple asset types natively, including CKB, BTC, and stablecoins, and benefits from CKB’s lower transaction fees and faster response times, which enable significant UX advancements. Additionally, Fiber has made several optimizations in terms of privacy and security. Furthermore, Fiber and the BTC Lightning Network can interconnect, forming a larger P2P network. CKB’s officials even mentioned that they plan to set up 100,000 physical nodes in Fiber and the Lightning Network during offline events to enhance and advance the P2P payment network. This undoubtedly represents a grand and unprecedented story

If CKB’s official vision is realized in the future, it would be a significant boon for the Lightning Network, CKB, and the broader Bitcoin ecosystem. According to mempool data, the BTC Lightning Network currently holds over $300 million in funds, with approximately 12,000 nodes and nearly 50,000 payment channels established between them.

On spendmybtc.com, we can observe that an increasing number of merchants are supporting Lightning Network payments. As BTC’s recognition grows, the rise of off-chain payment solutions like the Lightning Network and Fiber will likely gain momentum. To systematically analyze the technical solution of Fiber, “Geek Web3” has produced this research report on the overall Fiber solution. As an implementation of the Lightning Network based on CKB, Fiber’s principles are largely consistent with the Bitcoin Lightning Network but include optimizations in many details. Fiber’s overall architecture comprises four core components: payment channels, WatchTower, multi-hop routing, and cross-domain payments. Let’s start by explaining the most important component: payment channels.

The Foundation of the Lightning Network and Fiber: Payment Channels

Payment channels essentially move transactions off-chain, with the final state settled on-chain after some time. Since transactions are completed off-chain, they often bypass the performance limitations of the main chain, such as BTC. For example, if Alice and Bob open a channel together, they first create a multi-signature account on-chain and deposit some funds, say 100 units each, as their balance in the off-chain channel. They can then conduct multiple transactions within the channel, and when they close the channel, they synchronize the final balances on-chain, with the multi-signature account making payments to both parties—this is the “settlement.”

For instance, if both parties start with 100 units each, and Alice transfers 50 units to Bob, followed by another transfer of 10 units, and then Bob transfers 30 units back to Alice, their final balances would be: Alice—70 units, Bob—130 units. The total balance remains unchanged, as illustrated by the abacus beads example. If one party exits the channel, the final balances (Alice: 70, Bob: 130) are synchronized on-chain, and the multi-signature account’s 200 units are distributed according to these final balances to complete the settlement.

Although this process seems straightforward, it involves complex considerations in practice. You can’t predict when the other party will choose to exit the channel. For example, Bob could exit after the second transaction or even after the first one, as the channel allows participants to exit freely. To address this, the system assumes that anyone might exit at any time, and either party could submit the final balance to the chain for settlement. This is managed through “commitment transactions,” which record the latest balances in the channel. Each transaction generates a corresponding commitment transaction. To exit the channel, you submit the most recent commitment transaction to the chain to withdraw your share from the multi-signature account.

We can conclude that commitment transactions are used to settle the balances of both parties in the channel on-chain, with either party able to submit the latest commitment transaction to exit the channel. However, there’s a crucial malicious scenario: Bob might submit an outdated balance and commitment transaction to the chain. For example, after generating Commit Tx3, Bob’s balance is 130 units. But to his advantage, Bob might submit the outdated Commit Tx2, which shows a balance of 160 units. This outdated balance represents a classic “double-spending” attack.

To prevent such double-spending scenarios, there must be appropriate penalty measures. The design of these penalty measures is at the core of the one-to-one payment channel system, and understanding this is essential to grasp how payment channels work. In the channel design, if either party submits an outdated state and commitment transaction to the chain, instead of benefiting, they will find that the other party can withdraw all the funds. This utilizes the concepts of “asymmetric commitment transactions” and “revocation keys,” which are crucial. Let’s first explain “asymmetric commitment transactions” using Commit Tx3 as an example.

In this scenario, Bob creates a commitment transaction and sends it to Alice for her handling. As shown, this transaction involves a Bitcoin transfer, declaring that 70 units from the multi-signature account are allocated to Alice and 130 units to Bob. However, the unlocking conditions are “asymmetric,” placing harsher restrictions on Alice and benefiting Bob.

When Alice receives the commitment transaction from Bob, she can add her signature to meet the 2/2 multi-signature requirement. Alice can then choose to submit this commitment transaction on-chain to exit the channel. Alternatively, she can continue to make transactions within the channel if she does not submit it.

It’s crucial to note that this commitment transaction is constructed by Bob and has conditions unfavorable to Alice. Alice has the choice to either accept or reject it, but we need to ensure she retains some autonomy. In the design of payment channels, only Alice can submit the “unfavorable” commitment transaction to the chain because commitment transactions require a 2/2 multi-signature. After Bob constructs the transaction locally, it only has his signature and lacks Alice’s signature.

Alice can “accept Bob’s signature but withhold her own.” This is similar to a contract that requires dual signatures. If Bob signs first and sends the contract to Alice, she can choose not to provide her signature. To make the contract effective, Alice would need to sign and then submit it; otherwise, she can refrain from signing or submitting it. Thus, in this case, Alice has the means to limit Bob’s actions.

Here’s the key point: Each time a transaction occurs within the channel, a pair of commitment transactions is generated, with two mirrored versions, as illustrated below. Alice and Bob can each create commitment transactions that are favorable to themselves, specifying their respective balances or amounts to be received upon exit, and then send these transactions to each other for handling.

Interestingly, while the two commitment transactions declare the same “amount to be received upon exit,” their withdrawal conditions differ. This illustrates the concept of “asymmetric commitment transactions” mentioned earlier.

As previously explained, each commitment transaction requires a 2/2 multi-signature to be valid. The commitment transaction created by Bob that favors himself does not meet the 2/2 multi-signature requirement, while the commitment transaction that meets this requirement is held by Alice and can only be submitted by her, creating a check-and-balance mechanism. The same logic applies in reverse.

Thus, Alice and Bob can only submit commitment transactions that are unfavorable to themselves. If either party submits a commitment transaction to the chain and it becomes effective, the channel is closed.

Regarding the earlier discussed “double-spending” scenario, if someone submits an outdated commitment transaction to the chain, the concept of “revocation keys” comes into play. For example, if Bob submits the outdated Tx2 to the chain, Alice can use the revocation key associated with Tx2 to withdraw the funds Bob was supposed to receive.

In the example diagram, assuming the latest commitment transaction is Commit Tx3 and Tx2 is outdated, if Bob submits the outdated Tx2, Alice can act within the time lock period using Tx2’s revocation key to withdraw Bob’s funds.

Regarding the latest Tx3, Alice does not possess its revocation key and will only receive it after Tx4 is created in the future. This is due to the nature of public/private key cryptography and UTXO properties. For brevity, the implementation details of revocation keys are not discussed here.

The key takeaway is that if Bob dares to submit an outdated commitment transaction to the chain, Alice can use the revocation key to withdraw Bob’s funds as a penalty. Similarly, if Alice acts maliciously, Bob can apply the same penalty against her. This mechanism ensures that one-to-one payment channels effectively prevent double-spending, as rational participants would avoid malicious actions.

In this context, Fiber, based on CKB, offers substantial improvements over the Bitcoin Lightning Network. It natively supports transactions and transfers of multiple asset types, including CKB, BTC, and RGB++ stablecoins, whereas the Lightning Network natively supports only Bitcoin. Even with the Taproot Asset upgrade, the Bitcoin Lightning Network still cannot natively support non-BTC assets and can only indirectly support stablecoins.

(Images source: Dapangdun) Additionally, because Fiber relies on CKB as its Layer 1 main chain, the fees for opening and closing channels are significantly lower compared to the BTC Lightning Network. This reduces the user’s transaction costs, representing a clear advantage in terms of user experience (UX).

24/7 security: WatchTower

A challenge with revocation keys is that channel participants must constantly monitor each other to prevent the submission of outdated commitment transactions. However, no one can be online 24/7, so what happens if one party acts maliciously while the other is offline? Both Fiber and the Bitcoin Lightning Network address this issue with the design of WatchTowers.

WatchTowers are designed to monitor on-chain activities around the clock. If someone submits an outdated commitment transaction, the WatchTower will take timely action to protect the channel and funds. Here’s how it works:

ted commitment transaction, Alice or Bob can prepare a corresponding penalty transaction in advance (using the revocation key to handle the outdated commitment transaction, with the beneficiary declared as themselves). They then provide the plaintext of this penalty transaction to the WatchTower.

When the WatchTower detects an outdated commitment transaction being submitted to the chain, it will also submit the prepared penalty transaction, enforcing the penalty and safeguarding the channel’s integrity.

Fiber protects participants’ privacy by requiring users to send only the “hash of the outdated commitment transaction + plaintext of the penalty transaction” to the WatchTower. This way, the WatchTower initially only knows the hash of the commitment transaction, not its plaintext. The WatchTower only sees the plaintext if someone actually submits the outdated commitment transaction on-chain, at which point it will also submit the penalty transaction. This ensures that the WatchTower will only see a participant’s transaction record if there is actual wrongdoing, and even then, it will see only a single transaction.

In terms of optimization, Fiber improves upon the Bitcoin Lightning Network’s approach to penalty mechanisms. The Lightning Network’s “LN-Penalty” has a notable drawback: WatchTowers must store all outdated commitment transaction hashes and corresponding revocation keys, leading to significant storage pressure. In 2018, the Bitcoin community proposed a solution called “eltoo” to address this issue. Eltoo would allow the latest commitment transaction to penalize outdated ones, reducing the need to store all previous transactions. However, this solution requires the activation of the SIGHASH_ANYPREVOUT opcode, which has not yet been implemented.

Fiber, on the other hand, employs the Daric protocol, which modifies the revocation key design to make a single revocation key applicable to multiple outdated commitment transactions. This approach greatly reduces storage demands for WatchTowers and user clients.

Regarding network traffic systems: Payment channels are suited for one-to-one transactions, but the Lightning Network supports multi-hop payments, allowing transactions between parties who do not have a direct channel by routing through intermediary nodes. For example, if Alice and Ken do not have a direct channel but Ken and Bob do, and Bob and Alice do, Bob can act as an intermediary to facilitate transactions between Alice and Ken.

“Multi-hop routing” enhances network flexibility and coverage. However, senders need to be aware of the status of all public nodes and channels. In Fiber, the entire network structure, including all public channels, is fully transparent, allowing any node to access network information from other nodes. Since the network state in the Lightning Network is constantly changing, Fiber uses the Dijkstra algorithm to find the shortest routing path, minimizing the number of intermediaries and establishing a transaction path between the two parties.

To address the trust issue with intermediaries: How can you ensure they are honest? For instance, if Alice needs to make a payment of 100 units to Ken, but Bob, who is an intermediary between them, might withhold the funds. HTLC and PTLC are used to prevent such malicious behavior. Suppose Alice wants to pay Daniel 100 units, but they do not have a direct channel. Alice finds that she can route the payment through intermediaries Bob and Carol. HTLC is introduced as the payment channel: Alice first initiates the request to Daniel, who then provides Alice with a hash r, but Alice does not know the preimage R corresponding to r.

Then, Alice constructs the payment terms with Bob via HTLC: Alice is willing to pay Bob 102 units, 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 units, but Carol must reveal the key R within 25 minutes; otherwise, Bob will withdraw the money. Carol does the same with Daniel: Carol is willing to pay Daniel 100 units, but Daniel must reveal the key R within 20 minutes; otherwise, Carol will withdraw the money.

Daniel understands that the key R requested by Carol is actually what Alice wants, as only Alice is interested in the value of R. So, Daniel cooperates with Carol, provides the key R, and receives 100 units from Carol. This way, Alice achieves her goal of paying Daniel 100 units.

Subsequently, Carol provides the key R to Bob and receives 101 units. Bob then provides the key R to Alice and receives 102 units. Observing the gains and losses for everyone, Alice loses 102 units, Bob and Carol each earn a net of 1 unit, and Daniel receives 100 units. The 1 unit earned by Bob and Carol is their fee extracted from Alice.

Even if someone in the payment path, such as Carol, fails to provide the key R to the downstream Bob, it does not result in a loss for Bob: after the timeout, Bob can withdraw the HTLC he constructed. The same applies to Alice. However, the Lightning Network has its issues: paths should not be too long. If the path is too lengthy with too many intermediaries, it can reduce payment reliability. Some intermediaries may be offline or lack sufficient balance to construct a specific HTLC (e.g., each intermediary in the previous example needs to hold over 100 units). Therefore, adding more intermediaries increases the likelihood of errors.

Additionally, HTLCs may leak privacy. Although onion routing can provide some privacy protection by encrypting the routing information at each hop, so that each participant only knows their immediate neighbors and not the complete path, HTLCs are still susceptible to inference of relationships. From a higher perspective, the complete routing path may still be deduced.

Assume that Bob and Daniel are controlled by the same entity and receive many HTLCs every day. They notice that the key R requested by Alice and Carol is always the same, and that 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, as they always deal with the same key and can monitor their relationship. To address this, Fiber uses PTLCs, which enhance privacy over HTLCs by using different keys to unlock each PTLC in the payment path. Observing PTLCs alone cannot determine the relationships between nodes. By combining PTLCs with onion routing, Fiber becomes an ideal solution for privacy-preserving payments.

Additionally, the traditional Lightning Network is vulnerable to a “replacement cycling attack,” which can result in the theft of assets from intermediaries in the payment path. This issue led developer Antoine Riard to withdraw from Lightning Network development. As of now, the Bitcoin Lightning Network lacks a fundamental solution to this problem, making it a pain point. Currently, CKB addresses this attack scenario through improvements at the transaction pool level, allowing Fiber to mitigate the issue. As the replacement cycling attack and its solutions are quite complex, this article will not delve further into it. Interested readers can refer to related articles from BTCStudy and official CKB resources for more information.

Overall, Fiber represents a significant improvement over the traditional Lightning Network in both privacy and security aspects. Fiber enhances cross-domain atomic payments between itself and the Bitcoin Lightning Network.

Using HTLC and PTLC, Fiber can achieve cross-domain payments with the Bitcoin Lightning Network, ensuring “atomicity of cross-domain actions,” meaning all steps of the cross-domain transaction either fully succeed or fully fail, with no partial success or failure. With cross-domain atomicity assured, the risk of asset loss is mitigated. This allows Fiber to interconnect with the Bitcoin Lightning Network, enabling direct payments from Fiber to users in the BTC Lightning Network (with the receiver limited to BTC) and allowing conversions of CK

B and RGB++ assets into equivalent Bitcoin within the BTC Lightning Network.

Here’s a simplified explanation of the process: Suppose Alice operates a node within the Fiber network, and Bob operates a node within the Bitcoin Lightning Network. If Alice wants to transfer some money to Bob, she can do so via a cross-domain intermediary, Ingrid. Ingrid will run nodes in both the Fiber and BTC Lightning Networks, acting as the intermediary in the payment path.

If Bob wants to receive 1 BTC, Alice can negotiate an exchange rate with Ingrid, setting 1 CKB equal to 1 BTC. Alice would then send 1.1 CKB to Ingrid within the Fiber network, and Ingrid would send 1 BTC to Bob in the Bitcoin Lightning Network, keeping 0.1 CKB as a fee.

The process involves establishing a payment path between Alice, Ingrid, and Bob, using HTLC. Bob must provide Ingrid with the key R to receive the funds. Once Ingrid has the key R, she can unlock the funds Alice locked in the HTLC.

The cross-domain actions between the BTC Lightning Network and Fiber are atomic, meaning either both HTLCs are unlocked and the cross-domain payment is successfully executed, or neither is unlocked and the payment fails. This ensures that Alice does not lose money if Bob does not receive it.

Ingrid could potentially not unlock Alice’s HTLC after knowing the key R, but this would harm Ingrid, not Alice. Therefore, the design of Fiber ensures safety for users and requires no trust in third parties, enabling transfers between different P2P networks with minimal modifications.

Other advantages of Fiber compared to BTC Lightning Network

Earlier, we mentioned that Fiber supports native CKB assets and RGB++ assets (especially stablecoins), giving it significant potential for real-time payments and making it well-suited for daily small transactions.

In contrast, a major issue with the Bitcoin Lightning Network is liquidity management. As we discussed at the beginning, the total balance in a payment channel is fixed. If one party’s balance is depleted, they cannot transfer funds to the other party unless the other party sends money first. This requires reloading funds or opening a new channel.

Additionally, in a complex multi-hop network, if some intermediate nodes have insufficient balance and cannot forward payments, it may cause the entire payment path to fail. This is one of the pain points of the Lightning Network. The typical solution involves providing efficient liquidity injection mechanisms to ensure that most nodes can inject funds as needed.

However, in the Bitcoin Lightning Network, liquidity injection, as well as channel opening or closing, all occur on the Bitcoin blockchain. If Bitcoin network fees are very high, it negatively impacts the user experience of payment channels. For example, if you want to open a channel with a capacity of $100 but the setup fee is $10, this means 10% of your funds are consumed just to set up the channel, which is unacceptable to most users. The same issue applies to liquidity injection.

In contrast, Fiber offers significant advantages. Firstly, the TPS (transactions per second) of CKB is much higher than that of Bitcoin, with fees reaching cent-level costs. Secondly, to address the issue of liquidity shortages and ensure smooth transactions, Fiber plans to collaborate with Mercury Layer to introduce new solutions that eliminate the need for on-chain operations for liquidity injection, thus solving UX and cost issues.

We have now systematically outlined the overall technical architecture of Fiber, with a summary comparing it to the Bitcoin Lightning Network as shown in the image above. Given the complexity and breadth of topics covered by both Fiber and the Lightning Network, a single article may not be able to address every aspect. We will be releasing a series of articles in the future focusing on various aspects of both the Lightning Network and Fiber. Stay tuned for more updates.

Disclaimer：

1. This article is reprinted from [极客web3]. Forward the Original Title ‘系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验’. All copyrights belong to the original author [Faust & Nickqiao，极客web3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.