Giải mã hệ thống Fiber: Một thí nghiệm lớn về việc gói ghép Mạng Lighting vào CKB

Vào ngày 23 tháng 8, CKB chính thức phát hành giải pháp Fiber Network (Mạng sợi quang) dựa trên CKB - một giải pháp Lighting Network - khi tin tức này lan truyền, nhanh chóng gây ra sự tranh luận trong cộng đồng và đưa giá CKB tăng gần 30% trong một ngày. Lý do tin tức này gây ra sự phản ứng mạnh mẽ chủ yếu là do Lighting Network có sức hấp dẫn về cách kể chuyện mạnh mẽ, trong khi Fiber của CKB đã nâng cấp giải pháp truyền thống Lighting Network và đã thực hiện nhiều cải tiến đối với giải pháp trên.

Ví dụ, Fiber có thể hỗ trợ nhiều loại tài sản nguyên sinh như CKB, BTC, đồng tiền ổn định, vv. Và phí giao dịch của CKB thấp hơn nhiều so với BTC, tốc độ phản hồi nhanh hơn, Fiber có thể đạt được tiến bộ trong UX. Về mặt riêng tư và an ninh, Fiber cũng đã thực hiện nhiều cải tiến.

Ngoài ra, Fiber và BTCLighting Network có thể kết nối và tường tác với nhau, tạo nên mạng P2P lớn hơn, trong các sự kiện ngoại việ trước đây, thậm chính của CKB thậm chính thức địn điểm, sẽ thiết lập 100.000 nói vào cấu trúc của Fiber và Lighting Network, nhằm thúc đầy sự hoàn thiện và tiến bới của Mạng thanh toán P2P. Không có nghi ngị đây là một câu chuyện vào lân cảnh chưa từng có.

Nếu tầm nhìn chính thức của CKB được thực hiện trong tương lai, đối với Lighting Network, CKB và cả hệ sinh thái BTC, đều sẽ là một thông tin tốt lớn. Theo dữ liệu từ mempool, hiện tại có hơn 300 triệu USD được đặt trong BTCLighting Network, với khoảng 12 nghìn nút và gần 50 nghìn kênh thanh toán đã được thiết lập giữa chúng.

Và trên spendmybtc.com, chúng ta cũng có thể thấy ngày càng có nhiều nhà cung cấp hỗ trợ thanh toán thông qua Mạng Lighting, chỉ cần sự chấp nhận của BTC mạnh mẽ hơn, năng lượng tăng trưởng của các giải pháp thanh toán off-chain như Mạng Lighting và Fiber chắc chắn sẽ ngày càng gia tăng.

Với mục tiêu giải thích một cách hệ thống về giải pháp kỹ thuật của Fiber, 《Geek Web3》 đã viết một báo cáo nghiên cứu về toàn bộ giải pháp của Fiber. Là một giải pháp thực hiện dựa trên CKB của Mạng Ánh sáng, nguyên lý của Fiber tương tự nhưng đã được tối ưu hóa ở nhiều chi tiết so với Mạng Ánh sáng BTCLighting.

Cấu trúc tổng quan của Fiber bao gồm bốn phần cốt lõi sau: kênh thanh toán, WatchTower, đa nhảy định tuyến, thanh toán xuyên lĩnh vực. Bây giờ chúng ta sẽ mở rộng giải thích phần quan trọng nhất “kênh thanh toán”.

Lighting Network và Fiber: Căn cứ cho kênh thanh toán

Kênh thanh toán thực chất là chuyển các giao dịch/chuyển tiền sang off-chain để xử lý, và sau đó gửi trạng thái cuối cùng đến on-chain để thực hiện thanh toán. Vì giao dịch được thực hiện ngay trên off-chain, thường có thể tránh được hạn chế về hiệu suất của BTC và các Chuỗi chính khác.

Giả sử Alice và Bob cùng nhau mở một kênh, trước tiên họ xây dựng một tài khoản đa chữ ký trên chuỗi và gửi một số tiền vào đó, ví dụ: Alice và Bob mỗi người gửi 100 nhân dân tệ làm số dư tương ứng của họ trong kênh ngoài chuỗi. **Tiếp theo, hai bên có thể thực hiện nhiều lần chuyển tiền trong kênh và khi thoát khỏi kênh, họ sẽ đồng bộ hóa số dư cuối cùng với trên chuỗi và tài khoản tài khoản đa chữ ký sẽ thực hiện thanh toán cho cả hai bên, tức là “Thanh toán”. **

