Nghệ thuật của tính thanh khoản: Chúng ta cần mạng lưới mở rộng ngoài chuỗi Bitcoin như thế nào?
Tuyển chọn TechFlowTuyển chọn TechFlow
Nghệ thuật của tính thanh khoản: Chúng ta cần mạng lưới mở rộng ngoài chuỗi Bitcoin như thế nào?
Bài viết này sẽ thảo luận về quá trình phát triển và xu hướng tương lai của mạng lưới kênh từ góc độ mở rộng tính thanh khoản.
Chuyên sâu báo cáo Web3Tác giả: Ben, Người sáng lập Discoco Labs
Lời mở đầu
Tôi đã suy nghĩ trong thời gian dài về một vấn đề: Logic cốt lõi của việc mở rộng quy mô gốc trên Bitcoin là gì?
Khi nghiên cứu sâu về mạng lưới Lightning và cố gắng xây dựng các dịch vụ không lưu ký trên đó, chúng tôi cảm nhận thấy sự bất ổn ở nhiều khía cạnh. Về lý thuyết, kênh hai bên có khả năng xử lý giao dịch mạnh mẽ nhất, nhưng thực tế thì việc duy trì và sử dụng lại phát sinh nhiều vấn đề hơn dự kiến. Mạng Lightning hiện tại chưa đạt được kỳ vọng ban đầu trong lĩnh vực thanh toán vi mô, nguyên nhân chính là do tính thanh khoản. Dù hiện nay đã có rất nhiều cơ sở hạ tầng được đưa vào nhằm cải thiện tính thanh khoản, hiệu quả thực tế vẫn chưa đạt yêu cầu.
Trong quá trình viết bài này, Mutiny Wallet – ví tự lưu trữ nổi tiếng trên mạng Lightning – đã tuyên bố ngừng hoạt động, tiếp theo đó là nhà cung cấp dịch vụ thanh khoản (LSP) hợp tác với họ cũng đóng cửa. Mô hình hợp tác giữa ví tự lưu trữ và LSP luôn được xem là hướng đi quan trọng cho tương lai của mạng Lightning, điều này khiến người ta một lần nữa lo lắng về triển vọng phát triển của nó. Vì vậy, tại thời điểm này, bài viết sẽ thảo luận về quá trình tiến hóa và xu hướng phát triển tương lai của mạng kênh từ góc nhìn mở rộng tính thanh khoản.
1. Vấn đề hiện tại của mạng Lightning là gì?
Dung lượng khối Bitcoin bị giới hạn và thời gian tạo khối trung bình khoảng 10 phút, điều này rõ ràng cách xa mục tiêu trở thành hệ thống tiền mặt ngang hàng toàn cầu. Do đó, chúng ta cần một giải pháp mở rộng: chiếm ít dung lượng khối, có thể thanh toán nhanh chóng và phải là giải pháp gốc trên Bitcoin. Chính vì thế, mạng Lightning ra đời.
Mạng Lightning định nghĩa rằng sau khi tài sản được khóa trên chuỗi, chỉ cần trao đổi một giao dịch cam kết ngoài chuỗi là xem như hoàn tất giao dịch — đây cũng là lý do vì sao nó được gọi là thanh toán tức thì. So với thời gian xác nhận giao dịch trên mạng Bitcoin mất khoảng 10 phút, trải nghiệm này đối với các trường hợp thanh toán nhỏ rõ ràng đã giải quyết được vấn đề lớn nhất.
Tuy nhiên, trong quá trình phát triển và sử dụng thực tế của mạng Lightning, nhiều vấn đề dần xuất hiện. Bài viết này tóm tắt bốn vấn đề cốt lõi sau:
1.1 Khó khăn trong việc vận hành nút
Mạng Lightning hiện tại dựa trên mô hình trò chơi phạt giao dịch P2P. Để theo dõi liên tục xem đối phương có đưa trạng thái cũ bất lợi lên chuỗi hay không, mô hình này yêu cầu WatchTower phải luôn trực tuyến, nghĩa là người dùng phải tự vận hành nút. Ngoài ra, người dùng còn phải lưu trữ cục bộ khóa riêng dùng để trừng phạt và dữ liệu giao dịch cam kết, dẫn đến ngưỡng kỹ thuật và chi phí giáo dục cao khi vận hành nút.
1.2 Tính tương tác cao
Trong mạng Lightning, tính tương tác (interactivity) thường ám chỉ loạt thao tác mà người dùng cần thực hiện trong quá trình giao dịch, bao gồm ký tên, trao đổi giao dịch cam kết, khóa riêng trừng phạt... Ví dụ, mỗi lần cập nhật trạng thái ngoài chuỗi, cả hai bên phải đồng thời trực tuyến và ký giao dịch cam kết mới để trao đổi, điều kiện này đặt ra yêu cầu rất nghiêm ngặt về tính tương tác. Hơn nữa, độ phức tạp do HTLC và thanh toán đa chặng gây ra cũng khó khắc phục.
1.3 Hiệu suất vốn thấp
Cơ chế LN-Penalty của kênh hai bên về cơ bản giống như người dùng tự mở một tài khoản ngân hàng và phải tự mang theo dự trữ. Một vấn đề điển hình là người dùng muốn nhận tiền cũng phải đảm bảo tính thanh khoản của kênh, hiệu suất vốn cực kỳ thấp. Hơn nữa, phần lớn thanh khoản ở các kênh biên thường không được tận dụng triệt để.
1.4 Chi phí quản lý kênh cao
Trong kênh P2P, hiện tượng mất cân bằng thanh khoản xảy ra rất dễ dàng, người dùng buộc phải phụ thuộc vào các công cụ bổ sung thanh khoản như hoán đổi ngầm (submarine swap), nối kênh (channel splicing)... Nhưng những kỹ thuật này đều cần giao dịch trên chuỗi bổ sung để điều chỉnh giao dịch FundingTx ban đầu. Nói chung, mọi biện pháp điều chỉnh đều tốn kém, đặc biệt khi phí giao dịch tăng cao, mức giá này khiến người dùng không thể làm ngơ.
Hãy tưởng tượng, đối với những người cho rằng mình đang dùng công nghệ Layer2 để thực hiện giao dịch rẻ, đột nhiên phải đối mặt với vài khoản phí giao dịch trên mạng chính — thật là cảnh tượng lúng túng. Sự lúng túng này càng rõ rệt khi phí giao dịch trên mạng chính tăng cao, đúng là "kẻ ám sát phí giao dịch".
Những vấn đề này đã thể hiện hậu quả rõ rệt trong quá trình áp dụng thực tế của mạng Lightning: tăng trưởng người dùng yếu kém, phần lớn người dùng mới chọn giải pháp lưu ký, số liệu thống kê trong biểu đồ dưới đây nói lên điều đó.
Thống kê số lượng người dùng mới sử dụng ví lưu ký và ví không lưu ký trên mạng Lightning
Chúng ta dễ hiểu lý do gây ra tình trạng này, bởi đối với phần lớn người dùng thông thường, yêu cầu tự vận hành nút và kênh là quá khó khăn.
2. Chúng ta cần một mạng mở rộng ngoài chuỗi nào cho Bitcoin?
Trích từ whitepaper mạng Lightning
Theo mô tả trong whitepaper mạng Lightning, nếu mỗi người trên thế giới hàng năm mở/đóng kênh hai lần, dung lượng khối Bitcoin cần tăng lên 133MB. So sánh với mạng Bitcoin hiện tại, kích thước khối chỉ 1MB, thậm chí dùng địa chỉ P2TR với SegWit cũng chỉ đạt 4MB, chênh lệch rất lớn. Hơn nữa, xét đến thực tế các kỹ thuật điều chỉnh thanh khoản kênh (hoán đổi ngầm, nối kênh) đều cần giao dịch bổ sung trên chuỗi, vấn đề thiếu hụt dung lượng khối Bitcoin đối với mạng Lightning trong các kịch bản thực tế còn nghiêm trọng hơn nhiều.
Rõ ràng, mạng Lightning hiện tại khó đáp ứng nhu cầu người dùng C-end quy mô lớn trong ngắn hạn. Ngoài ra, do giới hạn dung lượng khối Bitcoin, tiềm năng mở rộng của mạng Lightning trong dài hạn cũng bị ảnh hưởng đáng kể.
Vấn đề đặt ra: Chúng ta thực sự cần một mạng mở rộng ngoài chuỗi Bitcoin như thế nào?
2.1 Hiện trạng mạng Lightning
Để hiểu rõ hạn chế hiện tại của mạng Lightning, chúng ta cần quay lại nguyên lý thiết kế của nó.
Mô hình mạng Lightning hiện tại còn gọi là LN-Penalty, nói đơn giản là mô hình kênh hai bên dựa trên giao dịch trừng phạt. Bảo mật của nó phụ thuộc vào việc người dùng lưu trữ cục bộ giao dịch kiểm soát đối phương và khóa riêng trừng phạt, đồng thời phải giám sát liên tục chuỗi Bitcoin để đảm bảo mọi hành động của đối tác đều nằm trong tầm kiểm soát của mình.
Trong thiết kế mô hình như vậy, người dùng tự vận hành nút là điều không thể tránh khỏi, bởi vì lưu trữ cục bộ và chức năng WatchTower là thiết yếu. Phần này đã được nhấn mạnh nhiều lần trước đó.
Xét về hiệu suất vốn và truyền thông, mô hình phổ biến hiện nay là một siêu nút LSP cung cấp thanh khoản ở giữa, rồi người dùng thiết lập kênh với siêu nút do LSP vận hành. Điều này bản thân đã đi ngược lại mô hình mạng lưới P2P lý tưởng ban đầu. Trong quá trình phát triển tự nhiên, cuối cùng vẫn quay về mô hình trục - nan hoa (hub-and-spoke) cổ điển.
Ví dụ như hình dưới đây, bên trái là mạng Lightning lý tưởng, bên phải là hiện trạng thực tế.
2.2 Đặc điểm của một mạng mở rộng ngoài chuỗi lý tưởng dành cho người dùng cá nhân
Bây giờ hãy hình dung những đặc điểm mà mạng mở rộng ngoài chuỗi Bitcoin dành cho người dùng cá nhân thực sự cần:
-
Sử dụng mô hình phi P2P, người dùng không cần tự vận hành nút, đồng thời đảm bảo an toàn và thuận tiện tốt
-
Trong tương tác, người dùng thanh toán không cần cả hai bên trực tuyến, một bên ngoại tuyến hoặc thao tác bất đồng bộ đều có thể thực hiện
-
Nâng cao hiệu suất vốn, đồng thời đáp ứng nhu cầu không lưu ký
-
Cơ chế quản lý thanh khoản rẻ và hiệu quả, thậm chí người dùng không cần tự duy trì thanh khoản
Dựa trên những mục tiêu này, bài viết sẽ dẫn dắt độc giả khám phá hướng phát triển tương lai của mạng mở rộng ngoài chuỗi Bitcoin.
3. Hành trình tiến hóa mở rộng gốc BTC
Trước tiên, chúng ta cần làm rõ rằng, cơ chế cốt lõi trong thiết kế mạng Lightning hiện tại — “LN-Penalty” — dựa trên nền tảng cập nhật trạng thái:
-
Lưu trữ và giám sát liên tục giao dịch cam kết
-
Cơ chế đa chặng phối hợp nhiều người (HTLC/PTLC)
Những yếu tố này tạo nên nền tảng thiết kế mạng Lightning hiện tại, đồng thời trực tiếp dẫn đến độ phức tạp trong thiết kế nút:
-
Giao tiếp mã hóa phức tạp
-
Lưu trữ cục bộ giao dịch cam kết và khóa riêng trừng phạt
-
WatchTower phải chạy liên tục trong suốt thời gian kênh tồn tại
Những vấn đề này thúc đẩy chúng ta suy nghĩ liệu có thể dùng cơ chế cập nhật trạng thái nhẹ hơn để thay thế “LN-Penalty”. Trong bối cảnh này, BIP118 (SIGHASH_ANYPREVOUT) được đề xuất như một phương án thay thế khả thi.
3.1 LN-Symmetry: Đưa cơ chế phiên bản vào cập nhật trạng thái
BIP118 đề xuất đưa vào chế độ ký SIGHASH_ANYPREVOUT, cho phép đầu vào giao dịch không cần chỉ định hoàn toàn đầu ra trước đó, và có thể cập nhật giao dịch tiền nhiệm mà không thay đổi chữ ký. Thiết kế như vậy so với “LN-Penalty” có thể giảm đáng kể độ phức tạp giao tiếp mã hóa và nhu cầu lưu trữ giữa các nút. SIGHASH_ANYPREVOUT bắt nguồn từ bài báo eltoo: A Simple Layer2 Protocol for Bitcoin. Trong các cuộc thảo luận phát triển mạng Lightning gần đây, mô hình mạng Lightning cải tiến dựa trên đó còn được gọi là “LN-Symmetry”.
Mặc dù LN-Symmetry giảm áp lực lưu trữ giao dịch cam kết cục bộ, nhưng nó chưa loại bỏ hoàn toàn nhu cầu giám sát. Mặc dù Eltoo không cần trao đổi giao dịch cam kết và chữ ký khóa riêng, nếu một bên cố gắng đăng trạng thái cũ lên chuỗi, bên kia vẫn phải giám sát thời gian thực và kịp thời đăng giao dịch trạng thái mới nhất để thay thế trạng thái cũ. Nhiệm vụ giám sát này vẫn cần WatchTower truyền thống, lúc này mục đích vận hành WatchTower không còn là trừng phạt mà là thay thế trạng thái. Người dùng vẫn phải duy trì nút của mình.
Đồng thời, LN-Symmetry vẫn cần cơ chế HTLC/PTLC để đảm bảo phối hợp nhiều người, điều này vẫn gây gánh nặng giao tiếp nghiêm trọng như thiết kế nút mạng Lightning trước đây.
Vì vậy, xét về tổng thể, cải tiến trải nghiệm từ LN-Symmetry đối với mạng Lightning hiện tại là có hạn, vẫn còn rất dài đường để đạt được mục tiêu chúng ta theo đuổi.
Để cải tiến thêm, bài viết giới thiệu hướng tiếp theo: Shared UTXO.
3.2 CoinPool: Giảm tính tương tác và nhu cầu thanh khoản trong kênh đa bên
Bài báo đầu tiên đưa ra khái niệm Shared UTXO là CoinPool: efficient off-chain payment pools for Bitcoin, mục tiêu chính là tiếp tục giải quyết vấn đề tương tác đa bên dưới cơ chế cập nhật phiên bản SIGHASH_ANYPREVOUT.
Trong thiết kế LN-Symmetry, nhờ cơ chế cập nhật trạng thái mới do Eltoo mang lại, việc quản lý trạng thái kênh điểm-điểm thực sự được đơn giản hóa. Tuy nhiên, khi liên quan đến phối hợp nhiều bên, độ phức tạp tương tác vẫn tồn tại, đặc biệt trong thanh toán đa chặng (HTLC/PTLC), cần sự phối hợp chặt chẽ và nhiều lần giao tiếp mã hóa.
Điểm đổi mới của CoinPool là sử dụng mô hình Shared UTXO, cho phép nhiều bên cộng tác trên cùng một UTXO có kiểm soát phiên bản. Thông qua cách này, nhiều người tham gia có thể cùng cam kết và quản lý trạng thái UTXO mà không cần cơ chế HTLC/PTLC phức tạp. Ưu điểm chính thể hiện ở:
-
Giảm đáng kể độ phức tạp tương tác trong kênh đa bên: Vì tất cả người tham gia đều chia sẻ cùng một UTXO, họ có thể đạt được sự đồng thuận bằng cách ký để cập nhật phiên bản UTXO, mà không cần nhiều giao dịch trên chuỗi hay tương tác phức tạp ngoài chuỗi. Cách đơn giản hóa này khiến việc quản lý kênh đa bên hiệu quả hơn.
-
Cơ chế cập nhật ngoài chuỗi trở nên trực tiếp hơn: Trong thiết kế này, cơ chế cập nhật trạng thái ngoài chuỗi chuyển thành việc nhiều bên cùng ký xác nhận một phiên bản UTXO. Phương pháp này không chỉ đơn giản hóa quy trình cập nhật trạng thái, mà còn giảm sự phụ thuộc lẫn nhau và các điểm xung đột tiềm tàng giữa các bên.
-
Loại bỏ nhu cầu thanh khoản độc lập: Thông qua mô hình Shared UTXO, nhiều người tham gia thực chất chia sẻ cùng một hồ thanh khoản, không cần mỗi người duy trì đủ thanh khoản riêng. Trong thiết kế CoinPool phối hợp nhiều bên, nhu cầu thanh khoản có thể giảm mạnh hoặc phân bổ lại. Người tham gia có thể dùng thanh khoản trong Shared UTXO để thanh toán, mà không cần khóa một lượng lớn tiền cho kênh riêng. Điều này không chỉ nâng cao hiệu suất sử dụng vốn, mà còn giảm áp lực vốn cho từng cá nhân tham gia.
Thiết kế CoinPool thông qua cách chia sẻ UTXO đã thành công giảm độ phức tạp tương tác trong kênh đa bên xuống mức hợp lý, đồng thời duy trì tính an toàn và hiệu quả của hệ thống. Quan trọng hơn, nó giảm sự phụ thuộc vào nhu cầu thanh khoản độc lập của mỗi người tham gia, cung cấp giải pháp nhẹ và linh hoạt hơn cho phối hợp nhiều bên, vượt qua giới hạn của mô hình LN truyền thống trong tương tác đa bên và quản lý thanh khoản.
Tuy nhiên, tại sao một giải pháp có nhiều ưu điểm như vậy đến nay vẫn chưa được áp dụng rộng rãi? Gốc rễ vấn đề nằm ở đâu?
3.3 Vì sao CoinPool chưa được triển khai thực tế?
Mặc dù CoinPool có nhiều ưu điểm và được xem là mô hình mở rộng lý tưởng, nhưng nó đòi hỏi quá nhiều nâng cấp soft fork, đến mức có thể cả đời chúng ta cũng chưa thấy nó triển khai trên mạng Bitcoin. Yêu cầu nâng cấp soft fork của CoinPool tập trung chủ yếu vào hai khía cạnh:
3.3.1 Nâng cấp cơ chế cập nhật trạng thái
Vì CoinPool dựa trên thiết kế Eltoo, thừa hưởng nhu cầu soft fork về cơ chế cập nhật trạng thái, tức là cần nâng cấp Bitcoin để kích hoạt chế độ ký mới SIGHASH_ANYPREVOUT (APO), nhưng ai cũng biết tiến độ nâng cấp soft fork Bitcoin chậm chạp, khiến công nghệ cơ chế cập nhật trạng thái mà CoinPool phụ thuộc khó áp dụng vào thực tế.
3.3.2 Shared UTXO cần cơ chế thao tác đơn giản hóa thỏa thuận
Như đã nói, mỗi lần cập nhật trạng thái Shared UTXO đều cần thu thập chữ ký từ tất cả người chia sẻ phiên bản UTXO đó. Trong quá trình này, nếu một bên mất kết nối, toàn bộ hệ thống sẽ đình trệ, dùng thuật ngữ blockchain là tính sẵn sàng (liveness) của hệ thống rất kém. Để khắc phục thách thức này, hệ thống cần một cơ chế có thể cập nhật Shared UTXO với chi phí thấp mà không hoàn toàn phụ thuộc vào sự hợp tác.
Bài báo CoinPool đề xuất OP_MERKLESUB, nhằm xác minh và cập nhật trạng thái người tham gia cụ thể thông qua cấu trúc cây Merkle. Mặc dù ý tưởng thiết kế này có tính khả thi về mặt lý thuyết, nhưng nó gặp phải vấn đề tương tự các thỏa thuận thao tác cây Merkle khác, tức là logic triển khai phức tạp và khó tạo thành thỏa thuận chung, có thể tái sử dụng. Ví dụ như các thỏa thuận kiểu **OP_TAPLEAFUPDATEVERIFY(TLUV)**. Hơn nữa, các chức năng thỏa thuận như OP_EVICT, trực tiếp loại bỏ bên không hợp tác khỏi Shared UTXO, lại quá đơn điệu, khó hình dung nó có thể thuận lợi thông qua nâng cấp mạng Bitcoin.
Trong các đề xuất thỏa thuận này, OP_CheckTemplateVerify (CTV) dần trở thành tâm điểm chú ý. Khác với việc xây dựng và xác minh cây Merkle, CTV giới hạn chi tiêu thông qua mẫu giao dịch được định nghĩa trước. CTV không chỉ triển khai đơn giản, mà còn có thể dùng chuỗi cam kết giao dịch để cam kết một loạt UTXO ngoài chuỗi qua một UTXO trên chuỗi. Những UTXO ngoài chuỗi được cam kết trên chuỗi này chính là nguồn gốc ban đầu của khái niệm Virtual UTXO.
Trong các thỏa thuận này, CTV được ủng hộ mạnh mẽ nhất vì vừa đơn giản vừa phổ quát. Khả năng mạnh mẽ của CTV không chỉ có thể hiện ý tưởng như CoinPool, mà còn có thể dùng cho Rollup. Có thể hình dung mỗi lần dùng OP_CAT xác minh ZKP-MerkleState, và trực tiếp cam kết trạng thái Layer2 tương ứng trong script vào Shared UTXO, chúng ta có thể xây dựng giải pháp Bitcoin ZK-Rollup thực sự.
Tóm lại, vấn đề chính trong việc triển khai CoinPool là cần cơ chế cập nhật trạng thái nhẹ APO và opcode thao tác Shared UTXO để hỗ trợ thực hiện, cả hai đều cần nâng cấp soft fork Bitcoin. Vì vậy, dù bài báo CoinPool ra đời nhiều năm, vẫn chỉ là một phương án trên giấy.
3.4 Bitcoin Clique: Nguyên thủy chống double-spend ngoài chuỗi 2-AS
Trong thảo luận mô hình CoinPool trước đó, chúng ta biết rằng cơ chế APO mà nó phụ thuộc cần nâng cấp soft fork mới có thể triển khai, điều này khó thực hiện trong ngắn hạn. Vậy nếu có một nguyên thủy mới chống double-spend ngoài chuỗi không phụ thuộc nâng cấp soft fork Bitcoin, vấn đề thực hiện sẽ được giải quyết phần lớn.
SỨC MẠNH CỐT LÕI CỦA SIGHASH_ANYPREVOUT là cung cấp cơ chế cập nhật trạng thái ngoài chuỗi tránh double-spend. Dựa trên ý tưởng này, nếu tìm được nguyên thủy mật mã tương đương, có thể giải quyết vấn đề cập nhật trạng thái ngoài chuỗi, đồng thời tránh được nhu cầu cập nhật opcode Bitcoin. Sự xuất hiện của bài báo Bitcoin Clique mang lại hy vọng mới. Nó giới thiệu một nguyên thủy mật mã hoàn toàn mới, 2-shot-adaptor-signature (2-AS), cung cấp giải pháp mới chống double-spend ngoài chuỗi.
2-AS là nguyên thủy mật mã dựa trên chữ ký adaptor Schnorr, để hiểu 2-AS, trước tiên chúng ta cần hiểu chữ ký Schnorr và chữ ký adaptor.
3.4.1 Chữ ký Schnorr
Chữ ký Schnorr có thuộc tính tuyến tính, nghĩa là nhiều chữ ký có thể gộp thành một chữ ký. Nói đơn giản, nếu có nhiều chữ ký $S_1$ và $S_2$, chúng có thể được cộng lại thành chữ ký $S=S_1+S_2$, và khóa công tương ứng khi xác minh cũng có thể gộp thành $P = P_1 + P_2$.
3.4.2 Chữ ký Adaptor
Chữ ký Adaptor có một số bước cơ bản như Gen, PSign, PVrfy, Adapt, Extract. Khi hiểu 2-AS, đặc biệt quan trọng là hiểu hai bước Psign và Extract.
Bài viết này tập trung vào việc hiểu chữ ký adaptor từ góc độ ứng dụng chứ không phải mật mã học. Nói đơn giản, khi hai bên muốn hợp tác xác nhận một chữ ký, thường dùng adaptor của đối phương như một phần của chữ ký, adaptor thường là phần khóa công trong cặp khóa công-khóa riêng, và bên nắm giữ khóa riêng tương ứng với adaptor — tức là bên nắm bí mật — có khả năng Adapt hoàn thiện phần chữ ký còn thiếu từ Psign. Nếu chỉ như vậy thì chẳng giống MuSig sao? Nhưng điểm độc đáo của chữ ký adaptor là có thể Extract, nghĩa là sau khi chữ ký đầy đủ được tiết lộ, bên phát hành Psign ban đầu có thể trích xuất khóa bí mật (khóa riêng) tương ứng thông qua chữ ký đầy đủ, phần chữ ký trước đó và adaptor (khóa công).
3.4.3 Kết hợp cả hai: 2-AS
Chúng ta đã hiểu đặc tính chữ ký Schnorr và chữ ký adaptor, bây giờ hãy xem sự kết hợp kỳ diệu của cả hai: 2-AS.
Giả sử chúng ta có một VTXO và muốn đảm bảo ngoài chuỗi rằng nó có thể bị tịch thu khi double-spend, chúng ta có thể thiết kế như sau:
-
Đầu tiên cần một đầu ra phạt, trong đó khóa công có thể mở là một khóa công phạt. Đảm bảo rằng khi người dùng double-spend, bên phục vụ có thể tịch thu.
-
Hợp tác giữa các đối tác giao dịch thông qua chữ ký adaptor để xác nhận giao dịch ngoài chuỗi, nếu người dùng dùng cùng một đầu vào hai lần, đầu ra đó có thể bị bên phục vụ tịch thu.
-
Yêu cầu người dùng mỗi lần cập nhật trạng thái phải tạo một khóa công làm đầu ra phạt, khóa công phạt của đầu ra phạt này được cấu thành bằng cách cộng hai cặp khóa công đã xác định trước bằng kỹ thuật chữ ký Schnorr.
Vì vậy, trước mỗi giao dịch chúng ta xác nhận cặp khóa công-khóa riêng sẽ dùng sau đó, tạo trước đầu ra phạt. Khi double-spend xảy ra, bên phục vụ có thể dùng hai chữ ký adaptor để cuối cùng lấy được khóa riêng tương ứng đầu ra phạt.
3.4.4 Ưu và nhược điểm của Bitcoin Clique
Phương án Bitcoin Clique cũng không hoàn hảo. Nhược điểm là trong cập nhật trạng thái ngoài chuỗi, cần liên tục trao đổi khóa 2-AS dùng để xây dựng khóa công phạt mới. Và do phương án này dựa trên thiết kế CoinPool, đồng thời để trao đổi khóa 2-AS và xác minh chữ ký cho UTXO phiên bản mới, phương án này cũng yêu cầu tất cả người tham gia trực tuyến khi cập nhật trạng thái. Nghĩa là độ phức tạp giao tiếp và tính tương tác vẫn rất cao.
Quan trọng nhất là mô hình này giống thiết kế StateChain, mỗi lần chúng ta chuyển nhượng quyền sở hữu một UTXO ngoài chuỗi, vì vậy các hệ thống dùng chữ ký ngăn double-spend kiểu 2-AS không thể thực hiện trả lại tiền trong thanh toán ngoài chuỗi, làm giới hạn rất lớn phạm vi ứng dụng.
Hơn nữa, ngay cả khi có cơ chế SharedUTXO dễ thao tác và nguyên thủy chống double-spend ngoài chuỗi không cần soft fork, chúng ta vẫn cần tất cả người tham gia trực tuyến để cập nhật xác nhận trạng thái mới của UTXO, ngay cả khi mỗi lần cập nhật trạng thái chỉ ảnh hưởng một phần người trong mạng ngoài chuỗi. Việc bắt những người không liên quan phải trực tuyến tham gia cập nhật trên chuỗi là không hợp lý. Đồng thời, hoàn toàn loại bỏ nhu cầu thanh khoản cũng không phải điều chúng ta mong muốn, thiếu thanh khoản bôi trơn thì phương án thanh toán không thể thực hiện trả lại tiền, và do vấn đề rút tiền, mệnh giá của mọi người thường phải giống nhau.
Vì vậy, hiện tại không tồn tại một phương án mở rộng ngoài chuỗi không dùng kênh, hỗ trợ mệnh giá động và dựa trên UTXO. Trước đây Ethereum cũng từng đau đầu với con đường này, chúng ta gọi là bẫy Plasma, các nghiên cứu liên quan có thể tham khảo bài báo Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma.
Tóm lại vấn đề và bài học:
-
Cần thanh khoản bôi trơn để đảm bảo thanh toán mệnh giá động (giao dịch có trả lại): cần giữ thiết kế kênh, đồng thời cũng có thể tránh vấn đề rút tiền.
-
Giảm sự phụ thuộc vào việc tất cả người tham gia trực tuyến đồng bộ: chúng ta không muốn mỗi người dùng đều phải trực tuyến khi mạng ngoài chuỗi cập nhật bất kỳ trạng thái nào, việc cập nhật Shared UTXO nên chỉ cần những người liên quan trực tuyến hợp tác cập nhật.
Dựa trên nhận thức này, bài viết tiếp tục theo hướng này, khám phá các phương án tối ưu hơn.
3.5 Nhà máy kênh và kênh ảo
Trong thảo luận trước đó, chúng ta nhận ra rằng không chỉ cần giữ thiết kế kênh, mà cũng cần Shared UTXO mang lại lợi ích chi phí thấp ngoài chuỗi. Vậy một khái niệm đã được thảo luận lâu trong lĩnh vực mạng Lightning bước vào tầm ngắm của chúng ta, đó là nhà máy kênh (Channel Factory).
Trước đó, chúng ta đề cập đến UTXO ngoài chuỗi được cam kết bởi UTXO trên chuỗi được gọi là Virtual UTXO. Nếu dùng Virtual UTXO ngoài chuỗi làm FundingTx cho kênh, chúng ta có được một khái niệm mới, tức là kênh ảo (Virtual Channel). Sau đó, các kênh ảo trong Shared UTXO này được nối bằng Virtual HTLC. Mọi thứ đều ngoài chuỗi, tất cả đều "ảo hóa". Điều này dường như cung cấp một giải pháp lý tưởng: thực hiện phần lớn chức năng ngoài chuỗi, bao gồm điều chỉnh thanh khoản, việc mở rộng mạng Lightning dường như được giải quyết dễ dàng.
Nhưng thực tế có thật sự tốt đẹp như vậy không?
Do kế thừa đặc tính Shared UTXO, nhà máy kênh cần sự hợp tác của nhiều người dùng để mở và đóng. Nếu bất kỳ người dùng nào không thể phối hợp kịp thời (ví dụ ngoại tuyến hoặc không phản hồi), có thể ảnh hưởng đến chức năng toàn bộ nhà máy kênh. Vì nhà máy kênh liên quan đến nhiều bên cùng ký cập nhật trạng thái, bất kỳ sự không đồng bộ hoặc hành vi ác ý nào của một bên cũng có thể khiến người dùng khác không thể đóng kênh và rút tiền một cách thuận lợi.
Hơn nữa, vấn đề của thiết kế này cũng rất rõ ràng, mặc dù giảm chi phí mở/đóng kênh, nhưng mô hình bảo mật giữa các kênh vẫn phụ thuộc vào giao dịch cam kết và HTLC. Vì vậy, vấn đề giao tiếp và tương tác vẫn tồn tại, thậm chí độ phức tạp triển khai của phương án này còn cao hơn LN-Penalty hiện tại.
3.6 ARK JoinPool và kênh tạm thời
Thông qua việc xem lại ví dụ nhà máy kênh, chúng ta rút ra kết luận: trong thiết kế kênh dựa trên Shared UTXO, có lẽ không nên tiếp tục dùng thiết kế kênh “LN-Penalty” cổ điển, nhưng đồng thời nên giữ những ưu điểm khi đưa kênh vào:
-
Thanh khoản mang lại mệnh giá động;
-
Dễ rút tiền.
Dựa trên đó, một thiết kế kênh tạm thời sử dụng JoinPool ra đời, tức là ARK Protocol.
3.6.1 JoinPool: Chỉ một phần người tham gia cập nhật
Như đã nói trước đó, CoinPool mang lại tiềm năng cho việc mở rộng cộng tác ngoài chuỗi nhiều người, ví dụ như không cần thanh khoản, đa chặng, HTLC — những thiết kế phức tạp và dễ lỗi. Nhưng vấn đề then chốt nhất của mô hình CoinPool là yêu cầu người dùng trực tuyến: tất cả người dùng trong Shared UTXO đều phải trực tuyến khi cập nhật trạng thái ngoài chuỗi, ngay cả khi trạng thái của một số người không thay đổi, vẫn cần trực tuyến xác minh và đưa ra chữ ký tương ứng. Yêu cầu này khiến chúng ta luôn không thể tránh khỏi vấn đề người dùng phải vận hành nút riêng.
Để giải quyết khó khăn này, một mô hình mới được đề xuất, tức là JoinPool. Triết lý của JoinPool trong Shared UTXO là: mỗi khi người dùng cần cập nhật trạng thái ngoài chuỗi của mình, mọi người cùng tham gia vào một Shared UTXO đại diện cho trạng thái mới của UTXO tương ứng. Điều này giải quyết vấn đề người dùng không liên quan phải trực tuyến khi người khác thực hiện. Nói cách khác, trong thiết kế dựa trên JoinPool, người dùng chỉ cần trực tuyến khi cần giao dịch.
Nhưng chúng ta đều hiểu, lý do cần vận hành liên tục nút mạng Lightning ngoài việc đảm bảo khóa riêng người dùng trực tuyến để ký tên, còn một lý do quan trọng khác là mỗi thành viên kênh đều cần WatchTower giám sát liên tục xem đối tác có đưa giao dịch cam kết bất lợi lên chuỗi hay không. Điều này dẫn đến vấn đề thứ hai cần giải quyết.
3.6.2 Chuyển trách nhiệm WatchTower: Người dùng không cần tự vận hành nút
Trong thiết kế cổ điển LN-Penalty, mỗi người dùng cần xây dựng WatchTower riêng để giám sát đối phương có đưa trạng thái cũ lên chuỗi hay không, nếu có thì sẽ trừng phạt. Trong mô hình cũ này, đối tác giao dịch của chúng ta đều là các nút Lightning đối xứng, mỗi lần tham gia giao dịch có thể là mở kênh với nút khác nhau. Nhưng trong ARK, tất cả người dùng thực chất đều tương tác với ASP (Nhà cung cấp dịch vụ ARK), không trực tiếp tương tác với người dùng khác.
Đối với ASP, khi VTXO ngoài chuỗi của người dùng được giao dịch, người dùng sẽ ký một giao dịch từ bỏ quyền. Bởi vì trong trường hợp lý tưởng, VTXO ngoài chuỗi của người dùng sẽ không được đưa lên chuỗi, mà liên tục được trích dẫn để thực hiện giao dịch vòng tiếp theo. Nếu một VTXO được giao dịch ngoài chuỗi đồng thời được đưa lên chuỗi, điều này biểu thị người dùng đã thực hiện giao dịch double-spend, ASP sẽ dùng giao dịch từ bỏ quyền mà người dùng ký trước đó để tịch thu tiền mà người dùng đưa lên chuỗi. ASP sẽ giám sát tất cả VTXO từng xuất hiện trong lịch sử, ngăn chặn việc ai đó cố tình rút tiền ác ý từ VTXO đã chi tiêu ngoài chuỗi lên chuỗi.
Điều này chuyển trách nhiệm vận hành WatchTower từ người dùng thông thường sang operator, so với mạng Lightning, mô hình này có một cải tiến lớn: cuối cùng chúng ta không còn cần người dùng thông thường vận hành nút riêng để đảm bảo an toàn cho bản thân.
Tổng kết các phương án khác trong việc tối ưu vận hành nút người dùng:
-
Hosting đám mây nút mạng Lightning
Một số phương án chọn vận hành nút mạng Lightning trên nền tảng đám mây để giúp người dùng giảm ngưỡng sử dụng. Tuy nhiên, phương án này về bản chất vi phạm giả định bảo mật của mạng Lightning. Trong công nghệ mạng Lightning, việc lưu trữ khóa riêng và giao dịch cam kết trong nhiều trường hợp cũng quan trọng như nhau. Vì vậy, đơn giản dùng khóa riêng từ xa không thể đảm bảo an toàn.
Bản chất, phương án này biến tình huống đối đầu hai bên thành tình huống đối đầu ba bên gồm tôi, đối tác giao dịch và bên hosting đám mây. Sau khi tôi giao dịch với đối tác nhưng trạng thái chưa lên chuỗi, bên hosting đám mây có thể đơn phương xóa giao dịch cam kết trong nút đám mây của tôi, lúc đó đối tác giao dịch của tôi có thể đưa trạng thái có lợi cho họ lên chuỗi. Trong các phương án hosting nút đám mây Lightning này, tồn tại rủi ro bên hosting và đối tác giao dịch thông đồng làm hại.
-
CRAB và Sleepy CRAB
Giao thức CRAB (Channel Resistant Against Bribery) do Aumayr và cộng sự đề xuất, thông qua việc thêm tài sản ký quỹ kết hợp cơ chế khuyến khích thợ đào để đảm bảo an toàn kênh thanh toán, đặc biệt trong trường hợp người dùng ngoại tuyến. Cơ chế này giảm sự phụ thuộc vào bên thứ ba WatchTower. Tuy nhiên, cơ chế tài sản ký quỹ này chắc chắn làm trầm trọng thêm vấn đề "thanh khoản nhận vào". Bởi vì người dùng khi tham gia mạng ngoài chuỗi cần khóa thêm tiền không liên quan đến mục đích giao dịch, mặc dù đảm bảo an toàn nhưng đánh đổi hiệu quả và tính thanh khoản vốn. Hơn nữa, các phương án này vẫn yêu cầu người dùng tự vận hành nút, chỉ giảm yêu cầu trực tuyến.
3.6.3 Kênh tạm thời: Người dùng không cần tự duy trì thanh khoản kênh
Có người có thể hỏi, tại sao nhà cung cấp dịch vụ ASP sẵn lòng bơm thanh khoản vào kênh JoinPool cho chúng ta? Bởi vì người dùng nếu muốn sử dụng VTXO dựa trên mạng ARK, phải trước tiên gửi UTXO của mình cùng với nhà vận hành vào một địa chỉ multisig, giống như một FundingTx, để đổi lấy VTXO. Về bản chất, mỗi giao dịch ngoài chuỗi của người dùng đều đang dùng tiền của operator, nhưng sẽ nhượng phần tiền multisig trước đó của mình với operator.
Và lý do gọi kênh ARK là kênh tạm thời là vì nó có hai đặc điểm: tính một chiều và nạp vốn một lần.
-
Tính một chiều: Trong kênh một chiều, tiền chỉ chuyển từ bên khởi tạo chỉ định sang bên đầu ra tương ứng.
-
Nạp vốn một lần: Kênh ARK chỉ cần nạp vốn một lần. Sau khi nạp vốn, không cần tiếp tục duy trì thanh khoản kênh.
Trong thiết kế kênh tạm thời như vậy, sau khi nạp vốn xong, kênh không cần tái cân bằng hay điều chỉnh nữa. So với mạng Lightning, không chỉ người dùng không cần lo lắng về thanh khoản kênh, mà nhà cung cấp thanh khoản cũng không cần duy trì thanh khoản kênh. Biến động duy nhất còn lại trong kênh chỉ là sự kiện người dùng rút tiền.
3.6.4 Tổng kết giao thức ARK
Tổng hợp tất cả những điều trên, chúng ta có thể thấy rõ ràng rằng, so với mạng Lightning, thiết kế ARK Protocol đã có bước tiến đáng kinh ngạc về trải nghiệm người dùng:
-
Người dùng không cần tự vận hành nút
-
Người dùng không cần tự duy trì thanh khoản kênh, không có vấn đề thanh khoản nhận vào
-
Hỗ trợ tương tác bất đồng bộ, không cần cả hai bên trực tuyến đồng thời
4. Thay đổi phạm trù mở rộng gốc Bitcoin
Thông qua nghiên cứu trên, chúng ta đã khám phá nhiều phương án mở rộng ngoài chuỗi dựa trên Shared UTXO. Mục đích ban đầu của thiết kế Shared UTXO là giải quyết vấn đề thanh khoản, tuy nhiên, khi giao thức không ngừng tiến hóa, chúng ta bất ngờ phát hiện nó mang lại nhiều lợi thế mà trước đây chúng ta từng mong muốn nhưng chưa dám mơ tới.
Điều này đánh dấu bước tiến vào hướng phát triển mới của việc mở rộng ngoài chuỗi Bitcoin, so với mô hình mạng Lightning ban đầu, đây là một sự chuyển đổi phạm trù:
-
Từ mô hình P2P đến việc đưa vào operator không cần tin tưởng
Logic của mạng mở rộng ngoài chuỗi đã dần chuyển từ mô hình đối đầu song phương "người dùng - người dùng" ban đầu của mạng Lightning sang mô hình đối đầu "người dùng và operator". Điểm khác biệt là người dùng không cần tin tưởng vào bên thứ ba operator này.
-
Người dùng không cần tự vận hành cơ sở hạ tầng nút để đảm bảo an toàn tài sản
Mô hình LN-Penalty truyền thống và các nghiên cứu mới nhất như CRAB, phụ thuộc vào việc người dùng tự cung cấp tài sản ký quỹ để đảm bảo an toàn tiền, đồng thời yêu cầu người dùng trực tuyến và vận hành nút trong suốt thời gian kênh tồn tại. Tuy nhiên, các phương án tương lai sẽ không cần những thao tác này nữa. Quan trọng hơn, các quy trình này vẫn giữ tính chất không lưu ký, người dùng luôn nắm quyền kiểm soát tài sản của mình.
-
Chuyển trách nhiệm quản lý thanh khoản từ người dùng sang operator
Trong mô hình LN-Penalty cổ điển và các thiết kế cải tiến, người dùng cần tự điều chỉnh thanh khoản trong kênh, đặc biệt khi thanh khoản mất cân bằng. Việc này thường cần chuyên môn nhất định, và thao tác phức tạp nếu không có sự giúp đỡ của LSP (nhà cung cấp dịch vụ thanh khoản). Tuy nhiên, khi trách nhiệm quản lý thanh khoản chuyển sang operator bên thứ ba, người dùng không còn phải lo lắng về việc này. Điều này cực kỳ đơn giản hóa trải nghiệm người dùng và loại bỏ rào cản gia nhập mạng.
-
Hiệu suất vốn và tiềm năng được nâng cao đáng kể
Các thiết kế giao thức mới đều đang hướng tới mô hình P2POOL, về hiệu suất vốn có sự khác biệt căn bản so với mạng Lightning hiện tại. Trong mô hình LN-Penalty, mỗi người dùng khi mở kênh Lightning phải tự cung cấp thanh khoản, nhưng thanh khoản các kênh này phần lớn thời gian nằm không (giao dịch không thường xuyên xảy ra, và phân bố không đều giữa các kênh), dẫn đến tiền của người dùng không được sử dụng hiệu quả. Trong xu hướng thiết kế giao thức mới, thanh khoản được tập trung vào hồ thanh khoản để quản lý thống nhất, điều này mở ra vô số khả năng cho các kịch bản DeFi trong tương lai.
Sự chuyển đổi phạm trù này cho thấy rằng quản lý thanh khoản là bản chất của việc tiến hóa mở rộng ngoài chuỗi gốc Bitcoin, cũng là chủ đề chính cốt lõi cho sự phát triển tiếp theo.
Trong tương lai, cùng với sự tiến bộ không ngừng của công nghệ và sự xuất hiện liên tục của các phương án mới, con đường mở rộng ngoài chuỗi Bitcoin chắc chắn sẽ đón nhận triển vọng phát triển tươi sáng hơn. Chúng tôi sẽ tiếp tục nghiên cứu sâu trong lĩnh vực này, kính mời độc giả đón chờ các thành quả tiếp theo của chúng tôi.
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
@blapta
