Cách triển khai thanh toán không đồng bộ trong Lightning Network

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

Tác giả: Lorenzo

Nguồn: https://www.voltage.cloud/blog/how-async-payments-on-lightning-network-work

Được xuất bản lần đầu vào tháng 10 năm 2023. Thông số kỹ thuật BOLT12 đã được sáp nhập vào BOLT vào tháng 9 năm 2024.

giới thiệu

Mạng lưới Lightning đặt mục tiêu trở thành giải pháp mở rộng thông lượng giao dịch Bitcoin. Tuy nhiên, khi tìm hiểu sâu hơn về Mạng lưới Lightning, chúng tôi nhận thấy vẫn còn những điểm cần cải thiện. Trong đó điểm đáng chú ý là khái niệm "thanh toán bất đồng bộ" - một tính năng mà nếu được triển khai, có thể cải thiện đáng kể quy trình thanh toán và trải nghiệm người dùng.

Thanh toán Bitcoin truyền thống trên Chuỗi cực kỳ đơn giản nhờ tính chất bất đồng bộ của chúng. Hãy lấy một ví dụ để minh họa: Hãy tưởng tượng Alice muốn trả tiền cho Bob học guitar. Cô ấy truy cập trang cá nhân trên mạng xã hội của Bob và thấy một địa chỉ Bitcoin trong hồ sơ của anh ấy. Để gửi thanh toán cho Bob, Alice chỉ cần sao chép địa chỉ này, dán vào trường người nhận trong ví Bitcoin của mình và nhấn "Gửi". Giao dịch này được xếp hàng và xác nhận bởi blockchain Bitcoin . Khi Bob mở ví, anh ấy sẽ thấy một khoản thanh toán bổ sung từ Alice.

Tuy nhiên, nếu Alice muốn thanh toán cho Bob qua Lightning Network, trải nghiệm người dùng sẽ khác. Khi thực hiện thanh toán, cả người gửi và người nhận đều phải trực tuyến và trao đổi thông tin.

Mặc dù không thể nói là hoàn hảo tuyệt đối, nhưng sự khác biệt ở đây đặt nền tảng để chúng ta giải thích về thanh toán đồng bộ và thanh toán không đồng bộ trong Lightning Network.

Tổng quan về thanh toán Lightning Network

Để hiểu khái niệm thanh toán không đồng bộ, trước tiên chúng ta cần hiểu cách thanh toán được triển khai trong Lightning Network.

Trên Mạng Lightning, nếu Alice muốn gửi thanh toán cho Bob, trước tiên cô ấy phải yêu cầu Bob xuất hóa đơn. Điều này có nghĩa là Bob phải chủ động mở ví Lightning của mình và tạo hóa đơn cho khoản thanh toán của Alice. Không giống như các địa chỉ Bitcoin truyền thống, hóa đơn của Mạng Lightning chỉ được sử dụng một lần. Việc thanh toán cùng một hóa đơn lần có thể khiến người gửi mất tiền.

(Ghi chú của người dịch: Mặc dù địa chỉ Bitcoin có thể được sử dụng lại, nhưng việc sử dụng lại địa chỉ là một thói quen xấu, ảnh hưởng đến quyền riêng tư của chủ sở hữu địa chỉ. Việc thanh toán hóa đơn hai lần gây rủi ro cho người gửi vì sau khi thanh toán hoàn tất, ảnh băm đảm bảo tính bảo mật của khoản thanh toán sẽ bị lộ và một nút trung gian không phải là người nhận cũng có thể lĩnh nhận khoản thanh toán lần. Vì lý do này, việc sử dụng lại hóa đơn cũng không an toàn cho người nhận.)

