Lời nói đầu
Tôi đã suy nghĩ về một câu hỏi trong một thời gian dài: Logic cốt lõi của việc mở rộng vốn có của Bitcoin là gì ?
Khi chúng tôi nghiên cứu sâu hơn về Lightning Network và cố gắng triển khai việc kinh doanh không giám sát trên Lightning Network, chúng tôi đã cảm nhận được một số điểm bất đồng. Về mặt lý thuyết, các kênh hai bên có thông lượng giao dịch mạnh mẽ nhất, nhưng vấn đề sử dụng và bảo trì thực tế lại nhiều hơn dự kiến. Hiệu suất hiện tại của Lightning Network theo hướng thanh toán vi mô ban đầu là không đạt yêu cầu và lý do cốt lõi là thanh khoản. Mặc dù lượng lớn cơ sở hạ tầng được cho là sẽ cải thiện thanh khoản đã được đưa vào sử dụng nhưng hiệu quả thực tế vẫn chưa đạt được như mong đợi.
Ngay khi bài viết này được viết, ví tự lưu trữ Lightning có tiếng trong ngành Mutiny Wallet đã thông báo đóng cửa, sau đó là đối tác Nhà cung cấp dịch vụ thanh khoản (LSP) đóng cửa. Mô hình hợp tác giữa ví tự lưu trữ và LSP luôn được cho rằng là hướng đi quan trọng trong tương lai của Lightning Network, điều này khiến mọi người một lần nữa lo lắng về tương lai của nó. Do đó, tại thời điểm này, bài viết này sẽ khám phá sự phát triển của mạng lưới kênh và xu hướng phát triển trong tương lai của nó từ góc độ mở rộng thanh khoản .
1. Các vấn đề hiện tại của Lightning Network là gì?
Dung lượng khối của Bitcoin bị hạn chế và thời gian tạo khối mainnet dài, trung bình khoảng 10 phút, rõ ràng là quá xa so với yêu cầu trở thành hệ thống tiền mặt ngang hàng của thế giới. Theo quan điểm này, chúng tôi rất cần một giải pháp mở rộng quy mô: nó cần chiếm không gian khối nhỏ, có thể quyết toán nhanh chóng và phải là giải pháp gốc dựa trên Bitcoin . Kết quả là Lightning Network ra đời.
Lightning Network định nghĩa rằng sau khi tài sản bị khóa trên Chuỗi , việc trao đổi giao dịch đã cam kết trong Chuỗi được coi là đã hoàn thành, đó là lý do tại sao nó được gọi là thanh toán ngay lập tức. Về mặt trải nghiệm, điều này được so sánh với giới hạn 10 phút về thời gian xác nhận thanh toán trên mainnet Bitcoin đối với các tình huống thanh toán số lượng nhỏ, chắc chắn nó sẽ giải quyết được vấn đề số một.
Tuy nhiên, trong quá trình phát triển và sử dụng Lightning Network thực tế, nhiều vấn đề dầ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 ở đây:
1.1 Việc bảo trì nút rất khó khăn
Lightning Network hiện tại dựa trên mô hình trò chơi giao dịch phạt P2P để liên tục theo dõi xem bên kia Chuỗi trạng thái cũ không có lợi cho chính họ trong quá trình tồn tại của kênh hay không, mô hình này yêu cầu WatchTower phải trực tuyến. lần, yêu cầu người dùng phải tự duy trì nút . Ngoài ra, người dùng cũng cần lưu dữ liệu giao dịch cam kết và private key bị phạt cục bộ, dẫn đến ngưỡng bảo trì nút cao và chi phí đào tạo.
1.2 Tính tương tác cao
Trong Lightning Network, tính tương tác thường đề cập đến sê-ri các hoạt động tương tác mà người dùng cần thực hiện trong quá trình giao dịch. Các hoạt động này thường liên quan đến việc ký kết, trao đổi các giao dịch cam kết, xử phạt private key, v.v. Ví dụ: lần khi trạng thái ngoài Chuỗi được cập nhật, cả hai bên tham gia giao dịch phải trực tuyến cùng lúc và ký một giao dịch cam kết mới để trao đổi, giao dịch này có yêu cầu nghiêm ngặt về khả năng tương tác của người dùng. Và khi bên long tương tác, sự phức tạp do HTLC và multi-hop mang lại cũng khó khắc phục.
1.3 Hiệu quả sử dụng vốn thấp
Cơ chế LN-Panelty của kênh hai bên ở một mức độ nhất định tương đương với việc người dùng mở tài khoản ngân hàng của riêng mình và cần mang theo tiền dự trữ của riêng mình. Một vấn đề điển hình là người dùng cần đảm bảo thanh khoản của kênh để nhận tiền và hiệu quả sử dụng vốn rất thấp. Và rất nhiều thanh khoản của kênh sẽ không được tận dụng tối đa.
1.4 Chi phí quản lý kênh cao
Trong các kênh P2P, sự mất cân thanh khoản cực kỳ dễ xảy ra và người dùng phải dựa vào nhiều công cụ khác nhau để hỗ trợ bổ sung thanh khoản, chẳng hạn như hoán đổi tàu ngầm, ghép kênh, v.v. Tuy nhiên, những công nghệ này yêu cầu các giao dịch trực Chuỗi bổ sung cặp giao dịch điều chỉnh FundingTx ban đầu được triển khai. Nhìn chung, mọi điều chỉnh đều tốn kém, đặc biệt khi phí tăng, khiến người dùng khó có thể bỏ qua.
Hãy tưởng tượng sẽ xấu hổ thế nào đối với những người dùng cho rằng họ đang sử dụng công nghệ Layer2 cho các giao dịch giá rẻ đột nhiên phải đối mặt với một số khoản phí trên mainnet trên Chuỗi . Sự bối rối này càng trở nên rõ ràng hơn khi phí xử lý trên Chuỗi mainnet ngày càng cao, có thể gọi là "sát thủ phí xử lý".
Nhiều vấn đề khác nhau cũng cho thấy những hậu quả rõ ràng trong việc áp dụng Lightning Network trên thực tế: tăng trưởng người dùng yếu và hầu hết người dùng mới sẽ chọn giải pháp lưu trữ, như có thể thấy từ dữ liệu trong hình bên dưới.
Không khó để hiểu lý do của tình trạng này, xét cho cùng, hầu hết người dùng bình thường đều quá khó để tự mình duy trì nút và kênh.
2. Chúng ta cần loại mạng mở rộng quy Chuỗi ngoài Bitcoin nào?
Theo mô tả trong Sách trắng của Lightning Network, nếu mọi người trên thế giới chuyển kênh lần một năm thì dung lượng khối Bitcoin cuối cùng sẽ cần tăng trưởng lên 133MB. So với mainnet Bitcoin hiện tại, kích thước khối chỉ là 1 MB và ngay cả địa chỉ P2TR sử dụng Segregated Witness cũng chỉ là 4 MB, điều này cho thấy một khoảng cách rất lớn. Ngoài ra, xem xét rằng các công nghệ thực sự điều chỉnh thanh khoản của kênh (trao đổi tàu ngầm, ghép kênh) yêu cầu các giao dịch trực Chuỗi bổ sung, vấn đề không đủ không gian khối đối diện trong Bitcoin sẽ còn nghiêm trọng hơn trong các tình huống thực tế.
Có thể thấy, Lightning Network hiện tại khó có thể đáp ứng nhu cầu của người dùng C-end quy mô lớn trong thời gian ngắn. Ngoài ra, bị hạn chế bởi dung lượng khối Bitcoin nên tiềm năng mở rộng của Lightning Network cũng rất đáng kể. hạn chế về lâu dài.
Sau đó, câu hỏi được đặt ra: Chúng ta cần loại mạng lưới mở rộng quy mô ngoài Chuỗi Bitcoin nào?
2.1 Hiện trạng của Lightning Network
Để hiểu những hạn chế hiện tại của Lightning Network, chúng ta cần quay lại các nguyên tắc thiết kế của nó.
Mô hình Lightning Network hiện tại còn được gọi là LN-Panelty . Nói chung, mô hình này là mô hình kênh hai bên dựa trên các giao dịch phạt. Tính bảo mật của nó dựa vào private key được lưu trữ cục bộ của người dùng để kiểm tra và cân bằng các giao dịch và hình phạt của bên kia, đồng thời duy trì giám sát Chuỗi Bitcoin mọi lúc để đảm bảo rằng mọi động thái của đối tác giao dịch đều nằm dưới sự giám sát của chính họ.
Theo thiết kế mô hình như vậy, việc người dùng chạy nút của riêng họ là điều không thể tránh khỏi vì chức năng lưu trữ cục bộ và WatchTower là không thể thiếu. Phần này đã được nhấn mạnh nhiều lần ở bài trước.
Từ góc độ về vốn và hiệu quả truyền thông, mô hình phổ biến hiện nay của Lightning Network là siêu nút LSP cung cấp thanh khoản ở giữa, sau đó người dùng thiết lập các kênh với siêu nút của người duy trì LSP. Bản thân điều này đã đi chệch khỏi P2P được hình dung ban đầu. mô hình hình dạng mạng. Trong trường hợp tiến hóa tự nhiên, cuối cùng nó đã quay trở lại mô hình trục và nan hoa cổ điển.
Hình dưới đây là một ví dụ. Bên trái là Lightning Network lý tưởng và bên phải là trạng thái Lightning Network thực sự.
2.2 Đặc điểm của mạng mở rộng ngoài Chuỗi toC lý tưởng
Vì vậy, bây giờ hãy tưởng tượng những tính năng mà người dùng bên C thực sự cần cho mạng mở rộng Bitcoin ngoài Chuỗi:
1. Sử dụng mô hình không phải P2P, người dùng không cần phải tự bảo trì nút mà vẫn duy trì được tính bảo mật và tiện lợi tốt.
2. Về mặt tương tác, người dùng không cần phải trực tuyến cùng lúc khi thực hiện thanh toán. Có thể thực hiện cả hoạt động ngoại tuyến và không đồng bộ.
3. Nâng cao hiệu quả sử dụng vốn đồng thời đáp ứng nhu cầu không cầm giữ
4. Cơ chế quản lý thanh khoản rẻ và hiệu quả, thậm chí không yêu cầu người dùng phải tự duy trì thanh khoản
Dựa trên những mục tiêu này, bài viết này sẽ dẫn dắt người đọc khám phá hướng phát triển trong tương lai của mạng lưới mở rộng quy mô ngoài Chuỗi Bitcoin .
3. Lộ trình phát triển mở rộng vốn có của BTC
Trước hết, chúng ta cần làm rõ rằng trong cơ chế cốt lõi hiện tại của thiết kế Lightning Network “LN-Panelty”, cơ sở của cơ chế cập nhật trạng thái là:
· Lưu trữ và giám sát liên tục các giao dịch đã cam kết
· Cơ chế multi-hop trên cộng tác nhiều người (HTLC/PTLC)
Các yếu tố này tạo thành nền tảng của thiết kế Lightning Network hiện tại và trực tiếp dẫn đến sự phức tạp của thiết kế nút, như thể hiện trong:
· Tương tác truyền thông crypto phức tạp
· Lưu trữ cục bộ các giao dịch cam kết và private key bị phạt
· Tháp canh đang chạy không thể bị gián đoạn trong suốt thời gian của kênh.
Những vấn đề này thúc đẩy chúng tôi phải suy nghĩ xem liệu có thể sử dụng cơ chế cập nhật trạng thái nhẹ hơn để thay thế "LN-Penalty" hay không. Trong bối cảnh này, BIP118 (SIGHASH_ANYPREOUT) được đề xuất như một giải pháp thay thế khả thi.
3.1 LN-Symmetry: Cập nhật trạng thái giới thiệu cơ chế phiên bản
BIP118 đề xuất giới thiệu chế độ chữ ký SIGHASH_ANYPREOUT, cho phép đầu vào của giao dịch cập nhật giao dịch trước đó mà không chỉ định đầy đủ đầu ra trước đó mà không thay đổi chữ ký. Thiết kế này có thể giảm đáng kể độ phức tạp và yêu cầu lưu trữ của giao tiếp crypto giữa nút so với "LN-Penalty". SIGHASH_ANYPREOUT xuất phát từ bài báo: Giao thức Layer2 đơn giản cho Bitcoin. Trong các cuộc thảo luận gần đây về phát triển Lightning Network, mô hình Lightning Network dựa trên cải tiến này còn được gọi là "LN-Symmetry".
Mặc dù LN-Symmetry làm giảm áp lực lên việc lưu trữ giao dịch đã cam kết cục bộ nhưng nó không loại bỏ hoàn toàn nhu cầu giám sát. Mặc dù Eltoo không yêu cầu trao đổi các giao dịch cam kết và chữ ký private key, nhưng nếu người tham gia cố gắng xuất bản trạng thái cũ lên Chuỗi, bên kia vẫn cần theo dõi trong thời gian thực và xuất bản giao dịch trạng thái mới nhất một cách kịp thời để thay thế. trạng thái cũ. Các nhiệm vụ giám sát trong quá trình này vẫn yêu cầu WatchTower truyền thống. Lúc này, mục đích chạy WatchTower thay đổi từ trừng phạt sang thay thế trạng thái. Người dùng vẫn cần duy trì nút của riêng họ.
Đồng thời, LN-Symmetry vẫn yêu cầu các cơ chế như HTLC/PTLC để đảm bảo sự cộng tác của nhiều người, điều này vẫn sẽ có gánh nặng liên lạc nặng nề như thiết kế nút Lightning Network trước đây.
Do đó, xét từ hiệu quả tổng thể, sự cải thiện trải nghiệm mà LN-Symmetry mang lại cho Lightning Network hiện tại còn hạn chế và vẫn còn một chặng đường dài phía trước để đạt được mục tiêu mà chúng ta đang theo đuổi.
Để cải thiện hơn nữa, bài viết này dẫn đến định hướng cho giai đoạn tiếp theo: UTXO được chia sẻ.
3.2 CoinPool: Giảm yêu cầu tương tác và thanh khoản của các kênh bên long
Bài báo đầu tiên giới thiệu khái niệm UTXO được chia sẻ là CoinPool: nhóm thanh toán ngoài chuỗi hiệu quả cho Bitcoin, mục tiêu cốt lõi của nó là giải quyết sâu hơn vấn đề tương tác bên long theo cơ chế cập nhật phiên bản của SIGHASH_ANYPREOUT.
Trong thiết kế LN-Symmetry, cơ chế cập nhật trạng thái mới do Eltoo giới thiệu thực sự đã đơn giản hóa việc quản lý trạng thái của các kênh điểm-điểm. Tuy nhiên, khi nói đến hợp tác bên long , sự phức tạp của các tương tác vẫn tồn tại, đặc biệt là trong thanh toán nhiều bước (HTLC/PTLC), đòi hỏi sự phối hợp chặt chẽ của tất cả các bên và giao tiếp crypto lần .
Điểm đổi mới của CoinPool là nó sử dụng mô hình UTXO được chia sẻ để cho phép bên long cộng tác trên cùng một UTXO với khả năng kiểm soát phiên bản. Bằng 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 của UTXO mà không cần dựa vào các cơ chế HTLC/PTLC phức tạp. Ưu điểm chính của nó được phản ánh trong:
· Giảm đáng kể độ phức tạp tương tác của các kênh bên long: Vì tất cả người tham gia đều có chung UTXO, họ có thể đạt được sự đồng thuận bằng cách ký vào bản cập nhật phiên bản của UTXO này mà không cần thực hiện lần giao dịch trực Chuỗi hoặc tương tác phức tạp ngoài Chuỗi. Sự đơn giản hóa này làm cho việc quản lý các kênh bên long hiệu quả hơn.
·Cơ chế cập nhật Chuỗi trở nên trực tiếp hơn: Theo thiết kế này, cơ chế cập nhật trạng thái ngoài Chuỗi được chuyển thành UTXO của một phiên bản nhất định được bên long cùng ký kết. Phương pháp này không chỉ đơn giản hóa quá trình cập nhật trạng thái mà còn giảm hơn nữa sự phụ thuộc và các điểm xung đột tiềm ẩn giữa các bên.
· Loại bỏ nhu cầu thanh khoản độc lập : Thông qua mô hình UTXO được chia sẻ, nhiều người tham gia thực sự chia sẻ cùng một nhóm thanh khoản, loại bỏ nhu cầu mỗi người tham gia phải duy trì đủ thanh khoản một cách độc lập. Trong thiết kế CoinPool hợp tác bên long, nhu cầu thanh khoản có thể giảm đáng kể hoặc được phân bổ lại. Người tham gia có thể sử dụng thanh khoản trong UTXO được chia sẻ để hoàn tất thanh toán mà không cần phải khóa lượng lớn cho các kênh của riêng họ. Điều này không chỉ nâng cao hiệu quả sử dụng vốn mà còn giảm áp lực tài chính cho cá nhân người tham gia.
Thiết kế của CoinPool đã giảm thành công độ phức tạp tương tác trong các kênh bên long xuống mức hợp lý bằng cách chia sẻ UTXO, đồng thời duy trì tính bảo mật và hiệu quả của hệ thống. Quan trọng hơn, nó làm 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ẹ nhàng và linh hoạt hơn cho sự hợp tác bên long , đồng thời vượt qua mô hình LN truyền thống trong các hạn chế về tương tác và quản lý thanh khoản bên long .
Tuy nhiên, tại sao giải pháp với những ưu điểm rõ ràng như vậy lại không được áp dụng trên quy mô lớn? Gốc rễ của vấn đề là gì?
3.3 Tại sao CoinPool không thực sự được triển khai?
Mặc dù CoinPool có nhiều ưu điểm và được coi là một mô hình mở rộng lý tưởng, nhưng nâng cấp soft fork mà nó dựa vào đòi hỏi rất nhiều yêu cầu mà chúng ta có thể chưa thấy nó được triển khai trên mạng Bitcoin trong đời. Nhu cầu nâng cấp soft fork của CoinPool chủ yếu tập trung vào hai khía cạnh sau:
3.3.1 Nâng cấp cơ chế cập nhật trạng thái
Vì CoinPool được thiết kế dựa trên Eltoo nâng cấp nó kế thừa nhu cầu về cơ chế cập nhật trạng thái soft fork soft fork , yêu cầu nâng cấp Bitcoin để kích hoạt chế độ chữ ký mới SIGHASH_ANYPREVOUT (APO). Điều này khiến công nghệ mà cơ chế cập nhật trạng thái của CoinPool dựa vào khó áp dụng vào thực tế.
3.3.2 Shared UTXO yêu cầu hợp đồng để đơn giản hóa cơ chế hoạt động
Như đã đề cập ở trên, lần bản cập nhật trạng thái của UTXO được chia sẻ đều yêu cầu thu thập chữ ký của tất cả các phiên bản được chia sẻ của UTXO. Trong quá trình này, nếu một bên ngoại tuyến, toàn bộ hệ thống sẽ ngừng hoạt động. Về mặt blockchain, hệ thống này có khả năng hoạt động kém. Để vượt qua thách thức này, hệ thống yêu cầu một cơ chế có thể cập nhật UTXO dùng chung với chi phí thấp và không phụ thuộc hoàn toàn vào sự hợp tác.
Trong bài báo của CoinPool, OP_MERKLESUB được đề xuất nhằm mục đích xác minh và cập nhật trạng thái của những người tham gia cụ thể thông qua cấu trúc Merkle trees. Mặc dù ý tưởng thiết kế này khả thi về mặt lý thuyết nhưng nó lại gặp phải những vấn đề tương tự như các hợp đồng vận hành khác dựa trên Merkle trees , tức là việc triển khai logic rất phức tạp và khó hình thành một hợp đồng phổ quát và có thể tái sử dụng. Ví dụ: các hợp đồng tương tự như **OP_TAPLEAFUPDATEVERIFY(TLUV)**, v.v. Ngoài ra, chức năng hợp đồng của OP_EVICT, trực tiếp loại bỏ bên bất hợp tác ra khỏi Shared UTXO, quá đơn giản và khó có thể đoán trước rằng nó có thể vượt qua nâng cấp mạng Bitcoin thành công.
Trong số Đề án hợp đồng này, OP_CheckTemplateVerify(CTV) dần trở thành tâm điểm chú ý. Thay vì trực tiếp xây dựng và xác thực Merkle trees, CTV giới hạn chi tiêu thông qua các mẫu giao dịch được xác định trước. CTV không chỉ dễ triển khai mà còn có thể thực hiện sê-ri UTXO ngoài Chuỗi thông qua UTXO Chuỗi thông qua chuỗi cam kết giao dịch. Các UTXO ngoài Chuỗi này được cam kết trên Chuỗi là nguồn gốc ban đầu của khái niệm UTXO ảo.
Trong số các hợp đồng này, CTV có sức hấp dẫn lớn nhất về tính phổ biến vì nó vừa đơn giản vừa đa năng. Khả năng mạnh mẽ của CTV không chỉ có thể hiện thực hóa những ý tưởng tương tự như CoinPool mà còn có thể được Rollup sử dụng. Có thể hình dung rằng bằng cách thực hiện xác minh ZKP-MerkleState thông qua OP_CAT lần và cam kết trực tiếp với UTXO được chia sẻ tương ứng với trạng thái Layer2 trong tập lệnh, chúng tôi sẽ có thể xây dựng giải pháp ZK-Rollup Bitcoin thực sự.
Tóm lại, vấn đề chính khi triển khai CoinPool gặp phải là nó yêu cầu cơ chế cập nhật trạng thái nhẹ APO và mã opcode UTXO được chia sẻ để giúp triển khai nó, cả hai đều yêu cầu nâng cấp soft fork của Bitcoin . Rất nhiều năm sau khi giấy CoinPool ra đời, nó vẫn là một giải pháp giấy.
3.4 Bitcoin Clique: 2-AS nguyên thủy chống chi tiêu gấp đôi ngoài Chuỗi
Trong cuộc thảo luận nói trên về mô hình CoinPool, chúng tôi đã biết rằng cơ chế APO mà nó dựa vào yêu cầu nâng cấp soft fork để hiện thực hóa giải pháp, điều này khó đạt được trong thời gian ngắn. Vì vậy, nếu có một phương thức chi tiêu gấp đôi Chuỗi mới không dựa vào nâng cấp soft fork Bitcoin thì vấn đề triển khai sẽ được giải quyết ở mức độ lớn.
Chức năng 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 có thể tránh chi tiêu gấp đôi. Dựa trên ý tưởng này, nếu có thể tìm thấy các nguyên tắc mã hóa tương đương thì vấn đề cập nhật trạng thái ngoài Chuỗi có thể được giải quyết và có thể tránh được nhu cầu cập nhật các nguyên tắc hoạt động Bitcoin. Sự xuất hiện của bài báo Bitcoin Clique mang đến một bình minh mới. Nó giới thiệu một chữ ký bộ chuyển đổi 2 lần bắn (2-AS) nguyên thủy bằng mật mã mới, cung cấp một giải pháp mới để ngăn chặn chi tiêu kép ngoài Chuỗi.
2-AS là một mật mã nguyên thủy dựa trên chữ ký bộ điều hợp Schnorr. Để hiểu 2-AS, trước tiên chúng ta phải có hiểu biết nhất định về chữ ký Schnorr và chữ ký bộ điều hợp.
3.4.1 Chữ ký Schnorr
Chữ ký Schnorr có đặc tính tuyến tính, nghĩa là nhiều chữ ký có thể được tổng hợp thành một chữ ký duy nhất. Nói một cách đơn giản, nếu có nhiều chữ ký $S_1$ và $S_2$, chúng có thể được tổng hợp thành một chữ ký $S=S_1+S_2$ thông qua phép cộng và khóa chung tương ứng trong quá trình xác minh cũng có thể được tổng hợp thành $P = P_1 + P_2 $.
3.4.2 Chữ ký bộ chuyển đổi
Có một số bước cơ bản để ký bộ điều hợp, chẳng hạn như Gen, PSign, PVrfy, Adapt và Extract. Khi hiểu 2-AS, điều đặc biệt quan trọng là phải hiểu hai bước Psign và Extract.
Bài viết này tập trung vào việc tìm hiểu chữ ký của bộ điều hợp từ một mục đích hơn là từ góc độ mật mã. Nói tóm lại, khi hai chủ thể muốn hợp tác để xác nhận chữ ký, họ thường sử dụng bộ chuyển đổi của bên kia làm một phần của chữ ký và bộ chuyển đổi thường là phần khóa chung của khóa chung và khóa riêng, sau đó giữ private key tương ứng. của bộ chuyển đổi, tức là Bên được gọi là bí mật có khả năng Thích ứng để hoàn thành phần chữ ký do Psign để lại. Nếu chỉ có vậy thì nó có giống MuSig không? Tuy nhiên, điểm độc đáo của chữ ký bộ điều hợp là nó có thể được trích xuất, nghĩa là sau khi chữ ký hoàn chỉnh được giải phóng, bên ban đầu khởi tạo Psign của chữ ký bộ điều hợp có thể rút bí mật tương ứng thông qua chữ ký hoàn chỉnh, chữ ký trước đó chữ ký một phần và bộ điều hợp (khóa chung) (private key).
3.4.3 Kết hợp cả hai: 2-AS
Bây giờ chúng ta đã tìm hiểu về các thuộc tính của chữ ký Schnorr và chữ ký bộ điều hợp, bây giờ chúng ta có thể xem xét điều kỳ diệu kết hợp cả hai: 2-AS.
Giả sử chúng ta có một VTXO và muốn đảm bảo rằng nó có thể bị cắt khỏi Chuỗi khi chi tiêu gấp đôi, thì chúng ta có thể thiết kế nó như thế này:
· Đầu tiên chúng ta cần có một đầu ra phạt, trong đó pubkey có thể mở khóa được là public key bị phạt. Đảm bảo rằng người dùng có thể bị trừng phạt khi chi tiêu gấp đôi.
· Đối tác giao dịch hợp tác với nhau để thực hiện chữ ký bộ điều hợp để xác nhận các giao dịch ngoài Chuỗi. Nếu người dùng sử dụng cùng một đầu vào lần, đầu ra có thể bị nhà cung cấp dịch vụ cắt giảm.
· Người dùng được yêu cầu tạo một pubkey làm đầu ra hình phạt lần khi họ cập nhật trạng thái. Khóa công khai hình phạt của đầu ra hình phạt bao gồm việc bổ sung công nghệ chữ ký Schnorr của hai cặp khóa chung được xác định trước.
Do đó, trước lần giao dịch, chúng tôi xác nhận cặp khóa chung và khóa riêng sẽ được sử dụng sau đó và tạo trước kết quả phạt. Sau đó, khi chi tiêu gấp đôi xảy ra, nhà cung cấp dịch vụ cuối cùng có thể lấy được private key tương ứng với đầu ra bị phạt thông qua lần chữ ký bộ điều hợp.
3.4.4 Ưu và nhược điểm của nhóm Bitcoin
Kế hoạch Bitcoin Clique cũng không hoàn hảo. Điểm bất lợi là các khóa 2-AS được sử dụng để xây dựng các khóa chung bị phạt mới cần phải được trao đổi liên tục khi trạng thái Chuỗi được cập nhật. Và vì giải pháp dựa trên thiết kế của CoinPool và để trao đổi khóa 2-AS cũng như xác minh chữ ký của phiên bản UTXO mới lần, giải pháp cũng yêu cầu mọi người phải trực tuyến khi trạng thái được cập nhật. Nói cách khác, tính phức tạp và tính tương tác của giao tiếp vẫn rất cao.
Điểm quan trọng nhất là mô hình này có thiết kế tương tự như StateChain. Lần chúng tôi chuyển quyền sở hữu một Chuỗi UTXO nhất định, hệ thống sử dụng chữ ký ngăn chặn chi tiêu kép như 2-AS không thể được sử dụng trên Chuỗi. được thực hiện trong quá trình thanh toán, điều này làm cho các kịch bản ứng dụng bị hạn chế.
Ngoài ra, ngay cả với cơ chế SharedUTXO dễ vận hành và cơ chế chi tiêu kép ngoài Chuỗi không yêu cầu soft fork , chúng tôi vẫn cần mọi người cập nhật và xác nhận trạng thái mới của UTXO trực tuyến, ngay cả khi lần cập nhật trạng thái chỉ ảnh hưởng đến phần mạng lưới ngoài Chuỗi của người dân. Thật không hợp lý khi cho phép những người không liên quan tham gia cập nhật trực tuyến Chuỗi. Và việc loại bỏ hoàn toàn nhu cầu thanh khoản là điều không mong muốn. Các phương án thanh toán thiếu bôi thanh khoản sẽ không thể tạo ra sự thay đổi về mệnh giá và do vấn đề thoát ra, mọi người thường phải có cùng một mệnh giá.
Do đó, hiện tại không có giải pháp mở rộng ngoài Chuỗi nào không phải là kênh và hỗ trợ mệnh giá động và dựa trên UTXO. Ethereum cũng gặp rắc rối với tuyến đường này mà chúng tôi gọi là bẫy Plasma. Để nghiên cứu liên quan, vui lòng tham khảo bài báo Giới hạn dưới cho các giao thức ngoài chuỗi: Khám phá các giới hạn của Plasma.
Tóm tắt các vấn đề và bài học rút ra:
1. Cần phải bôi trơn thanh khoản để đảm bảo thanh toán mệnh giá linh hoạt (có thể thực hiện các giao dịch thay đổi): Điều này đòi hỏi phải giữ lại thiết kế kênh, đồng thời có thể tránh được các vấn đề thoát ra.
2. Giảm sự phụ thuộc vào việc tất cả người tham gia trực tuyến đồng thời: Chúng tôi không muốn mọi người dùng đều trực tuyến khi thực hiện bất kỳ cập nhật trạng thái nào trong mạng Chuỗi được chia sẻ phải được cập nhật trực tuyến bởi những người có liên quan.
Dựa trên những hiểu biết trên, bài viết này tiếp tục khám phá các giải pháp tối ưu hơn theo hướng này.
Nhà máy 3.5 kênh và kênh ảo
Trong cuộc thảo luận trước, chúng tôi nhận ra rằng chúng tôi không chỉ cần duy trì thiết kế của kênh mà còn cần UTXO được chia sẻ để mang lại cho chúng tôi lợi nhuận chi phí thấp ngoài Chuỗi . Sau đó, một khái niệm đã được thảo luận từ lâu trong lĩnh vực Lightning Network đã lọt vào tầm nhìn của chúng tôi, đó là Channel Factory.
Trước đây, chúng tôi đã đề cập rằng UTXO ngoài Chuỗi được cam kết bởi UTXO trên Chuỗi được gọi là UTXO ảo. Nếu chúng ta sử dụng UTXO ảo ngoài Chuỗi làm FundingTx của kênh, chúng ta sẽ có một khái niệm mới, đó là kênh ảo (Kênh ảo). Sau đó, các kênh ảo trong Chuỗi trong UTXO được chia sẻ này được kết nối bằng Virtual HTLC. Mọi thứ đều nằm ngoài Chuỗi và được "ảo hóa". Điều này dường như cung cấp một giải pháp lý tưởng: triển khai hầu hết các chức năng ngoài Chuỗi, bao gồm điều chỉnh thanh khoản, v.v., mở rộng Lightning Network dường như có thể được giải quyết dễ dàng.
Nhưng nó có thực sự đẹp như vậy không?
Vì nó kế thừa các đặc điểm của UTXO được chia sẻ nên nhà máy sản xuất kênh yêu cầu sự hợp tác của nhiều người dùng để mở và đóng nó. Nếu bất kỳ người dùng nào trong đó không hợp tác kịp thời (ví dụ: ngoại tuyến hoặc không phản hồi), điều đó có thể ảnh hưởng đến chức năng của toàn bộ nhà máy kênh. Vì các nhà máy sản xuất kênh liên quan đến việc bên long đồng ký cập nhật trạng thái nên hành vi không đồng bộ hóa hoặc độc hại của bất kỳ bên nào cũng có thể ngăn người dùng khác đóng kênh và rút tiền thành công.
Và các vấn đề với thiết kế này cũng rất rõ ràng. Mặc dù chi phí chuyển kênh theo cách này giảm đi nhưng mô hình bảo mật giữa các kênh vẫn dựa vào các giao dịch cam kết và HTLC. Do đó, các vấn đề về giao tiếp và tương tác vẫn tồn tại và độ phức tạp khi triển khai giải pháp này thậm chí còn cao hơn LN-Panelty hiện tại.
3.6 ARK JoinPool và kênh tạm thời
Thông qua việc xem xét các trường hợp nhà máy sản xuất kênh trước đây, chúng tôi đã đi đến kết luận: trong thiết kế kênh dựa trên UTXO được chia sẻ, thiết kế kênh "LN-Panelty" cổ điển có thể không được tiếp tục, nhưng đồng thời, những lợi thế của việc giới thiệu các kênh nên được duy trì giữ lại:
1. Mệnh giá động do thanh khoản mang lại;
2. Dễ dàng thoát ra.
Dựa trên điều này, một thiết kế các kênh tạm thời sử dụng JoinPool đã xuất hiện, cụ thể là Giao thức ARK.
3.6.1 JoinPool: Một số người tham gia cập nhật
Như đã đề cập ở trên, CoinPool mang đến tiềm năng mở rộng hợp tác ngoài Chuỗi cho nhiều người, chẳng hạn, nó không yêu cầu các thiết kế phức tạp và dễ bị lỗi như thanh khoản, nhiều bước nhảy và HTLC. Tuy nhiên, vấn đề quan trọng nhất của mô hình CoinPool là yêu cầu trực tuyến đối với người dùng: tất cả người dùng trong toàn bộ UTXO được chia sẻ 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 dùng không thay đổi, việc xác minh trực tuyến và chữ ký tương ứng đều phải trực tuyến. vẫn được yêu cầu. Yêu cầu này khiến không thể tránh khỏi vấn đề người dùng cần chạy nút của riêng họ.
Để giải quyết vấn đề này, một mô hình mới được đề xuất, đó là JoinPool. Khái niệm JoinPool trong UTXO được chia sẻ là: lần 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 sẽ tham gia UTXO được chia sẻ đại diện cho trạng thái mới của UTXO tương ứng của họ. Điều này giải quyết vấn đề người dùng không liên quan cần trực tuyến trong khi những người khác đang thực thi. 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 thực hiện giao dịch.
Nhưng tất cả chúng tôi đều hiểu rằng ngoài việc đảm bảo rằng private key của người dùng trực tuyến để ký, còn có một lý do quan trọng dẫn đến nhu cầu chạy nút Lightning Network một cách liên tục. Mỗi thành viên kênh cần WatchTower liên tục theo dõi xem đối tác giao dịch có đặt bất kỳ nút nào hay không. thông tin bất lợi cho chính nó. Cam kết giao dịch với Chuỗi. Điều này đưa chúng ta đến câu hỏi thứ hai mà chúng ta cần giải quyết.
3.6.2 Chuyển giao trách nhiệm của WatchTower: người dùng không cần tự mình duy trì nút
Trong thiết kế LN-Panelty cổ điển, mỗi người dùng cần xây dựng Tháp canh của riêng mình để theo dõi xem bên kia có tải trạng thái cũ lên Chuỗi hay không và nếu có sẽ bị trừng phạt. Trong mô hình cũ như vậy, đối tác giao dịch của tất cả chúng ta đều là nút sét ngang hàng và lần chúng ta tham gia vào một giao dịch, có thể mở một kênh với một nút khác để giao dịch. Nhưng trong ARK, tất cả người dùng thực sự tương tác với ASP (Nhà cung cấp dịch vụ ARK) và không tương tác trực tiếp với những người dùng khác.
Đối với ASP, khi giao dịch ngoài Chuỗi VTXO của người dùng được giao dịch, giao dịch từ bỏ sẽ được ký. Điều này là do lý tưởng nhất là VTXO off- Chuỗi của người dùng sẽ không được đề cập trên Chuỗi mà sẽ liên tục được tham chiếu và sau đó được chuyển sang vòng giao dịch tiếp theo. Nếu một VTXO được giao dịch ngoài Chuỗi và được đề xuất trên Chuỗi cùng một lúc, điều đó có nghĩa là VTXO đã được người dùng chi tiêu gấp đôi và khi đó ASP sẽ sử dụng giao dịch từ bỏ được ký bởi người dùng Chuỗi để phát hành một yêu cầu bồi thường cho người dùng Số tiền trên Chuỗi sẽ bị tịch thu. ASP sẽ giám sát tất cả các VTXO đã xuất hiện trong lịch sử để ngăn chặn bất kỳ ai cố tình thoát khỏi các VTXO đã được sử dụng ngoài Chuỗi và sau đó trên Chuỗi.
Điều này chuyển trách nhiệm vận hành của WatchTower từ người dùng thông thường sang nhà điều hành. So với Lightning Network, mô hình này là một cải tiến lớn: cuối cùng chúng tôi không còn cần người dùng thông thường chạy nút của riêng họ để đảm bảo an ninh của riêng họ .
Tóm tắt các giải pháp khác trong việc tối ưu hóa hoạt động nút người dùng:
· Lưu trữ đám mây nút Lightning Network
Một số giải pháp chọn chạy nút Lightning Network trên nền tảng đám mây để giúp người dùng hạ thấp ngưỡng chạy nút. Tuy nhiên, giải pháp này về cơ bản vi phạm các giả định bảo mật của chính Lightning Network. Trong công nghệ Lightning Network, việc lưu trữ private key và các giao dịch đã cam kết đều quan trọng như nhau trong nhiều tình huống. Do đó, chỉ sử dụng private key từ xa không đảm bảo tính bảo mật.
Về cơ bản, giải pháp này biến kịch bản trò chơi hai bên thành kịch bản trò chơi ba bên liên quan đến tôi, đối tác giao dịch và bên lưu trữ đám mây. Khi tôi đã giao dịch với đối tác của mình nhưng trạng thái chưa được tải lên Chuỗi, người giám sát đá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 này, đối tác giao dịch của tôi có thể dễ dàng Chuỗi trạng thái có lợi cho nó. Trong giải pháp lưu trữ nút đám mây Lightning Network như vậy, có rủi ro thông đồng giữa nền tảng lưu trữ đám mây và đối tác giao dịch .
· CUA và CUA buồn ngủ
Giao thức CRAB (Kênh chống hối lộ) do Aumayr và cộng sự đề xuất đảm bảo tính bảo mật của các kênh thanh toán bằng cách thêm tài sản thế chấp bổ sung và cơ chế khích lệ thợ đào, đặc biệt là khi người dùng ngoại tuyến. Cơ chế này làm giảm sự phụ thuộc vào WatchTower của bên thứ ba. Tuy nhiên, cơ chế thế chấp này chắc chắn sẽ làm trầm trọng thêm các vấn đề như “thanh khoản đã đặt trước”. Bởi vì nó yêu cầu người dùng khóa nhiều tiền hơn không liên quan đến mục đích giao dịch khi tham gia mạng Chuỗi ngoài chuỗi. Mặc dù tính bảo mật được đảm bảo nhưng thanh khoản và hiệu quả của tiền lại bị hy sinh. Hơn nữa, loại giải pháp này vẫn yêu cầu người dùng tự chạy nút nhưng chỉ giảm yêu cầu người dùng phải 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 của kênh
Ai đó có thể hỏi, tại sao nhà cung cấp dịch vụ ASP lại sẵn sàng bơm thanh khoản vào kênh của chúng tôi trong JoinPool? Điều này là do nếu người dùng muốn sử dụng VTXO dựa trên mạng ARK, trước tiên họ phải gửi UTXO của mình cho nhà điều hành vào một địa chỉ có nhiều chữ ký, tương tự như FundingTx, để đổi lấy VTXO. Về bản chất, người dùng đang sử dụng tiền của nhà điều hành lần giao dịch ngoài Chuỗi, nhưng họ sẽ chuyển số tiền mà họ đã ký với nhà điều hành trước đó.
Sở dĩ kênh của ARK được gọi là kênh tạm thời là vì nó có hai đặc điểm: vốn một chiều và bơm vốn một lần .
· Một chiều: Trong kênh một chiều, tiền sẽ chỉ được chuyển từ người khởi xướng được chỉ định sang bên đầu ra tương ứng.
· Bơm vốn một lần: Kênh của ARK chỉ yêu cầu bơm vốn một lần. Sau khi tiền được bơm vào, không cần tiếp tục duy trì thanh khoản của kênh.
Theo thiết kế kênh tạm thời như vậy, sau khi bơm vốn xong, kênh không cần điều chỉnh như tái cân bằng. So với Lightning, không chỉ người dùng không còn cần quan tâm đến thanh khoản của kênh mà nhà cung cấp thanh khoản cũng không còn cần phải duy trì thanh khoản của kênh nữa. Thay đổi duy nhất tồn tại trong kênh là sự kiện thoát của người dùng.
3.6.4 Tóm tắt giao thức ARK
Dựa vào những điều trên, chúng ta có thể thấy rõ rằng thiết kế của ARK Protocol đã đạt được tiến bộ đáng kinh ngạc về trải nghiệm người dùng so với Lightning Network:
· Người dùng không cần phải tự bảo trì nút
· Người dùng không cần phải tự mình duy trì thanh khoản của kênh và không có vấn đề thanh khoản kế toán
· Hỗ trợ tương tác không đồng bộ mà không cần cả hai bên trực tuyến cùng một lúc
4. Những thay đổi trong mô hình mở rộng quy mô gốc của Bitcoin
Thông qua nghiên cứu trên, chúng tôi đã khám phá nhiều giải pháp mở rộng ngoài Chuỗi dựa trên UTXO được chia sẻ. UTXO được chia sẻ ban đầu được thiết kế để giải quyết các vấn đề thanh khoản. Tuy nhiên, khi giao thức tiếp tục phát triển, chúng tôi bất ngờ nhận thấy rằng nó mang lại nhiều lợi ích mà chúng tôi đã mong đợi nhưng lại không dám mơ tới.
Điều này đánh dấu việc mở rộng ngoài Chuỗi Bitcoin đã bước vào một hướng phát triển mới. So với mô hình Lightning Network ban đầu, đây là một sự thay đổi mô hình:
· Từ mô hình P2P đến việc giới thiệu các nhà khai thác không cần sự tin cậy
Logic của mạng mở rộng ngoài Chuỗi đã dần phát triển từ mô hình trò chơi song phương "người dùng so với người dùng" ban đầu của mạng Lightning thành mô hình trò chơi giữa "người dùng và nhà điều hành". Điểm khác biệt là người dùng không cần phải tin tưởng vào nhà điều hành bên thứ ba này.
· Người dùng không cần phải tự bảo trì cơ sở nút để đảm bảo an ninh tài sản
Mô hình LN-Penalty truyền thống và nghiên cứu mới nhất như CRAB dựa vào người dùng để cung cấp tài sản thế chấp để đảm bảo an toàn cho tiền, đồng thời yêu cầu người dùng phải trực tuyến và chạy nút trong suốt thời gian tồn tại của kênh. Tuy nhiên, các kịch bản trong tương lai sẽ không còn yêu cầu các hoạt động này nữa. Hơn nữa, các quy trình này vẫn không bị giám sát và người dùng luôn giữ quyền kiểm soát tài sản của họ.
· Trách nhiệm quản lý thanh khoản được chuyển từ người dùng sang nhà điều hành
Trong mô hình LN-Penalty cổ điển và 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 không cân bằng. Điều này thường đòi hỏi một số kiến thức chuyên môn và rất phức tạp để vận hành nếu không có sự trợ giúp của LSP (Nhà cung cấp dịch vụ thanh khoản). Tuy nhiên, do trách nhiệm quản lý thanh khoản được chuyển giao cho các nhà khai thác bên thứ ba nên người dùng không còn cần phải lo lắng về việc quản lý thanh khoản. Điều này giúp đơn giản hóa đáng kể trải nghiệm người dùng và loại bỏ các rào cản khi tham gia mạng.
· Hiệu quả và tiềm năng vốn được cải thiện rất nhiều
Các thiết kế giao thức mới đang hướng tới mô hình P2POOL, về cơ bản khác với Lightning Network hiện tại về hiệu quả sử dụng vốn. Trong mô hình LN-Penalty, mỗi người dùng phải tự cung cấp thanh khoản khi mở kênh Lightning, nhưng thanh khoản của các kênh này hầu như không hoạt động (thanh toán không diễn ra thường xuyên và thanh toán được phân bổ không đồng đều giữa các kênh). Kết quả là tiền của người dùng không thể đượ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 các nhóm thanh khoản để quản lý thống nhất, mang lại khả năng không giới hạn cho các kịch bản DeFi trong tương lai.
Sự thay đổi mô hình này cho thấy quản lý thanh khoản là bản chất của sự mở rộng và phát triển Chuỗi gốc của Bitcoin và nó cũng là chủ đề cốt lõi của sự phát triển trong tương lai.
Trong tương lai, với sự tiến bộ không ngừng của công nghệ và sự xuất hiện của các giải pháp mới, việc mở rộng Chuỗi của Bitcoin chắc chắn sẽ có triển vọng phát triển tươi sáng hơn. Chúng tôi sẽ tiếp tục tiến hành nghiên cứu chuyên sâu trong lĩnh vực này và mời độc giả đón chờ những kết quả tiếp theo của chúng tôi.
Chào mừng bạn tham gia cộng đồng chính thức BlockBeats BlockBeats:
Nhóm đăng ký Telegram: https://t.me/theblockbeats
Nhóm liên lạc Telegram: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
