Bởi Elle Mouton
Nguồn: https://btctranscripts.com/advancing-bitcoin/2022/static-invoices-in-lightning
Bài viết này là bản ghi lại bài phát biểu của Elle Mouton tại hội nghị Advancing Bitcoin 2022, được ghi lại bởi b3h3rkz.
giới thiệu
Xin chào, tôi tên là Elle, và tôi sẽ nói về hóa đơn tĩnh trong Mạng Lightning. Như hầu hết các bạn có thể đã biết, trong Mạng Lightning hiện tại, nếu muốn được thanh toán, bạn cần tạo một "hóa đơn" mới lần. Điều này có thể là một rào cản đối với những người chưa biết gì về Mạng Lightning. Hôm nay, tôi sẽ nói về lý do tại sao chúng ta nên hướng tới hóa đơn tĩnh, và sau đó phác thảo ba đề xuất mà mọi người đã thảo luận: LNURL, Offer và Amp.
Vậy nên, đây chỉ là một cái nhìn tổng quan nhanh. Tôi cho rằng điều thực sự quan trọng là đảm bảo mọi người hiểu rõ vấn đề. Vì vậy, tôi vẫn sẽ dành chút thời gian để giới thiệu về thanh toán Lightning. Không đi sâu vào chi tiết, mà chỉ là một cái nhìn tổng quan để mọi người có thể hiểu được những điều kiện tiên quyết để thanh toán được thực hiện thông qua Mạng Lightning. Sau đó, chúng ta sẽ tìm hiểu vai trò của hóa đơn BOLT11. Tiếp theo, tôi sẽ nói về những thiếu sót của những điều này và đi sâu vào các đề xuất đã nêu ở trên. Tiếp theo, tôi sẽ tóm tắt lại những vấn đề cấp cao và xem xét các lập luận mà mọi người đã thảo luận trên Twitter. Cuối cùng, tôi sẽ liệt kê một số vấn đề còn bỏ ngỏ.
Thanh toán sét 101
Vậy hãy bắt đầu thôi. Như các bạn có lẽ đã biết, Mạng lưới Lightning được tạo thành từ các kênh. "Kênh" là một hợp đồng giữa Alice và Bob cho phép họ chuyển giao giá trị cho nhau bao nhiêu lần tùy thích, rất nhanh chóng và ngoài chuỗi, dựa trên một tập lệnh đa blockchain 2-trong-2. Điều này thật tuyệt vời. Nếu có một kênh giữa bất kỳ hai người nào trong Mạng lưới Lightning, thì vấn đề hóa đơn tĩnh sẽ không tồn tại, và tôi có thể kết thúc bài nói chuyện của mình ngay lập tức.
Nhưng nếu đúng như vậy, Mạng Lightning sẽ không thể mở rộng— bạn không thể mở kênh với tất cả những người mà bạn có thể thanh toán/yêu cầu thanh toán (mỗi kênh là một UTXO), vì vậy mô hình này hoàn toàn không hiệu quả. Điểm hay của Mạng Lightning là góc nhìn của Alice trông hơi giống thế này, và tất cả những gì cô ấy cần làm là tìm một đường dẫn qua mạng đến Dave nếu cô ấy muốn thanh toán cho anh ta (mà không cần phải mở kênh trực tiếp với Dave).
Hãy nhìn kỹ hơn. Alice đang tìm đường đến Dave, và cô ấy chỉ cần tập trung vào đường đi đó. Vậy Alice trả tiền cho Dave bằng cách nào? Tại sao quy trình này không thể tĩnh? Tại sao cô ấy không thể chỉ cần ra lệnh cho nút của mình "vui lòng trả cho người này (ID nút của Dave) số lượng Bitcoin này"? Đó là tĩnh.
Cách ngây thơ nhất là Alice liên lạc với Bob: "Này Bob, làm ơn giúp tôi. Tôi sẽ đưa anh một ít Bitcoin, anh lấy một ít đưa cho Charlie, rồi Charlie lại lấy một ít đưa cho Dave." Tuyệt, Dave được trả tiền. Nhưng cách này cũng không hiệu quả, bởi vì trong thế giới Bitcoin, chúng ta không thể tin tưởng Bob. Thực tế, nếu Alice chỉ đưa cho Bob một ít tiền như thế này, chẳng có gì ngăn cản Bob bỏ trốn với số tiền đó. Vậy nên, thanh toán qua Lightning Network cũng không hoạt động theo cách này.
Vậy nó hoạt động như thế nào? Thực ra, trước khi quá trình thanh toán bắt đầu, nói thẳng ra là trước khi chúng ta sử dụng Mạng Lightning, Alice nói: "Này Dave, tôi sẽ trả tiền cho anh, hãy chú ý nhé." Dave hiểu ý cô ấy, tạo ra một giá trị bí mật, rồi gửi lại mã băm của giá trị bí mật đó cho Alice. Tất cả diễn ra bên ngoài Mạng Lightning. Giờ đây, Alice lại tìm thấy Bob, nhưng lần này, Alice sẽ nói: "Bob, nếu anh tìm được hình ảnh gốc đằng sau giá trị băm này, anh có thể lấy lại 3 BTC tôi đã đưa. Nếu anh không giải được, thì sau một khoảng thời gian, tôi sẽ lấy lại tiền." Sau khi Bob nhìn thấy thông tin này, anh biết rằng anh chỉ có thể lấy lại tiền của Alice bằng cách tiếp tục mô hình tương tự, tìm Charlie và cuối cùng lấy được giá trị bí mật.
Sau đó, anh ta cũng thiết lập một khoản thanh toán có điều kiện với Charlie theo cùng điều kiện, và Charlie cũng thiết lập một hợp đồng với Dave theo cùng điều kiện. Dave có giá trị bí mật, vì vậy khi anh ta tiết lộ giá trị bí mật, anh ta sẽ nhận được khoản thanh toán từ Charlie; sau đó, Charlie có thể đưa giá trị bí mật cho Bob và nhận được khoản thanh toán từ Bob; Bob sau đó có thể tìm thấy Alice. Tại thời điểm này, Alice nhận được giá trị bí mật, và Dave cũng nhận được khoản thanh toán. Giá trị bí mật này được gọi là "bằng chứng thanh toán".
Vậy là đã xong phần kiến thức cơ bản về Lightning Payments 101. Có hai điều bạn cần lưu ý ở đây (thực ra là cùng một điều), thứ nhất là Alice và Dave phải tương tác với nhau bên ngoài Mạng Lightning trước khi thanh toán thực sự diễn ra. Điều này đặt ra câu hỏi: tại sao lại như vậy?
Dave phải gửi một mã băm cho Alice, nhưng vấn đề không chỉ nằm ở mã băm. Đây chính là lúc hóa đơn BOLT11 xuất hiện.
Hóa đơn BOLT11
BOLT11 chỉ rõ cách Dave nên xây dựng thông tin anh ta gửi cho Alice. Vì vậy, bất kỳ ví Lightning nào cũng biết cách xây dựng thông tin này và cách đọc nó. Tôi khá chắc rằng tất cả các bạn đều đã thấy hóa đơn BOLT11, thường được hiển thị dưới dạng mã QR. Lưu ý rằng đây là hóa đơn từ mạng regtest, không an toàn để thanh toán, như tôi sẽ nói đến ngay sau đây.
Hãy cùng xem xét kỹ hơn hóa đơn BOLT11 trông như thế nào. Có tiền tố, cho biết đây là hóa đơn Lightning Network; sau đó là số tiền mà Dave mong đợi, dấu thời gian, một số mảng dữ liệu(tôi sẽ quay lại vấn đề này sau), và cuối cùng là chữ ký cho tất cả những thứ này.
Tôi đã đề cập trong đó dữ liệu là mã băm thanh toán, rất quan trọng vì đây là phương pháp duy nhất để đảm bảo tính toàn vẹn của khoản thanh toán, vì vậy đây là điều đầu tiên. Dữ liệu còn lại là ID nút.
Nếu Alice lần đầu tiên bước vào quán cà phê của Dave, cô ấy cần biết cách tìm nút của Dave trong Mạng Lightning, điều này yêu cầu ID nút. Một điều khác mà Dave có thể đưa vào hóa đơn là "Hop-Gợi ý", vì chế độ xem mạng của Alice có thể giống như thế này, và Dave chỉ có một kênh riêng tư, mà Alice không thể tìm thấy trong chế độ xem mạng công cộng, vì vậy Dave phải nói với cô ấy rằng anh ấy phải cho cô ấy biết UTXO trong kênh riêng tư để Alice có thể tìm thấy Dave.
Hóa đơn cần phải chứa những thông tin này. Nó cũng có thể chứa một mô tả, chẳng hạn như "Đây là một tách cà phê", và một số thông tin khác cho biết đặc điểm của nút, tương đương với việc Dave nói với Alice: "Tôi có thể chấp nhận thanh toán với những đặc điểm này", v.v.
Còn nhiều thứ khác nữa, nhưng bài nói chuyện hôm nay của tôi thế là đủ rồi. Vậy vấn đề ở đây là gì?
Mối quan tâm chính của tôi là: nó chỉ được thanh toán một lần. Tôi thường nghe mọi người nói: "Hóa đơn chỉ được thanh toán một lần nên không an toàn". Tôi chỉ muốn giải thích lý do tại sao.
Giả sử Alice và Bob cùng bước vào quán cà phê của Dave. Dave tạo hóa đơn vì anh ấy muốn nhận tiền. Hãy tạo hóa đơn BOLT11, hiển thị mã QR. Alice đang xếp hàng ký, vì vậy cô ấy trả tiền trước, như chúng ta đã thấy ở trên. Sau đó, Dave tiết lộ mã bí mật, nhờ đó Alice có bằng chứng thanh toán cho hóa đơn này. Nhưng tình cờ Bob cũng nhìn thấy hóa đơn cùng lúc và cho rằng nó dành cho mình, nên anh ấy cũng cố gắng thanh toán. Vì vậy, anh ấy cũng bước tới và quét mã để thanh toán.
Giờ thì, nếu Eve và Charlie là cùng một người, hoặc họ thông đồng với nhau, thì chuyện gì sẽ xảy ra? Charlie đã biết giá trị bí mật khi anh ta chuyển tiếp khoản thanh toán của Alice, và giờ anh ta chỉ cần gửi giá trị bí mật cho Eve, và họ nhận được tiền từ Bob. Bob cho rằng, "Tuyệt, mình đã có bằng chứng thanh toán rồi", nhưng Dave không được trả tiền. Anh ta chỉ được trả tiền một lần. Vì vậy, bạn có thể thấy rằng nếu bạn đang thanh toán hóa đơn, bạn phải đảm bảo rằng chưa có ai khác đã thanh toán trước đó. Điều này rất quan trọng.
Điều này dẫn tôi đến kết luận tiếp theo: đây là một bằng chứng thanh toán rất yếu. Như tôi vừa nói, cả Alice và Bob đều nhận được cùng một bằng chứng thanh toán. Vì vậy, trên thực tế, việc có một giá trị bí mật chỉ chứng minh rằng khoản thanh toán liên quan đã được hoàn tất tại một thời điểm nào đó, chứ không phải bạn đã thanh toán.
Còn một số vấn đề khác nữa. Tôi đã đề cập rằng Dave có thể cần phải thêm ghi chú nhảy vào hóa đơn. Nếu tất cả các kênh của anh ấy đều ở chế độ riêng tư, thì việc này chẳng khác nào tự bắn vào chân mình, vì chẳng còn kênh nào là riêng tư nữa. Alice có thể bán thông tin này. Vậy nên điều này cũng không lý tưởng.
Một vấn đề nữa là quyền riêng tư của người gửi và người nhận. Trong ví dụ này, tôi đã chỉ ra rằng khi Alice trả tiền cho Dave, Dave không có quyền riêng tư nào với Alice. Alice biết chính xác khoản thanh toán của mình sẽ đi đâu. Nhưng Alice có rất nhiều quyền riêng tư. Dave không biết khoản thanh toán cho anh ta đến từ đâu, trừ khi Alice muốn hoàn lại tiền, điều đó có nghĩa là cô ấy phải tiết lộ vị trí của mình trong mạng lưới; và điều này chắc chắn không phải là một lựa chọn tốt.
Một chi tiết nhỏ khác là chữ ký BOLT11 được thiết kế để chứng minh người phát hành đã tạo hóa đơn. Nó là chữ ký của toàn bộ hóa đơn (dưới dạng cấu trúc phẳng). Điều này không lý tưởng. Nếu bạn muốn chứng minh chữ ký là hợp lệ, bạn chỉ có thể hiển thị toàn bộ hóa đơn và hiển thị tất cả thông tin.
Một vấn đề khác là trải nghiệm người dùng kém. Đây là hóa đơn BOLT11 hợp lệ với 20 lần nhắc nhở. Như bạn thấy, điều này không lý tưởng. Người thanh toán không thể quét mã bằng điện thoại. Và điều này chứng tỏ mô hình xuất hóa đơn này rất hạn chế. Lượng thông tin mà Dave có thể hiển thị trực tiếp cho Alice rất hạn chế. Điều này hơi bất tiện.
Chúng ta đều quen với việc giữ tiền trong một tài khoản ngân hàng không thay đổi. Giờ đây, chúng ta phải nói với người dùng: "Này anh bạn, nếu anh muốn được trả tiền, người trả tiền cho anh phải chào anh trước, và anh phải yêu cầu nút của mình tạo một hóa đơn mới. Sau đó, anh cần gửi hóa đơn cho người đó, và nút của cô ấy sẽ trả tiền cho anh." Chẳng phải hơi kỳ quặc sao?
Một vấn đề khó xử khác là quy trình rút tiền. Giả sử Dave là một sàn giao dịch và bạn muốn rút tiền từ sàn giao dịch. Giả sử bạn tương tác với sàn giao dịch trên máy tính, nhưng nút của bạn lại nằm trên điện thoại. Giờ bạn phải tạo hóa đơn trên điện thoại, sau đó bằng cách nào đó tải hóa đơn về máy tính, rồi gửi cho Dave để anh ấy thanh toán cho bạn. Khó xử, vẫn khó xử.
Cuối cùng, chúng tôi đưa ra một số đề xuất để giải quyết vấn đề này.
LNURL
Tuy nhiên, nói vậy thôi, tôi vẫn chủ yếu quan tâm đến các kịch bản thanh toán, và tạm thời tôi sẽ không xem xét các kịch bản rút tiền. Vậy nên, "LNURL", đơn giản và đẹp mắt. LNURL về cơ bản là một tập hợp các thông số kỹ thuật chỉ định các phương thức giao tiếp khác nhau mà Alice và Dave có thể tương tác với nhau. Tất cả các phương thức giao tiếp mà nó chỉ định đều diễn ra bên ngoài Mạng Lightning. Điều nó có thể làm là trong kịch bản thanh toán, Dave có thể sử dụng máy chủ HTTP với điểm cuối mạng tĩnh, chẳng hạn như "dave.com/payme". Máy chủ HTTP này sẽ giao tiếp với nút của Dave.
Bây giờ, tất cả những gì Alice cần làm là tìm hiểu về điểm cuối này. Như bạn thấy, điểm cuối không cần phải thay đổi, nó có thể tĩnh, bạn có thể in ra, hoặc bạn có thể xăm nó lên người. Alice truy cập điểm cuối này, và máy chủ HTTP yêu cầu nút của Dave tạo hóa đơn và gửi lại, sau đó hóa đơn này sẽ được chuyển đến máy trạm của Alice. Bất kỳ ai cũng có thể truy cập điểm cuối này và đảm bảo rằng hóa đơn họ nhận được là duy nhất. Điều này thực sự tuyệt vời, như bạn thấy đấy, đơn giản và đẹp mắt.
Sau đó, những ý tưởng tương tự có thể được áp dụng cho quy trình rút tiền. Nếu bạn muốn biết thêm, hãy hỏi đội ngũ Coincorner ở trên, thẻ của họ sử dụng giao thức "LNURL-withdrawal". Về cơ bản, nó cho phép chúng tôi xuất trình mã như thế này và hiển thị cho khách hàng một cách an toàn. Bạn không thể làm điều đó với hóa đơn BOLT11, vì nó không an toàn. Đúng vậy, với LNURL, việc sử dụng điểm cuối tĩnh là an toàn.
Vậy nên, điều thú vị nữa là tôi có thể thay đổi các tham số của hóa đơn đằng sau nó, mà bản thân điểm cuối thì không cần phải thay đổi. Ví dụ, hôm nay tôi định giá một cốc bia là 10 satoshi, và ngày mai tôi định giá là 20 satoshi; nhưng bản thân điểm cuối thì không cần phải thay đổi, đúng không?
Sau đây là một plug-in nhỏ cho giao thức "LNURL-pay", được gọi là "Lightning Address". Nguyên lý hoạt động của nó hoàn toàn giống nhau, chỉ là dễ giải thích hơn qua điện thoại, và trông giống như một địa chỉ email.
Ưu và nhược điểm
Nó cực kỳ đơn giản và đã được đưa vào sử dụng. Nhiều ví đã tích hợp LNURL. Và không cần phải thay đổi Lightning Network hay BOLT11, vì giao tiếp diễn ra bên ngoài Lightning Network. Nó cung cấp cho chúng tôi hóa đơn tĩnh có thể được nhập bằng mã QR nhỏ hơn, và quy trình thanh toán rất đơn giản và dễ hiểu.
Một nhược điểm lớn là, như mọi người thường nói, bạn cần một máy chủ HTTP để sử dụng LNURL để thu tiền. Hơn nữa, nếu bạn không sử dụng Tor, bạn sẽ không hiểu tên miền và chứng chỉ TLS, v.v. Vâng, nó cũng không lý tưởng cho nút trên điện thoại của bạn (ví dụ).
Một vấn đề nữa là nếu bạn không sử dụng Tor, cả người gửi và người nhận đều sẽ bị rò rỉ thông tin riêng tư vì bạn có máy chủ này. Trước đó tôi đã đề cập rằng Alice rất thích nặc danh vì Dave không biết khoản thanh toán đến từ đâu. Nhưng giờ đây, cô ấy đang gửi yêu cầu đến máy chủ HTTP này trước, vì vậy cô ấy sẽ tiết lộ địa chỉ IP của mình.
Lời đề nghị
Tiếp theo là BOLT12, hay còn gọi là "Offer", một đề xuất rất lớn với rất nhiều tính năng bổ sung từ Rusty Russell, một kỹ sư tại Blockstream. Đúng vậy, xét về mặt trừu tượng, nó rất giống với LNURL, cả về quy trình làm việc lẫn kết quả cuối cùng, ngoại trừ một điểm: việc truy xuất hóa đơn mà tôi đã đề cập trong phần LNURL diễn ra trong mạng, nghĩa là bạn không cần thêm máy chủ HTTP nào nữa. Vì vậy, người dùng trên điện thoại di động có thể sử dụng nó. Sức mạnh của nó nằm ở chỗ, vâng, bạn không cần bất cứ thứ gì khác. Một khi bạn khởi động nút, nó đã sẵn sàng hoạt động.
Đây là một ví dụ rất thô sơ. Lần này, Dave sẽ tạo ra một thứ gọi là "Ưu đãi". Ưu đãi này có thể tĩnh, chứa đủ thông tin để Alice tìm thấy Dave trong mạng Lightning, nhưng không chứa bất kỳ thông tin nào cần phải liên tục thay đổi. Vì vậy, nó có thể tĩnh.
Sau đó, Alice có thể sử dụng thông tin này để tìm Dave trên Mạng Lightning và gửi cho anh ấy một "yêu cầu xuất hóa đơn". Khi nút của Dave nhận được thông báo này, nó sẽ gửi lại hóa đơn, cũng được truyền qua Mạng Lightning. Giờ đây, Alice có thể thanh toán hóa đơn.
Tuyệt vời, nghe có vẻ rất thú vị và đơn giản, nhưng vẫn còn lượng lớn việc phải làm để chương trình truy xuất hóa đơn này hoạt động trên Lightning Network. Chúng ta hãy cùng xem xét kỹ hơn.
Trước tiên, chúng ta cần có khả năng gửi tin nhắn như thế này. Giao tiếp trong Lightning Network. Vậy chúng ta có thể tận dụng các mẫu tin nhắn hiện có không?
Hiện tại, trong Lightning Network, chúng ta có "tin đồn". Có những tin nhắn mà bạn muốn phát sóng, bạn muốn nó tràn ngập toàn bộ mạng. Bạn muốn thông báo cho toàn bộ mạng: "Chào mọi người, đây là kênh mới, tôi là một nút mới, yêu cầu sử dụng kênh của tôi đã được cập nhật", v.v. Đây không phải là cách lý tưởng để yêu cầu hóa đơn. Chúng tôi không muốn toàn bộ mạng biết rằng chúng tôi đang yêu cầu hóa đơn, và chúng tôi chắc chắn không muốn toàn bộ mạng nhìn thấy hóa đơn này. Hơn nữa, tin đồn bị giới hạn tốc độ nghiêm ngặt. Lượng lớn nút sẽ xử lý các tin nhắn mà chúng muốn gửi đi theo nhóm, điều này rất chậm. Bạn phải chờ rất lâu, điều này cũng không lý tưởng trong trường hợp của chúng tôi.
Có một loại tin nhắn khác, đó là tin nhắn dành riêng cho thanh toán. Hãy sử dụng ví dụ trước của chúng ta. Khi gửi thanh toán, Alice phải cho Bob và Charlie biết nơi chuyển tiếp thanh toán và kênh nào để sử dụng. Điều này gần với những gì chúng ta muốn vì nó sẽ gửi tin nhắn theo đường dẫn cụ thể mà Alice chọn. Nhưng vấn đề là đó là tin nhắn dành riêng cho thanh toán, điều này sẽ kích hoạt quá trình thêm HTLC và quá trình vô hiệu hóa HTLC. Để sử dụng phương pháp này để gửi tin nhắn, bạn cần tạo một khoản thanh toán. Tuy nhiên, trên thực tế, mọi người đã gửi dữ liệu trong Mạng Lightning theo cách này. Chỉ tạo ra một khoản thanh toán giả và điền vào một giá trị băm ngẫu nhiên. Dave không biết nó sắp đến. Bạn thêm dữ liệu bạn muốn gửi vào tin nhắn dành riêng cho thanh toán, crypto nó (để chỉ Dave mới có thể giải mã) và gửi cho Dave. Khi Dave nhận được tin nhắn, anh ấy biết rằng mình không có giá trị bí mật nào cả, nhưng anh ấy có thể giải mã thông tin bạn đã đính kèm vào trong đó và khiến giao dịch thanh toán thất bại. Thao tác này sẽ gửi tin nhắn. Bạn chỉ cần khóa một lượng thanh khoản nhỏ và miễn là Dave trực tuyến thì sẽ không có vấn đề gì; nhưng nếu Dave ngoại tuyến, bạn sẽ phải đợi thời gian khóa tương đối của HTLC trong mỗi kênh trên đường đi hết hạn từng cái một, điều này không tốt cho mạng lưới.
Vâng, điều này có nghĩa là để Offer hoạt động, chúng ta cần một hệ thống truyền thông điệp hoàn toàn mới để gửi những loại tin nhắn mới này. Đó chính là lúc "Onion Messaging in Lightning" ra đời. Đúng vậy, BOLT12 được xây dựng trên Onion Messaging. Nó thực hiện chính xác như tên gọi. Nó cho phép Alice gửi tin nhắn đến một nút trong Mạng Lightning, và đường dẫn của tin nhắn sẽ do Alice quyết định.
Một số người có thể cho rằng đây là một trò lừa đảo, rằng để một tính năng cục bộ hoạt động, toàn bộ mạng lưới phải được cập nhật để hiểu được các thông điệp onion. Nhưng tôi cho rằng đây không phải là vấn đề lớn, bởi vì nếu chúng ta có thể hưởng lợi nhiều từ nó, và quy mô của Lightning Network vẫn còn hạn chế, chúng ta có thể nâng cấp nhanh chóng. Và mọi người nâng cấp rất nhanh.
Bạn có thể làm được nhiều hơn thế nữa với tin nhắn onion, không chỉ tin nhắn yêu cầu hóa đơn và tin nhắn trả lại hóa đơn mà chúng tôi đã đề cập trước đó; hãy nghĩ mà xem, bạn có thể gửi bất kỳ tin nhắn nào. Vậy nên, có rất nhiều thứ bạn có thể làm, nhưng tôi sẽ không đi sâu vào chi tiết ở đây, bạn có thể tiếp tục tập trung vào phần này.
Có thể bạn đã nghe quan điểm khác, đặc biệt là trên Twitter, rằng tính năng này (nhắn tin Onion) không nên được thêm vào vì nó sẽ tạo điều kiện cho các cuộc tấn công từ chối dịch vụ (DoS). Người dùng có thể đánh bom mạng, phát trực tuyến phim qua Lightning Network, v.v. Đây là mối lo ngại lớn của mọi người, và hiện tại vẫn chưa có giải pháp tích hợp nào cho Đề án này.
Một vấn đề nữa là Alice không thể - ít nhất là hiện tại - biết liệu tin nhắn đã được gửi hay chưa. Đây cũng ít nhiều là một vấn đề. Một vấn đề nữa là ở đây, Bob và Charlie đang giúp Alice miễn phí. Vì tin nhắn của Alice không liên quan đến bất kỳ khoản thanh toán nào, họ không có khích lệ thực sự nào để chuyển tiếp tin nhắn, trừ khi xuất phát từ ý tưởng: "Tôi đã giúp bạn lần này, và bạn sẽ giúp tôi trong tương lai". Chúng ta biết rằng điều này cũng đúng với việc chuyển tiếp các giao dịch trong mạng lưới Bitcoin.
Tôi cũng muốn nói rằng, hãy theo dõi thông tin này, vì trong hai tuần qua, đã có một số đề xuất nhằm bảo vệ giao diện khỏi các cuộc tấn công DoS.
Ưu đãi có một số tính năng bổ sung thực sự thú vị.
Trước tiên, tôi đã đề cập đến gợi ý hop và lý do tại sao chúng lại là một vấn đề (các UTXO mà ban đầu chúng tôi muốn giữ bí mật sẽ được tiết lộ). Vì vậy, thay vì gợi ý hop, Offer sử dụng một "đường dẫn ẩn". Về cơ bản, đây chính là cách Dave hướng dẫn Alice phương pháp tìm anh ta: Dave đưa ra một đường dẫn ẩn cho phép Alice liên lạc với anh ta trong mạng mà không tiết lộ vị trí của cô ấy trong mạng. Tôi sẽ không đi sâu vào chi tiết, nhưng nó thực sự đáng để nghiên cứu. Và điều này thật tuyệt vời vì giờ đây, Alice không cần biết vị trí chính xác của Dave để vẫn có thể trả tiền cho Dave. Sau đó, nếu Alice muốn hoàn tiền, cô ấy có thể cung cấp một đường dẫn ẩn để anh ta không phải tiết lộ nặc danh của mình.
Một điều thực sự thú vị khác là "Bằng chứng Người nhận". Trong yêu cầu hóa đơn mà Alice gửi cho Dave qua mạng, cô ấy đã bao gồm một khóa thuộc về mình, được gọi là "Khóa Người trả tiền". Khi Dave gửi lại hóa đơn, anh ấy cần phải xác nhận tin nhắn mà Alice đã gửi trước đó, và do đó cũng xác nhận khóa của Alice. Điều này có nghĩa là khi Alice nhận được S (giá trị bí mật đằng sau hàm băm), giá trị S này có thể chứng minh rằng cô ấy là người đã gửi khoản thanh toán, bởi vì chính hóa đơn chứng minh rằng cô ấy là người đã yêu cầu. Vì vậy, đây là một bằng chứng thanh toán tuyệt vời.
Ngoài ra, còn có chữ ký cho các thông báo chào hàng, hóa đơn và yêu cầu hóa đơn: nội dung được ký là giá trị gốc Merkle, không phải toàn bộ hóa đơn; Merkle trees được xây dựng từ tất cả các trường trong hóa đơn. Vì vậy, nếu bạn cần hiển thị hóa đơn cho ai đó, bạn chỉ có thể hiển thị những phần bạn muốn hiển thị.
Không chậm trễ trong thanh toán
Vâng, Offer không giải quyết được vấn đề thanh toán bị kẹt, nhưng tôi sẽ giải thích trước. Thanh toán bị kẹt là gì? Tôi bước vào một quán cà phê, nhận được hóa đơn, tôi bắt đầu thanh toán, và nó bị kẹt; vì vậy, tôi yêu cầu cửa hàng xuất cho tôi một hóa đơn khác, và nút của tôi bắt đầu thanh toán qua một đường dẫn khác, lần này thành công; nhưng tại thời điểm này, khoản thanh toán đầu tiên cũng báo cáo thành công.
Cửa hàng không thể biết tôi chỉ muốn thanh toán một lần. Vì vậy, Offer cũng tính đến điều này. Khi bạn yêu cầu xuất hóa đơn lần, bạn có thể nói: "Này, tôi muốn thay thế hóa đơn đầu tiên". Điều này vẫn khả thi, chỉ cần thêm một số khả năng từ chối hợp lý.
Và điều thú vị là bạn có thể chỉ định số tiền bằng các loại tiền tệ khác (không phải Bitcoin), điều này rất hữu ích cho các điểm cuối tĩnh, đặc biệt là khi giá cả biến động mạnh. Giờ đây, bạn đã có một điểm cuối tĩnh và có thể nói, "Tôi sẽ đánh dấu số tiền thanh toán bằng đô la Mỹ"; và sau đó điểm cuối này có thể được sử dụng mọi lúc. Khi mọi người, ví của người trả tiền cần có tỷ giá chuyển đổi để thanh toán.
Và Offer cũng có thể được sử dụng để hỗ trợ đăng ký. Ví dụ: đây là một Offer, nghĩa là bạn sẽ trả cho tôi một khoản phí đăng ký hàng tháng. Vân vân. Tuy nhiên, hiện tại, do vấn đề thời gian, tính năng này đã bị xóa.
Ưu và nhược điểm
Điểm tuyệt vời của Offer là nó được xây dựng trên nền tảng Lightning Network. Vì vậy, ngay khi bạn khởi động nút, bạn sẽ nhận được lợi ích này mà không cần phải lo lắng về việc sử dụng thêm máy chủ. Nhờ đường dẫn ẩn, cả người trả tiền và người nhận đều có quyền riêng tư tốt hơn. Và, một lần nữa, nhờ các điểm cuối tĩnh, chúng tôi có trải nghiệm người dùng tốt hơn và bằng chứng thanh toán tốt hơn.
Tất nhiên, nó cũng có một số nhược điểm, chẳng hạn như việc cần phải nâng cấp toàn bộ mạng, điều mà tôi đã đề cập, và cá nhân tôi không cho rằng đó là vấn đề lớn. Vấn đề hiện tại là chưa có giải pháp nào được thiết kế để bảo vệ chống DoS. Một điều khác mà mọi người thường nói là nó phụ thuộc vào nhiều yếu tố. Tôi đã đề cập đến các thông điệp onion và đường dẫn mù. Đúng vậy, nếu chúng ta muốn sử dụng offer, chúng ta phải triển khai rất nhiều thứ. Và nó cũng mang lại một số vấn đề ở cấp độ ứng dụng cho mạng, mà một số người không thích. Ví dụ, như tôi đã đề cập trước đó, việc sử dụng các loại tiền tệ khác để chỉ định số tiền.
Thanh toán đa đường nguyên tử (Amp)
Trước khi nói thêm, tôi muốn đề cập rằng sức mạnh thực sự của Amp nằm ở chỗ nó cho phép bạn sử dụng toàn bộ hoặc một phần kênh của mình để bắt đầu thanh toán. Và như một tác dụng phụ, bạn có thể sử dụng hóa đơn tĩnh.
Kịch bản đường dẫn đơn
Trước tiên, tôi sẽ nói về hóa đơn tĩnh. Hãy lấy ví dụ về một kịch bản thanh toán một đường dẫn. Ban đầu, Dave muốn tạo hóa đơn BOLT11; tôi đã giới thiệu những gì có trong hóa đơn BOLT11. Lý do bạn phải tạo hóa đơn mới lần là vì bạn cần thay đổi mã băm thanh toán để đảm bảo tính bảo mật.
Nhưng khi sử dụng Amp , hàm băm thanh toán sẽ vô nghĩa, Dave sẽ sử dụng bit tính năng trong hóa đơn để báo cho Alice biết đây là hóa đơn Amp và bạn có thể thanh toán lần một cách an toàn. Tất nhiên, nút của người thanh toán cần phải hiểu tính năng này.
Cho đến nay, chúng ta đã giả định rằng Dave luôn cần tạo một giá trị bí mật, tính toán giá trị băm và gửi giá trị băm đó cho Alice. Nhưng Amp đảo ngược mọi thứ: Alice tạo một giá trị bí mật và tính toán giá trị băm; cô ấy crypto giá trị bí mật để chỉ Dave mới có thể giải mã nó; sau đó, cô ấy tạo một thông điệp thanh toán cụ thể. Khi thông điệp thanh toán cụ thể được chuyển tiếp đến Dave, anh ấy có thể giải mã thông điệp, lấy giá trị bí mật ẩn trong trong đó, rồi sử dụng nó lĩnh nhận thanh toán; giá trị bí mật được gửi ngược lại.
Tuyệt, vậy là chúng ta có hai điều. Thứ nhất, Alice có thể thực hiện thanh toán trực tiếp mà không cần thông báo trước cho Dave. Điều này cho phép thanh toán tự động. Thứ hai, Alice không thể nhận được bằng chứng thanh toán. Vì cô ấy đã biết giá trị bí mật ngay từ đầu, nghĩa là giá trị bí mật cô ấy nhận được sau đó sẽ không có ý nghĩa gì.
Bây giờ, tôi muốn cho thấy vẻ đẹp thực sự của Amp và sử dụng hình ảnh để minh họa cách thức hoạt động của nó.
Alice có thể muốn sử dụng số dư của mình phân tán trên nhiều kênh khác nhau để thanh toán cho Dave. Vì vậy, trước tiên, cô ấy tạo ra một thứ gọi là "root Seed", một khối dữ liệu lớn. Sau đó, cô ấy sẽ tạo ra bốn giá trị bí mật khác nhau một cách xác định và tính toán giá trị băm của các giá trị bí mật này. Tại sao lại là bốn? Bởi vì cô ấy muốn sử dụng cả bốn kênh. Bây giờ, cô ấy chia root seed thành bốn phần. Trong đường dẫn đầu tiên để gửi thanh toán, cô ấy tạo ra một HTLC với giá trị băm đầu tiên và đính kèm phần đầu tiên của root seed. Khi khoản thanh toán này được gửi, Dave không thể lĩnh nhận khoản thanh toán vì anh ấy không biết giá trị bí mật đằng sau giá trị băm.
Chỉ khi cả bốn khoản thanh toán đều đến nơi, Dave mới có thể tái tạo lại hạt giống gốc, sau đó tạo ra bốn giá trị bí mật một cách xác định, rồi lĩnh nhận khoản thanh toán. Đây chính là điều tuyệt vời.
Lợi ích và Nhược điểm
Một lần nữa, hóa đơn tĩnh. Chỉ Alice và Dave cần hỗ trợ Amp. Điều này cho phép Alice thanh toán trực tiếp mà không cần liên hệ trước với Dave. Hơn nữa, chúng ta có thể sử dụng lại hóa đơn BOLT11. Bạn có thể sử dụng tất cả các kênh của mình, điều này rất tuyệt vì nếu người dùng mới đăng nhập, họ sẽ không biết "kênh" là gì; ứng dụng chỉ hiển thị số dư, và thực tế họ có quyền truy cập vào toàn bộ số dư. Tuy nhiên, một nhược điểm lớn là không có bằng chứng thanh toán.
Phần kết luận
Được rồi, vậy là xong. Bài nói chuyện này chỉ nhằm mục đích so sánh các giải pháp khác nhau ở mức độ trừu tượng. Sau đó, tôi muốn để lại một số câu hỏi cho các bạn.
Trước tiên, hãy xem xét các lớp bên trong của Mạng Lightning. BOLT1 đến BOLT11 hiện tại về cơ bản bao gồm các lớp này, bao gồm kết nối mạng, gửi tin nhắn, thanh toán và xây dựng hóa đơn. Tại thời điểm này, dù sao chúng ta cũng không thể tránh khỏi việc giao tiếp hóa đơn. Trên hết, chúng ta có thể phát triển các ứng dụng. Vậy, ba giải pháp được đề cập ở trên nằm ở những lớp nào?
LNURL chỉ xác định giao tiếp hóa đơn, ít nhất thì giao thức "LNURL-pay" mà tôi đã đề cập trước đó cũng chỉ làm được điều này. Amp chỉ là một hình thức thanh toán mới. Nhưng Offer lại trải dài trên nhiều lớp. Nó liên quan đến nhiều thứ.
Bản thân đặc tả Offer không bao gồm điều này, nhưng nó dựa trên Onion Messaging. Nó cũng sử dụng định dạng hóa đơn khác với BOLT11, do đó bao gồm một cấu trúc hóa đơn mới. Nó cũng chỉ định giao tiếp hóa đơn. Và nó cũng bao gồm một số tính năng ở tầng ứng dụng, chẳng hạn như chỉ định số tiền thanh toán bằng các loại tiền tệ khác.
Vậy nên có một vài điểm cần thảo luận. Nếu bạn theo dõi cuộc tranh luận trên Twitter, có một vài điều mọi người thường thảo luận:
Đầu tiên là tầm quan trọng của bằng chứng thanh toán. Tôi đã đề cập rằng bằng chứng thanh toán hiện tại do hóa đơn BOLT11 cung cấp tương đối yếu. Amp không có bằng chứng thanh toán. Taproot và PTLC (hợp đồng khóa thời gian điểm) sẽ thay đổi tất cả những điều này, chúng sẽ mang đến bằng chứng thanh toán rất mạnh. Nhưng mọi người vẫn tranh cãi về điều đó. Một bên sẽ nói, vâng, rõ ràng bằng chứng thanh toán rất quan trọng, bởi vì khi mạng lưới trở nên rất lớn, bạn sẽ thực sự, thực sự, thực sự muốn có bằng chứng thanh toán. Và bên kia sẽ nói, mọi người sử dụng bằng chứng thanh toán như thế nào bây giờ? Họ sử dụng nó thường xuyên như thế nào? Bạn biết đấy, nhiều ví thậm chí không hiển thị hình ảnh thanh toán trước cho người dùng. Vì vậy, hai bên đã tranh luận.
Một vấn đề khác sẽ được tranh luận là những gì nên đưa vào giao thức và những gì không nên đưa vào giao thức? Ranh giới giữa chúng được đặt ra ở đâu?
Ngoài ra, chúng ta có cần phải duy trì một hệ thống lập hóa đơn duy nhất không? Chúng ta có thể kết hợp chúng lại với nhau được không?
Liệu chúng ta có cần một hệ thống có thể phục vụ mọi loại người dùng không? Ví dụ, mọi người nói rằng LNURL rất thân thiện với các nhà bán lẻ vì họ luôn vận hành máy chủ, nhưng lại không thân thiện với những người dùng chỉ muốn sử dụng ví trên điện thoại di động. Đúng vậy, LNURL hoạt động rất tốt ở phía nhà bán lẻ, còn Offer lại rất thân thiện với người dùng sử dụng Lightning Network trên điện thoại di động. Vậy, liệu chúng ta có thể có cả hai không? Liệu chúng ta có cần đảm bảo rằng chỉ có một giải pháp duy nhất không?
Tôi rất quan tâm đến những câu hỏi này nên tôi xin nhường lại cho bạn. Cảm ơn.
(qua)
