Ark như một nhà máy trung gian: tối ưu hóa quản lý thanh khoản để cải thiện tính khả thi của thanh toán.

Bài viết này được dịch máy
Xem bản gốc

Tác giả: Pickhardt

Nguồn: https://delvingbitcoin.org/t/ark-as-a-channel-factory-compressed-liquidity-management-for-improved-payment-feasibility/2179

Tôi đã thảo luận các ý tưởng trong bài viết này trong nhiều cuộc trò chuyện song phương trong vài tháng qua. Để tránh lặp lại những tuyên bố không mạch lạc và để khuyến khích thêm phản hồi, tôi đã viết chúng ra đây. Tôi xin lỗi những độc giả đã quen thuộc với các khái niệm này và hoan nghênh các ý kiến ​​đóng góp, phản biện và câu hỏi mở.

Lưu ý: Vì tiếng mẹ đẻ của tôi không phải là tiếng Anh, tôi đã sử dụng mô hình ngôn ngữ lớn (LLM) để trau chuốt bài viết; trong đó, nội dung kỹ thuật và lập luận là của riêng tôi. Khi hướng dẫn sử dụng LLM, tôi không đi chệch khỏi định dạng và phong cách ngôn ngữ chuẩn.

bản tóm tắt

Mạng Lightning hỗ trợ thanh toán Bitcoin nhanh chóng, không cần lưu giữ, miễn là có đủ thanh khoản dọc theo đường dẫn của dòng thanh toán (thường chỉ có một đường dẫn). Tuy nhiên, tính khả thi của thanh toán (sự tồn tại của dòng thanh toán như vậy) là một ràng buộc cấu trúc không thể giải quyết đơn giản bằng cách phân tích định tuyến theo kinh nghiệm hoặc cân bằng lại ngoài Chuỗi. Khi thanh khoản không đủ, các giao dịch trong Chuỗi phải được gửi để sửa đổi biểu đồ kênh , điều này về cơ bản hạn chế khả năng mở rộng thông lượng thanh toán Bitcoin của Mạng Lightning.

Mặc dù các kênh bên long được biết đến là giúp cải thiện hiệu quả sử dụng vốn, việc phối hợp trong thực tế lại rất khó khăn. Ark đề xuất một cơ chế để phối hợp cập nhật trạng thái giữa bên long bên theo từng vòng, cho phép các thành viên đạt được sự đồng thuận về một trạng thái mới với chi phí phối hợp tương đối thấp. Bài báo này thách thức quan điểm phổ biến cho rằng Ark chủ yếu nên hoạt động như một hệ thống thanh toán "chặng cuối", kết nối với nhau thông qua các Kênh Lightning. Thay vào đó, bài báo này lập luận rằng có thể hiểu Ark như là cơ sở hạ tầng của Mạng Lightning , đặc biệt là như một " nhà máy kênh " cho phép phân bổ lại thanh khoản hiệu quả. Bài báo này tập trung vào các sự đánh đổi, các ràng buộc về tính khả thi và các câu hỏi nghiên cứu mở.

Lưu ý quan trọng : Bài viết này không phản đối việc sử dụng Ark cho thanh toán một cách rõ ràng, mà chỉ đơn thuần tìm hiểu xem liệu có những kịch bản ứng dụng nào tốt hơn hay không.

1. Xem xét tính khả thi của việc thanh toán và những hạn chế về cấu trúc của Mạng Lightning.

Một giao dịch thanh toán nhanh chóng chỉ khả thi khi mức chênh lệch tối thiểu giữa người gửi và người nhận trong biểu đồ thanh khoản vượt quá số tiền cần thanh toán. Trên thực tế, việc xác định tính khả thi rất khó khăn do sự không chắc chắn về số dư kênh ở đầu bên kia . Sự không chắc chắn này có thể được giảm thiểu bằng cách sử dụng định tuyến xác suất và các luồng thanh toán tối ưu đáng tin cậy .

Tuy nhiên, ngay cả khi việc tối ưu hóa tuyến đường, cập nhật phí và cân bằng lại có thể cải thiện hiệu quả sử dụng, chúng cũng không thể thay đổi tính khả thi tổng thể của việc thanh toán trừ khi chính biểu đồ kênh được thay đổi.

Đặc biệt:

  • Công nghệ tái cân bằng ngoài Chuỗi có thể phân phối lại thanh khoản trong các kênh hiện có.
  • không tạo ra khả năng kết nối hoặc định hướng mới.
  • Khi không có luồng thanh toán khả thi nào tồn tại, cần phải khởi tạo một giao dịch trong chuỗi (mở kênh, đóng kênh, nối các kênh, v.v.).

