Ghi chú và tóm tắt về hội nghị nhà phát triển Lightning Network năm 2024

Tác giả: roasbeef

Nguồn: https://delvingbitcoin.org/t/ln-summit-2024-notes-summary-commentary/1198

Khoảng 3 tuần trước, hơn 30 nhà phát triển và nhà nghiên cứu của Lightning Network đã tập trung tại Tokyo, Nhật Bản và thảo luận nhiều điều về hiện trạng và tương lai của giao thức Lightning Network (và các giao thức Bitcoin P2P và giao thức đồng thuận liên quan) trong ba ngày. các vấn đề liên quan đến phát triển.

Trước đó, hội nghị cuối cùng như vậy đã diễn ra tại Oakland, California, Hoa Kỳ vào tháng 6 năm 2022: LN Summit 2022 Notes & Summary/Commentary . Bạn có thể tìm thấy bản tóm tắt sơ bộ về các ghi chú của hội nghị tại đây: LN Summit Oakland 2022 - Google Docs .

Bạn có thể tìm thấy bản viết tắt của tôi cho Hội nghị nhà phát triển Lightning lần tại đây: Lightning Summit Tokyo - 2024 - Google Docs . Và bạn có thể tìm thấy lịch trình đã thống nhất của chúng tôi về các chủ đề hàng ngày tại đây: Lightning Summit.md · GitHub .

Điều đáng nói là có nhiều cuộc thảo luận nhóm không xuất hiện trong ghi chú của tôi (mặc dù tôi đã cố gắng hết sức), cũng như không được phản ánh trong lịch trình trên.

Đã nói tất cả những điều đó, đây là nỗ lực của tôi để tóm tắt các chủ đề và kết luận thảo luận chính (cùng với một số nhận xét). Nếu những người tham dự tìm thấy bất kỳ sự thiếu chính xác hoặc thiếu sót nào trong bản tóm tắt của tôi về các cuộc thảo luận và quyết định diễn ra trong ba ngày, vui lòng phản hồi và điền vào chỗ trống.

Còn giao dịch chuyển tiếp gói hàng và giao dịch cam kết V3 thì sao?

Đây là chủ đề thảo luận lớn đầu tiên của chúng tôi và diễn ra sau khi phát hành ứng cử viên phát hành mới nhất cho Bitcoin Core 28.0 (tại thời điểm viết bài, đã được phát hành).

Dự toán phí và các cam kết cơ bản

Trước khi chuyển sang thiết kế giao dịch cam kết mới nhất và tuyệt vời nhất được đề xuất cho đến nay, tôi muốn phác thảo ngắn gọn cách thức hoạt động của thiết kế giao dịch cam kết ngày nay và những thiếu sót của nó nằm ở đâu.

(Nếu bạn đã biết cách thức hoạt động của các giao dịch cam kết trong kênh Lightning hiện tại thì có thể bỏ qua phần này)

Một khía cạnh quan trọng trong thiết kế của Lightning Network là khái niệm “thoát đơn phương”. Bất cứ lúc nào, một trong hai bên phải có khả năng buộc phải thoát khỏi kênh và lấy lại tiền sau khi bị trì hoãn. Sự chậm trễ này là cần thiết vì một bên có thể lừa gạt đối thủ bằng cách xuất bản trạng thái cũ, bị thu hồi lên Chuỗi. Khoảng thời gian này cho phép một bên trung thực từ chối yêu cầu cấp vốn của đối thủ bằng cách chứng minh rằng họ biết một giá trị bí mật sẽ chỉ được tiết lộ khi một trạng thái nhất định bị thu hồi.

Khả năng đơn phương rút khỏi kênh này cũng là một mô-đun chính cần thiết để thực thi việc thực hiện hợp đồng HTLC; hợp đồng HTLC thực hiện chức năng "lấy đi hoặc hoàn lại tiền", giúp thanh toán qua Lightning Network nhiều bước có thể thực hiện được. Các hợp đồng này đi kèm với một mô-đun độ trễ khác: độ trễ được xác định bởi các điểm thời gian tuyệt đối (khóa thời gian tuyệt đối). Trên đường chuyển tiếp thanh toán trong Lightning Network, mỗi bước nhảy có một khoảng thời gian gồm các khối T (chênh lệch khóa thời gian của CLTV) để xác nhận các giao dịch đã cam kết của họ và để hết thời gian HTLC không thể quyết toán trong một thời gian dài. Nếu các giao dịch đã cam kết này không thể được xác nhận kịp thời, họ sẽ có rủi ro mất tiền do “đơn phương mua lại” vì HTLC được ghi lại sau đó sẽ hết thời gian chờ, tạo ra một cuộc đua hết thời gian chờ/mua lại.

(Lưu ý của người dịch: Khi chuyển tiếp thanh toán, một nút sẽ nhận được "HTLC đến" từ nút trước đó và cung cấp "HTLC gửi đi" cho nút tiếp theo của nó. Khi nút hạ lưu không cho phép thanh toán Nếu nó không thành công và không trả lại bản gốc hình ảnh, nó chỉ trì hoãn. Cách duy nhất cho nút là nhận giao dịch đã cam kết được xác nhận bởi khối và truy xuất giá trị của HTLC gửi đi trên Chuỗi. Tuy nhiên, HTLC đến cũng có thời gian hết hạn sau khi HTLC đến hết hạn. ., nút hạ lưu sử dụng hình ảnh gốc để lĩnh nhận giá trị trong HTLC gửi đi (tham gia vào cuộc đua tính nút ), điều này sẽ dẫn đến việc nút gửi đi bị lỗ ròng. HTLC phải được khối xác nhận trước khi HTLC đến hết thời gian loại cuộc đua/mất ròng).

Khả năng nút thực hiện các giao dịch đã cam kết (trong trường hợp đơn phương thoát) nhận được xác nhận kịp thời phụ thuộc vào khả năng đưa ra dự đoán phí hiệu quả của chúng. Nếu giao dịch cam kết (không thể được sửa đổi đơn phương) có phí xử lý không đủ, thì giao dịch đó sẽ không được xác nhận kịp thời (thậm chí nó sẽ không được nhóm giao dịch của nút chấp nhận!). Hiện tại, người khởi tạo kênh có thể gửi tin nhắn update_fee cho đối tác để tăng (hoặc giảm) phí xử lý cho giao dịch cam kết mới nhất. Đây là một công cụ quan trọng nhưng nó buộc người khởi tạo phải sẵn sàng trả mức phí cao hơn đáng kể cho các giao dịch đã cam kết (để đảm bảo rằng chúng sẽ luôn được xác nhận trong khối tiếp theo sau khi giao dịch được phát sóng) hoặc phải mất nhiều thời gian để dự đoán. Tỷ lệ xử lý trong tương lai. Vì người khởi xướng phải thanh toán toàn bộ phí xử lý cho giao dịch đã cam kết nên người phản hồi không thể ảnh hưởng trực tiếp đến khoản phí xử lý này. Ngược lại, hiện tại, nếu họ không chấp nhận mức phí xử lý này thì họ chỉ có thể cố gắng cưỡng bức đóng kênh. .

Đầu ra điểm neo ở đây!