Ví dụ, lúc đầu mỗi bên có 100 đồng, sau đó Alice chuyển 50 đồng cho Bob, sau đó Alice lại chuyển thêm 10 đồng cho Bob, sau đó Bob lại chuyển 30 đồng cho Alice, cuối cùng số dư của cả hai là: Alice - 70 đồng, Bob - 130 đồng. Mọi người dễ dàng nhận thấy tổng số dư của hai người không thay đổi, ví dụ về việc kéo đẩy hạt tính trong hình dưới đây có thể giải thích điều này tốt.

Nếu một bên thoát khỏi kênh, thì cân bằng hiện tại của Alice: 70/Bob: 130 được đồng bộ lên on-chain, chuyển 200 đồng tiền trong tài khoản đa ký theo số dư của mỗi người cho hai người, hoàn thành Thanh toán. Quy trình trên có vẻ đơn giản nhưng khi thực hiện cần xem xét nhiều tình huống phức tạp.

Đầu tiên, bạn thực sự không biết đối phương muốn rời khỏi kênh vào thời điểm nào, lấy ví dụ ở trên, Bob có thể rời khỏi sau khi giao dịch thứ hai hoàn thành, hoặc là rời khỏi sau giao dịch đầu tiên, và kênh thanh toán không bắt buộc điều này, mà cho phép các bên tham gia tự do rời khỏi. Để thực hiện điều này, cần giả sử bất cứ lúc nào có người rời khỏi, bất kỳ bên nào cũng có thể gửi số dư cuối cùng lên chuỗi, để thực hiện thanh toán.

Vì vậy có một cài đặt ‘giao dịch cam kết’, ‘Giao dịch cam kết’ được sử dụng để khai báo số dư mới nhất của cả hai bên trong kênh, mỗi lần chuyển tiền sẽ tạo ra một ‘giao dịch cam kết’ tương ứng. Nếu bạn muốn thoát khỏi kênh, bạn có thể gửi giao dịch cam kết mới nhất đến on-chain, rút tiền mà bạn có quyền từ tài khoản đa chữ ký.

Chúng ta có thể kết luận rằng: Giao dịch cam kết được sử dụng để thanh toán trên chuỗi cho số dư của hai bên trong kênh, bất cứ bên nào có thể đưa giao dịch cam kết mới nhất lên chuỗi và rời khỏi kênh bất cứ lúc nào.

**Nhưng có một tình huống quan trọng của việc gian lận ở đây: Bob có thể gửi số dư hết hạn và giao dịch cam kết lên chuỗi, ví dụ như khi Commit Tx3 trong hình được tạo ra, số dư của Bob là 130, nhưng để lợi dụng bản thân, Bob gửi Commit Tx2 hết hạn lên chuỗi, tuyên bố số dư của mình là 160, và trạng thái số dư này không phải là thời gian thực, đó chính là trường hợp “Thanh toán gấp đôi” điển hình.

Để ngăn chặn các tình huống chi tiêu kép như vậy, cần có các biện pháp trừng phạt tương ứng, và việc thiết kế các biện pháp trừng phạt chính là cốt lõi của kênh thanh toán 1-1. Chỉ khi hiểu rõ phần này, người ta mới có thể hiểu thực sự về kênh thanh toán. Trong thiết kế kênh, nếu bất kỳ bên nào đưa trạng thái hết hạn và Giao dịch Cam kết lên on-chain, không chỉ không đạt được mục đích, mà ngược lại sẽ bị bên kia lấy toàn bộ số tiền.

Ở đây sử dụng “giao dịch cam kết không đối xứng” và “rút Chìa khoá bảo mật”, hai khái niệm này rất quan trọng. Đầu tiên chúng ta sẽ giải thích về “giao dịch cam kết không đối xứng”. Lấy ví dụ giao dịch Cam kết Tx3 ở trên, hình dưới đây là biểu đồ minh họa cho giao dịch cam kết:

