Chuyển tiếp tiêu đề gốc '系统解读Fiber:把闪电网络嫁接到CKB上的宏大实验'

Vào ngày 23 tháng 8, CKB chính thức phát hành Mạng sợi, một giải pháp Mạng Lightning dựa trên CKB. Tin tức này nhanh chóng gây ra cuộc thảo luận sôi nổi trong cộng đồng, dẫn đến một sự tăng mạnh gần 30% trong giá của CKB trong vòng một ngày. Phản ứng mạnh mẽ có thể được quy cho câu chuyện hấp dẫn về Mạng Lightning và việc Mạng sợi cung cấp một giải pháp nâng cấp hơn so với Mạng Lightning truyền thống với nhiều cải tiến. Ví dụ, Mạng sợi hỗ trợ nhiều loại tài sản một cách tự nhiên, bao gồm CKB, BTC và stablecoins, và được hưởng lợi từ mức phí giao dịch thấp và thời gian phản hồi nhanh hơn của CKB, giúp tiến bộ đáng kể về trải nghiệm người dùng. Ngoài ra, Mạng sợi đã tối ưu hóa nhiều về quyền riêng tư và an ninh. Hơn nữa, Mạng sợi và Mạng Lightning của BTC có thể kết nối với nhau, tạo thành một mạng P2P lớn hơn. Người đại diện của CKB thậm chí còn đề cập rằng họ dự định thiết lập 100,000 nút vật lý trong Mạng sợi và Mạng Lightning trong các sự kiện ngoại tuyến để tăng cường và tiến triển mạng thanh toán P2P. Điều này không thể phủ nhận là một câu chuyện lớn và 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, đó sẽ là một lợi ích quan trọng cho Lightning Network, CKB, và hệ sinh thái Bitcoin rộng lớn hơn. Theo dữ liệu mempool, BTC Lightning Network hiện tại đang nắm giữ hơn 300 triệu đô la trong quỹ, với khoảng 12.000 nút và gần 50.000 kênh thanh toán được thiết lập giữa chúng.

Trên spendmybtc.com, chúng ta có thể quan sát thấy rằng ngày càng có nhiều người bán hỗ trợ thanh toán Lightning Network. Khi sự công nhận của BTC tăng lên, sự gia tăng của các giải pháp thanh toán ngoài chuỗi như Lightning Network và Fiber có thể sẽ đạt được đà. Để phân tích một cách có hệ thống giải pháp kỹ thuật của Fiber, "Geek Web3" đã đưa ra báo cáo nghiên cứu này về giải pháp Fiber tổng thể. Là một triển khai của Lightning Network dựa trên CKB, các nguyên tắc của Fiber phần lớn phù hợp với Bitcoin Lightning Network nhưng bao gồm các tối ưu hóa trong nhiều chi tiết. Kiến trúc tổng thể của Fiber bao gồm bốn thành phần cốt lõi: kênh thanh toán, Tháp canh, định tuyến đa bước và thanh toán đa miền. Hãy bắt đầu bằng cách giải thích thành phần quan trọng nhất: các kênh thanh toán.

Nền tảng của Lightning Network và Fiber: Kênh thanh toán

Các kênh thanh toán về cơ bản chuyển giao dịch ra khỏi chuỗi, sau một thời gian cuối cùng trạng thái được giải quyết trên chuỗi. Khi giao dịch hoàn tất ngoài chuỗi, chúng thường bỏ qua các hạn chế về hiệu suất của chuỗi chính, chẳng hạn như BTC. Ví dụ, nếu Alice và Bob mở một kênh cùng nhau, họ trước tiên tạo một tài khoản đa chữ ký trên chuỗi và gửi một số quỹ, ví dụ 100 đơn vị mỗi người, là số dư của họ trong kênh ngoại chuỗi. Sau đó, họ có thể tiến hành nhiều giao dịch trong kênh, và khi họ đóng kênh, họ đồng bộ số dư cuối cùng trên chuỗi, với tài khoản đa chữ ký thực hiện thanh toán cho cả hai bên - đây là “thanh toán.”

