Source: Nervos CKB

In the previous article "How does the Lighting Network work (1)", we discussed the operating principle of the Lighting Network (Lightning Network) and the security-related technologies of bidirectional payment channels. In this article, we will continue to introduce the Lighting Network, explaining the principles and technologies related to extending bidirectional payment channels into the Lighting Network.

Expanding bidirectional payment channels into the Lighting Network: multi-hop routing technology

We also use Alice and Bob to establish channels as the basic background, but what if other people in the world want to join the Lighting Network? Is there a way to connect everyone to the network and ensure that payments can be made to anyone in the network?

To solve this problem, we need to extend the two-way payment channel into a Lighting Network and use multi-hop routing technology. "routing" literally means "finding a path", and in a Lighting Network, it's about finding a path that is connected before and after a channel to pay for a specific object. **

Taking the example of Alice paying 2000 Satoshi to David, assuming that they have not established a payment channel between them, but payment channels have been established between Alice and Bob, Bob and Carol, and Carol and David. In this case, Alice can transfer money to Bob first, then Bob can transfer it to Carol, and finally Carol can transfer it to David. This seems to achieve a payment channel from Alice to David, with Bob and Carol acting as routing nodes in the network. If payment channels are also established between Alice and Eva, and Eva and David, then Alice can also choose to transfer money to Eva first, and then Eva can transfer it to David.

From the perspective of the path, it is obviously the shortest choice for Alice to transfer money to David through EVA, but in the actual operation process, the shortest path may not always be the best choice, because other factors need to be considered, such as the capacity of the channel, the charging standards of the routing node, whether the routing node is online, etc.

Currently, the mainstream BTCLighting Network implementations (clients), such as LND developed by Lightning Labs and CLN (Core Lightning) developed by Blockstream, use a variation of Dijkstra Algorithm for the routing algorithm. The Lighting Network Fiber Network introduced by Nervos CKB will also use Dijkstra Algorithm to find the optimal routing path.

Securing Router Safety: From HTLC to PTLC

In the example where Alice wants to pay David above, how do we ensure that the intermediary Node in the middle does not renege or maliciously withhold funds? TradFi systems typically rely on credit guarantees from large and well-known Financial Intermediary institutions, but the Lighting Network is a P2P network and does not have a third party independent of the traders to provide credit guarantees. We need a different mechanism to ensure transaction security. This is where the role of HTLC (Hashed TimeLock Contract) comes in.

HTLC consists of two parts: hash verification and timeout verification. Let's take the example of Alice wanting to pay 2000 Satoshi to David, and choosing Bob and Carol to act as routing nodes in the network, to understand how HTLC works:

1. First, David needs to generate a secret value R, which can be any word or any number, then calculate its hash value H and send it to Alice. This hash value H will be placed in the locking script of the transaction output. Only the person who knows the secret value R corresponding to H can use this output, and R is called the "preimage" in the Lighting Network. If the secret value R is not disclosed in time, the payment will be unusable, and the sender will reclaim all funds.
2. Then, Alice uses the received hash value H to create an HTLC, with a time lock set to 5 Blocks in the future, and an output amount of 2020 Satoshi, of which 20 Satoshi is for the routing Node Bob's fee. In plain language, Alice will pay Bob 2020 Satoshi, as long as he can provide the secret value R within 5 Blocks; otherwise, the money will be returned to Alice.
3. In Bob's channel with Carol, he creates an HTLC using the same hash value H as provided by Alice, with a time lock set to 4 blocks in the future. The output amount is 2010 Satoshi, of which 10 Satoshi is the transaction fee for routing node Carol. In plain terms, Bob will pay Carol 2010 Satoshi as long as Carol can provide the secret value R within 4 blocks. Otherwise, the money will be returned to Bob.
4. In Carol's and David's channel, Carol uses the same hash value H to create an HTLC with a time lock set to 3 Blocks in the future, with an output amount of 2000 Satoshi. In plain language, Carol will pay David 2000 Satoshi as long as he can provide the secret value R within 3 Blocks; otherwise, the money will be returned to Carol.
5. David unlocks the HTLC set by Carol using secret value R and takes away 2000 Satoshi.
6. After David takes the funds, Carol will also know the secret value R. He uses R to unlock the HTLC set by Bob and takes away 2010 Satoshi.
7. After Carol takes the funds, Bob also gets the secret value R, with which he unlocks the HTLC set by Alice and takes away 2020 Satoshi.

Through this mechanism, Alice successfully paid 2000 Satoshi to David without the need to establish a payment channel directly. Throughout the entire process, there is no need for mutual trust between parties, and the routing Node also receives the appropriate transaction fee. Even if the payment is interrupted at some point, no party will suffer losses due to the existence of a time lock mechanism, and the funds will automatically be returned after the lock-in period.

However, HTLC also has a potential privacy issue: the entire path uses the same secret value (pre-image). If an entity controls multiple nodes on the payment path, it may infer complete transaction information by comparing the inputs and outputs of different nodes, and even guess the payer and payee, which weakens the privacy protection achieved by the Lighting Network through onion routing.

To address this issue, the BTC community proposed the PTLC (Point Time Lock Contract). In the PTLC scheme, each hop in the path uses a different secret value, thereby protecting the privacy achieved through onion routing. Nervos CKB's Lighting Network Fiber Network plan will introduce PTLC in the future to further enhance the privacy protection capabilities of the Lighting Network.

Conclusion

With the continuous progress of technology, the Lighting Network is still being optimized and improved. From LN-Penalty to eltoo and then to Daric, from HTLC to PTLC, we have seen the continuous improvement of the Lighting Network in terms of security, privacy protection, and more. In the future, with the application of more innovative technologies and the improvement of the ecosystem, the Lighting Network is expected to become a key infrastructure for promoting the popularization of Cryptocurrency and contribute to the realization of a true P2P economy.

Reference