Giao dịch cam kết này được Bob tạo ra và gửi cho Alice để tự xử lý. Như hình vẽ, đây là một giao dịch chuyển BTC, tuyên bố chuyển 70 đồng tiền vào tài khoản đa chữ ký cho Alice và 130 đồng tiền cho Bob, nhưng điều kiện mở khóa tiền là “bất đối xứng”, với Alice phải đối mặt với ràng buộc khắt khe hơn, có lợi cho Bob hơn.

Sau khi Alice nhận được giao dịch cam kết do Bob xây dựng, cô ấy có thể đính kèm chữ ký của mình để đáp ứng 2/2 multisig, và sau đó Alice có thể chủ động gửi “giao dịch cam kết” cho chuỗi, để cô ấy có thể thoát khỏi kênh và nếu cô ấy không làm như vậy, cô ấy có thể tiếp tục chuyển tiền trong kênh.

Ở đây, chúng ta cần chú ý: Giao dịch cam kết này là do Bob tự tạo ra, trong đó điều kiện bất lợi cho Alice, Alice chỉ có thể chấp nhận/từ chối, chúng ta cần tìm cách để Alice có một số quyền tự chủ. Trong thiết kế kênh thanh toán, chỉ có Alice mới có thể đưa giao dịch cam kết “bất lợi cho mình” vào on-chain để kích hoạt, điều này bởi vì giao dịch cam kết cần phải có đủ 2/2 chữ ký, sau khi Bob tạo giao dịch cục bộ, chỉ có chữ ký của Bob, không có chữ ký của Alice.

Và Alice có thể “chỉ nhận chữ ký của Bob mà không gửi chữ ký của mình cho anh ta”, điều này tương tự như một bản hợp đồng bất lợi cho bạn, yêu cầu bạn và người khác ký kết, đối tác ký tên trước rồi gửi tài liệu cho bạn, bạn có thể không cho đối tác nhìn thấy chữ ký. Bạn muốn hợp đồng có hiệu lực thì ký tên sau đó công khai, không muốn có hiệu lực thì không ký tên hoặc không công khai. Rõ ràng trong trường hợp trên, Alice có cách để hạn chế Bob.

Sau đó đến điểm chính: **Sau mỗi lần chuyển tiền trong kênh, sẽ xuất hiện một cặp giao dịch cam kết, có hai phiên bản tương tự như một bức ảnh đối xứng, ** như dưới đây. Alice và Bob có thể xây dựng một giao dịch cam kết có lợi cho mình, trong đó khai báo số dư/số tiền nhận được khi rút tiền, sau đó gửi nội dung giao dịch cho bên kia xử lý.

Điều thú vị là hai giao dịch cam kết có cùng “số tiền nhận được khi thoát” nhưng điều kiện rút tiền khác nhau, đó là nguồn gốc của “giao dịch cam kết bất đối xứng”. **

Trước đó, chúng tôi đã giải thích rằng mỗi giao dịch cam kết đều cần có 2/2 chữ ký đa bên mới có thể có hiệu lực. Giao dịch cam kết mà Bob tạo ra tại địa phương, có lợi cho chính mình, không đáp ứng đủ 2/2 chữ ký đa bên, trong khi giao dịch cam kết đáp ứng đủ 2/2 chữ ký đa bên lại nằm trong tay của Alice, Bob không thể nộp, chỉ có thể do Alice nộp, điều này tạo ra sự cân bằng. Ngược lại cũng tương tự.

Do đó, Alice và Bob chỉ có thể tự nguyện gửi một giao dịch cam kết bất lợi cho họ và ngay sau khi một trong hai bên cam kết Commit Tx on-chain và có hiệu lực, kênh sẽ bị đóng. Quay trở lại kịch bản “Thanh toán gấp đôi” ngay từ đầu, điều gì sẽ xảy ra nếu ai đó gửi giao dịch cam kết hết hạn trên chuỗi?

Ở đây cần đề cập đến một thứ gọi là “撤销Chìa khoá bảo mật”. Nếu Bob đưa giao dịch cam kết hết hạn lên chuỗi, Alice có thể lấy tiền của Bob bằng cách sử dụng chìa khoá bảo mật để hủy bỏ giao dịch đó.