Để giải quyết một số thiếu sót của hình thức giao dịch cam kết hiện tại, "đầu ra neo" [ 1 ] đã được đề xuất. Ý tưởng chung là cả hai bên có thể nhận được đầu ra có mệnh giá nhỏ trong giao dịch cam kết, số tiền này chỉ có thể được chi tiêu bởi một bên (bên kia không thể chi tiêu); sản lượng bụi này cho phép phí xử lý bổ sung cho giao dịch cam kết sau đó. Thiết kế này nới lỏng yêu cầu về phí ước tính nhưng không loại bỏ hoàn toàn nhu cầu. Bây giờ, mục tiêu không còn là giao dịch đã cam kết được xác nhận trong khối tiếp theo nữa mà là có mức phí đủ cao để vào nhóm giao dịch của nút. Sau khi giao dịch vào nhóm giao dịch, cả hai bên có thể thêm phí xử lý và cuối cùng xác nhận giao dịch đã cam kết. Hơn nữa, bằng cách này, chúng tôi cũng có thể kết hợp các giao dịch HTLC hai giai đoạn lại với nhau để đạt được mức độ xử lý hàng loạt cao hơn khi thanh toán các hợp đồng HTLC quyết toán. Tuy nhiên, phí xử lý cần thiết để vào nhóm giao dịch, tương tự như phí xử lý cần thiết để vào khối tiếp theo, liên tục thay đổi. Do nút có giới hạn trên mặc định của không gian nhóm giao dịch là khoảng 300 MB, nên khi số lượng giao dịch đến tăng dần, nút cũng sẽ bắt đầu từ bỏ một số giao dịch có tỷ giá thấp nhất, do đó sẽ tăng ngưỡng phí để vào nhóm giao dịch. . Cuối cùng, phí xử lý tối đa mà giao dịch cố định hiện tại có thể đưa ra có thể không đủ để vào nhóm giao dịch. Tại thời điểm này, giao dịch đã cam kết cũng sẽ bị nút bỏ qua. Tại thời điểm này, nút muốn giao dịch được xác nhận không thể phát sóng giao dịch đã cam kết của mình (sử dụng mạng P2P hiện có), điều đó có nghĩa là TA có thể không xác nhận kịp thời (hoặc thậm chí hoàn toàn không thể xác nhận nó), vì vậy cuộc đua không thể tránh khỏi.

Theo con đường này, các nhà phát triển và nhà nghiên cứu đã phát hiện ra sê-ri cơ chế tinh vi liên quan đến việc phát sóng giao dịch và thực sự cho phép kẻ thù "đóng đinh" một giao dịch trong nhóm giao dịch (cố tình ngăn chặn nó được xác nhận) chiến lược chuyển tiếp nhóm giao dịch . . Nhiều giao diện tấn công đóng đinh đã biết khác nhau khai thác các điểm thoái hóa liên quan đến BIP 125 và chiến lược tổng hợp giao dịch được sử dụng rộng rãi ngày nay (giới hạn giao dịch nhiều tổ tiên).

V3, TRUC và 1P1C sắp ra mắt (lần này)!

Tiếp theo là “Giao dịch V3” và “Cấu trúc liên kết bị hạn chế cho đến khi xác nhận khối (TRUC)”. Ước mơ cuối cùng của các nhà phát triển Lightning Network là loại bỏ hoàn toàn update_fee và thực hiện các giao dịch đã cam kết mà không mất phí . Điều này giúp loại bỏ mọi phỏng đoán khi cố gắng tìm ra mức phí cần thiết. Tuy nhiên, nếu bạn làm điều này một mình, hậu quả của việc hứa rằng giao dịch không mất phí là nó sẽ không được nhóm giao dịch chấp nhận và do đó sẽ không được phổ biến trong mạng Bitcoin P2P.

Sự kết hợp giữa TRUC (tức là BIP 434) (một loại đầu ra neo mới) và chiến lược chuyển tiếp gói giao dịch "lạc quan 1 cha mẹ 1 con" đã trở thành giải pháp được biết đến nhiều nhất hiện nay và có thể giải quyết một cách thực tế các vấn đề hiện tại của Giao dịch Lightning Network. vấn đề chuyển tiếp và xác nhận.

TRUC giới thiệu một bộ quy tắc thay thế giao dịch mới nhằm giải quyết sự xuống cấp của BIP 125 trong một số ít trường hợp. Ngoài ra, nó bổ sung thêm một tập hợp mới các ràng buộc về kích thước cấu trúc liên kết giao dịch để hạn chế hơn nữa vấn đề. Các giao dịch TRUC sử dụng giá trị trường số phiên bản 3 (chứ không phải trường chuỗi như BIP 125) để chỉ ra rằng giao dịch tự nguyện sử dụng bộ quy tắc mới này.

Cũng trong Bitcoin Core 28.0, loại tập lệnh khóa công khai tiêu chuẩn mới "PayToAnchor (P2A)" đã có sẵn [ 2 ]. P2A là đầu ra Segwit v1 đặc biệt mới ( OP_1 <0x4e37> ), dành cho việc bổ sung phí CPFP. Đầu vào dành cho đầu ra này phải có đầu vào chứng kiến ​​trống và có thể được sử dụng mà không cần chữ ký. Các phiên bản trong tương lai của loại đầu ra mới này cuối cùng có thể cho phép các đầu ra biến thành bụi miễn là chúng được sử dụng trong cùng khối mà chúng được tạo ra (thông qua CPFP).

mô-đun cuối cùng được thiết kế trong bộ định dạng giao dịch cam kết mới này là: chuyển tiếp gói giao dịch 1 cha 1 con (1P1C) [ 4 ]. 1P1C về cơ bản là chuyển tiếp gói cơ hội. Thay vì dựa vào tin nhắn P2P mới (có thể mất thời gian để triển khai trên toàn bộ mạng), nó cho phép nút thay đổi hành vi khi chúng nhận được một giao dịch mồ côi (một giao dịch chưa biết giao dịch đầu vào của nó). Nút sẽ không lưu trữ giao dịch con này trong nhóm giao dịch mồ côi, nhưng sẽ cố gắng yêu cầu giao dịch gốc một cách có chọn lọc nút đã báo cáo giao dịch con, ngay cả khi phí giao dịch gốc thấp hơn ngưỡng phí của nhóm giao dịch cục bộ.

Về mặt phối hợp, ba nguyên tắc chuyển tiếp giao dịch mới này có thể được sử dụng để thiết kế lại định dạng giao dịch cam kết của Lightning Channel (tức là neo) nhằm giải quyết nhiều vấn đề tồn tại lâu dài được đề cập ở trên. t-bast đã bắt đầu tạo mẫu một định dạng giao dịch cam kết mới: x.com .

Tuy nhiên, vẫn còn một số vấn đề chưa được giải quyết, bao gồm:

• Xử lý bụi phát sinh từ các giao dịch đã cam kết như thế nào?
  • Sử dụng phương pháp P2A, chúng ta có thể đưa toàn bộ bụi vào đầu ra neo, thay vì biến nó thành phí thợ đào như hiện nay. Điều này sẽ giải quyết một số vấn đề đã biết liên quan đến lượng bụi phát ra quá mức nhưng cũng sẽ gây ra những lo ngại mới vì đầu ra neo P2A không yêu cầu phải sử dụng chữ ký.