Ví dụ, nếu cả hai bên đều bắt đầu với mỗi bên 100 đơn vị, và Alice chuyển 50 đơn vị cho Bob, tiếp theo là chuyển tiếp 10 đơn vị, và sau đó Bob chuyển 30 đơn vị trở lại cho Alice, số dư cuối cùng của họ sẽ là: Alice - 70 đơn vị, Bob - 130 đơn vị. Tổng số dư vẫn không thay đổi, như đã minh họa bằng ví dụ về quả cầu tính. Nếu một bên rời khỏi kênh, số dư cuối cùng (Alice: 70, Bob: 130) được đồng bộ trên chuỗi, và 200 đơn vị của tài khoản đa chữ ký được phân phối theo số dư cuối cùng này để hoàn tất việc thanh toán.

Mặc dù quá trình này có vẻ đơn giản, nhưng nó liên quan đến những cân nhắc phức tạp trong thực tế. Bạn không thể dự đoán khi nào bên kia sẽ chọn thoát khỏi kênh. Ví dụ: Bob có thể thoát sau giao dịch thứ hai hoặc thậm chí sau giao dịch đầu tiên, vì kênh cho phép người tham gia thoát tự do. Để giải quyết vấn đề này, hệ thống giả định rằng bất kỳ ai cũng có thể thoát ra bất cứ lúc nào và một trong hai bên có thể gửi số dư cuối cùng cho chuỗi để giải quyết. Điều này được quản lý thông qua "giao dịch cam kết", ghi lại số dư mới nhất trong kênh. Mỗi giao dịch tạo ra một giao dịch cam kết tương ứng. Để thoát khỏi kênh, bạn gửi giao dịch cam kết gần đây nhất cho chuỗi để rút cổ phần của bạn khỏi tài khoản đa chữ ký.

Chúng tôi có thể kết luận rằng các giao dịch cam kết được sử dụng để giải quyết số dư của cả hai bên trong kênh trên chuỗi, với một trong hai bên có thể gửi giao dịch cam kết mới nhất để thoát khỏi kênh. Tuy nhiên, có một kịch bản độc hại quan trọng: Bob có thể gửi số dư lỗi thời và giao dịch cam kết cho chuỗi. Ví dụ: sau khi tạo Commit Tx3, số dư của Bob là 130 đơn vị. Nhưng để có lợi cho mình, Bob có thể gửi Commit Tx2 lỗi thời, cho thấy số dư là 160 đơn vị. Sự cân bằng lỗi thời này đại diện cho một cuộc tấn công "chi tiêu gấp đôi" cổ điển.

Để ngăn chặn các tình huống chi tiêu gấp đôi như vậy, phải có các biện pháp trừng phạt thích hợp. Thiết kế của những biện pháp trừng phạt này nằm ở trung tâm của hệ thống kênh thanh toán một cấp, và hiểu điều này là cực kỳ quan trọng để hiểu cách hoạt động của các kênh thanh toán. Trong thiết kế kênh, nếu một trong hai bên gửi một trạng thái lỗi thời và giao dịch cam kết lên chuỗi, thay vì được lợi, họ sẽ phát hiện rằng bên kia có thể rút hết các quỹ. Điều này sử dụng các khái niệm “giao dịch cam kết bất đối xứng” và “chìa khóa thu hồi,” đều rất quan trọng. Hãy trước tiên giải thích “giao dịch cam kết bất đối xứng” bằng việc sử dụng Commit Tx3 như một ví dụ.

Trong tình huống này, Bob tạo một giao dịch cam kết và gửi nó cho Alice xử lý. Như đã thể hiện, giao dịch này liên quan đến việc chuyển Bitcoin, tuyên bố rằng 70 đơn vị từ tài khoản đa chữ ký được phân bổ cho Alice và 130 đơn vị cho Bob. Tuy nhiên, các điều kiện mở khóa là “bất đối xứng,” đặt ra các hạn chế nghiêm ngặt đối với Alice và có lợi cho Bob.