Chúng ta hãy xem bức tranh dưới đây, giả sử giao dịch cam kết mới nhất là Commit Tx3, Commit Tx2 đã hết hạn, nếu Bob đưa ra Tx2 đã hết hạn để xác nhận on-chain, Alice có thể rút tiền của Bob thông qua việc thu hồi Tx2 (Alice phải hành động trong khoảng thời gian khóa).

Với Tx3 mới nhất, Alice không có chìa khoá bảo mật để rút lui chỉ khi Tx4 trong tương lai xuất hiện, Alice mới có thể nhận chìa khoá bảo mật để rút lui Tx3. Điều này được quyết định bởi tính chất của mật mã khóa công khai và UTXO, vì sự hạn chế về độ dài, bài viết này sẽ không đi sâu vào giải thích cách thức triển khai của chìa khoá bảo mật để rút lui.

Chúng ta có thể nhớ kết luận: Chỉ cần Bob dám gửi giao dịch cam kết đã hết hạn lên chuỗi, Alice có thể lấy tiền của Bob bằng cách rút Chìa khoá bảo mật làm hình phạt. Ngược lại, nếu Alice làm điều xấu, Bob cũng có thể trừng phạt cô ấy theo cùng cách. Như vậy, kênh thanh toán 1-1 có thể tránh được Thanh toán gấp đôi một cách hiệu quả, miễn là tất cả các bên tham gia đều là những người hợp lý, không dám làm điều xấu.

Về phần kênh thanh toán này, so với BTCLighting Network, Fiber dựa trên CKB đã được tối ưu hóa mạnh mẽ, có thể hỗ trợ gốc đa dạng loại tài sản trong quá trình chuyển tiền/giao dịch, như CKB, BTC và RGB++Coin ổn định, trong khi Lighting Network chỉ có thể hỗ trợ gốc BTC, Sau khi TAPROOT Asset được niêm yết, BTCLighting Network vẫn không thể hỗ trợ gốc tài sản không phải BTC, chỉ có thể hỗ trợ gián tiếp Coin ổn định.

（Hình ảnh từ Dapangdun）

Ngoài ra, do Fiber phụ thuộc vào Chuỗi chính Layer1 là CKB, việc mở và đóng kênh giao dịch tiêu tốn phí giao dịch thấp hơn rất nhiều, không gây mất quá nhiều phí giao dịch của người dùng như BTCLighting Network, đây là lợi thế rõ ràng về UX của nó.

Bảo vệ toàn thời gian: WatchTower瞭望塔

Vấn đề với việc rút Chìa khoá bảo mật đã được đề cập ở trên là: Các bên tham gia kênh phải luôn giám sát lẫn nhau để ngăn chặn việc đối tác gửi giao dịch cam kết hết hạn lên chuỗi mà không được phép. Tuy nhiên, không ai có thể đảm bảo luôn trực tuyến trong 24 giờ. Nếu đối tác làm điều xấu khi bạn offline, bạn phải làm gì?

Đối với điều này, cả Fiber và BTCLighting Network đều có thiết kế WatchTower để giúp người dùng theo dõi hoạt động on-chain mọi lúc. Khi có ai đó gửi giao dịch cam kết quá hạn trong kênh, WatchTower sẽ xử lý kịp thời, đảm bảo an toàn cho kênh và quỹ vốn.

Giải thích cụ thể như sau: Đối với mỗi giao dịch cam kết hết hạn, Alice hoặc Bob có thể trước đó xây dựng giao dịch trừng phạt tương ứng (sử dụng chìa khoá bảo mật để rút lại giao dịch cam kết hết hạn, và tuyên bố người hưởng lợi là chính họ), sau đó gửi văn bản thuần túy của giao dịch trừng phạt đến WatchTower. Một khi WatchTower phát hiện rằng ai đó đã gửi giao dịch cam kết hết hạn lên chuỗi, nó sẽ gửi giao dịch trừng phạt lên chuỗi và tiến hành trừng phạt một cách đích danh.