Sự khác biệt này rất quan trọng. Ngay cả khi một nút có thể chuyển thanh khoản từ kênh này sang kênh khác (thông qua thanh toán vòng lặp), thao tác đó chỉ ảnh hưởng đến kênh ở xa và do đó không làm tăng cụ thể tính khả thi của khoản thanh toán mong muốn. Cách duy nhất để thay đổi tính khả thi cục bộ mà không ảnh hưởng đến phần còn lại của mạng là thông qua các giao dịch Chuỗi.

Phân tích chính thức trong " Lý thuyết toán học về mạng lưới kênh thanh toán " chứng minh rằng tỷ lệ thanh toán tối đa được hỗ trợ phụ thuộc rất nhiều vào:

  • Băng thông khả dụng cố định trong Chuỗi và
  • Tỷ lệ dự kiến ​​của các khoản thanh toán không khả thi.

Điều này đặt ra những hạn chế nghiêm trọng đối với mạng lưới kênh thanh toán hai bên, và trong những giả định thực tế, tỷ lệ thanh toán không khả thi dự kiến ​​có thể trở nên cực kỳ cao nếu không có sự hỗ trợ băng thông liên tục Chuỗi. Hạn chế này thúc đẩy việc nghiên cứu các cơ chế phối hợp để tái cấu trúc đồ thị mạng lưới thanh toán với dung lượng trên Chuỗi nhỏ hơn.

2. Ark: UTXO theo lượt và ảo

Ark giới thiệu khái niệm " vòng ": những người tham gia trong cùng một vòng trao đổi " UTO ảo (vTXO)" dưới sự điều phối của Nhà cung cấp dịch vụ Ark (ASP). Các vTXO này đại diện cho các cam kết giá trị ngoài Chuỗi có thể được phân phối lại trong một khoảng thời gian.

Có vẻ như hệ thống kiểu Ark làm giảm yêu cầu về phối hợp và tương tác trực tuyến của nhóm tiền điện tử bằng cách giới thiệu một ASP (Alternate Exchange Service) làm điều phối viên; ASP cung cấp thanh khoản dư thừa trong một khung thời gian cố định, do đó loại bỏ nhu cầu mọi người phải ngay lập tức đồng ý về mọi trạng thái mới, chỉ cần sự đồng thuận cuối cùng. Đây là một đặc tính rất đáng mong muốn.

Tuy nhiên, khi Ark được sử dụng trực tiếp như một hệ thống thanh toán, ba đặc tính sau của nó không thể bị bỏ qua:

  1. Khóa thanh khoản do cơ chế hết hạn : vTXO có cơ chế hết hạn, trong đó tiền ASP bị khóa cho đến khi hết hạn.
  2. Sự khuếch đại của sự thay đổi : Các khoản thanh toán thường bao gồm đốt một đầu vào và tạo ra nhiều đầu ra (biên lai và tiền thừa), điều này làm tăng lượng thanh khoản(ASP) phải ứng trước.
  3. Yếu tố tin cậy trong quyết toán giữa các vòng : Các khoản thanh toán chỉ có thể được quyết toán tại ranh giới giữa các vòng. Giữa hai vòng, vTXO đã sử dụng về mặt lý thuyết có thể được sử dụng lại, điều này đặt ra câu hỏi về cách hiểu tuân thủ đối nhân vật của máy chủ lưu trữ và ASP.

Nếu vTXO thường xuyên được thanh toán trước khi đáo hạn, vốn hoạt động cần thiết cho ASP có thể tăng trưởng đáng kể (so với các khoản thanh toán ròng) . Điều này làm phức tạp lập luận rằng Ark có thể tự cung cấp một lớp thanh toán có chi phí thấp và mở rộng.

3. Hãy xem Ark như một nhà máy sản xuất kênh và là cơ sở hạ tầng của Mạng Lightning.

Một cách hiểu khác là không xem Ark như một hệ thống thanh toán cạnh tranh với Lightning Network, mà là cơ sở hạ tầng nằm bên dưới Lightning Network . Cụ thể hơn, nó có thể được hiểu như một nhà máy kênh, hay bên long kênh .

Dựa trên sự hiểu biết này:

  • vTXO tương ứng với kênh Lightning.
  • Một vòng chơi Ark có thể tự động mở, đóng và định hình lại nhiều kênh.
  • Một giao dịch nội Chuỗi duy nhất có thể tái tạo lại một phần lớn đồ thị kênh .

Điều này khác biệt về cơ bản so với định tuyến và cân bằng lại (Chuỗi). Thay vì tối ưu hóa luồng thanh toán trong một đồ thị cố định, nó tạo ra sự thay đổi cấu trúc trong chính đồ thị đó, điều này có thể giúp các khoản thanh toán trước đây không khả thi trở nên khả thi.