Khi Alice nhận được giao dịch cam kết từ Bob, cô ấy có thể thêm chữ ký của mình để đáp ứng yêu cầu đa chữ ký 2/2. Alice sau đó có thể chọn gửi giao dịch cam kết này trên chuỗi khối để thoát khỏi kênh. Tuy nhiên, cô ấy có thể tiếp tục thực hiện các giao dịch trong kênh nếu không gửi nó.

Quan trọng nhất là phải lưu ý rằng giao dịch cam kết này được xây dựng bởi Bob và có các điều kiện không thuận lợi cho Alice. Alice có lựa chọn là chấp nhận hoặc từ chối nó, nhưng chúng ta cần đảm bảo rằng cô ấy vẫn giữ được một số quyền tự chủ. Trong thiết kế của các kênh thanh toán, chỉ có Alice mới có thể gửi giao dịch cam kết “không thuận lợi” lên chuỗi vì giao dịch cam kết yêu cầu chữ ký đa chữ ký 2/2. Sau khi Bob xây dựng giao dịch tại địa phương, nó chỉ có chữ ký của anh ấy và thiếu chữ ký của Alice.

Alice có thể "chấp nhận chữ ký của Bob nhưng giữ lại chữ ký của chính mình". Điều này tương tự như một hợp đồng yêu cầu chữ ký kép. Nếu Bob ký trước và gửi hợp đồng cho Alice, cô ấy có thể chọn không cung cấp chữ ký của mình. Để làm cho hợp đồng có hiệu lực, Alice sẽ cần phải ký và sau đó nộp nó; Nếu không, cô ấy có thể kiềm chế ký hoặc nộp nó. Do đó, trong trường hợp này, Alice có phương tiện để hạn chế hành động của Bob.

Điểm quan trọng là: Mỗi khi giao dịch xảy ra trong kênh, một cặp giao dịch cam kết được tạo ra, với hai phiên bản gương nhau, như minh họa bên dưới. Alice và Bob có thể tạo ra các giao dịch cam kết thuận lợi cho bản thân mình, chỉ định số dư hoặc số tiền tương ứng để nhận khi kết thúc, sau đó gửi các giao dịch này cho nhau để xử lý.

Một cách thú vị, trong khi hai giao dịch cam kết này khai báo cùng “số tiền nhận được khi thoát”, điều kiện rút tiền của chúng lại khác nhau. Điều này minh họa khái niệm về “giao dịch cam kết không đối xứng” đã được đề cập trước đó.

Như đã giải thích trước đó, mỗi giao dịch cam kết đều cần phải có chữ ký đa chữ số 2/2 để có hiệu lực. Giao dịch cam kết được tạo ra bởi Bob ưa thích bản thân anh ấy không đáp ứng yêu cầu chữ ký đa chữ số 2/2, trong khi giao dịch cam kết đáp ứng yêu cầu này được giữ bởi Alice và chỉ có thể được gửi bởi cô ấy, tạo ra một cơ chế kiểm tra và cân bằng. Cùng một logic áp dụng ngược lại.

Do đó, Alice và Bob chỉ có thể gửi các giao dịch cam kết không thuận lợi cho chính họ. Nếu bất kỳ bên nào gửi một giao dịch cam kết lên chuỗi và nó trở nên hiệu quả, kênh sẽ đóng lại.

Liên quan đến kịch bản "chi tiêu gấp đôi" đã thảo luận trước đó, nếu ai đó gửi một giao dịch cam kết lỗi thời cho chuỗi, khái niệm "khóa thu hồi" sẽ phát huy tác dụng. Ví dụ: nếu Bob gửi Tx2 đã lỗi thời cho chuỗi, Alice có thể sử dụng khóa thu hồi được liên kết với Tx2 để rút số tiền mà Bob đáng lẽ phải nhận.

