Giải thích hệ thống về Fiber: Thí nghiệm quy mô lớn khi ghép mạng lưới chớp nhoáng lên CKB
Tuyển chọn TechFlowTuyển chọn TechFlow
Giải thích hệ thống về Fiber: Thí nghiệm quy mô lớn khi ghép mạng lưới chớp nhoáng lên CKB
Đây có thể là bài báo nghiên cứu về Fiber hệ thống nhất trong số các báo cáo.
Chuyên sâu báo cáo Web3Tác giả: Faust & Nickqiao, Geeks web3
Ngày 23 tháng 8, CKB chính thức công bố phương án mạng lưới Lightning Network dựa trên CKB – Fiber Network (mạng sợi quang), tin tức này vừa được lan truyền đã nhanh chóng gây xôn xao trong cộng đồng, khiến giá CKB tăng gần 30% chỉ trong một ngày. Lý do sự kiện này thu hút phản ứng mạnh mẽ là vì Lightning Network mang sức hút câu chuyện lớn, và Fiber của CKB đã nâng cấp giải pháp so với Lightning Network truyền thống, thực hiện nhiều cải tiến đáng kể.
Ví dụ, Fiber hỗ trợ gốc đa dạng tài sản như CKB, BTC, stablecoin,... hơn nữa phí giao dịch CKB thấp hơn rất nhiều so với BTC, tốc độ xử lý nhanh hơn, nhờ đó Fiber có thể đột phá về trải nghiệm người dùng (UX). Đồng thời ở khía cạnh bảo mật và riêng tư, Fiber cũng có nhiều tối ưu hóa.
Hơn thế nữa, Fiber và Lightning Network của BTC có thể liên thông, tạo thành mạng ngang hàng (P2P) lớn hơn. Trong các hoạt động ngoại tuyến trước đây, CKB còn cho biết sẽ thiết lập 100.000 nút vật lý trong cả Fiber và Lightning Network nhằm thúc đẩy sự hoàn thiện và phát triển của mạng thanh toán P2P. Không nghi ngờ gì đây là một câu chuyện vô cùng hoành tráng.
Nếu tầm nhìn của CKB trở thành hiện thực trong tương lai, thì dù xét về bản thân Lightning Network, hay CKB, hay hệ sinh thái Bitcoin đều sẽ hưởng lợi lớn.Theo dữ liệu từ mempool, hiện tại hơn 300 triệu USD vốn được đặt trong Lightning Network của BTC, với khoảng 12.000 nút kết nối qua gần 50.000 kênh thanh toán.
Tại spendmybtc.com, chúng ta cũng thấy ngày càng nhiều thương gia chấp nhận thanh toán bằng Lightning Network. Khi độ phổ biến của BTC ngày càng cao, tiềm năng bùng nổ của các giải pháp thanh toán ngoài chuỗi như Lightning Network và Fiber chắc chắn sẽ ngày càng mạnh mẽ.
Vì mục đích phân tích toàn diện cơ chế kỹ thuật của Fiber, Geeks Web3 viết báo cáo nghiên cứu tổng quan về giải pháp Fiber này. Là một hiện thực hóa Lightning Network dựa trên CKB, nguyên lý tổng thể của Fiber về cơ bản giống với Lightning Network của Bitcoin, nhưng đã được tinh chỉnh ở nhiều chi tiết.
Kiến trúc tổng thể của Fiber bao gồm bốn phần cốt lõi: kênh thanh toán, WatchTower, định tuyến đa bậc, thanh toán xuyên miền. Trước tiên, chúng ta hãy tìm hiểu phần quan trọng nhất: «kênh thanh toán».
Cơ sở của Lightning Network và Fiber: Kênh thanh toán
Bản chất kênh thanh toán là dời tất cả giao dịch/chuyển khoản xuống xử lý ngoài chuỗi, sau một thời gian mới gửi trạng thái cuối cùng lên chuỗi để «thanh toán». Do giao dịch được hoàn tất tức thì ngoài chuỗi, thường có thể vượt qua giới hạn hiệu suất của các chuỗi chính như BTC.
Giả sử Alice và Bob cùng mở một kênh, họ đầu tiên xây dựng ví đa chữ ký trên chuỗi và nạp tiền vào, ví dụ Alice và Bob mỗi người nạp 100 đơn vị làm số dư ban đầu trong kênh ngoài chuỗi.Sau đó hai bên có thể thực hiện nhiều giao dịch trong kênh, khi thoát khỏi kênh, họ mới đồng bộ số dư cuối cùng lên chuỗi, để ví đa ký chuyển tiền cho hai bên theo số dư tương ứng, gọi là «thanh toán».
Ví dụ, ban đầu mỗi người có 100, sau đó Alice chuyển 50 cho Bob, rồi lại chuyển thêm 10, sau đó Bob chuyển lại 30 cho Alice, cuối cùng số dư là: Alice—70, Bob—130. Dễ thấy tổng số dư của hai người không đổi, minh họa bằng hình ảnh hạt bàn tính di chuyển qua lại mô tả điều này rất rõ.
Nếu một bên rút khỏi kênh, họ sẽ đồng bộ trạng thái hiện tại Alice:70/Bob:130 lên chuỗi, ví đa ký sẽ chia 200 đơn vị tiền theo số dư cho hai người, hoàn tất thanh toán. Quy trình trên có vẻ đơn giản, nhưng trong thực tế cần xử lý nhiều tình huống phức tạp.
Trước hết, bạn không thể biết đối tác muốn rút khỏi kênh lúc nào, lấy ví dụ trên, Bob có thể rút sau giao dịch thứ hai hoặc thậm chí sau giao dịch đầu tiên, kênh thanh toán không bắt buộc thời điểm, cho phép các bên tự do rút lui. Để đạt được điều này, cần giả định rằng bất kỳ lúc nào cũng có thể có người rút, bất kỳ bên nào cũng có thể gửi số dư cuối cùng lên chuỗi để thanh toán.
Do đó có khái niệm «giao dịch cam kết», «giao dịch cam kết» dùng để xác nhận số dư mới nhất giữa hai bên trong kênh, mỗi giao dịch sẽ tạo ra một «giao dịch cam kết» tương ứng. Nếu bạn muốn rút khỏi kênh, bạn có thể gửi giao dịch cam kết mới nhất lên chuỗi để rút số tiền thuộc về mình từ ví đa ký.
Chúng ta ghi nhận kết luận: Giao dịch cam kết dùng để thanh toán số dư giữa hai bên trên chuỗi, bất kỳ bên nào cũng có thể随时 gửi giao dịch cam kết mới nhất lên chuỗi rồi rút khỏi kênh.
Nhưng ở đây tồn tại một kịch bản gian lận nghiêm trọng: Bob có thể gửi trạng thái cũ và giao dịch cam kết quá hạn lên chuỗi, ví dụ sau khi Commit Tx3 được tạo, số dư của Bob là 130, nhưng để trục lợi, Bob gửi Commit Tx2 quá hạn lên chuỗi, tuyên bố số dư của mình là 160, trong khi trạng thái này không còn cập nhật — đây là điển hình của «chi tiêu kép».
Để ngăn chặn các trường hợp chi tiêu kép, cần có biện pháp trừng phạt tương ứng, thiết kế cơ chế 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 mới thực sự hiểu được kênh thanh toán. Trong thiết kế kênh, nếu bất kỳ bên nào gửi trạng thái cũ và Commit Tx lên chuỗi, không những không đạt được mục đích mà ngược lại sẽ bị bên kia rút sạch toàn bộ tiền.
Ở đây sử dụng «giao dịch cam kết bất đối xứng» và «khóa hủy bỏ», hai khái niệm này rất quan trọng. Trước tiên giải thích «giao dịch cam kết bất đối xứng». Lấy Commit Tx3 trước đó làm ví dụ, hình dưới là sơ đồ giao dịch cam kết:
Giao dịch cam kết này do Bob tạo ra, sau đó gửi cho Alice để cô ấy xử lý. Như hình vẽ, đây là một giao dịch Bitcoin, tuyên bố chuyển 70 đơn vị cho Alice và 130 cho Bob từ ví đa ký, nhưng điều kiện mở khóa tiền «bất đối xứng», nghĩa là yêu cầu với Alice khắt khe hơn, có lợi hơn cho Bob.
Sau khi nhận được giao dịch cam kết do Bob tạo, Alice có thể thêm chữ ký của mình để thỏa mãn điều kiện 2/2 đa ký, sau đó chủ động gửi «giao dịch cam kết» lên chuỗi, như vậy có thể rút khỏi kênh, nếu không làm vậy thì tiếp tục giao dịch trong kênh.
Chúng ta cần lưu ý: giao dịch cam kết này do Bob chủ động tạo, điều kiện có lợi cho Bob, bất lợi cho Alice, Alice chỉ có thể chấp nhận hoặc từ chối, ta cần phải dành quyền kiểm soát nhất định cho Alice. Trong thiết kế kênh thanh toán, chỉ có chính Alice mới có thể đưa giao dịch cam kết «bất lợi cho mình» lên chuỗi kích hoạt, bởi vì giao dịch cam kết cần đủ 2/2 chữ ký, Bob khi tạo giao dịch cục bộ chỉ có chữ ký của mình, chưa có chữ ký của Alice.
Và Alice có thể «chỉ nhận chữ ký của Bob, nhưng không gửi chữ ký của mình cho anh ta», cũng giống như một bản hợp đồng bất lợi cho bạn, cần hai bên ký tên, đối phương ký trước rồi đưa cho bạn, bạn có thể giữ lại chữ ký của mình. Bạn muốn hợp đồng có hiệu lực thì ký và công bố, không muốn thì không ký hoặc không công bố. Rõ ràng trong ví dụ trên, Alice có cách kiểm soát Bob.
Sau đến điểm mấu chốt: Mỗi lần có giao dịch xảy ra trong kênh, sẽ xuất hiện một cặp giao dịch cam kết, có hai phiên bản giống như ảnh phản chiếu nhau, như hình dưới. Alice và Bob có thể lần lượt tạo giao dịch cam kết có lợi cho mình, tuyên bố số dư / số tiền nhận được khi rút, rồi gửi nội dung giao dịch cho đối phương xử lý.
Thú vị là, số tiền «nhận được khi rút» mà hai giao dịch cam kết này tuyên bố là như nhau, nhưng điều kiện rút tiền khác nhau, đây chính là nguồn gốc của «giao dịch cam kết bất đối xứng» đề cập trước đó.
Trước đó chúng ta đã giải thích, mỗi giao dịch cam kết cần 2/2 chữ ký mới có hiệu lực, giao dịch cam kết do Bob tạo cục bộ có lợi cho anh ta không thỏa mãn 2/2 chữ ký, còn giao dịch cam kết thỏa mãn 2/2 chữ ký đang nằm trong tay Alice, Bob không thể gửi lên, chỉ có thể do Alice gửi lên, như vậy tạo thành thế cân bằng. Ngược lại cũng tương tự.
Như vậy, Alice và Bob chỉ có thể chủ động gửi giao dịch cam kết bất lợi cho mình, chỉ cần một trong hai bên gửi Commit Tx lên chuỗi và có hiệu lực, kênh sẽ đóng lại. Trở lại với kịch bản «chi tiêu kép» ban đầu, nếu ai đó gửi giao dịch cam kết quá hạn lên chuỗi thì sao?
Ở đây cần nhắc đến «khóa hủy bỏ». Giả sử Bob gửi giao dịch cam kết quá hạn lên chuỗi, Alice có thể dùng khóa hủy bỏ để rút tiền thuộc về Bob.
Xem hình dưới, giả sử giao dịch cam kết mới nhất là Commit Tx3, Commit Tx2 đã quá hạn, nếu Bob gửi Tx2 quá hạn lên chuỗi, Alice có thể dùng khóa hủy bỏ của Tx2 để rút tiền của Bob (Alice phải hành động trong phạm vi thời gian khóa).
Đối với Tx3 mới nhất, Alice không có khóa hủy bỏ, chỉ khi Tx4 xuất hiện trong tương lai, Alice mới có được khóa hủy bỏ của Tx3. Điều này do đặc tính mật mã khóa công khai - riêng và UTXO quyết định, do giới hạn độ dài bài viết, phần này sẽ không đi sâu vào nguyên lý triển khai khóa hủy bỏ.
Chúng ta ghi nhớ kết luận: Chỉ cần Bob dám gửi giao dịch cam kết quá hạn lên chuỗi, Alice có thể dùng khóa hủy bỏ để lấy tiền của Bob làm hình phạt. Ngược lại nếu Alice gian lận, Bob cũng có thể trừng phạt cô ấy. Như vậy, kênh thanh toán 1-1 có thể hiệu quả tránh chi tiêu kép, miễn là các bên tham gia đều hành xử hợp lý, sẽ không dám gian lận.
Về kênh thanh toán, Fiber dựa trên CKB so với Lightning Network của Bitcoin có tối ưu hóa lớn, có thể hỗ trợ gốc việc chuyển khoản/giao dịch đa loại tài sản như CKB, BTC và stablecoin RGB++, trong khi Lightning Network chỉ hỗ trợ gốc Bitcoin, sau khi Taproot Asset ra mắt, Lightning Network của Bitcoin vẫn không thể hỗ trợ gốc tài sản ngoài BTC, chỉ hỗ trợ gián tiếp stablecoin.
Nguồn ảnh: Dapangdun
Hơn nữa, vì Fiber phụ thuộc vào chuỗi Layer1 là CKB, phí khi mở và đóng kênh thấp hơn nhiều, không giống như Lightning Network của BTC khiến người dùng mất nhiều phí giao dịch, đây là lợi thế rõ rệt về UX.
Bảo vệ 24/7: WatchTower (Đài giám sát)
Vấn đề với khóa hủy bỏ đề cập ở phần trên: Các bên tham gia kênh phải luôn giám sát đối phương, phòng ngừa việc đối phương âm thầm gửi giao dịch cam kết quá hạn lên chuỗi. Nhưng không ai đảm bảo trực 24/7, nếu bạn offline mà đối phương gian lận thì sao?
Đối với vấn đề này, cả Fiber và Lightning Network của Bitcoin đều có thiết kế WatchTower, giúp người dùng giám sát hoạt động trên chuỗi suốt ngày đêm. Một khi có người gửi giao dịch cam kết quá hạn lên chuỗi, WatchTower sẽ xử lý kịp thời, đảm bảo an toàn cho kênh và tài sản.
Cụ thể giải thích như sau: Đối với mỗi giao dịch cam kết quá hạn, Alice hoặc Bob có thể trước tiên tạo sẵn giao dịch trừng phạt (sử dụng khóa hủy bỏ xử lý giao dịch cam kết quá hạn, người thụ hưởng là chính mình), sau đó gửi bản rõ giao dịch trừng phạt cho WatchTower. Ngay khi WatchTower phát hiện có người gửi giao dịch cam kết quá hạn lên chuỗi, nó sẽ gửi giao dịch trừng phạt lên chuỗi để thực hiện trừng phạt.
Để bảo vệ quyền riêng tư của người dùng kênh, Fiber chỉ yêu cầu người dùng gửi «hash của giao dịch cam kết quá hạn + bản rõ giao dịch trừng phạt» cho WatchTower, như vậy ban đầu WatchTower không biết bản rõ giao dịch cam kết, chỉ biết hash của nó. Trừ khi thật sự có người gửi giao dịch cam kết quá hạn lên chuỗi, WatchTower mới thấy bản rõ, sau đó nhanh chóng gửi giao dịch trừng phạt lên chuỗi. Như vậy, trừ khi thật sự có người gian lận, WatchTower sẽ không thấy lịch sử giao dịch của người dùng kênh (ngay cả khi thấy cũng chỉ thấy một giao dịch).
Ở đây cần nói đến cải tiến của Fiber so với Lightning Network của Bitcoin. Cơ chế trừng phạt liên quan đến khóa hủy bỏ nêu trên được gọi là «LN-Penalty», trong khi LN-Penalty của Lightning Network Bitcoin có nhược điểm rõ rệt: WatchTower phải lưu trữ tất cả hash giao dịch cam kết quá hạn và khóa hủy bỏ tương ứng, gây áp lực lưu trữ lớn.
Ngay từ năm 2018, cộng đồng Bitcoin đã đề xuất một giải pháp gọi là «eltoo» để giải quyết vấn đề trên, nhưng cần fork Bitcoin hỗ trợ mã vận hành SIGHASH_ANYPREVOUT. Ý tưởng là khi giao dịch cam kết quá hạn được đưa lên chuỗi, giao dịch cam kết mới nhất có thể trừng phạt nó, như vậy người dùng chỉ cần lưu trữ giao dịch cam kết mới nhất. Tuy nhiên mã vận hành SIGHASH_ANYPREVOUT đến nay vẫn chưa được kích hoạt, giải pháp này mãi chưa thể triển khai.
Trong khi đó, Fiber triển khai giao thức Daric, sửa đổi thiết kế khóa hủy bỏ, khiến cùng một khóa hủy bỏ có thể áp dụng cho nhiều giao dịch cam kết quá hạn. Như vậy có thể giảm đáng kể áp lực lưu trữ cho WatchTower và client người dùng.
Hệ thống giao thông trong mạng: Định tuyến đa bậc và HTLC/PTLC
Kênh thanh toán đề cập trước đó chỉ phù hợp với trường hợp giao dịch 1-1, trong khi Lightning Network hỗ trợ thanh toán đa bậc, tức là dùng các nút trung gian để định tuyến, cho phép hai bên chưa mở kênh trực tiếp có thể chuyển tiền cho nhau. Ví dụ Alice và Ken chưa mở kênh, nhưng Ken có kênh với Bob, Bob có kênh với Alice, Bob có thể làm trung gian giữa Alice và Ken, cho phép Alice và Ken giao dịch. «Định tuyến đa bậc» nghĩa là xây dựng đường dẫn chuyển tiền qua nhiều trung gian.
«Định tuyến đa bậc» tăng tính linh hoạt và phạm vi phủ sóng của mạng. Tuy nhiên, người gửi cần biết trạng thái của tất cả các nút công cộng và kênh. Trong Fiber, mọi kênh công khai và cấu trúc mạng đều hoàn toàn công khai, 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 Lightning Network luôn thay đổi, Fiber sẽ dùng thuật toán tìm đường ngắn nhất Dijkstra để tìm đường dẫn ngắn nhất, giảm thiểu số lượng trung gian, sau đó thiết lập đường dẫn chuyển tiền giữa hai bên.
Tuy nhiên ở đây cần giải quyết vấn đề uy tín trung gian: Làm sao đảm bảo họ trung thực? Ví dụ trước đó Alice và Ken có trung gian Bob, giờ Alice muốn chuyển 100 đơn vị cho Ken, Bob có thể giữ tiền bất cứ lúc nào. Cần có biện pháp ngăn trung gian gian lận, HTLC và PTLC được dùng để giải quyết vấn đề này.
Giả sử Alice muốn trả 100 đơn vị cho Daniel, nhưng họ chưa mở kênh. Alice phát hiện có thể dùng hai trung gian Bob và Carol để trả cho Daniel. Ở đây cần dùng HTLC làm kênh thanh toán, trước tiên Alice gửi yêu cầu đến Daniel, sau đó Daniel gửi cho Alice một hàm băm r, nhưng Alice không biết văn bản gốc R tương ứng với r.
Sau đó, trong kênh giữa Alice và Bob, Alice dùng HTLC thiết lập điều khoản thanh toán: Alice sẵn sàng trả 102 cho Bob, 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 lại tiền. Tương tự Bob tạo HTLC với Carol: Bob sẽ trả 101 cho Carol, 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 lại tiền.
Carol làm tương tự, tạo HTLC với Daniel: Carol sẵn sàng trả 100, nhưng Daniel phải nói cho cô R trong vòng 20 phút, nếu không tiền sẽ bị Carol thu hồi.
Daniel hiểu rằng khóa R mà Carol đòi hỏi thực chất là cái Alice muốn, vì ngoài Alice ra chẳng ai quan tâm nội dung R. Do đó Daniel sẽ phối hợp với Carol, nói cho cô R và nhận 100 từ Carol, như vậy Alice đạt được mục tiêu: chuyển 100 cho Daniel.
Việc tiếp theo dễ hình dung: Carol nói khóa R cho Bob, nhận 101; Bob nói khóa R cho Alice, nhận 102. Quan sát lợi hại của mọi người, thấy Alice mất 102, Bob và Carol lời ròng 1, Daniel nhận 100. Trong đó 1 đơn vị mà Bob và Carol kiếm được chính là phí mà họ lấy từ Alice.
Ngay cả khi ai đó trong đường dẫn thanh toán này đình trệ, ví dụ Carol không nói khóa R cho Bob bên dưới, Bob cũng không bị thiệt: sau thời gian quy định Bob có thể rút lại HTLC đã tạo. Với Alice cũng tương tự.
Nhưng Lightning Network cũng có vấn đề: đường dẫn không nên quá dài, nếu quá dài và có nhiều trung gian sẽ làm giảm độ tin cậy thanh toán: một số trung gian có thể offline, hoặc số dư không đủ để tạo HTLC cụ thể (ví dụ trong ví dụ trên mỗi trung gian ít nhất cần hơn 100 đơn vị). Do đó mỗi khi thêm một nút trung gian vào đường dẫn, khả năng lỗi sẽ tăng lên.
Hơn nữa, HTLC có thể rò rỉ quyền riêng tư. Mặc dù định tuyến hành tây (onion routing) có thể bảo vệ nhất định, ví dụ mã hóa thông tin định tuyến từng bậc, ngoài người khởi tạo Alice ra, mỗi người chỉ biết láng giềng liền kề, không biết toàn bộ đường dẫn, nhưng thực tế HTLC vẫn dễ bị suy luận mối liên hệ. Chúng ta nhìn từ góc nhìn toàn tri thức đường dẫn sau:
Giả sử Bob và Daniel là hai nút do cùng một thực thể kiểm soát, hằng ngày nhận được nhiều HTLC từ mọi người. Họ phát hiện mỗi lần Alice và Carol gửi HTLC, khóa cần biết luôn giống nhau, và Eve bên dưới kết nối với Daniel luôn biết nội dung khóa R. Do đó Daniel và Bob có thể đoán rằng có đường thanh toán giữa Alice và Eve, vì họ luôn liên quan đến cùng một khóa, từ đó suy luận mối quan hệ giữa Alice và Eve và giám sát.
Đối với điều này, Fiber sử dụng PTLC, cải tiến riêng tư trên nền HTLC, mỗi PTLC trong đường dẫn thanh toán dùng khóa khác nhau để mở khóa, chỉ quan sát khóa yêu cầu bởi PTLC không thể xác định mối liên hệ lẫn nhau. Kết hợp PTLC với định tuyến hành tây, Fiber có thể trở thành giải pháp thanh toán riêng tư lý tưởng.
Hơn nữa, Lightning Network truyền thống tồn tại kịch bản «tấn công vòng thay thế giao dịch» (replacement cycling attack) có thể khiến tài sản của trung gian trong đường thanh toán bị đánh cắp. Phát hiện này thậm chí khiến nhà phát triển Antoine Riard rời bỏ công việc phát triển Lightning Network. Đến nay Bitcoin Lightning Network vẫn chưa có biện pháp căn bản giải quyết vấn đề này, đã trở thành điểm đau.
Hiện tại, CKB chính thức cải tiến ở cấp độ pool giao dịch, giúp Fiber giải quyết được kịch bản tấn công trên. Vì tấn công vòng thay thế và giải pháp khá phức tạp, bài viết này không định chiếm thêm dung lượng để giải thích, độc giả quan tâm có thể đọc bài viết sau của BTCStudy và tài liệu chính thức của CKB.
Nói chung, dù về riêng tư hay an toàn, Fiber đều cải tiến đáng kể so với Lightning Network truyền thống.
Thanh toán nguyên tử xuyên miền giữa Fiber và Lightning Network Bitcoin
Sử dụng HTLC và PTLC, Fiber có thể thực hiện thanh toán xuyên miền với Lightning Network Bitcoin, đồng thời đảm bảo «tính nguyên tử của hành vi xuyên miền», nghĩa là tất cả bước liên quan đến xuyên miền hoặc đều thành công, hoặc đều thất bại, không có tình huống thành công một phần thất bại một phần.
Khi tính nguyên tử xuyên miền được đảm bảo, có thể đảm bảo bản thân hành vi xuyên miền sẽ không gây tổn thất tài sản, như vậy có thể liên kết Fiber với Lightning Network Bitcoin, ví dụ có thể xây dựng đường dẫn thanh toán trong mạng hỗn hợp gồm Fiber và Lightning Network, trực tiếp chuyển tiền từ Fiber cho người dùng trong Lightning Network BTC (đầu nhận chỉ giới hạn BTC), cũng có thể dùng tài sản CKB và RGB++ trong Fiber để đổi lấy lượng Bitcoin tương đương trong Lightning Network BTC.
Chúng ta nói sơ lược nguyên lý: Giả sử Alice vận hành nút trong mạng Fiber, Bob vận hành nút trong Lightning Network Bitcoin, Alice muốn chuyển tiền cho Bob, cô có thể dùng trung gian chuyển tiếp Ingrid để thực hiện giao dịch này. Ingrid sẽ vận hành nút trong cả Fiber và Lightning Network BTC, đóng vai trò trung gian trong đường dẫn chuyển tiền.
Nếu Bob muốn nhận 1 BTC, Alice có thể thỏa thuận tỷ lệ đổi với Ingrid, dùng 1 CKB đổi 1 BTC. Sau đó Alice gửi 1.1 CKB cho Ingrid trong Fiber, rồi Ingrid gửi 1 BTC cho Bob trong Lightning Network BTC, và Ingrid giữ lại 0.1 CKB làm phí.
Cách thực hiện cụ thể ở đây thực chất là thiết lập đường dẫn thanh toán giữa Alice, Bob và Ingrid, tức Alice—>Ingrid—>Bob, sau đó dùng HTLC. Nguyên lý tương tự đã nói trước đó, để nhận tiền, Bob phải nói cho Ingrid nội dung khóa R. Ngay khi Ingrid có được khóa R, có thể mở khóa số tiền Alice khóa trong HTLC.
Cần lưu ý, hai hành vi xuyên miền xảy ra trong Lightning Network BTC và Fiber này mang tính nguyên tử, nghĩa là hoặc cả hai HTLC đều được mở khóa, thanh toán xuyên miền thực hiện thành công. Hoặc cả hai đều không mở khóa, thanh toán xuyên miền thất bại, không xảy ra trường hợp Alice trả tiền mà Bob không nhận được.
(Thực tế trung gian Ingrid có thể sau khi biết khóa R lại không mở khóa HTLC của Alice, nhưng như vậy người chịu thiệt là trung gian Ingrid chứ không phải người dùng Alice, do đó thiết kế Fiber an toàn cho người dùng)
Cách này cho phép chuyển tiền giữa các mạng P2P khác nhau mà không cần tin tưởng bên thứ ba, hầu như không cần sửa đổi gì.
Những ưu điểm khác của Fiber so với Lightning Network BTC
Trước đó chúng ta đã nói, Fiber hỗ trợ tài sản gốc 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 tức thì, phù hợp hơn với nhu cầu thanh toán nhỏ lẻ hằng ngày.
Hơn nữa, Lightning Network Bitcoin có một điểm đau chính là quản lý thanh khoản. Có lẽ bạn nhớ lúc đầu chúng ta nói rằng tổng số dư trong kênh thanh toán là cố định, nếu số dư của một bên cạn kiệt, sẽ không thể chuyển tiền cho đối phương, trừ khi đối phương chuyển tiền cho anh ta trước, lúc đó cần nạp lại tiền hoặc mở kênh mới.
Hơn nữa, nếu trong mạng đa bậc phức tạp, một số nút trung gian thiếu thanh khoản không thể chuyển tiền ra ngoài, có thể khiến toàn bộ đường dẫn thanh toán thất bại. Đây là một điểm đau của Lightning Network, giải pháp hiện tại chủ yếu là cung cấp phương án nạp thanh khoản hiệu quả, đảm bảo đa số nút luôn có thể nạp tiền bất cứ lúc nào.
Tuy nhiên, trong Lightning Network BTC, việc nạp thanh khoản, mở hoặc đóng kênh đều diễn ra trên chuỗi BTC, nếu phí mạng BTC rất cao, sẽ ảnh hưởng xấu đến trải nghiệm người dùng (UX) của kênh thanh toán. Giả sử bạn muốn mở kênh dung lượng 100 USD, nhưng phí mở kênh mất 10 USD, như vậy kênh đã mất 10% vốn ngay từ đầu, điều này đa số người dùng không thể chấp nhận; việc nạp thanh khoản cũng tương tự.
Đối với điều này Fiber có lợi thế rất rõ rệt. Trước hết TPS của CKB cao hơn nhiều so với BTC, phí có thể ở mức cent Mỹ; thứ hai, để giải quyết vấn đề không thể chuyển tiền do thiếu thanh khoản, Fiber dự kiến hợp tác với Mercury layer ra mắt giải pháp mới, khiến việc nạp thanh khoản có thể thoát khỏi thao tác trên chuỗi, giải quyết vấn đề UX và chi phí.
Tới đây, chúng ta đã hệ thống hóa toàn bộ kiến trúc kỹ thuật tổng thể của Fiber, bảng so sánh tổng quan với Lightning Network Bitcoin như hình trên. Vì bản thân Fiber và Lightning Network liên quan đến quá nhiều kiến thức phức tạp, một bài viết đơn thuần khó có thể bao quát toàn bộ, trong tương lai chúng tôi sẽ tiếp tục loạt bài về chủ đề Lightning Network và Fiber, kính mời quý vị đón chờ.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@godrealmx