Sau khi nhận được hóa đơn của Bob, Alice sử dụng ví Lightning của mình để gửi thanh toán dựa trên thông tin hóa đơn. Đằng sau hậu trường, khoản thanh toán của cô ấy đi qua một loạt các kênh Lightning cho đến khi đến nút của Bob (được ví Lightning của anh ấy kiểm soát). Khi nhận được thanh toán, nút của Bob sẽ gửi lại biên lai. Biên lai này đảm bảo rằng mỗi nút trung gian nhận được phí của mình và đảm bảo với Alice rằng khoản thanh toán đã thành công. Nếu nút của Bob ngoại tuyến (và không gửi lại biên lai) khi khoản thanh toán đến, khoản thanh toán sẽ bị treo, không thể hoàn tất. Mặc dù giao thức Mạng Lightning đảm bảo không ai bị mất tiền, nhưng nó cũng đặt ra một thách thức trải nghiệm người dùng, vì việc duy trì trạng thái trực tuyến liên tục rất khó khăn, đặc biệt là trên thiết bị di động.

Tóm lại, thanh toán qua Lightning Network phải đối mặt với hai rào cản về tính đồng bộ:

  • Người nhận phải được mời để tạo hóa đơn;
  • Người nhận phải trực tuyến khi người trả tiền gửi thanh toán.

Xử lý thanh toán không đồng bộ

Tác động của thanh toán không đồng bộ

Việc triển khai thanh toán bất đồng bộ trong Mạng Lightning cho phép thanh toán có thể được thực hiện ngay cả khi người nhận ngoại tuyến. Một nút trung gian sẽ giữ khoản thanh toán một cách an toàn và chỉ chuyển giao khi người nhận được kết nối lại với mạng và có thể nhận được.

Phương pháp đơn giản

Thoạt nhìn, việc tạo thanh toán Lightning không đồng bộ có vẻ dễ dàng. Vấn đề tương tác hóa đơn có thể được giải quyết bằng cách để nút của Bob tạo trước nhiều hóa đơn, lưu trữ chúng trên máy chủ của bên thứ ba, sau đó để máy chủ phân phối hóa đơn theo yêu cầu. Vấn đề xác nhận thanh toán có thể được giải quyết bằng cách để nút cuối cùng trong đường dẫn chuyển tiếp thanh toán tạm thời giữ thanh toán cho đến khi nút của Bob ra mắt.

Tuy nhiên, phương pháp này có rất nhiều vấn đề. Vấn đề rõ ràng nhất là việc đưa yếu tố tin cậy vào một hệ thống thanh toán được thiết kế để không cần sự tin cậy. Người nhận phải tin tưởng "người giám hộ" hóa đơn của họ sẽ cung cấp dịch vụ trung thực. Một vấn đề khác là hóa đơn có thể hết hạn. Cuối cùng, do thanh toán bị tạm dừng giữa chừng, tất cả nút trên đường dẫn chuyển tiếp thanh toán phải khóa một phần thanh khoản cho đến khi Bob trực tuyến trở lại hoặc hóa đơn hết hạn. Đây là một kết quả tiêu cực, vì nút chuyển tiếp cần quản lý thanh khoản hiệu quả, và việc khóa thanh khoản trong một khoảng thời gian không xác định là không hiệu quả.

Chúng ta có thể làm tốt hơn không?

Trở lại năm 2021, Matt Corallo đã đề xuất một giải pháp thỏa hiệp có thể cải thiện thanh toán bất đồng bộ. Điều này sẽ yêu cầu sử dụng " LNURL ", với cả người gửi và người nhận đều sử dụng Nhà cung cấp dịch vụ Lightning (LSP). Ông đề xuất sử dụng LNURL để tạo hóa đơn bất đồng bộ. Những hóa đơn này có thể được gắn thẻ để cảnh báo người gửi rằng người nhận đã kết nối với LSP nhưng hiện đang ngoại tuyến. Sau đó, người gửi sẽ gửi một lệnh thanh toán với thời gian chờ dài đến LSP của họ, yêu cầu LSP tạm dừng thanh toán cho đến khi nhận được một tin nhắn nhất định.