• Đầu ra P2A có nên trở thành "không cần chìa khóa" không?
  • Nếu đầu ra không cần khóa thì bất kỳ bên thứ ba nào cũng có thể giúp làm sạch đầu ra neo ngay lập tức (so với hiện tại, chỉ có hai bên tham gia kênh có thể làm sạch ngay đầu ra neo cho đến 16 khối sau khi đầu ra neo được xác nhận).
  • Liên quan đến điểm trên, nếu chúng ta cho toàn bộ bụi phát ra vào neo P2A thì ai làm sạch neo P2A có thể lấy đi giá trị của toàn bộ bụi phát ra. Đương nhiên, thợ đào là những người có khả năng nhận được số tiền trong đó một cách đáng tin cậy nhất, giả sử không có yêu cầu về chữ ký.
  • Một số cho rằng rằng chúng ta nên duy trì yêu cầu về chữ ký vì nó ngăn cản người khác can thiệp vào những người tham gia đang cố gắng xác nhận các giao dịch đã cam kết. Điều này nhằm phòng ngừa rủi ro có những sai sót chưa được phát hiện trong tổ hợp TRUC+P2A (có thể gây ra rủi ro xảy ra các cuộc tấn công đóng đinh chưa được phát hiện).
• Liệu các đặc điểm lan truyền virus của giao dịch V3 có ảnh hưởng đến các kịch bản ứng dụng nhất định liên quan đến việc ghép kênh nâng cao không?
  • Tất cả các giao dịch con chưa được xác nhận của giao dịch V3 vẫn phải là giao dịch V3. Vì vậy, có những lo ngại rằng điều này sẽ ảnh hưởng đến việc sử dụng ghép kênh, trong đó một nút cố gắng đáp ứng nhiều luồng giao dịch bằng một loạt giao dịch. Bản chất lan truyền của loại giao dịch V3 sẽ buộc bất kỳ ai chi tiêu đầu ra thay đổi chưa được xác nhận phải tiếp tục sử dụng giao dịch V3, điều này có thể vượt quá khả năng của họ.

Các quy tắc TRUC mới cũng cho phép một loại gói giao dịch RBF. Nếu có gói giao dịch xung đột mới xuất hiện, nút sẽ cố gắng khớp với gói giao dịch RBF hiện có. Trong bối cảnh 1P1C, điều này còn được gọi là "đuổi anh chị em" [ 5 ].

Tất cả thông tin trên có thể được tìm thấy trong hướng dẫn hữu ích này dành cho các nhà phát triển ví với nhiều chi tiết hơn [ 6 ].

Việc xử lý lượng bụi thải ra có thể là một trong những sáng kiến ​​mới cụ thể hơn sau cuộc họp lần. Từ đây, chúng ta sẽ tìm hiểu các giao dịch cam kết V3 mới sẽ trông như thế nào trong khi chờ đợi đủ nút trong mạng P2P nâng cấp lên phiên bản mới để chúng ta có thể dựa vào hành vi chuyển tiếp mới.

Cũng cần chỉ ra rằng sự thay đổi này sẽ tác động hơn nữa đến cách các ví đằng sau nút Lightning xử lý hàng tồn kho UTXO. Sử dụng phương pháp này, một giao dịch cam kết nhất định sẽ không tính phí xử lý. Để xác nhận giao dịch, nútphải sử dụng UTXO hiện có để neo giao dịch cam kết, nếu không thì giao dịch cam kết thậm chí không thể được phát sóng. Trong thực tế, điều này có nghĩa là ví cần dự trữ tiền trên Chuỗi trong trường hợp kênh buộc phải đóng kịp thời. Các công cụ như ghép kênh và hoán đổi tàu ngầm cũng có thể được sử dụng để cho phép ví di chuyển tiền hoặc xử lý hàng loạt nhiều tương tác trên Chuỗi.

PTLC và định dạng giao dịch cam kết đơn giản hóa

Cuộc họp sau đây tập trung vào sự kết hợp giữa "Hợp đồng khóa thời gian điểm (PTLC)" và "Máy trạng thái kênh đơn giản hóa". Thoạt nhìn, hai chủ đề này dường như không liên quan gì đến nhau, nhưng chúng ta sẽ sớm thấy rằng một số tình huống khó khăn do cân nhắc thiết kế của PTLC đưa ra có thể được giải quyết bằng cách sửa đổi giao thức máy trạng thái kênh hiện tại (hãy gọi nó là "Lightning Channel"). Giao thức cam kết (LCP)") là một biến thể đơn giản hóa để giảm thiểu.

Đầu tiên chúng tôi giới thiệu ngắn gọn về PTLC. Trong giao thức Lightning Network hiện tại, chúng tôi sử dụng hàm băm thanh toán để triển khai các xác nhận quyền sở hữu nhiều bước hoặc thiết bị xuống cấp, cho phép thanh toán nhiều bước với mức độ tin cậy tối thiểu. Mặc dù đơn giản nhưng giao thức này có nhược điểm lớn về quyền riêng tư: trong mọi kênh tạo nên toàn bộ đường dẫn chuyển tiếp, giá trị băm mang khoản thanh toán là như nhau, vì vậy nếu kẻ thù chiếm giữ hai vị trí, bạn có thể dễ dàng liên kết một khoản thanh toán với nhau. (đồng thời phá vỡ chu kỳ “thanh toán đa đường (MPP)”).

Để khắc phục lỗ hổng bảo mật này, nhiều năm trước, các nhà phát triển đã đề xuất chuyển sang sử dụng đường cong elip và private key(thay vì trả tiền băm và hình ảnh trước). Vào năm 2018, một sơ đồ chính thức đã xuất hiện [ 7 ] thực sự cho phép cấu trúc mới này được khởi tạo bằng cách sử dụng "chữ ký bộ điều hợp" trên các sơ đồ chữ ký ECDSA và Schnorr. Điều này thật thú vị vì nó có nghĩa là chúng ta không phải đợi nâng cấp taproot kích hoạt (nó sẽ kích hoạt chữ ký Schnorr). Ngược lại, khóa nhiều bước nhảy có thể được truyền trên đường dẫn bao gồm các bước nhảy ECDSA và bước nhảy Schnorr. Cuối cùng, vì nhiều lý do, phương pháp kết hợp này chưa bao giờ được triển khai. Lợi ích là chúng ta có thể triển khai khóa đa chặng chỉ có chữ ký Schnorr đơn giản hơn, thống nhất hơn.

Chuyển nhanh đến thời điểm hiện tại, ngoài việc nghiên cứu thiết kế cụ thể của "Kênh Lightning đối xứng (LN-Symmetry)", istagibbs đã khám phá nhiều không gian thiết kế khác nhau, từ truyền bá thông báo đến plug-in máy trạng thái [ 8 ].

Sau khi thảo luận về một số phát hiện của anh ấy, chúng tôi bắt đầu tập trung vào một số vấn đề thiết kế chính:

1. Chúng ta nên sử dụng chữ ký bộ chuyển đổi dựa trên chữ ký đơn hay đa chữ ký? Trong cả hai phương pháp, điểm tiếp hợp T được sử dụng để tạo chữ ký cho phép người đề xuất bổ sung private key cần thiết để ký chữ ký vào HTLC.

   Chữ ký bộ điều hợp dựa trên thuật toán chữ ký musig2 có kích thước nhỏ hơn (cuối cùng chỉ có một chữ ký thay vì hai), nhưng bổ sung thêm các yêu cầu phối hợp vì cả hai bên đều cần cung cấp giá trị nonce để tạo giao dịch cam kết mới đúng cách.

   Bộ điều hợp dựa trên chữ ký đơn có chữ ký lớn hơn (có hai chữ ký, giống như các giao dịch HTLC hai pha hiện tại), nhưng giao thức đơn giản hơn vì chữ ký HTLC có thể được gửi cùng với commit_sig như bình thường.