Trong sơ đồ ví dụ, giả sử giao dịch cam kết mới nhất là Cam kết Tx3 và Tx2 đã lỗi thời, nếu Bob nộp Tx2 lỗi thời, Alice có thể thực hiện trong khoảng thời gian khóa cần sử dụng khóa thu hồi của Tx2 để rút tiền của Bob.

Về Tx3 mới nhất, Alice không sở hữu khóa thu hồi của nó và chỉ nhận được nó sau khi Tx4 được tạo ra trong tương lai. Điều này là do tính chất của mật mã khóa công khai/số riêng và các đặc tính UTXO. Vì sự ngắn gọn, chi tiết triển khai của khóa thu hồi không được thảo luận ở đây.

Điểm quan trọng cần lưu ý là nếu Bob dám gửi một giao dịch cam kết lỗi thời lên chuỗi, Alice có thể sử dụng khóa thu hồi để rút tiền của Bob như một khoản phạt. Tương tự, nếu Alice hành động độc hại, Bob cũng có thể áp dụng cùng một khoản phạt đối với cô ấy. Cơ chế này đảm bảo rằng các kênh thanh toán một-một hiệu quả trong việc ngăn chặn gian lận kép, vì các bên tham gia có lý trí sẽ tránh hành động độc hại.

Trong ngữ cảnh này, Fiber, dựa trên CKB, cung cấp cải tiến đáng kể so với Bitcoin Lightning Network. Nó hỗ trợ giao dịch và chuyển khoản của nhiều loại tài sản khác nhau một cách tự nhiên, bao gồm CKB, BTC và stablecoin RGB++, trong khi Lightning Network chỉ hỗ trợ Bitcoin một cách tự nhiên. Ngay cả sau khi nâng cấp Taproot Asset, Bitcoin Lightning Network vẫn không thể hỗ trợ các tài sản không phải là BTC một cách tự nhiên và chỉ có thể hỗ trợ stablecoin một cách gián tiếp.

(Nguồn hình ảnh: Dapangdun) Ngoài ra, do Fiber dựa vào CKB như là chuỗi chính Layer 1 của mình, phí mở và đóng kênh giảm đáng kể so với Mạng Lightning BTC. Điều này giảm chi phí giao dịch của người dùng, đồng thời tạo ra một ưu thế rõ ràng trong trải nghiệm người dùng (UX).

24/7 bảo mật: WatchTower

Một thách thức với các khóa thu hồi là các bên tham gia kênh phải liên tục theo dõi lẫn nhau để ngăn chặn việc nộp giao dịch cam kết đã lỗi thời. Tuy nhiên, không ai có thể trực tuyến 24/7, vì vậy điều gì xảy ra nếu một bên hành động xấu trong khi bên kia đang ngoại tuyến? Cả Fiber và Bitcoin Lightning Network đều giải quyết vấn đề này với thiết kế của WatchTowers.

WatchTowers được thiết kế để giám sát hoạt động trên chuỗi liên tục. Nếu ai đó gửi một giao dịch cam kết lỗi thời, WatchTower sẽ thực hiện hành động kịp thời để bảo vệ kênh và quỹ. Dưới đây là cách hoạt động của nó:

Sau khi giao dịch cam kết đã hết hạn, Alice hoặc Bob có thể chuẩn bị trước một giao dịch phạt tương ứng (sử dụng khóa thu hồi để xử lý giao dịch cam kết đã hết hạn, với người hưởng được tuyên bố là chính họ). Sau đó, họ cung cấp văn bản của giao dịch phạt này cho WatchTower.

Khi WatchTower phát hiện một giao dịch cam kết đã lỗi thời được gửi lên chuỗi, nó cũng sẽ gửi giao dịch phạt đã chuẩn bị, thực thi việc phạt và bảo vệ tính toàn vẹn của kênh.