Fiber để bảo vệ sự riêng tư của các bên tham gia kênh chỉ cho phép người dùng gửi “hash giao dịch thỏa thuận hết hạn + giao dịch phạt Văn bản thuần túy” cho WatchTower, điều này có nghĩa là WatchTower ban đầu không biết về giao dịch thỏa thuận Văn bản thuần túy, chỉ biết về hash của nó. Chừng nào có ai đó thực sự gửi giao dịch thỏa thuận đã hết hạn lên on-chain, WatchTower mới thấy Văn bản thuần túy, sau đó nhanh chóng gửi giao dịch phạt lên chuỗi. Điều này có nghĩa rằng, trừ khi có ai đó thực sự gian lận, WatchTower sẽ không thấy được lịch sử giao dịch của các bên tham gia kênh (thậm chí nếu nhìn thấy, cũng chỉ thấy một giao dịch).

Ở đây, chúng ta cần đề cập đến cải tiến của Fiber so với Lighting Network của BTCLighting. Cơ chế trừng phạt liên quan đến việc rút lại Chìa khoá bảo mật được đề cập ở trên được gọi là ‘LN-Penalty’. Tuy nhiên, LN-Penalty của BTCLighting Network có nhược điểm rõ ràng: WatchTower phải lưu trữ tất cả các giao dịch cam kết hết hạn và Chìa khoá bảo mật tương ứng, điều này sẽ gây áp lực lưu trữ khá lớn.

Ngay từ năm 2018, cộng đồng BTC đã đề xuất một phương án gọi là “eltoo” để giải quyết vấn đề trên, nhưng cần sự hỗ trợ của BTCfork SIGHASH_ANYPREVOUT opcode. Ý tưởng là khi giao dịch cam kết hết hạn được gửi lên chuỗi, giao dịch cam kết mới nhất có thể trừng phạt nó, do đó người dùng chỉ cần lưu trữ giao dịch cam kết mới nhất. Tuy nhiên, opcode SIGHASH_ANYPREVOUT vẫn chưa được kích hoạt cho đến nay, và phương án này vẫn chưa thể triển khai.

Và ** Fiber thực hiện giao thức Daric, sửa đổi thiết kế chìa khóa bảo mật để sử dụng cùng một chìa khóa bảo mật để thu hồi nhiều giao dịch cam kết đã hết hạn. Điều này giúp giảm đáng kể áp lực lưu trữ trên WatchTower và các khách hàng của người dùng. **

Hệ thống giao thông mạng: định tuyến nhiều bước và HTLC/PTLC

Ví dụ: Alice và Ken không có kênh, nhưng có một kênh giữa Ken và Bob, và Bob và Alice có một kênh, Bob có thể hoạt động như một Nút trung gian giữa Alice và Ken, để có thể chuyển giữa Alice và Ken. “Tuyến đường đa nhảy” đề cập đến việc thiết lập một con đường chuyển qua nhiều người trung gian. **

“Định tuyến đa bước” có thể tăng cường tính linh hoạt và phạm vi của mạng. Tuy nhiên, bên gửi cần hiểu trạng thái của tất cả các nút và kênh công cộng. ** Trong Fiber, tất cả các kênh công cộng, nghĩa là cấu trúc mạng, đều được công khai hoàn toàn, ** bất kỳ nút nào cũng có thể biết thông tin mạng mà các nút khác nắm giữ. Vì trạng thái toàn bộ mạng trong Lighting Network thay đổi liên tục, ** Fiber sẽ sử dụng thuật toán đường đi ngắn nhất Dijkstra để tìm đường đi ngắn nhất, giảm thiểu số lượng người trung gian càng ít càng tốt, sau đó thiết lập đường dẫn chuyển tiền giữa hai bên. **

Tuy nhiên, vấn đề cần giải quyết ở đây là vấn đề tin cậy của Nút trung gian: Làm thế nào để bạn đảm bảo rằng anh ấy là trung thực, ví dụ như đã đề cập ở trên, giữa Alice và Ken có người trung gian là Bob, Alice bây giờ muốn chuyển 100 đô la cho Ken, Bob có thể bất cứ lúc nào giữ lại số tiền này. Cần có cách để ngăn chặn người trung gian làm ác, HTLC và PTLC được sử dụng để giải quyết vấn đề này.