2. Nếu chúng tôi quyết định sử dụng thiết kế chữ ký của bộ điều hợp musig2, chúng tôi có cố gắng giữ lại luồng LCP không đồng bộ song công hoàn toàn hiện tại không? Hoặc nó nên được đơn giản hóa hơn nữa và sử dụng giao thức máy trạng thái lời hứa đồng bộ đơn giản?

   Việc giới thiệu musig2 nonce cho các giao dịch HTLC hai pha sẽ làm phức tạp thêm giao thức LCP hiện tại, bởi vì chúng tôi sẽ không thể gửi chữ ký của giao dịch HTLC hai pha bằng thông báo commit_sig nữa, vì bên đề xuất thay đổi trạng thái cần một chữ ký mảnh từ người phản hồi để tiếp tục an toàn.

   Tuy nhiên, nếu chúng tôi sửa đổi giao thức máy trạng thái kênh thành dựa lần , thì mặc dù chúng tôi hy sinh một số x-put, nhưng chúng tôi không cần phải lo lắng về cách xử lý việc thực thi xen kẽ có thể xảy ra (cả hai bên gửi update_add_sig+commit_sig cùng một lúc ). Điều này dẫn đến chủ đề hợp lý hóa quy trình.

Giao thức máy trạng thái kênh dựa lần

Trong giao thức Lightning Network ngày nay, chúng tôi sử dụng máy trạng thái không đồng bộ song công hoàn toàn. Điều này có nghĩa là cả hai bên có thể đề xuất thay đổi trạng thái bất kỳ lúc nào mà không cần hỏi ý kiến ​​​​trước của bên kia. Bất cứ lúc nào, chúng ta có thể có 4 loại giao dịch cam kết: giao dịch cam kết đã hoàn tất cho một bên và giao dịch cam kết chưa được xây dựng (đã nhận được chữ ký nhưng giá trị bí mật thu hồi chưa được gửi) . Giả sử rằng cả hai bên tiếp tục gửi chữ ký và thu hồi các giao dịch cam kết cũ của mình thì cuối cùng "người đứng đầu chuỗi giao dịch cam kết" của cả hai bên sẽ quản lý cùng một bộ HTLC đang diễn ra.

Thiết kế này thân thiện với thông lượng vì ngay cả khi cả hai bên gửi nhiều giá trị bí mật thu hồi khi bắt đầu kết nối, họ vẫn có thể tiếp tục gửi trạng thái mới mà không cần đợi bên kia vì họ sử dụng nó trong một điểm Hoàn tác. lần một giá trị bí mật hoàn tác mới được đặt cho phương pháp, trạng thái cũ có thể bị vô hiệu. Nó tương tự như chức năng của cửa sổ trượt của TCP.

Một nhược điểm của giao thức này là hoàn toàn không thể phục hồi sau những bất đồng hoặc lỗi gặp phải trong quá trình thực thi. Bởi vì cả hai bên gửi thông tin cập nhật tùy ý(và tiếp tục làm như vậy ngay cả sau khi gửi lại), nên không có cách nào để tạm dừng hoặc sụp đổ và do đó khôi phục trạng thái thỏa thuận.

Một ví dụ là khoản dự trữ của kênh (Lưu ý của người dịch: một phần không có sẵn của số dư, nhằm ngăn người tham gia có thể gửi bất kỳ giao dịch cam kết bị hủy nào mà không bị mất sau khi cạn kiệt số dư). Trong giao dịch cam kết hiện tại, bất kể bên nào muốn thêm HTLC, người khởi tạo kênh đều phải trả phí bằng vốn đầu vào của chính mình. Tuy nhiên, để thực sự trả tiền cho HTLC mới có thể xuất hiện bất kỳ lúc nào, các nhà tài trợ kênh có thể phải sử dụng nguồn dự trữ kênh của riêng mình để trả phí. Vì cả hai bên đều có thể đề xuất HTLC bất cứ lúc nào nên để ngăn chặn tình huống khó khăn này, họ cần để lại đủ vốn đệm để xử lý phí cho HTLC trong tương lai. Tuy nhiên, rất khó để ước tính chính xác HTLC trong tương lai của bên kia.

Nếu chúng tôi có giao thức dựa trên lần, thì chúng tôi có thể nắm bắt trước tất cả các tình huống khó khăn này và sau đó đảm bảo rằng tôi luôn có thể tiếp tục thực thi kênh và tránh việc đóng cửa tốn kém. Giao thức theo lần như vậy sẽ tương tự như giao thức điều khiển luồng dựa trên RTS (yêu cầu gửi) và CTS (xóa để gửi) [ 8 ].

Trong quá trình thực hiện thông thường, cả hai bên thay phiên nhau đề xuất thay đổi tập hợp các giao dịch đã cam kết (thêm hoặc xóa HTLC). Nếu một bên không thực hiện bất kỳ thay đổi nào thì bên kia có thể tiến hành trước. Điều quan trọng là trong thỏa thuận đơn giản hóa này, cả hai bên có thể phản đối (NACK) hoặc đồng ý (ACK) một cách rõ ràng đối với một loạt các thay đổi. Khả năng phản đối các thay đổi cho phép chúng tôi khôi phục sau các quy trình không ổn định, giúp giao thức trở nên mạnh mẽ hơn trước các yêu cầu tắt máy sai.

Nếu chúng ta sử dụng PTLC dựa trên musig2 thì khi thực hiện theo lần, cả hai bên có thể gửi trước các giá trị nonce, do đó loại bỏ khó khăn trong phân tích khi trao đổi chéo không đồng bộ các giá trị nonce. Một điều đáng chú ý nữa là giao thức này có thể dễ phân tích hơn nhiều vì các giao thức máy trạng thái hiện tại nổi tiếng là thiếu mô tả chi tiết.

Các chương trình hấp dẫn ngoài Chuỗi: SuperScalar, Channel Factory và hơn thế nữa

Vào cuối ngày đầu tiên của hội nghị, chúng tôi đã tập trung vào cấu trúc kênh ngoài Chuỗi có thể được kích hoạt bằng cách tận dụng "quyền sở hữu UTXO được chia sẻ": tạo kênh ngoài Chuỗi, ví di động tự quản lý rẻ hơn (để thu hút người dùng mới) , xử lý hàng loạt việc thực hiện giao dịch bên long. Các đề xuất liên quan bao gồm: nhà máy kênh, cây thời gian chờ, hòm, clark, v.v.

Một đề xuất được công bố gần đây, SuperScalar [ 9 ], cố gắng kết hợp nhiều nguyên thủy để giải quyết vấn đề "dặm cuối" của ví Lightning di động do người dùng kiểm soát. SuperScalar cố gắng thay đổi hiện trạng đồng thời: đảm bảo rằng các LSP (Nhà cung cấp dịch vụ mạng Lightning) không thể lấy cắp tiền, không phụ thuộc vào bất kỳ thay đổi đồng thuận Bitcoin nào được thảo luận và cuối cùng là duy trì khả năng cải thiện khi hệ thống phát triển, đồng thời cho phép một số/tất cả người dùng sang ngoại tuyến.

