Nghệ thuật thanh khoản: Chúng ta cần loại mạng lưới mở rộng quy mô ngoài chuỗi Bitcoin nào?

Tiêu đề gốc: "Nghệ thuật thanh khoản: Chúng ta cần loại mạng mở rộng quy mô ngoài chuỗi Bitcoin nào"
Tác giả gốc: Ben , Người sáng lập Discoco Labs

Lời nói đầu

Tôi đã suy nghĩ về một câu hỏi từ lâu :Logic cốt lõi của việc mở rộng vốn có của Bitcoin là gì?

Trong khi nghiên cứu sâu hơn về Lightning Network và cố gắng triển khai các dịch vụ 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à tính thanh khoản. Mặc dù một lượng lớn cơ sở hạ tầng được cho là sẽ cải thiện tính thanh khoản đã được đưa vào sử dụng nhưng hiệu quả thực tế vẫn chưa đạt được kỳ vọng.

Khi bài viết này đang được viết, ví tự lưu trữ Lightning nổi tiếng trong ngành Mutiny Wallet đã thông báo đóng cửa, sau đó là đối tác của nó là Nhà cung cấp dịch vụ thanh khoản ( LSP). Mô hình hợp tác giữa ví tự lưu trữ và LSP luôn được coi 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 mạng chính dài, trung bình khoảng 10 phút. Điều này rõ ràng là cần thiết để nó trở thành mạng ngang hàng của thế giới. -peer tiền mặt Các yêu cầu hệ thống rất khác nhau. 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ể giải quyết 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 khóa tài sản trên chuỗi, việc hoàn thành trao đổi giao dịch đã cam kết ngoài chuỗi được coi là hoàn thành giao dịch, tức là nó tuyên bố là lý do thanh toán ngay lập tức. Về mặt kinh nghiệm, điều này được so sánh với thời gian xác nhận thanh toán trên mạng chính Bitcoin được giới hạn trong 10 phút đối với các tình huống thanh toán nhỏ, chắc chắn nó sẽ giải quyết được vấn đề số một.

Tuy nhiên, trong thực tế phát triển và sử dụng Lightning Network, 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 ở đâ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 để theo dõi xem bên kia có tải lên trạng thái cũ không có lợi cho mình trong quá trình tồn tại hay không. kênh, mô hình này yêu cầu WatchTower phải luôn trực tuyến, yêu cầu người dùng phải tự duy trì các 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à khóa riêng 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 một loạt 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 các khóa riêng, v.v. Ví dụ: mỗi khi cập nhật trạng thái ngoài chuỗi, 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 nhiều bên 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

LN của hai bên kênh Cơ chế -Panelty tương đương với việc người dùng mở tài khoản ngân hàng của riêng họ ở một mức độ nhất định và họ cũng cần mang theo khoả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 tính 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 , rất dễ xảy ra mất cân bằng thanh khoản 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 tuyến bổ sung để điều chỉnh FundingTx ban đầu được triển khai. Nhìn chung, tất cả các phương pháp điều chỉnh đều tốn kém, đặc biệt khi phí xử lý tăng cao và người dùng khó có thể bỏ qua.

Hãy tưởng tượng những người dùng nghĩ rằng họ đang sử dụng công nghệ Lớp 2 cho các giao dịch giá rẻ sẽ xấu hổ đến mức nào khi đột nhiên phải đối mặt với một số khoản phí xử lý trên mạng chính. 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 mạng chính ngày càng cao, có thể gọi là "sát thủ phí xử lý".

Các 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ế: mức 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ữ. thấy trong số liệu thống kê dưới đây.

Người dùng Lightning Network mới được thêm chọn sử dụng giải pháp ví lưu ký và không giám sát ví Số lượng gó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ì các nút và kênh.

2. Chúng ta cần loại mạng mở rộng quy mô ngoài chuỗi Bitcoin nào?

Trích từ Sách trắng của Lightning Network

Theo mô tả của sách trắng Lightning Network, nếu mọi người trên thế giới chuyển kênh hai lần một năm thì dung lượng khối Bitcoin cuối cùng sẽ cần tăng lên 133MB. So với mạng chính Bitcoin hiện tại, kích thước khối chỉ là 1 MB và thậm chí đị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 tí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 tuyến bổ sung, vấn đề không đủ không gian khối mà Lightning Network phải đối mặt 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 rằng Lightning Network hiện tại khó có thể đáp ứng được nhu cầu của người dùng C-end quy mô lớn trong thời gian ngắn. bị giới hạn bởi dung lượng khối Bitcoin Về lâu dài, khả năng mở rộng của Lightning Network cũng bị hạn chế đáng kể.

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 được những hạn chế hiện tại của Lightning Network Lightning Network, chúng ta cần Truy 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à kênh hai bên dựa trên hình phạt. giao dịch. Tính bảo mật của nó dựa vào khóa riêng đượ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 đề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 các 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ố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 và sau đó người dùng duy trì nó với LSP Thiết lập một kênh với siêu nút của tác giả, bản thân nó đã đi chệch khỏi mô hình lưới P2P được hình dung ban đầu. 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.