假设Alice要向Daniel付款100块，但他们之间没有建立通道。而Alice发现，可以通过Bob和Carol这两个người trung gian向Daniel付款。这里面要引入HTLC作为支付渠道，首先Alice向Daniel发起请求，然后Daniel发给Alice一个哈希r，但Alice不知道r对应的Văn bản thuần túyR。

Sau đó, Alice xây dựng các điều khoản thanh toán bằng cách sử dụng HTLC trong kênh thanh toán với Bob: Alice sẽ trả cho Bob 102 đồng, nhưng Bob phải nói ra khóa R trong vòng 30 phút, nếu không, Alice sẽ rút tiền. Tương tự, Bob xây dựng HTLC với Carol: Bob sẽ thanh toán cho Carol 101 đồng, nhưng Carol phải nói ra khóa R trong vòng 25 phút, nếu không, Bob sẽ rút tiền.

Carol如法炮制，在和Daniel的通道中创建HTLC：Carol愿意支付100块，但Daniel要在20分钟内告诉她R的Văn bản thuần túy，否则钱会被Carol收回。

Daniel hiểu rằng khóa bí mật R mà Carol yêu cầu thực sự là điều mà Alice muốn, vì ngoài Alice không ai quan tâm đến nội dung của R. Vì vậy, Daniel sẽ hợp tác với Carol, cho cô ấy biết nội dung của R và nhận 100 đô la từ Carol, như vậy Alice đã đạt được mục tiêu của mình: trả 100 đô la cho Carol.

Những điều tiếp theo dễ dàng tưởng tượng: Carol đưa khóa R cho Bob, nhận được 101 đô la; Bob lại đưa khóa R cho Alice, nhận được 102 đô la. Chúng ta quan sát tất cả mọi người đều có được hoặc mất đi những gì, có thể thấy Alice mất 102 đô la, Bob và Carol kiếm được 1 đô la, Daniel nhận được 100 đô la. Đồng tiền mà Bob và Carol kiếm được là khoản phí mà họ thu được từ Alice.

Ngay cả khi một người trong đường dẫn thanh toán trên bị mắc kẹt, ví dụ như Carol không cung cấp khóa R cho Bob phía dưới, Bob cũng không gặp thiệt hại: Bob có thể rút lại HTLC đã xây dựng sau một thời gian. Điều tương tự cũng áp dụng cho Alice.

Tuy nhiên, Lightning Network cũng có vấn đề: không nên có quá nhiều người trung gian nếu đường dẫn quá dài, điều này sẽ giảm tính đáng tin cậy của việc thanh toán: Một số người trung gian có thể ngoại tuyến hoặc không đủ số dư để xây dựng HTLC cụ thể (ví dụ như mỗi người trung gian trong trường hợp trước đó cần ít nhất 100 đồng). Do đó, mỗi khi tăng một Nút trung gian trong đường dẫn, khả năng lỗi cũng sẽ tăng lên.

Ngoài ra, HTLC có thể xâm phạm quyền riêng tư. Mặc dù định tuyến hành tây có thể bảo vệ quyền riêng tư đúng cách, ví dụ như thông tin định tuyến của mỗi bước nhảy là mã hóa, ngoại trừ người khởi xướng ban đầu Alice, mọi người chỉ biết nhà trên và dưới liền kề, và không biết đường dẫn hoàn chỉnh, nhưng trên thực tế, HTLC vẫn dễ dàng suy ra sự liên kết. Chúng ta hãy nhìn vào con đường này từ quan điểm của Đức Chúa Trời

Giả sử Bob và Daniel là hai Nút được kiểm soát bởi cùng một thực thể, mỗi ngày họ nhận được rất nhiều HTLC từ nhiều người khác nhau. Họ nhận thấy rằng mỗi khi Alice và Carol gửi HTLC, họ luôn cần biết về cùng một Chìa khoá bảo mật, và người kế tiếp kết nối với Daniel, Eve, luôn biết về nội dung của Chìa khoá bảo mật R. Do đó, Daniel và Bob có thể suy đoán rằng tồn tại một đường dẫn thanh toán giữa Alice và Eve, bởi vì họ luôn liên quan đến cùng một Chìa khoá bảo mật, từ đó suy luận về mối quan hệ giữa Alice và Eve và thực hiện giám sát.