Lời giải thích hợp lý nhất cho SuperScalar là nó là sự tổng hợp của ba công nghệ: kênh thanh toán vi mô song công [ 10 ], "Cây hết thời gian" [ 11 ] do John Law đề xuất và công nghệ bậc thang cho phép SuperScalar để Điều phối viên của các trường hợp có thể phân bổ vốn và giảm thiểu chi phí cơ hội.

Tôi sẽ không trình bày đầy đủ toàn bộ kế hoạch ở đây, thay vào đó tôi khuyên bất kỳ ai quan tâm hãy xem bài đăng Delving Bitcoin được tham chiếu ở trên. Sau cuộc họp, Z đã đề xuất một số điểm mới trong kế hoạch của mình, giải quyết một số tồn tại và fork theo các hướng khác nhau.

Tóm lại, miễn là bạn kết hợp ba điều trên lại với nhau, bạn sẽ có một cây giao dịch lớn. Mỗi giao dịch (lá) là một kênh hai bên thông thường, thuộc về LSP và một người dùng. Bắt đầu từ kênh (lá), mỗi cấp độ lên là một thiết bị đa chữ ký khác bao gồm những người tham gia cây con của nó. Mỗi lá cũng có một đầu ra bổ sung với số tiền bổ sung L, có thể được sử dụng để phân bổ thanh khoản bổ sung cho kênh miễn là LSP và người dùng trực tuyến. Nếu có nhiều người tham gia trực tuyến hơn, các nhánh cao hơn trong cây giao dịch cũng có thể được ký lại, cho phép phân bổ lại dung lượng của kênh trên quy mô lớn hơn.

Công nghệ bậc thang này cho phép các LSP phân bổ vốn của họ trên nhiều phiên bản của cấu trúc cây ngoài Chuỗi này. Công nghệ cây hết thời gian được sử dụng để cung cấp đường thoát dựa trên độ trễ cho tất cả người dùng. Cấu trúc này không phải lúc nào cũng yêu cầu hiển thị toàn bộ cây giao dịch để buộc thoát ra. Sau một khoảng thời gian, tất cả số tiền trong một phiên bản sẽ được trao cho LSP. Điều này có nghĩa là người dùng cần chuyển đến phiên bản/ bậc thang tiếp theo của cấu trúc, tương tự như cách hoạt động của VTXO được chia sẻ trong cấu trúc Ark (cũng sử dụng dạng cây thời gian chờ). Kết quả là, tất cả các kênh trong cấu trúc này không còn có tuổi thọ vô hạn: người dùng chuyển toàn bộ số tiền của họ ra ngoài hoặc hợp tác với LSP để có được kênh mới trong trường hợp tiếp theo. Nếu không, người dùng sẽ mất tiền.

Vòng đời của một phiên bản SuperScalar có thể được chia thành hai giai đoạn: giai đoạn hoạt động và giai đoạn chết. Trong giai đoạn hoạt động, người dùng có thể sử dụng các kênh của mình một cách bình thường. Họ có thể chọn thoát khỏi phiên bản sớm nhưng có thể vẫn ngoại tuyến trong hầu hết thời gian. Trong giai đoạn ngừng hoạt động, người dùng phải trực tuyến, chuyển tiền hoặc chuyển sang phiên bản khác. Nó cũng có một cửa sổ bảo mật tích hợp khi thời gian chết bắt đầu, LSP sẽ không còn hợp tác với người dùng để cập nhật cây giao dịch và chỉ có thể ký để thanh toán (LSP là một phần của tất cả các kênh, nhưng các kênh phụ có thể cũng được thực hiện và cần thêm sự tin tưởng).

Quay trở lại với đầu ra bổ sung L, như đã đề cập trước đó, đầu ra L là số tiền mà LSP có thể chi tiêu tùy ý. Nếu người dùng cần thêm dung lượng kênh, LSP có thể tạo kênh con mới với người dùng mục tiêu A với chi phí là L. Tuy nhiên, LSP cũng có thể ký L với một người dùng B khác, nghĩa là liên tục sử dụng L đầu ra ngoài Chuỗi . Chỉ một phiên bản của khoản chi tiêu như vậy có thể xuất hiện trên Chuỗi , điều này về cơ bản cho thấy rằng LSP đã bị rút quá mức, có khả năng bị đánh cắp tiền hoặc khiến người dùng mất số tiền mà họ tưởng là của họ. Một giải pháp là sử dụng sơ đồ chữ ký khiến private key bị lộ nếu được ký lần . Có một số cách để xây dựng sơ đồ như vậy: OP_CAT, chia chữ ký thành hơn 7 trường hợp hoặc sử dụng sơ đồ chữ ký hai bộ chuyển đổi được mô tả trong bài báo này [11].

Việc sử dụng các kênh thanh toán vi mô song công ở các cấp cao hơn có nghĩa là khi số lượng cập nhật nội bộ tăng lên thì số lượng giao dịch mà người dùng phải thực hiện để bị buộc rời khỏi cấu trúc này cũng tăng theo. Như mọi khi, cuối cùng chúng ta gặp phải sự đánh đổi không thể tránh khỏi liên quan đến tính kinh tế của blockchain: nếu chi phí thực hiện thanh toán vượt quá giá trị của khoản thanh toán đó thì khoản thanh toán sẽ không xảy ra hoặc Xảy ra trong một hệ thống hy sinh tính bảo mật để tiết kiệm chi phí . Nói cách khác, việc người dùng có các kênh quy mô nhỏ trong cấu trúc như vậy có thể không có ý nghĩa vì việc thoát cưỡng bức sẽ yêu cầu phải trả thêm phí. Để làm cho các kênh nhỏ trở nên tiết kiệm hơn, các điều phối viên cần phải trợ cấp cho chúng hoặc người dùng không bao giờ cần hiển thị chúng trên Chuỗi và luôn có thể chuyển sang bậc thang SuperScalar tiếp theo.

Một chủ đề thú vị khác là phỏng đoán: không thể tham gia kênh ngoài Chuỗi một cách an toàn mà không sử dụng bất kỳ giao dịch trực Chuỗi nào. Để hiểu tại sao điều này lại khó khăn, hãy xem xét tình huống trong đó Alice và Bob đã có một kênh và họ muốn Carol tham gia kênh đó. Alice và Bob tạo trạng thái mới và thêm đầu ra thứ ba vào giao dịch cam kết của kênh bằng cách sử dụng khóa chung của Carol. Carol yêu cầu một số thông tin từ Alice và Bob để thuyết phục cô ấy rằng đây là trạng thái mới nhất, nhưng trên thực tế, A và B luôn có thể ngụy tạo một số lịch sử cập nhật trạng thái giả mạo. Vì cài đặt đa chữ ký trên thư mục gốc chỉ có hai người ký nên A và B luôn có thể chi tiêu gấp đôi giao dịch đã cam kết cho Carol, xóa cô ấy khỏi kênh và lấy cắp số dư đã cam kết với cô ấy. Nếu suy nghĩ một chút, bạn sẽ thấy rằng điều này tương tự như vấn đề “không có gì bị stake ” trong Chuỗi PoS: Không có chi phí nào cho A và B ngụy tạo lịch sử để đánh lừa Caorl.