Fiber bảo vệ sự riêng tư của các thành viên bằng cách yêu cầu người dùng chỉ gửi “băm của giao dịch cam kết lỗi thời + văn bản thô của giao dịch phạt” đến WatchTower. Điều này đồng nghĩa với việc, ban đầu WatchTower chỉ biết băm của giao dịch cam kết, không phải văn bản thô của nó. WatchTower chỉ nhìn thấy văn bản thô nếu ai đó thực sự gửi giao dịch cam kết lỗi thời trên chuỗi, tại điểm này nó cũng sẽ gửi giao dịch phạt. Điều này đảm bảo rằng WatchTower chỉ sẽ nhìn thấy hồ sơ giao dịch của một thành viên nếu có hành vi sai trái thực sự, và thậm chí, ngay cả khi có, nó cũng chỉ nhìn thấy một giao dịch duy nhất.

Về mặt tối ưu hóa, Fiber cải thiện cách tiếp cận của Bitcoin Lightning Network đối với các cơ chế phạt. "LN-Penalty" của Lightning Network có một nhược điểm đáng chú ý: Tháp canh phải lưu trữ tất cả các hàm băm giao dịch cam kết lỗi thời và các khóa thu hồi tương ứng, dẫn đến áp lực lưu trữ đáng kể. 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 đề này. Eltoo sẽ cho phép giao dịch cam kết mới nhất để phạt những giao dịch lỗi thời, giảm nhu cầu lưu trữ tất cả các giao dịch trước đó. Tuy nhiên, giải pháp này yêu cầu kích hoạt opcode SIGHASH_ANYPREVOUT, chưa được triển khai.

Mặt khác, Fiber sử dụng giao thức Daric, điều chỉnh thiết kế khóa thu hồi để tạo ra một khóa thu hồi duy nhất có thể áp dụng cho nhiều giao dịch cam kết cũ. Phương pháp này giảm đáng kể nhu cầu lưu trữ cho WatchTowers và các máy khách người dùng.

Về hệ thống giao thông mạng: Các kênh thanh toán phù hợp cho các giao dịch một cách một, nhưng Mạng Lightning hỗ trợ thanh toán đa điểm, cho phép giao dịch giữa các bên không có kênh trực tiếp bằng cách định tuyến qua các nút trung gian. Ví dụ, nếu Alice và Ken không có kênh trực tiếp nhưng Ken và Bob có, và Bob và Alice có, Bob có thể đóng vai trò làm trung gian để t facilità giao dịch giữa Alice và Ken.

"Định tuyến đa bước" tăng cường tính linh hoạt và vùng phủ sóng của mạng. Tuy nhiên, người gửi cần phải biết trạng thái của tất cả các nút và kênh công cộng. Trong Fiber, toàn bộ cấu trúc mạng, bao gồm tất cả các kênh công cộng, hoàn toàn minh bạch, cho phép bất kỳ nút nào truy cập thông tin mạng từ các nút khác. Vì trạng thái mạng trong Lightning Network liên tục thay đổi, Fiber sử dụng thuật toán Dijkstra để tìm đường dẫn định tuyến ngắn nhất, giảm thiểu số lượng trung gian và thiết lập đường dẫn giao dịch giữa hai bên.

Để giải quyết vấn đề tin cậy với các trung gian: Làm thế nào bạn có thể đảm bảo họ trung thực? Ví dụ, nếu Alice cần thanh toán 100 đơn vị cho Ken, nhưng Bob, người làm trung gian giữ lại tiền. HTLC và PTLC được sử dụng để ngăn chặn hành vi độc ác như vậy. Giả sử Alice muốn thanh toán Daniel 100 đơn vị, nhưng họ không có kênh trực tiếp. Alice nhận ra rằng cô có thể định tuyến thanh toán qua các trung gian Bob và Carol. HTLC được giới thiệu như là kênh thanh toán: Alice đầu tiên khởi xướng yêu cầu đến Daniel, sau đó Daniel cung cấp cho Alice một hash r, nhưng Alice không biết preimage R tương ứng với r.