Để làm điều này, Fiber đã sử dụng PTLC, cải tiến quyền riêng tư dựa trên HTLC, mỗi PTLC trong đường thanh toán được mở khóa bằng một Chìa khoá bảo mật khác nhau, việc quan sát chỉ từ PTLC yêu cầu Chìa khoá bảo mật sẽ không thể xác định được sự liên quan giữa chúng. Bằng cách kết hợp PTLC với định tuyến củ cải, Fiber có thể trở thành giải pháp thanh toán riêng tư lý tưởng.

Ngoài ra, Lighting Network truyền thống tồn tại tình huống tấn công chuỗi giao dịch thay thế (replacement cycling attack) có thể làm cho tài sản của người trung gian trong đường thanh toán bị đánh cắp. Phát hiện này đã khiến cho nhà phát triển Antoine Riard rút lui khỏi công việc phát triển Lighting Network. Cho đến nay, BTCLighting Network vẫn chưa có giải pháp cơ bản để giải quyết vấn đề này, và đã trở thành một điểm đau đớn.

Hiện tại, CKB chính thức đã cải thiện tầng giao dịch trong hồ bơi giao dịch, giúp Fiber giải quyết tình huống tấn công trên. Do vòng lặp giao dịch thay thế và giải pháp khá phức tạp, bài viết này không dự định tiếp tục giải thích chi tiết, người quan tâm có thể đọc bài viết dưới đây của BTCStudy cũng như đọc các tài liệu liên quan từ phía chính thức của CKB.

Nhìn chung, Fiber đã được cải tiến đáng kể so với Lighting Network truyền thống, cả về khía cạnh bảo mật lẫn an toàn.

Thanh toán nguyên tử chéo giữa Fiber và Lightning Network của Bitcoin

Sử dụng HTLC và PTLC, Fiber có thể nhận ra thanh toán tên miền chéo với BTCLighting Network và có thể đảm bảo “tính nguyên tử của hành vi tên miền chéo”, nghĩa là tất cả các bước liên quan đến tên miền chéo sẽ thành công hoặc thất bại và sẽ không có thành công một phần và thất bại một phần.

Sau khi tính nguyên tử qua các lĩnh vực được đảm bảo, có thể đảm bảo rằng sự chuyển vùng không gây thiệt hại tài sản, điều này có thể kết nối Fiber với BTCLighting Network, ví dụ như có thể xây dựng đường dẫn thanh toán trong mạng lưới kết hợp của Fiber và Lighting Network, chuyển tiền trực tiếp từ Fiber tới người dùng trong BTCLighting Network (chỉ dành cho người nhận BTC), cũng có thể đổi CKB và tài sản RGB++ trong Fiber để nhận số tiền tương đương BTC trong BTCLighting Network.

Chúng tôi sẽ giải thích nguyên lý một cách đơn giản: Giả sử Alice đang chạy một nút trên mạng Fiber, trong khi Bob đang chạy một nút trên mạng BTCLighting Network. Alice muốn chuyển một số tiền cho Bob, và điều này có thể được thực hiện thông qua người trung gian Ingrid hoạt động trên cả mạng Fiber và BTCLighting Network.

Nếu Bob muốn nhận 1 BTC, Alice có thể thương lượng tỷ lệ trao đổi với Ingrid, ví dụ như sử dụng 1 CKB để đổi lấy 1 BTC. Alice có thể gửi 1,1 CKB cho Ingrid trên Fiber, sau đó Ingrid sẽ gửi 1 BTC cho Bob trên Mạng Lighting của BTC, và Ingrid sẽ giữ lại 0,1 CKB làm phí giao dịch.

Cách thức cụ thể ở đây thực tế là thiết lập đường dẫn thanh toán giữa Alice và Bob với Ingrid, tức là Alice—>Ingrid—>Bob, sau đó sẽ sử dụng HTLC. Tương tự như đã giải thích trước đó, để nhận tiền, Bob phải cung cấp cho Ingrid nội dung của khóa R. Khi Ingrid nhận được khóa R, cô ấy có thể mở khóa số tiền mà Alice đã đóng trong HTLC.