Kết luận chính của phỏng đoán bất khả thi này là việc xây dựng tư cách năng động hoàn toàn ngoài Chuỗi (bất kỳ ai cũng có thể vào và ra bất kỳ lúc nào) đòi hỏi (1) sự tin tưởng vào người ký gốc hoặc (2) một số loại cơ chế quy định + Trừng phạt; hoặc (3) giao dịch trên Chuỗi. Các giải pháp trong danh mục đầu tiên bao gồm: Liquid, Statechian và Ark với các khoản thanh toán vượt lần. Loại giải pháp thứ hai, trong năm qua, chúng ta đã thấy sự xuất hiện của các kế hoạch như BitVM, dựa trên giả định 1 trong 1 người tham gia trung thực và sử dụng bằng chứng gian lận tương tác trên Chuỗi để quy kết và trừng phạt hành vi gian lận. Trong danh mục cuối cùng, tôi sẽ bao gồm các cấu trúc như Ark, SuperScalar và nói chung là Cây thời gian chờ của John Law. Trong danh mục kế hoạch cuối cùng, người dùng sử dụng các đầu ra mới được tạo bởi các giao dịch Chuỗi để xác thực một tập hợp giao dịch hợp lệ và bất biến từ lá đến gốc, cho phép họ đơn phương triệu tập các kênh mới của riêng họ.

Tóm lại, tôi cho rằng tóm tắt có ý nghĩa của phần này là:

• Các nhà phát triển và nhà cung cấp dịch vụ đang tìm kiếm phương pháp mới để tiếp cận người dùng với hy vọng có được dấu chân Chuỗi nhỏ hơn và hiệu quả về vốn hơn.
• Một giải pháp đầy hứa hẹn dường như là sự kết hợp của một số công nghệ sau: nhà máy kênh, cây thời gian chờ, kênh bên long, giao thức trao đổi quỹ ngoài Chuỗi đặc biệt (họ giao thức Ark).
• Để tránh gây ra quá nhiều sự phức tạp không cần thiết, bất kỳ giao thức mới nào cũng có thể tuân theo kế hoạch triển khai tăng dần, phân phối mô-đun một cách tuần tự, với mỗi mô-đun mới được xây dựng trên mô-đun trước đó.

Link trứng Phục sinh: Bài phát biểu chớp nhoáng

Giữa các cuộc họp, có một sự kiện trò chuyện chớp nhoáng, nơi mọi người có thể nói về bất kỳ điều gì thú vị mà họ đang phát triển.

Điểm tuyệt vời nổi lên từ những cuộc nói chuyện này là khả năng người dùng phục hồi sau những yêu cầu tắt máy cưỡng bức sai lầm. Những điều như thế này luôn xảy ra vì nhiều lý do, chẳng hạn như sự không nhất quán giữa việc triển khai phần mềm và lý do phổ biến nhất là sự bất đồng về phí xử lý. Ý tưởng cơ bản ở đây là cung cấp thêm một khóa cho phép đối thủ tiêu tiền của mình càng nhanh càng tốt nếu kênh buộc phải đóng. Đây sẽ là một hành động hoàn toàn mang tính vị tha, đại diện cho bên không bắt đầu giao dịch trên Chuỗi và cũng sẽ là một hành động thân thiện có thể thực sự giúp ích cho đối thủ.

Về mặt cơ học, một cách để đạt được điều này là cố gắng hết sức để giúp đối thủ xóa đầu ra bằng cách hoàn tác đường dẫn (ngược lại với cách sử dụng thông thường). Một số người cũng đã thảo luận về việc sửa đổi một chút cấu trúc dẫn xuất của đầu ra, phương pháp thông tin mới trong thông báo xây dựng lại kênh. Bên không phát sóng sẽ chỉ tiết lộ những thông tin đó nếu họ biết chắc chắn rằng những gì được phát hành là cập nhật và đã nhận được xác nhận.

Làm cho việc buôn chuyện bớt khó chịu hơn

Buổi học đầu tiên vào sáng hôm sau là về việc xác định những cải tiến cụ thể có thể đạt được nhờ giao thức buôn chuyện.

Manh mối đồng bộ tin đồn

Giao thức tin đồn của Lightning Network có cấu trúc được xác định rõ ràng nhưng để lại nhiều lĩnh vực hành vi tùy thuộc vào việc triển khai. Ví dụ về hành vi như vậy bao gồm: Cần duy trì bao nhiêu nút được đồng bộ hóa? Tôi có nên hạn chế tỷ lệ tin nhắn buôn chuyện gửi đến không? Kênh mới nhập được xác minh như thế nào (nếu có)? Bạn có cần kiểm tra định kì bản đồ cấu trúc liên kết để tìm các kênh bị thiếu không? Bạn có phải tải xuống mọi thứ từ đầu lần không?

Trong quá trình thảo luận, hầu hết thời gian, mỗi lần triển khai đều học được điều gì đó từ những lần triển khai khác mà nó không triển khai tương tự. Cứ sau vài tháng/tuần, chúng tôi lại phát hiện ra các lỗi nhỏ ngăn cản việc lan truyền các bản cập nhật kênh mới hoặc thông báo kênh. LND nhận thấy rằng cải tiến lớn nhất mà họ đã thực hiện gần đây để hỗ trợ khả năng hiển thị và liên lạc là bắt đầu sử dụng thông tin dấu thời gian cập nhật kênh trong các yêu cầu truy vấn tin đồn. Nếu không có thông tin này, nút không thể xác định được điều đó, ngay cả khi chúng có cùng bộ kênh (dựa trên scid) với đối tác, đối tác có thể có kênh mới hơn . Nếu quá trình triển khai loại bỏ các "kênh zombie" không hoạt động từ lâu nhưng không chủ động đồng bộ hóa tin đồn thì chúng không thể lấy lại các kênh zombie cũ nếu không kiểm tra dấu thời gian cập nhật kênh trong các yêu cầu truy vấn tin đồn, thì sẽ mất một khoản lớn một phần của sơ đồ cấu trúc liên kết mạng.

Chuyện phiếm 2.0

Tiếp theo, chúng tôi chuyển sang một sửa đổi mới được đề xuất cho giao thức tin đồn, có tên mã là "Gossip 2.5" (hoặc "2.0", tùy thuộc vào người bạn đang nói chuyện). Kể từ cuộc họp đặc tả lần trước, LND đã nâng cao đặc tả [14] và triển khai [ 15 ]. Hiện tại, thông số kỹ thuật này đang chờ xem xét/phản hồi bổ sung và kể từ năm nay, LND đã làm cho giao thức này hoạt động trong hoàn cảnh e2e (chỉ kênh mới).

Một bổ sung mới mà chúng tôi đã thảo luận là thêm bằng chứng SPV vào thông báo thông báo kênh. Một số triển khai có điều kiện hoặc vô điều kiện hoàn toàn không xác minh số tiền Chuỗi của các kênh được khai báo (trước đây, chẳng hạn như LND, sử dụng cờ --routing.assumechanvalid ). Đối với máy trạm hạng nhẹ sử dụng hoàn toàn mạng P2P (ví dụ: máy trạm Neutrino), việc tìm nạp hàng chục nghìn giao dịch trong một khối có thể là gánh nặng rất lớn về nguồn điện/băng thông/CPU. Nếu thông báo thông báo kênh có thể mang (nhưng luôn cam kết) bằng chứng SPV thì sự tồn tại của kênh chỉ có thể được xác minh bằng Chuỗi Block Header mới nhất . Nếu chỉ có bản tóm tắt băm/gốc của tải trọng cuối cùng được ký thì nút không cần bằng chứng bổ sung đều có thể yêu cầu người gửi bỏ qua thông tin này. Trước đây, LND đã phát triển một định dạng bằng chứng hỗ trợ tổng hợp ở cấp độ xử lý hàng loạt và có thể được sử dụng lại [ 16 ].