Nhiều thao tác kênh—cấp vốn, đóng kênh và ghép kênh—đều có thể được nén vào một giao dịch vòng Ark duy nhất. Vì Mạng Lightning đã yêu cầu xác nhận Chuỗi cho những thay đổi như vậy, Ark sẽ không làm trầm trọng thêm độ trễ, vì các vòng Ark cuối cùng có thể diễn ra trong mỗi khối.

4. Phân bổ lại thanh khoản và các yếu tố vận hành

Các nhà điều hành mạng Lightning Network hiện đã cần:

  • Kênh giám sát
  • Phản hồi các sự kiện trong Chuỗi,
  • Thỉnh thoảng cần cân bằng lại hoặc tắt kênh.

Việc xoay vòng vTXO trong các vòng Ark (ví dụ: lần mỗi tháng) về mặt vận hành là tương tự. Các kênh có mức sử dụng cao hơn có thể yêu cầu xoay vòng thường xuyên hơn, và việc này có thể được phối hợp trong khi kênh vẫn đang được sử dụng tích cực.

Các giả định về sự cố khác nhau về chi tiết nhưng giống nhau về bản chất: người vận hành cần tham gia định kì, thay vì giám sát liên tục.

5. Các quỹ thanh khoản và phân bổ động

Trong một nhà máy kênh (hoặc bên long kênh):

  • Thanh khoản sẽ được hình thành trong một quỹ chung giữa các bên tham gia.
  • Kích thước của mỗi bể bơi có thể được điều chỉnh theo từng vòng.
  • Nhu cầu có thể được dự đoán hoặc đáp ứng một cách linh hoạt.

Điều này hoàn toàn trái ngược với mô hình LSP hiện tại: trong mô hình LSP, thanh khoản được cung cấp trên cơ sở từng người dùng và thường bị giữ ở trạng thái nhàn rỗi hoặc phân bổ không đồng đều.

Việc gộp chung có thể cải thiện hiệu quả sử dụng vốn—đặc biệt (nhưng không giới hạn) máy trạm di động—và điều này cũng áp dụng cho Ark, mặc dù nó mang đến một số đánh đổi, bao gồm các sự kiện hết hạn, chi phí điều phối và quản lý thanh khoản ASP. Việc xác định các tham số thời gian chờ tối ưu (cho phép ASP lĩnh nhận vTXO) vẫn là một câu hỏi chưa có lời giải.

6. Tích hợp với Lightning Network và các vấn đề cần xem xét khi lưu trữ

Khi Ark được sử dụng như một cơ sở hạ tầng:

  • Việc thanh toán diễn ra trong Kênh/Mạng Lightning.
  • Quyết toán vẫn mang tính chất nguyên tử và khép kín.
  • Các ASP điều phối thanh khoản nhưng không đóng vai trò trung gian trong các giao dịch thanh toán.

Điều này giúp duy trì các đặc tính quyết toán tức thời, không cần quản lý của Lightning Channel. Ngược lại, việc sử dụng Ark trực tiếp trong thanh toán sẽ tạo ra các giả định về sự tin tưởng giữa các vòng giao dịch.

Mỗi thành phần đều có chức năng riêng—Lightning Channels được sử dụng cho thanh toán, và Ark được sử dụng để điều phối thanh khoản—duy trì các đảm bảo cốt lõi của Lightning Network, chẳng hạn như quyết toán toán tức thời và bảo mật mạnh mẽ, đồng thời giải quyết các hạn chế mở rộng cấu trúc.

7. Các vấn đề về định tuyến, tin đồn và tính cởi mở

Kênh cấp vốn thông qua vTXO thiếu các giao dịch cấp vốn Chuỗi, do đó hiện tại không thể công khai thông tin này thông qua mạng Lightning Network gossip. Điều này đặt ra một số câu hỏi chưa được giải đáp:

  • Kênh này nên được hiển thị cho bộ định tuyến như thế nào?
  • Việc định tuyến có nên được thực hiện ở cấp độ nhà máy không?
  • Liệu "quảng cáo thanh khoản" có cần một khái niệm trừu tượng mới?
  • Các cơ chế này sẽ ảnh hưởng như thế nào đến quyền riêng tư và độ tin cậy?
  • Liệu các kênh dựa trên vTXO chỉ nên tồn tại giữa ASP và người dùng? Hay chúng có thể tồn tại trực tiếp giữa người dùng với nhau?

8. Các vấn đề về tính mở rộng