Sau đó, Alice xây dựng các điều khoản thanh toán với Bob qua HTLC: Alice sẵn lòng trả cho Bob 102 đơn vị, nhưng Bob phải tiết lộ khóa R trong vòng 30 phút; nếu không, Alice sẽ rút tiền. Tương tự, Bob tạo ra một HTLC với Carol: Bob sẽ trả Carol 101 đơn vị, nhưng Carol phải tiết lộ khóa R trong vòng 25 phút; nếu không, Bob sẽ rút tiền. Carol cũng làm điều tương tự với Daniel: Carol sẵn lòng trả cho Daniel 100 đơn vị, nhưng Daniel phải tiết lộ khóa R trong vòng 20 phút; nếu không, Carol sẽ rút tiền.

Daniel hiểu rằng chìa khóa R được yêu cầu bởi Carol thực sự là những gì mà Alice muốn, vì chỉ có Alice quan tâm đến giá trị của R. Vì vậy, Daniel hợp tác với Carol, cung cấp chìa khóa R và nhận được 100 đơn vị từ Carol. Như vậy, Alice đạt được mục tiêu của mình là trả cho Daniel 100 đơn vị.

Sau đó, Carol cung cấp chìa khóa R cho Bob và nhận được 101 đơn vị. Bob sau đó cung cấp chìa khóa R cho Alice và nhận được 102 đơn vị. Quan sát lợi và lỗ của mọi người, Alice mất 102 đơn vị, Bob và Carol mỗi người kiếm được 1 đơn vị ròng và Daniel nhận được 100 đơn vị. 1 đơn vị kiếm được bởi Bob và Carol là phí được trích từ Alice.

Ngay cả khi ai đó trong đường thanh toán, chẳng hạn như Carol, không cung cấp khóa R cho Bob ở hạ lưu, điều này cũng không dẫn đến mất mát đối với Bob: sau khi hết thời gian chờ, Bob có thể rút tiền HTLC mà anh ấy đã xây dựng. Điều tương tự áp dụng cho Alice. Tuy nhiên, Mạng Lightning cũng có những vấn đề của riêng nó: đường đi không nên quá dài. Nếu đường đi quá dài với quá nhiều trung gian, nó có thể làm giảm độ tin cậy của thanh toán. Một số trung gian có thể offline hoặc thiếu cân bằng đủ để xây dựng một HTLC cụ thể (ví dụ, mỗi trung gian trong ví dụ trước đó cần giữ hơn 100 đơn vị). Do đó, việc thêm nhiều trung gian tăng khả năng xảy ra lỗi.

Ngoài ra, HTLC có thể làm rò rỉ quyền riêng tư. Mặc dù định tuyến hành tây có thể cung cấp một số bảo vệ quyền riêng tư bằng cách mã hóa thông tin định tuyến ở mỗi bước nhảy, để mỗi người tham gia chỉ biết hàng xóm trực tiếp của họ chứ không phải đường dẫn hoàn chỉnh, HTLC vẫn dễ bị suy luận về các mối quan hệ. Từ góc độ cao hơn, đường dẫn định tuyến hoàn chỉnh vẫn có thể được suy luận.

Giả sử rằng Bob và Daniel được điều khiển bởi cùng một thực thể và nhận nhiều HTLC mỗi ngày. Họ nhận thấy rằng khóa R được yêu cầu bởi Alice và Carol luôn luôn giống nhau, và nút downstream Eve, kết nối với Daniel, luôn biết nội dung của khóa R. Do đó, Daniel và Bob có thể suy luận rằng có một đường dẫn thanh toán giữa Alice và Eve, vì họ luôn xử lý cùng một khóa và có thể theo dõi mối quan hệ của họ. Để giải quyết vấn đề này, Fiber sử dụng PTLC, tăng cường tính riêng tư so với HTLC bằng cách sử dụng các khóa khác nhau để mở khóa mỗi PTLC trong đường dẫn thanh toán. Chỉ quan sát PTLC một mình không thể xác định mối quan hệ giữa các nút. Bằng cách kết hợp PTLC với định tuyến hành cebola, Fiber trở thành một giải pháp lý tưởng cho thanh toán bảo vệ tính riêng tư.