Đối với thử nghiệm khả năng tương tác, các triển khai khác hiện có các triển khai ưu tiên khác hoặc có thể phải đợi tiến trình của thư viện ngược dòng tích hợp musig2 (sau cuộc họp nhà phát triển lần, PR của musig2 trong thư viện libsecp đã được hợp nhất!). Hiện tại không có triển khai chính nào hỗ trợ testnet4, vì vậy nó có thể chưa có Lightning Channel và những người tham dự đều đồng ý biến testnet4 trở thành nền tảng chứng minh đầu tiên cho tin đồn 2.0!

Gossip 2.0 hủy trường dấu thời gian trong thông báo cập nhật kênh cũ và thay thế bằng Block Height. Điều này giúp đơn giản hóa việc giới hạn tốc độ vì bạn có thể chỉ định rằng một nút chỉ có thể cập nhật mỗi khối một lần. Vì Block Height đồng nhất trên toàn cầu (không có thuộc tính cục bộ như múi giờ), nên nó phù hợp hơn với các giao thức phối hợp tập thể khác nhau. Một số người tham dự đã thực hiện một số nghiên cứu về việc tái sử dụng các triển khai minisketch hiện có và mặc dù chúng tôi gặp phải những hạn chế khác nhau nhưng cuối cùng chúng tôi có thể sử dụng nhiều thứ khác nhau cùng một lúc.

(Lưu ý: Tôi đã làm đổ cà phê vào máy tính xách tay của mình trong thời gian này. Tôi đã bỏ lỡ một phần quan trọng của cuộc thảo luận khi cố gắng khắc phục sự cố.)

Những hạn chế cơ bản về phân bổ thanh toán

Sau đó, một trong những phiên của chúng tôi đã thảo luận về một số nghiên cứu mới nhất về định tuyến/tìm đường dẫn của Lightning Network. Chủ đề chính là trình bày/thảo luận về một số nghiên cứu mới cố gắng tìm hiểu những hạn chế cơ bản của việc phân phối thanh toán trong mạng kênh thanh toán /Giới hạn của kênh hai bên/bài báo/lý thuyết toán học về mạng kênh thanh toán.pdf)].

Tóm lại, nghiên cứu này mô hình hóa cấu trúc liên kết mạng như sê-ri các cạnh và đỉnh, mỗi cạnh có ba thuộc tính: số dư cục bộ, số dư từ xa và tổng công suất. Với cấu trúc liên kết mẫu, chúng tôi có thể xác định liệu một khoản thanh toán có thể được gửi hay không: liệu có sê-ri các sửa đổi số dư theo cặp cung cấp cho "người nhận" trạng thái cuối số dư mong muốn hay không. Nghiên cứu này không chạy các thuật toán tìm đường dựa trên tham lam thông thường mà thay vào đó ứng xử tính khả thi của thanh toán trên toàn cầu. Lưu ý rằng phương pháp này nắm bắt một cách tự nhiên khả năng buộc tái cân bằng trong thời gian thanh toán, cho phép thực hiện các luồng thanh toán không thỏa mãn.

Không thể tránh khỏi, một số luồng thanh toán đơn giản là không thể đạt được. Các nguyên nhân bao gồm: dung lượng kênh không đủ, người gửi không có đủ số dư, người nhận không có đủ tín dụng, v.v. Khi điều này xảy ra, trong mô hình này, một giao dịch Chuỗi phải xảy ra để thêm tiền vào hoặc rút tiền từ việc thu thập số dư hiện tại của mạng. Ví dụ về các giao dịch trực Chuỗi như vậy bao gồm: mở kênh, đóng kênh, ghép kênh hoặc sử dụng cuộc gọi tàu ngầm.

Dựa trên các biện pháp phòng ngừa ở trên và đưa ra một số giả định ban đầu (sơ đồ cấu trúc liên kết, phân phối số dư, phân phối mẫu về khả năng thanh toán giữa hai nút bất kỳ), chúng tôi có thể rút ra giới hạn trên cho thông lượng hiệu quả của mạng kênh thanh toán. Để đạt được giá trị này (T), chúng tôi chia TPS (Q) băng thông blockchain cho tỷ lệ xảy ra dự kiến ​​​​của các khoản thanh toán không khả thi (R), nghĩa là T = Q/R. Nếu chúng ta muốn T là (ví dụ) 47k TPS, sau đó thay thế TPS của Chuỗi chính hiện tại (khoảng 14), chúng ta có thể nhận được R là 0,029%, tức là chỉ có thể đạt được 47k TPS khi thanh toán 0,029% là không khả thi.

Cuối cùng, những con số này rút gọn thành phép toán đơn giản dựa trên các giả định đơn giản hóa. Một khía cạnh mà mô hình này không tính đến là các tương tác trên Chuỗi có thể được theo nhóm, tức là nhiều kênh/người dùng có thể định cấu hình dung lượng/băng thông ngoài Chuỗi của họ bằng một giao dịch trên Chuỗi duy nhất. Công cụ phái sinh ở trên cũng không tính đến các khoản thanh toán cân bằng (ví dụ: tôi thanh toán qua lại giữa hai nút của mình mà không mất phí), điều này không bao giờ cần kích hoạt giao dịch Chuỗi, nhưng không tính đến nguồn gốc của TPS. Tuy nhiên, một mô hình như vậy vẫn hữu ích trong việc đạt được cảm nhận trừu tượng về những hạn chế của hệ thống.

Kênh bên long& kênh tín dụng

Nghiên cứu cũng xác định hai nguyên tắc cơ bản có thể giúp giảm số lượng thanh toán không khả thi: kênh bên long và tín dụng nội mạng.

Các kênh bên long tổng hợp nhiều người dùng trong biểu đồ kênh, tạo thành một biểu đồ con mới được kết nối đầy đủ một cách hiệu quả. Trực giác ở đây là: nếu bạn coi số tiền được thêm vào kênh theo mỗi hướng là không đổi thì bằng cách tăng số lượng người tham gia, bạn cũng tăng số tiền tối đa mà mỗi người dùng có thể có. Khi bạn tăng số tiền tối đa này, bạn sẽ giảm số lượng thanh toán không khả thi do hạn chế về số dư/công suất.

Sau đó là các khoản tín dụng và ý tưởng rất đơn giản: nếu việc thanh toán không khả thi thì trong một số bước nhảy nhất định, các khoản tín dụng có thể được đưa ra để mở rộng vĩnh viễn hoặc tạm thời công suất của một kênh đồng thời tăng số dư của một bên nhất định. Để giảm thiểu rủi ro hệ thống, có vẻ như khoản tín dụng đó không nên được đưa vào lõi của mạng mà chỉ nên tồn tại ở rìa. Về lý thuyết, một giao thức như Taproot Assets cũng có thể được sử dụng để tăng khả năng thanh toán đồng thời giảm chi phí cho người dùng tham gia, vì nó cho phép người dùng thể hiện khái niệm tín dụng có thể xác minh/có thể xác minh ngay trong kênh.