Lấy hình sau làm ví dụ. Bên trái là Lightning Network lý tưởng và bên phải là hiện trạng Lightning Network thực sự.

2.2 Đặc điểm của mạng mở rộng toC ngoài chuỗi 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 . Khi áp dụng mô hình không phải P2P, người dùng không cần phải tự duy trì các nút mà vẫn duy trì tính bảo mật và thuận tiện tốt

2. 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 lưu ký

3. p>

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 cùng nhau khám phá Bitcoin Hướng phát triển trong tương lai của các mạng mở rộng ngoài chuỗi.

3. Con đường phát triển của việc mở rộng nguồn gốc BTC

Trước hết, chúng ta cần phải làm rõ rằng trong cơ chế cốt lõi của thiết kế Lightning Network "LN-Panelty" hiện nay, 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ế nhiều bước (HTLC/PTLC) trong quá trình cộng tác nhiều người

Những 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 thiết kế nút Sự phức tạp của>

· Tháp canh không thể bị gián đoạn trong quá trình tồn tại của kênh

Những vấn đề này đã thúc đẩy chúng tôi để suy nghĩ xem liệu có thể sử dụng cơ chế cập nhật trạng thái nhẹ nhàng 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: Giới thiệu cơ chế phiên bản để cập nhật trạng thái

BIP118 đề xuất giới thiệu SIGHASH_ANYPREOUT chế độ chữ ký, cho phép cập nhật đầu vào của giao dịch mà không chỉ định đầy đủ đầu ra trước đó và cập nhật giao dịch 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 được mã hóa giữa các 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ý khóa riêng, 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 theo 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ì các 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 giữa nhiều người. Điều này vẫn sẽ giống như Lightning trước đây. Thiết kế nút mạng, có vấn đề nghiêm trọng về truyền thông.

Vì vậy, xét từ hiệu quả tổng thể, việc cải thiện trải nghiệm của LN-Symmetry đối với 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 trước khi chúng tôi theo đuổi mục tiêu Phải đi.

Để hoàn thiện hơn nữa, bài viết này giới thiệu hướng đi của giai đoạn tiếp theo: UTXO dùng chung.

3.2 CoinPool: Giảm yêu cầu về tính tương tác và thanh khoản của các kênh nhiều bên

Đầu tiên one Bài báo 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 nhiều bên 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 nhiều bên, 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à liên lạc được mã hóa nhiều lần.

Sự đổi mới của CoinPool là nó sử dụng mô hình UTXO được chia sẻ để cho phép nhiều bên 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 thể hiện ở chỗ:

·Giảm đáng kể độ phức tạp tương tác của các kênh nhiều bên:Vì tất cả người tham gia đều có chung một UTXO Họ có thể đạt được sự đồng thuận bằng cách ký các bản cập nhật phiên bản của UTXO này mà không cần thực hiện nhiều giao dịch trực tuyến hoặc các tương tác ngoài chuỗi phức tạp. Sự đơn giản hóa này làm cho việc quản lý các 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: 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 chữ ký của nhiều bên xác nhận Một phiên bản nhất định của UTXO. Cách tiếp cận 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. mỗi người tham gia để duy trì đủ thanh khoản một cách độc lập. Trong thiết kế CoinPool hợp tác nhiều bên, nhu cầu thanh khoản có thể giảm đáng kể hoặc được phân bổ lại. Những người tham gia có thể tận dụng tính thanh khoản trong các UTXO được chia sẻ để hoàn tất thanh toán mà không cần phải khóa số tiền 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 nhiều bên 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 của hệ thống. tình dục và hiệu quả. 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 của nhiều bên, đồ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 của nhiều bên.

Tuy nhiên, tại sao cho đến nay giải pháp với những ưu điểm rõ ràng như vậy vẫn chưa được áp dụng trên diện rộng? 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 việc nâng cấp soft fork mà nó dựa vào đòi hỏi nhiều thứ đến mức trong đời chúng ta, họ có thể không nhìn thấy nó đổ bộ vào mạng Bitcoin. 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ên nó kế thừa nhu cầu về fork mềm trong cơ chế cập nhật trạng thái, cơ chế này yêu cầu Bitcoin phải nâng cấp để kích hoạt chế độ chữ ký mới SIGHASH_ANYPREVOUT (APO), nhưng như chúng ta đều biết, Bitcoin The Tiến độ nâng cấp soft fork chậm khiến cơ chế cập nhật trạng thái của CoinPool khó có thể dựa vào công nghệ có thể áp dụng trong thực tế.