Ngoài ra, Lightning Network truyền thống dễ bị tấn công "chu kỳ thay thế", có thể dẫn đến hành vi trộm cắp tài sản từ các trung gian trong đường dẫn thanh toán. Vấn đề này đã khiến nhà phát triển Antoine Riard rút khỏi phát triển Lightning Network. Hiện tại, Bitcoin Lightning Network thiếu một giải pháp cơ bản cho vấn đề này, khiến nó trở thành một điểm đau. Hiện tại, CKB giải quyết kịch bản tấn công này thông qua các cải tiến ở cấp độ nhóm giao dịch, cho phép Fiber giảm thiểu vấn đề. Vì cuộc tấn công đi xe đạp thay thế và các giải pháp của nó khá phức tạp, bài viết này sẽ không đi sâu hơn vào nó. Bạn đọc quan tâm có thể tham khảo các bài viết liên quan từ BTCStudy và các nguồn chính thức của CKB để biết thêm thông tin.

Tổng thể, Fiber đại diện cho một cải tiến đáng kể so với mạng Lightning truyền thống về cả khía cạnh bảo mật và riêng tư. Fiber nâng cao khả năng thanh toán ngang domain nguyên tử giữa chính nó và mạng Lightning Bitcoin.

Sử dụng HTLC và PTLC, Fiber có thể đạt được thanh toán chéo miền với Bitcoin Lightning Network, đảm bảo “tính nguyên tử của các hành động chéo miền,” có nghĩa là tất cả các bước của giao dịch chéo miền đều hoàn toàn thành công hoặc hoàn toàn thất bại, không có thành công hoặc thất bại một phần nào. Với sự đảm bảo tính nguyên tử chéo miền, rủi ro mất tài sản được giảm thiểu. Điều này cho phép Fiber kết nối với Bitcoin Lightning Network, cho phép thanh toán trực tiếp từ Fiber đến người dùng trong BTC Lightning Network (với người nhận bị giới hạn là BTC) và cho phép chuyển đổi CK

Chuyển đổi tài sản B và RGB++ thành Bitcoin tương đương trong Mạng lưới BTC Lightning.

Dưới đây là một giải thích đơn giản về quá trình: Giả sử Alice vận hành một nút trong mạng Fiber, và Bob vận hành một nút trong Mạng Bitcoin Lightning. Nếu Alice muốn chuyển tiền cho Bob, cô ấy có thể làm điều đó thông qua một trung gian qua miền, Ingrid. Ingrid sẽ vận hành các nút trong cả hai mạng Fiber và BTC Lightning, đóng vai trò là trung gian trong đường dẫn thanh toán.

Nếu Bob muốn nhận 1 BTC, Alice có thể thương lượng tỷ lệ trao đổi với Ingrid, đặt 1 CKB bằng 1 BTC. Alice sau đó sẽ gửi 1,1 CKB cho Ingrid trong mạng Fiber, và Ingrid sẽ gửi 1 BTC cho Bob trong mạng Bitcoin Lightning, giữ lại 0,1 CKB làm phí.

Quá trình liên quan đến việc thiết lập một đường dẫn thanh toán giữa Alice, Ingrid và Bob, sử dụng HTLC. Bob phải cung cấp cho Ingrid khóa R để nhận được số tiền. Khi Ingrid có khóa R, cô ấy có thể mở khóa số tiền mà Alice đã khóa trong HTLC.

Các hoạt động chéo lĩnh vực giữa Mạng Lightning BTC và Fiber là nguyên tử, có nghĩa là cả hai HTLC đều được mở khóa và thanh toán chéo lĩnh vực được thực hiện thành công, hoặc cả hai đều không được mở khóa và thanh toán sẽ thất bại. Điều này đảm bảo rằng Alice sẽ không mất tiền nếu Bob không nhận được nó.