Các vấn đề cuối cùng để thu hút người dùng di động

Vào cuối ngày, chúng tôi có hai phiên riêng biệt nhưng có liên quan, tập trung vào việc thu hút khách hàng và trải nghiệm người dùng về ví tự quản lý trên thiết bị di động. Đầu tiên, đó là vấn đề “dặm cuối”, vì nó liên quan đến trải nghiệm người dùng thiết bị di động và bắt đầu [ 17 ].

Trong Lightning Network hiện tại, phần lớn các thách thức trải nghiệm người dùng đến từ việc một người dùng cố gắng thanh toán cho người dùng khác nhưng người nhận lại sử dụng ví di động tự duy trì. Điều này tương tự như vấn đề đường truyền cuối cùng trong cơ sở hạ tầng và băng thông Internet: bên trong mạng chứa những “ống lỏng lẻo” với băng thông cao có thể nhanh chóng trao đổi thông tin trong mạng nội bộ. Tuy nhiên, việc gửi thông tin từ mạng nội bộ đến đích cuối cùng trở nên đắt hơn, kém tin cậy hơn và chậm hơn.

Chi phí thu hút khách hàng và thanh khoản của kênh

Trong bối cảnh của Lightning Network, điều cần giải quyết không phải là cơ sở hạ tầng cũ kỹ hay chi phí xây dựng cao mà là các đặc điểm khác nhau của bản thân thiết bị di động. Ngược lại với nút định tuyến luôn trực tuyến, nút di động cần được đánh thức để ký các bản cập nhật mới đến. Ngoài ra, nếu một nút di động hy vọng trở thành người dùng thanh toán ròng (nhưng không có quỹ Chuỗi chính và trực tiếp vào Lightning Network), thì phải có một nút định tuyến để khóa dòng thanh khoản cho TA. Việc thiết lập kênh đầu tiên này sẽ tiêu tốn vốn từ góc độ của nút định tuyến, bởi vì có thể nút di động sẽ thoát khỏi mạng kể từ bây giờ, khiến tiền trong kênh không hoạt động. Để lấy lại tiền từ những người dùng đã ngoại tuyến trong một thời gian dài, nút định tuyến cần phải đóng kênh một cách mạnh mẽ và trả giá phí và thời gian xử lý trên Chuỗi(chờ khóa thời gian tương đối hết hạn, tối đa 2 tuần).

Khi chúng ta tìm hiểu sâu hơn về chi phí thanh khoản chặng cuối, chúng ta bắt đầu gặp phải một số giới hạn cơ bản đối với nền kinh tế. Nếu người dùng chỉ nhận được 10 satoshi trong một kênh nhưng phải trả giá 1.000 satoshi (phí xử lý Chuỗi) để mở kênh thì việc thiết lập kết nối với người dùng đó sẽ dẫn đến mất ròng nút định tuyến (chưa kể rằng vẫn còn 1.000 satoshi trên mạng hiện nay). Có giới hạn về dung lượng tối thiểu của kênh). Thay vào đó, bất kỳ vốn (số tiền nhận) nào được nút phân bổ cho người dùng không hoạt động đều có thể được phân bổ cho các kênh tốc độ cao trong mạng, trong đó phí định tuyến được kiếm để trang trải chi phí mở kênh. Giả sử rằng chi phí có thể được trải đều và trợ cấp có thể được duy trì, các công cụ cơ sở hạ tầng bao gồm: hệ thống kênh JIT của Phoenix Wallet, Liquidity Ads [ 18 ], Sidecar Channel sử dụng Lightning Pool, Amboss' Magma, v.v.

Sự cố trải nghiệm người dùng do giao thức gây ra

Ngoài các yêu cầu tương tác trực tuyến và phí xử lý trên Chuỗi, thiết kế giao thức hiện tại còn có một số điểm trừu tượng, cuối cùng sẽ được đưa vào ví di động của người dùng cuối và trở thành chi phí thu hút khách hàng. Một ví dụ là dự trữ kênh: để đảm bảo rằng cả hai bên đều có điều gì đó phải lo lắng trong suốt vòng đời (ngăn chặn các nỗ lực gian lận), họ phải luôn giữ một số dư nhỏ trong kênh (thường là khoảng 1%). Điều này có thể gây khó chịu cho người dùng, vì họ thường muốn chuyển toàn bộ số dư trong ví của mình sang ví khác nhưng nhận ra rằng họ luôn phải giữ một lượng tiền nhỏ. Ngoài ra, khi phí xử lý Chuỗi tăng, công suất kênh hiệu quả về mặt kinh tế cũng tăng.

Thanh khoản phí thanh khoản

Một giải pháp gần đây cho vấn đề bụi/đầu ra nhỏ là một khái niệm được phoenixd [ 21 ] sử dụng có tên là "giảm phí". Giảm phí là khoản thanh toán không hoàn lại được sử dụng để mua tín dụng thanh toán trong tương lai. Bất cứ khi nào người dùng nhận được tiền từ một nút định tuyến đặc biệt ( nút hỗ trợ plug-in in giao thức này), nhưng người dùng chưa có kênh, số tiền sẽ được chuyển vào bể giảm phí này. Sau khi người dùng tích lũy đủ tiền trong lọ giảm giá này, nút định tuyến sẽ mở một kênh có TA và sử dụng số tiền giảm giá trong lọ để trả phí dịch vụ và phí xử lý trên Chuỗi. Số tiền tối thiểu cần thiết để mở một kênh sẽ khác nhau tùy thuộc vào dịch vụ và phí Chuỗi.

Từ góc độ thực tế, việc giảm phí có hiệu quả. Giả sử người dùng cuối cùng nhận đủ tiền, họ có thể nhận được tiền ngay lập tức mà không cần phải đợi kênh mở. Sau khi họ có đủ tiền để tạo UTXO L1, họ có thể được thanh toán bằng khoản giảm giá phí để tạo UTXO này. Kỹ thuật này có thể được kết hợp với một hệ thống như eCash (sử dụng số tiền trong trạm đúc tiền để đại diện cho các khoản tiền đang chờ xử lý) hoặc thậm chí là kênh tín dụng sử dụng Taproot Assets (sử dụng UTXO của tài sản được biểu thị trong Pocket Universe để bù đắp phí trên L1).

Tại thời điểm này, cuộc thảo luận quay trở lại các cấu trúc Chuỗi khác nhau tương tự như các nhà máy kênh và những hạn chế của chúng trong hoàn cảnh phí trên Chuỗi cụ thể, số lượng người dùng và phân bổ số dư giữa những người dùng đó. Về cơ bản, nếu bạn tưởng tượng một loại công trình như thế này, dựa trên cây thời gian chờ, thì nếu có 100 triệu người dùng, mỗi người trong số họ chỉ có 1 satoshi, thì việc họ hủy toàn bộ cây trên đó sẽ không hiệu quả về mặt chi phí. Chuỗi(vì Phí xử lý đã vượt quá 1 satoshi). Nếu chúng ta tưởng tượng rằng có một cơ chế tích hợp cho phép người dùng chuyển tiền đến nơi khác, để người điều phối có thể lấy tất cả số tiền cùng một lúc (tương tự như mô hình của Ark), thì nếu người dùng không thoát ra kịp thời, thì đ