Việc xem Ark như là cơ sở hạ tầng của Mạng Lightning, thay vì một hệ thống thanh toán độc lập, làm rõ một số sự đánh đổi, nhưng cũng đặt ra một số câu hỏi mở khác đáng để tìm hiểu thêm:

  • Khích lệ và hành vi của ASP : Làm thế nào để điều chỉnh khích lệ sao cho các quyết định quản lý thanh khoản của ASP cải thiện tính khả thi của thanh toán ở cấp độ Mạng Lightning, thay vì chỉ lợi nhuận cục bộ? Sự cạnh tranh giữa nhiều ASP sẽ ảnh hưởng như thế nào đến việc phân bổ thanh khoản và định giá?
  • Áp lực tập trung hóa : Việc gộp thanh khoản trong cấu trúc bên long có mang lại lợi thế kinh tế theo quy mô cho một số ít nhà máy quy mô lớn hay không? Điều này so với tác động của các trung tâm thanh toán và nhà cung cấp dịch vụ thanh toán (LSP) hiện có trong Mạng Lightning như thế nào?
  • Các Chế Độ Thất Bại và Giải Pháp Thoát : Dựa trên bài viết của Peter Todd trên Layer 2 ( bản dịch tiếng Trung ): Hậu quả Chuỗi của một sự cố ASP (hoặc việc thoát quy mô lớn) là gì? Làm thế nào để giảm tải cho hệ thống một cách nhẹ nhàng? Và, trong trường hợp xấu nhất, chi phí cho các hoạt động Chuỗi là bao nhiêu?
  • Độ trễ và tính khả thi : Ark hỗ trợ cấu hình lại hệ thống, nhưng chỉ một lần mỗi vòng. Tần suất vòng và thời gian hết hạn nên được lựa chọn như thế nào để cân bằng giữa tính khả thi thanh toán, hiệu quả vốn và trải nghiệm người dùng?
  • Vấn đề về quyền riêng tư : Liệu các cơ chế phối hợp theo vòng có dần dần làm rò rỉ thông tin về mô hình nhu cầu hoặc hoạt động của người dùng? So sánh giữa các tập hợp nặc danh và các kênh Lightning hai chiều thì như thế nào?
  • Khả năng tương tác và trừu tượng hóa định tuyến : Kênh cấp vốn vTXO nên được biểu diễn như thế nào cho bộ định tuyến (khi biết rằng nó không có giao dịch cấp vốn Chuỗi )? Có cần một thông điệp gossip mới hay một sự trừu tượng hóa ở cấp độ nhà máy không?

Những vấn đề này không chỉ riêng Ark gặp phải; mà chúng là những câu hỏi sẽ tự nhiên nảy sinh bất cứ khi nào một cơ chế điều phối thanh khoản bên long xuất hiện. Giải quyết chúng là điều cơ bản để hiểu được cách thức một cơ chế như vậy bổ sung cho Mạng Lightning.

Tham khảo

  1. Pickhardt et al., Về sự không chắc chắn của số dư kênh mạng Lightning [ 2103.08576] Bảo mật và quyền riêng tư của các khoản thanh toán mạng Lightning với số dư kênh không chắc chắn
  2. Pickhardt & Richter, Luồng thanh toán đáng tin cậy tối ưu trên Mạng Lightning [ 2107.05322] Luồng thanh toán đáng tin cậy và rẻ tối ưu trên Mạng Lightning
  3. Pickhardt, Lý thuyết toán học về mạng lưới kênh thanh toán (bản nháp) [Lightning-Network-Limitations/Limits of two party channels/paper/a mathematical theory of payment channel networks.pdf tại f670738cd2af93a55c3c919c9a864015f6dd042a · renepickhardt/Lightning-Network-Limitations · GitHub]( https://github.com/renepickhardt/Lightning-Network-Limitations/blob/f670738cd2af93a55c3c919c9a864015f6dd042a/Limits of two party channels/paper/a mathematical theory of payment channel networks.pdf)
  4. Pickhardt: Ark xử lý thanh toán Bitcoin tốt đến mức nào? https://bitcoin.stackexchange.com/questions/128113/how-well-does-ark-scale-bitcoin-payments 5 Todd, Đánh giá Layer 2 phụ thuộc vào Covenant: Đánh giá Soft-Fork/ Layer 2 phụ thuộc vào Covenant .
  5. Buổi nói chuyện của BTC++ về khả năng mở rộng và những hạn chế của Lightning Network : https://www.youtube.com/watch?v=c3AuaHJordg
  6. Bitcoin Amsterdam LN vs Ark panel (2025) https://www.youtube.com/watch?v=AU52kQz2zIM

Lời cảm ơn

Các cuộc thảo luận và phản hồi từ nhiều bạn bè trên BTC++ và Bitcoin Amsterdam đã giúp tôi làm rõ những lập luận này. Nghiên cứu này được tài trợ bởi Optensats và Patreons.

Nguồn
Tuyên bố từ chối trách nhiệm: Nội dung trên chỉ là ý kiến của tác giả, không đại diện cho bất kỳ lập trường nào của Followin, không nhằm mục đích và sẽ không được hiểu hay hiểu là lời khuyên đầu tư từ Followin.
Thích
Thêm vào Yêu thích
Bình luận