LSP nhận thanh toán không chuyển tiếp ngay lập tức khoản thanh toán, mà chỉ để lại tiền của người gửi "bị khóa" cho khoản thanh toán chưa hoàn tất. Sau đó, người gửi hướng dẫn LSP của người nhận gửi tin nhắn đến LSP của họ khi người nhận trực tuyến trở lại. Người gửi sau đó có thể đăng xuất an toàn. Khi người nhận trực tuyến trở lại, LSP của họ sẽ gửi tin nhắn đến LSP của người trả tiền, kích hoạt việc chuyển tiếp khoản thanh toán.

Chiến lược này loại bỏ nhu cầu giám sát của bên thứ ba bất cứ lúc nào. Điều này có nghĩa là tiền không thể bị đánh cắp; về mặt kỹ thuật, LSP không thể được định nghĩa là đơn vị giám sát cho mục đích quản lý. Hơn nữa, sau khi thông số kỹ thuật BOLT 12 được hoàn thiện, nó có thể thay thế LNURL. Điều này sẽ giúp các khoản thanh toán bất đồng bộ ít phụ thuộc hơn vào máy chủ bên ngoài (điều mà LNURL đang làm).

Vấn đề với phương pháp LNURL là người dùng vẫn cần tin tưởng bên thứ ba để cung cấp hóa đơn. Không có gì đảm bảo các nhà cung cấp dịch vụ này sẽ không tái sử dụng hóa đơn, tạo điều kiện cho LSP đánh cắp tiền. Một cách để cải thiện điều này là sử dụng PTLC . Điều này đòi hỏi sự thông đồng giữa người gửi và nhà cung cấp dịch vụ LNURL để đánh cắp tiền, nhưng không có lý do gì để người gửi làm như vậy.

Mặc dù không có giải pháp nào cho mối quan hệ tin cậy là hoàn hảo, nhưng đây là phương pháp tốt hơn so với phương pháp đơn giản nêu trên. Đề xuất của Matt dựa trên việc tin tưởng nhà cung cấp LNURL, và khoản thanh toán đã quá hạn, giống như phương pháp đơn giản.

kết luận

Trong cuộc đua giúp thanh toán Bitcoin nhanh hơn và hiệu quả hơn, Lightning Network đã nổi lên như một công nghệ dẫn đầu. Tuy nhiên, bất chấp tiềm năng của nó, tính đồng bộ của thanh toán Lightning hiện đang làm nổi bật những thiếu sót trong trải nghiệm người dùng.

Thanh toán Bitcoin truyền thống đơn giản và linh hoạt, vì người gửi và người nhận không cần phải trực tuyến cùng lúc. Mặt khác, thanh toán Lightning yêu cầu cả hai bên phải trực tuyến cùng lúc, tạo ra một rào cản tiềm ẩn khi sử dụng.

Các giải pháp thô sơ, chẳng hạn như dựa vào bên thứ ba lưu ký hóa đơn và chiến lược chuyển tiếp hoãn lại nút, mang lại sự tin cậy cho một hệ thống đang hướng đến sự không cần tin cậy. Đề xuất năm 2021 của Matt Corallo, tận dụng các nhà cung cấp LNURL và Lightning Network, mang lại một nền tảng đầy hứa hẹn. Nó giảm thiểu thanh khoản bị khóa, loại bỏ bên thứ ba lưu ký và hứa hẹn khả năng tương thích với thông số kỹ thuật BOLT12 sắp tới. Tuy nhiên, các vấn đề về tin cậy liên quan đến LNURL vẫn là một mối lo ngại. Những cải tiến như PTLC sẽ tăng cường bảo mật.

Cuộc phiêu lưu triển khai thanh toán không đồng bộ trong Lightning Network đã bắt đầu và nhiều giải pháp được đề xuất đang đưa chúng ta đến gần hơn với trải nghiệm thanh toán liền mạch và không cần tin cậy.

(qua)

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