Lưu ý rằng, hai giao dịch này là hoạt động chuyển tiền qua biên giới giữa BTC Lightning Network và Fiber là nguyên tử, có nghĩa là hoặc cả hai HTLC đều được mở khóa và thanh toán qua biên giới thành công, hoặc cả hai đều không được mở khóa và thanh toán qua biên giới thất bại, không có tình huống Alice trả tiền mà Bob không nhận được tiền.

（Thực tế người trung gian Ingrid có thể không mở khóa HTLC của Alice sau khi biết khóa R, nhưng điều này làm tổn thương người trung gian Ingrid, chứ không phải người dùng Alice, vì vậy thiết kế của Fiber là an toàn đối với người dùng）

Phương thức này không cần tin tưởng bên thứ ba mà vẫn có thể thực hiện giao dịch chuyển tiền giữa các mạng P2P khác nhau mà gần như không cần bất kỳ sự sửa đổi nào.

Fiber相比于BTCLighting Network的其他优点

Trước đó, chúng tôi đã đề cập đến việc Fiber hỗ trợ tài sản gốc của CKB và tài sản RGB++ (đặc biệt là stablecoin), điều này khiến nó có tiềm năng lớn trong các tình huống thanh toán ngay lập tức, phù hợp hơn với nhu cầu thanh toán số tiền nhỏ hàng ngày.

Ngoài ra, BTCLighting Network có một vét thương chính, đó là vấn đề quản lý Thanh khoản. Mọi người có thể nhớ ra rằng, chỗ thanh toán có tổng số dừ dàng là cố định, nếu một bên hết tiền, thì không thể chuyển tiền cho bên kia trừ khi bên kia chuyển tiền cho hệ, lúc đó sẽ phải tiết tối vào với tiền hoặc mở mời kên.

Ngoài ra, ** nếu trong một mạng lưới nhiều bước phức tạp, một số Nút trung gian có số dư không đủ để chuyển tiền ra ngoài, có thể dẫn đến thất bại của toàn bộ đường dẫn thanh toán. ** Đây là một trong những điểm đau của Lighting Network, giải pháp cho vấn đề này không thể thiếu là cung cấp giải pháp tiêm thanh khoản hiệu quả, đảm bảo hầu hết các Nút có thể tiêm vốn bất cứ lúc nào.

Tuy nhiên, ** trong BTCLighting Network, các bước tiêm Thanh khoản, mở hoặc đóng kênh đều được thực hiện trên chuỗi BTC, nếu phí giao dịch mạng BTC rất cao, sẽ ảnh hưởng xấu đến trải nghiệm người dùng của kênh thanh toán.** Giả sử bạn muốn mở một kênh với số dư 100 đô la, nhưng thao tác thiết lập kênh tốn phí 10 đô la, điều này đồng nghĩa với việc bạn mất 10% số vốn khi khởi tạo kênh, điều này không thể chấp nhận được đối với đa số người; công việc tiêm Thanh khoản cũng tương tự.

Với những ưu điểm rất đáng kể. Trước hết, TPS của CKB cao hơn rất nhiều so với BTC, phí giao dịch có thể đạt đến mức đồng xu; thứ hai, để giải quyết vấn đề về Thanh khoản không đủ dẫn đến việc không thể chuyển tiền, Fiber kế hoạch hợp tác với lớp Mercury để ra mắt các giải pháp mới, giúp việc tiêm nhiệt độ của Thanh khoản có thể thoát khỏi hoạt động on-chain, giải quyết vấn đề UX và chi phí.

Đến đây, chúng tôi đã tổng hợp được kiến trúc công nghệ tổng thể của Fiber, và tóm tắt so sánh chung với BTCLighting Network như hình trên. Do Fiber và Lighting Network bản thân liên quan đến quá nhiều kiến thức và chủ đề khác nhau, một bài viết đơn thuần có thể không bao quát được toàn bộ, trong tương lai chúng tôi sẽ tung ra các bài viết liên quan đến chủ đề Lighting Network và Fiber, mọi người giữ nguyên.