Ingrid có thể tiềm ẩn không mở khóa HTLC của Alice sau khi biết khóa R, nhưng điều này sẽ gây hại cho Ingrid, không phải Alice. Do đó, thiết kế của Fiber đảm bảo an toàn cho người dùng và không đòi hỏi sự tin cậy vào bên thứ ba, cho phép chuyển giao giữa các mạng P2P khác nhau với ít sự điều chỉnh.

Những lợi ích khác của Fiber so với BTC Lightning Network

Trước đây, chúng tôi đã đề cập rằng Fiber hỗ trợ tài sản CKB bản địa và tài sản RGB++ (đặc biệt là stablecoin), mang lại tiềm năng đáng kể cho thanh toán trực tuyến và làm cho nó phù hợp cho các giao dịch nhỏ hằng ngày.

Trái ngược với đó, một vấn đề lớn với Mạng Lightning của Bitcoin là quản lý thanh khoản. Như chúng ta đã thảo luận ở đầu, tổng số dư trong một kênh thanh toán là cố định. Nếu số dư của một bên bị hết, họ không thể chuyển tiền cho bên kia trừ khi bên kia gửi tiền trước. Điều này đòi hỏi nạp lại tiền hoặc mở một kênh mới.

Ngoài ra, trong một mạng lưới phức tạp với nhiều bước nhảy, nếu một số nút trung gian có số dư không đủ và không thể chuyển tiếp thanh toán, điều này có thể làm cho toàn bộ đường dẫn thanh toán bị thất bại. Đây là một trong những điểm đau của Mạng Lightning. Giải pháp điển hình bao gồm cung cấp cơ chế tiêm lượng tiền hiệu quả để đảm bảo rằng hầu hết các nút có thể tiêm vốn khi cần thiết.

Tuy nhiên, trong Mạng Lightning của Bitcoin, việc cung cấp thanh khoản, cũng như mở hoặc đóng kênh, đều diễn ra trên chuỗi khối Bitcoin. Nếu phí mạng Bitcoin cao, điều này ảnh hưởng tiêu cực đến trải nghiệm của người dùng trong việc sử dụng các kênh thanh toán. Ví dụ, nếu bạn muốn mở một kênh với khả năng tối đa là $100 nhưng phí thiết lập là $10, điều này có nghĩa là 10% số tiền của bạn được tiêu hao chỉ để thiết lập kênh, điều này không chấp nhận được đối với phần lớn người dùng. Vấn đề tương tự cũng áp dụng cho việc cung cấp thanh khoản.

Ngược lại, Fiber cung cấp những lợi ích đáng kể. Đầu tiên, TPS (giao dịch mỗi giây) của CKB cao hơn nhiều so với Bitcoin, với phí rơi vào mức đội xu. Thứ hai, để giải quyết vấn đề thiếu thanh khoản và đảm bảo giao dịch trôi chảy, Fiber dự định hợp tác với Mercury Layer để giới thiệu các giải pháp mới loại bỏ nhu cầu về hoạt động trên chuỗi để tiêm thanh khoản, từ đó giải quyết các vấn đề UX và chi phí.

Chúng tôi đã phác thảo hệ thống kiến trúc kỹ thuật tổng thể của Fiber một cách hệ thống, với một bản tóm tắt so sánh nó với Mạng Lightning Bitcoin như được thể hiện trong hình ảnh ở trên. Với sự phức tạp và phạm vi của các chủ đề được đề cập bởi cả Fiber và Mạng Lightning, một bài viết đơn lẻ có thể không đủ sức để đề cập đến mọi khía cạnh. Chúng tôi sẽ phát hành một loạt các bài viết trong tương lai tập trung vào các khía cạnh khác nhau của cả Mạng Lightning và Fiber. Hãy chờ đợi thêm thông tin cập nhật.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được sao chép từ [Geek web3].Chuyển tiêu đề gốc '系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验'. Tất cả bản quyền thuộc về tác giả gốc [Faust & Nickqiao, 极客web3]. Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ với Gate Learnnhóm và họ sẽ xử lý nhanh chóng.
2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.