3.3.2 UTXO dùng chung yêu cầu hợp đồng để đơn giản hóa cơ chế hoạt động

Như đã đề cập ở trên , Được chia sẻ Mỗi bản cập nhật trạng thái UTXO yêu cầu thu thập chữ ký chia sẻ một phiên bản UTXO nhất định. 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 cây Merkle. 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 cây Merkle, đó 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 khỏi Shared UTXO, quá đơn giản và khó có thể đoán trước rằng nó có thể vượt qua quá trình nâng cấp mạng Bitcoin thành công.

Trong số những đề xuất 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 cây Merkle, 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 một loạt UTXO ngoài chuỗi thông qua UTXO trên 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 phổ biến lớn nhất vì nó đơn giản và linh hoạt. Khả năng mạnh mẽ của CTV không chỉ có thể triển khai các ý tưởng như CoinPool mà Rollup còn có thể 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 mọi lúc 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à các mã opcode UTXO được chia sẻ để giúp triển khai cả hai điều này. 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 Nhóm Bitcoin: Nguyên tắc 2-AS chống chi tiêu kép ngoài chuỗi

Như đã đề cập ở trên Trong quá trình thảo luậ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 fork mềm để 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 giải pháp ngăn ngừa chi tiêu gấp đôi ngoài chuỗi mới không dựa vào nâng cấp soft fork của 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 (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ó tính chất 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ộ điều hợp

Chữ ký bộ điều hợp có một số bước cơ bản, chẳng hạn như Gen , PSign, PVrfy, Thích ứng, Trích xuất. 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ý bộ điều hợp từ góc độ sử dụng hơn là 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ữ khóa riêng 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ể trích xuấ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ộ chuyển đổi (khóa chung) (khóa riêng).

3.4.3 Sự kết hợp của cả hai: 2-AS

Chúng ta đã học về Thuộc tính chữ ký Schnorr và chữ ký Adaptor, 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ể được cắt ra 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 hình phạt, trong đó pubkey có thể mở khóa được là khóa chung 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.

· Các bên hợp tác 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 hai 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 phạt mỗi khi họ cập nhật trạng thái. Khóa công khai phạt của đầu ra phạt bao gồm hai cặp được xác định. trước. Khóa công khai được hình thành bằng cách thêm công nghệ chữ ký Schnorr.

Vì vậy, trước mỗi giao dịch, chúng tôi xác nhận cặp khóa công khai 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 khóa riêng tương ứng với đầu ra bị phạt thông qua hai 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 ngoà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 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. Mỗi khi chúng tôi chuyển quyền sở hữu một UTXO off-chain nhất định, chúng tôi sẽ sử dụng các Hệ thống như. Chữ ký ngăn chặn chi tiêu gấp đôi của 2-AS không thể tạo ra thay đổi trong thanh toán ngoài chuỗi, điều này khiến cho các kịch bản ứng dụng rất hạn chế.

Ngoài ra, ngay cả với cơ chế SharedUTXO dễ vận hành và cơ chế nguyên thủy chống chi tiêu gấp đôi ngoài chuỗi không yêu cầu fork mềm, chúng tôi vẫn cần mọi người cập nhật trực tuyến Xác nhận trạng thái mới của UTXO, ngay cả khi mỗi cập nhật trạng thái chỉ ảnh hưởng đến một nhóm nhỏ những người trong mạng ngoài chuỗi. 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 trên chuỗi. Và việc loại bỏ hoàn toàn nhu cầu về thanh khoản là điều không mong muốn. Các phương án thanh toán thiếu bôi trơn 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 là phi kênh và hỗ trợ mệnh giá động và dựa trên UTXO. Ethereum đã từ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. Để biết các nghiên cứu liên quan, vui lòng tham khảo bài viết 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:

1. Bôi trơn yêu cầu thanh khoản đảm bảo thanh toán mệnh giá năng động. (Thay đổi giao dịch): Điều này đòi hỏi phải duy trì thiết kế kênh đồng thời tránh 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 ngoài chuỗi, được chia sẻ UTXO Bản cập nhật phải được cập nhật thông qua cộng tác trực tuyến giữa 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á những giải pháp tối ưu hơn theo hướng này.

Kênh ảo và Nhà máy 3.5 kênh

Trong cuộc thảo luận trước, chúng tôi nhận ra rằng không chỉ Thiết kế của kênh cần được giữ nguyên và UTXO được chia sẻ cần mang lại cho chúng tôi lợi ích 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 các UTXO ngoài chuỗi được cam kết bởi các UTXO trên chuỗi được gọi là UTXO ảo. Nếu chúng tôi sử dụng UTXO ảo ngoài chuỗi làm FundingTx của kênh, chúng tôi sẽ có một khái niệm mới, đó là 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., việc mở rộng Lightning Network dường như có thể được giải quyết dễ dàng.

Nhưng sự thật có thực sự đẹp đẽ đến thế?

Do kế thừa đặc điểm của Shared UTXO nên nhà máy sản xuất kênh yêu cầu sự cộng 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 số này 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à sản xuất kênh liên quan đến nhiều bên đồ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ó thể ngăn người dùng khác đóng kênh và rút tiền thành công.

Và 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 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à thậm chí độ phức tạp triển khai của giải pháp này còn cao hơn LN-Panelty hiện tại.

3.6 ARK JoinPool và kênh tạm thời

Qua việc xem xét trường hợp trước đây về nhà máy sản xuất kênh, chúng tôi nhận được 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 sử dụng thiết kế kênh "LN-Panelty" cổ điển, nhưng đồng thời nên giữ lại những ưu điểm của việc giới thiệu kênh:

1. Mệnh giá năng động do tính thanh khoản mang lại;

2.

Dựa trên đó, một thiết kế 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 dành cho nhiều người Tiềm năng do việc mở rộng hợp tác ngoài chuỗi mang lại không đòi hỏi các thiết kế phức tạp và dễ bị lỗi như tí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 các 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à: 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 sẽ tham gia UTXO được chia sẻ đạ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 cần trực tuyến trong khi những người khác đang thực thi. Nghĩa là, 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 khóa riêng của người dùng trực tuyến để ký, còn có một lý do quan trọng khác khiến mỗi kênh Lightning Network chạy không bị gián đoạn. thành viên cần WatchTower liên tục theo dõi xem đối tác có giao dịch các cam kết bất lợi cho chính mình trên chuỗi hay không. Đ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 phải tự duy trì các nút

Trong classic LN -Trong thiết kế của Panelty, mỗi người dùng cần xây dựng WatchTower 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. Nếu có thì sẽ bị phạt. Trong một mô hình cũ như vậy, các đối tác của tất cả chúng ta đều là các nút Lightning ngang hàng và mỗi khi 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ý kết. Điều này là do lý tưởng nhất là VTXO off-chain 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 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 ngoài 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 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 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 thì chúng tôi cũng không làm như vậy với người dùng thông thường. không còn cần phải chạy các nút riêng để đảm bảo an ninh của chính họ.

Tóm tắt các giải pháp khác trong việc tối ưu hóa hoạt động của nút người dùng:

· Lightning Network Node Cloud lưu trữ

Một số giải pháp chọn chạy các 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 các 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ữ khóa riêng tư và các giao dịch đã cam kết đều quan trọng như nhau trong nhiều trường hợp. Do đó, chỉ sử dụng khóa riêng 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 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 của tôi có thể dễ dàng tải lên trạng thái có lợi cho giao dịch đó. Trong giải pháp lưu trữ nút đám mây Lightning Network như vậy, có nguy cơ thông đồng giữa nền tảng lưu trữ đám mây và đối tác.

· CRAB và Sleepy CRAB

Giao thức CRAB (Kênh chống hối lộ) đảm bảo các kênh thanh toán bằng cách thêm tài sản thế chấp bổ sung kết hợp với cơ chế khuyến khích người khai thác, đặ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 WatchtTower của bên thứ ba. Tuy nhiên, cơ chế tài sản 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 lưới ngoài chuỗi. Mặc dù tính bảo mật được đảm bảo nhưng tính 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 các nút nhưng nó chỉ làm giảm yêu cầu trực tuyến của người dùng.

3.6.3 Kênh tạm thời: người dùng không cần tự mình duy trì tính thanh khoản của kênh

Ai đó có thể đặt câu hỏi, tại sao nhà cung cấp dịch vụ ASP 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 vào một địa chỉ có nhiều chữ ký với nhà điều hành, 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 cho mọi giao dịch ngoài chuỗi, nhưng sẽ chuyển số tiền mà họ đã ký với nhà điều hành trước đó.

Lý do kênh của ARK được gọi là kênh tạm thời là vì nó có tính đơn hướng và bơm vốn một lần mạnh> Hai đặc điểm.

· 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.

· Cấp vốn một lần: Kênh của ARK chỉ yêu cầu cấp 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ì tính 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 tính thanh khoản của kênh mà các nhà cung cấp thanh khoản cũng không cần duy trì tính 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

Căn cứ vào những điều trên chúng ta có thể thấy rõ Nó có thể thấy thiết kế của ARK Protocol đã đạt được tiến bộ vượt bậ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ì các nút

· p>

· Người dùng không cần tự mình duy trì tính thanh khoản của kênh và không có vấn đề về thanh khoản trong tài khoản

· Hỗ trợ tương tác không đồng bộ, không cần cả hai bên phải trực tuyến cùng lúc

4 . Những thay đổi trong mô hình mở rộng vốn có của Bitcoin

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 đề về 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 sự ra đời của nhà điều hành 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ở vật chất 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 các nút trong suốt quá trình 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 chuyển từ người dùng sang nhà điều hành

Theo kiểu cổ điển Trong Mô hình LN-Penalty 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

Mới Các thiết kế giao thức đ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 tính 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 rằng quản lý thanh khoản là bản chất của việc mở rộng và phát triển chuỗi gốc của Bitcoin, đồng thời nó cũng là chủ đề cốt lõi cho sự phát triển liên tục 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 liên tục của các giải pháp mới, con đường mở rộng ngoài chuỗi của Bitcoin chắc chắn sẽ mở ra một 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.

Tài liệu tham khảo:

· Poon, J., Dryja, T. (2016) Mạng Lightning Bitcoin: Có thể mở rộng ngoài chuỗi. Thanh toán tức thì được lấy từ https://lightning.network/lightning-network-paper.pdf

· Decker, C., Russell, R., Osuntokun, O. (n.d.). Giao thức Layer2 đơn giản cho Bitcoin. Truy xuất từ https://blockstream.com/eltoo.pdf

· Naumenko, G., Riard, A. (n.d.: Thanh toán ngoài chuỗi hiệu quả). Nhóm dành cho Bitcoin. Được lấy từ https://coinpool.dev/v0.1.pdf

· Tóm tắt dự án LN-Symmetry. t/ln-symmetry-project-recap/359

· Riahi, S., Litos, O. S. T. (2024). Nhóm Bitcoin: Thanh toán ngoài chuỗi không có kênh bằng cách sử dụng Chữ ký bộ điều hợp hai lần. Lưu trữ ePrint, Báo cáo 2024/025.

· Được lấy từ https://eprint.iacr.org/2024/025Dziembowski, S., Fabiański, G., Faust, S., Riahi, S . (2020). 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 Kho lưu trữ ePrint mật mã, Báo cáo 2020/175.

· Được lấy từ https://eprint.iacr.org/2020/175ARK. Blog Mạng (n.d.). Được lấy từ https://github.com/ark-network/arkdev.info/tree/master/blog

· Somsen, R. (n.d. Giải thích về Ark đơn giản nhất được lấy ra). từ https://Gist.github.com/RubenSomsen/a394beb1dea9e47e981216768e007454?permalink_comment_id=4633382

· BRQGoo. /introducing-ark-6f87ae45e272

· JohnLaw2. ing Covenants. Kho lưu trữ GitHub được lấy từ https://github.com/JohnLaw2/ln-scaling-covenants

· JohnLaw2. (n.d.. Được tối ưu hóa tại nhà máy GitHub). .com/JohnLaw2/ln-factory-optimized

· Shinobi. (n.d.). Cây hết thời gian: Giải pháp mở rộng các LSP của Lightning Network. timeout-trees-a-solution-to-scaling-lightning-network-lsps

· Rubin, J ., O'Beirne, J. (2020: Đề xuất cải tiến Bitcoin CHECKTEMPLATEVERIFY. Được lấy từ https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki

· Đen, B. (2023) Kết hợp CTV+APO với . Danh sách gửi thư TXHASH+CSFS tối thiểu. Được lấy từ https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ 2023-August/021907.html

· Aumayr, L., Avarikioti, Z., Maffei, M., Mazumdar, S. (2021). Kênh buồn ngủ: Kênh thanh toán hai chiều tương thích với Bitcoin không yêu cầu giám sát. · Được lấy từ https://eprint.iacr.org/2021/1445Aumayr, L., Avarikioti, Z., Maffei, M., Mazumdar, S. (2024). Báo cáo 2024/826. Được lấy từ https://eprint.iacr.org/2024/826.pdf

· Todd, P. (2024). Đánh giá lớp 2 phụ thuộc vào giao ước. /petertodd.org/2024/covenant-depend-layer-2-review

Liên kết gốc