엘 무통 지음
출처: https://btctranscripts.com/advancing-bitcoin/2022/static-invoices-in-lightning
이 기사는 b3h3rkz가 필사한, 엘 무통의 Advancing Bitcoin 2022 컨퍼런스 연설 전문입니다.
소개
안녕하세요, 저는 엘입니다. 라이트닝 네트워크의 정적 송장에 대해 이야기해 보겠습니다. 아마 대부분 아시겠지만, 현재 라이트닝 네트워크에서는 지급을 받으려면 매번 새로운 "송장"을 생성해야 합니다. 라이트닝 네트워크에 대해 아무것도 모르는 사람들에게는 이것이 장벽이 될 수 있습니다. 오늘은 정적 송장을 지향해야 하는 이유와 함께, 사람들이 논의해 온 세 가지 제안, 즉 LNURL, Offer, 그리고 AMP에 대해 간략하게 설명하겠습니다.
자, 이건 간략한 개요일 뿐입니다. 모든 사람이 문제가 무엇인지 이해하는 것이 정말 중요하다고 생각합니다. 그래서 라이트닝 결제에 대해 잠시 소개하겠습니다. 심층적인 내용은 아니지만, 라이트닝 네트워크를 통해 결제가 이루어지기 위한 전제 조건이 무엇인지 모두가 이해할 수 있도록 간략하게 설명드리겠습니다. 그런 다음 BOLT11 송장의 역할에 대해 알아보겠습니다. 그리고 이러한 것들의 단점을 살펴보고 위에서 언급한 제안들을 살펴보겠습니다. 마지막으로 전체적인 내용을 요약하고 트위터에서 사람들이 논의해 온 주장들을 검토하겠습니다. 마지막으로 몇 가지 미해결 문제를 나열하겠습니다.
라이트닝 결제 101
자, 시작해 볼까요? 아마 다들 아시겠지만, 라이트닝 네트워크는 여러 채널로 구성되어 있습니다. "채널"은 앨리스와 밥 사이의 계약으로, 2대 2 다중 서명 스크립트를 기반으로 두 사람이 원하는 만큼, 매우 빠르게, 그리고 오프체인으로 가치를 전송할 수 있도록 해줍니다. 정말 멋진 기능입니다. 라이트닝 네트워크에서 두 사람 사이에 채널이 있다면, 정적 송장 문제는 발생하지 않으므로, 바로 발표를 마칠 수 있습니다.
하지만 만약 그렇다면 라이트닝 네트워크는 확장성이 없을 것입니다. 지불하거나 지불을 요청하는 모든 사람에게 채널을 열 수는 없기 때문입니다(각 채널은 UTXO입니다). 따라서 이 모델은 전혀 작동하지 않습니다. 라이트닝 네트워크의 장점은 앨리스의 관점이 이와 비슷하다는 것입니다. 앨리스가 데이브에게 지불하고 싶다면 (데이브와 직접 채널을 열 필요 없이) 네트워크를 통해 데이브에게 가는 경로만 찾으면 됩니다.
좀 더 자세히 보세요. 앨리스는 데이브에게 도달할 경로를 찾고 있고, 그 경로에만 집중하면 됩니다. 그렇다면 앨리스는 데이브에게 어떻게 돈을 지불할까요? 왜 이 과정은 고정되어 있을 수 없는 걸까요? 왜 자신의 노드에 "이 사람(데이브의 노드 ID)에게 이 금액의 비트코인을 지불해 주세요"라고 명령할 수 없는 걸까요? 그건 고정되어 있습니다.
가장 순진한 방법은 앨리스가 밥에게 연락하는 것입니다. "밥, 제발 도와주세요. 내가 비트코인을 좀 줄게요. 밥은 그중에서 일부를 빼서 찰리에게 주고, 찰리는 다시 그중에서 일부를 빼서 데이브에게 주세요." 잘됐네요. 데이브는 돈을 받습니다. 하지만 이 방법도 효과가 없습니다. 비트코인 세계에서는 밥을 믿을 수 없기 때문입니다. 사실 앨리스가 밥에게 이렇게 돈을 준다고 해서 밥이 돈을 가지고 도망가는 것을 막을 수 있는 것은 없습니다. 따라서 라이트닝 네트워크 결제도 이런 식으로는 작동하지 않습니다.
그렇다면 어떻게 작동할까요? 사실, 결제가 시작되기 전, 간단히 말해서 라이트닝 네트워크를 사용하기 전에 앨리스는 "데이브, 내가 돈을 낼 테니 잘 들어."라고 말합니다. 데이브는 앨리스의 말을 이해하고 비밀 값을 생성한 다음, 비밀 값의 해시값을 앨리스에게 다시 보냅니다. 이 모든 과정은 라이트닝 네트워크 밖에서 일어납니다. 이제 앨리스는 밥을 다시 찾습니다. 하지만 이번에는 앨리스가 "밥, 이 해시값 뒤에 있는 원본 이미지를 찾으면 내가 준 3 BTC를 얻을 수 있어. 만약 답을 찾지 못하면, 일정 시간 후에 내 돈을 돌려줄게."라고 말할 것입니다. 이 정보를 본 밥은 앨리스의 돈을 얻으려면 같은 패턴을 반복해서 찰리를 찾고, 마침내 비밀 값을 얻어내야만 한다는 것을 알게 됩니다.
그런 다음 그는 찰리와 동일한 조건으로 조건부 지불을 체결하고, 찰리는 데이브와도 동일한 조건으로 계약을 체결합니다. 데이브는 비밀 값을 가지고 있으므로 비밀 값을 공개하면 찰리로부터 지불을 받습니다. 찰리는 밥에게 비밀 값을 제공하고 밥에게서 지불을 받습니다. 밥은 앨리스를 찾을 수 있습니다. 이 시점에서 앨리스는 비밀 값을 얻고 데이브도 지불을 받습니다. 이 비밀 값을 우리는 "지불 증거"라고 부릅니다.
라이트닝 결제 101에 대한 설명은 여기까지입니다. 여기서 알아두셔야 할 두 가지 사항이 있습니다(사실은 같은 내용입니다). 첫째, 앨리스와 데이브는 라이트닝 네트워크 외부에서 서로 소통해야 결제가 실제로 이루어진다는 것입니다. 그렇다면 왜 이런 일이 발생하는 걸까요?
데이브는 앨리스에게 해시값을 전달해야 하는데, 해시값만 중요한 게 아닙니다. 바로 이 부분에서 BOLT11 송장이 등장합니다.
BOLT11 송장
BOLT11은 데이브가 앨리스에게 보내는 정보를 어떻게 구성해야 하는지 명시합니다. 따라서 모든 라이트닝 지갑은 이 정보를 어떻게 구성하고 읽는지 알고 있습니다. BOLT11 송장은 보통 QR 코드로 표시되는 것을 보셨을 겁니다. 이 송장은 regtest 네트워크에서 발행된 것으로, 결제가 안전하지 않습니다. 곧 자세히 설명하겠습니다.
BOLT11 송장의 모양을 자세히 살펴보겠습니다. 라이트닝 네트워크 송장임을 나타내는 접두사가 있고, Dave가 예상하는 금액, 타임스탬프, 데이터 배열(나중에 다시 설명하겠습니다), 그리고 이 모든 항목에 대한 서명이 있습니다.
데이터 중 하나는 결제 해시라고 말씀드렸는데, 결제 해시는 결제 무결성을 보장하는 유일한 방법이기 때문에 매우 중요합니다. 따라서 이 부분을 가장 먼저 살펴보겠습니다. 다른 데이터는 노드 ID입니다.
앨리스가 데이브의 카페에 처음 방문하면 라이트닝 네트워크에서 데이브의 노드를 찾는 방법을 알아야 하는데, 이를 위해서는 노드 ID가 필요합니다. 데이브가 청구서에 포함할 수 있는 또 다른 정보는 "홉 힌트"입니다. 앨리스의 네트워크 뷰가 이와 같을 수 있고, 데이브는 개인 채널만 가지고 있는데, 앨리스는 공개 네트워크 뷰에서 이를 찾을 수 없기 때문입니다. 따라서 데이브는 앨리스가 데이브를 찾을 수 있도록 개인 채널의 UTXO를 알려줘야 합니다.
송장에는 이러한 내용이 포함되어야 합니다. 또한 "커피 한 잔 값입니다"와 같은 설명이나 노드의 특성을 나타내는 다른 정보도 포함될 수 있습니다. 이는 데이브가 앨리스에게 "이러한 특성으로 결제를 받을 수 있습니다"라고 말하는 것과 같습니다.
다른 것들도 있지만, 오늘 제 강연에서는 이 정도면 충분합니다. 그럼 뭐가 문제일까요?
제가 가장 걱정되는 건 바로 이거예요. 일회성이라는 거죠. "송장은 일회성이니까 안전하지 않아요."라는 말을 자주 듣습니다. 그 이유를 설명해 드리고 싶습니다.
앨리스와 밥이 데이브의 카페에 들어갔다고 가정해 보겠습니다. 데이브는 결제를 받기 위해 송장을 생성합니다. BOLT11 송장을 생성하고 QR 코드를 표시합니다. 앨리스는 서명하기 위해 줄을 서 있었기 때문에 위에서 보았듯이 먼저 결제합니다. 그런 다음 데이브는 비밀 값을 공개하여 앨리스가 이 송장에 대한 결제 증빙을 얻습니다. 그런데 밥도 동시에 그 송장을 보고 자기 것이라고 생각하여 결제를 시도합니다. 밥도 앞으로 나아가 코드를 스캔하여 결제합니다.
자, 이브와 찰리가 동일인이거나 공모했다면 어떨까요? 찰리는 앨리스에게 송금할 때 이미 비밀 값을 알고 있는데, 이제 그 비밀 값을 이브에게 보내면 밥에게서 돈을 받게 됩니다. 밥은 "잘됐네, 송금 증빙을 받았네."라고 생각하지만, 데이브는 돈을 받지 못합니다. 그는 한 번만 돈을 받습니다. 따라서 송장을 결제할 때는 다른 사람이 이전에 결제한 적이 없는지 확인해야 합니다. 이는 매우 중요합니다.
이것으로 저는 다음 결론에 도달합니다. 이것은 매우 취약한 지불 증명입니다. 방금 말씀드렸듯이 앨리스와 밥은 모두 동일한 지불 증명을 받습니다. 따라서 실제로 비밀 값을 가지고 있다는 것은 해당 지불이 어느 시점에 완료되었다는 것을 증명할 뿐, 실제로 지불했다는 것을 증명하지는 못합니다.
몇 가지 다른 문제가 있습니다. 앞서 데이브가 송장에 이동 메모를 포함해야 할 수도 있다고 말씀드렸죠. 만약 그의 모든 채널이 비공개라면, 더 이상 비공개 채널이 아니기 때문에 자업자득입니다. 앨리스는 이 정보를 팔 수도 있습니다. 그러니 이것도 이상적이지 않습니다.
또 다른 문제는 발신자와 수신자의 프라이버시입니다. 이 예시에서 앨리스가 데이브에게 돈을 지불할 때 데이브는 앨리스로부터 프라이버시를 전혀 확보하지 못한다는 것을 보여주었습니다. 앨리스는 자신의 돈이 어디로 가는지 정확히 알고 있습니다. 하지만 앨리스는 상당한 프라이버시를 확보합니다. 데이브는 앨리스가 환불을 원하지 않는 한, 자신에게 지불되는 돈이 어디에서 오는지 알 수 없습니다. 환불을 원한다면 앨리스는 네트워크에서 자신의 위치를 공개해야 하므로, 이는 결코 좋은 선택이 아닙니다.
또 다른 작은 세부 사항은 BOLT11 서명이 발행자가 송장을 생성했음을 증명하기 위해 설계되었다는 것입니다. 이는 송장 전체에 대한 서명(평면 구조)입니다. 이는 이상적이지 않습니다. 서명이 유효함을 보여주려면 송장 전체만 표시하고 모든 정보를 노출해야 합니다.
또 다른 문제는 사용자 경험이 좋지 않다는 것입니다. 이 송장은 20개의 점프 프롬프트가 있는 유효한 BOLT11 송장입니다. 보시다시피, 이 송장은 이상적이지 않습니다. 납부자가 휴대폰으로 코드를 스캔할 수 없습니다. 이는 이러한 송장 제시 모델이 매우 제한적임을 보여줍니다. 데이브가 앨리스에게 직접 보여줄 수 있는 정보의 양이 매우 제한적입니다. 이는 다소 불편합니다.
우리는 모두 변하지 않는 은행 계좌에 돈을 넣어두는 것에 익숙합니다. 이제 사용자들에게 "이봐요, 돈을 받으려면 돈을 지불하는 사람이 먼저 인사를 해야 하고, 그러면 노드에서 새 송장을 생성해야 해요. 그런 다음 그 사람에게 송장을 보내면, 그 사람이 노드에서 돈을 지불하게 됩니다."라고 말해야 하죠. 좀 어색하지 않나요?
또 다른 불편한 점은 출금 절차입니다. 예를 들어 데이브가 거래소 이고 당신이 거래소 에서 돈을 인출하려고 한다고 가정해 보겠습니다. 컴퓨터로 거래소 와 소통하지만, 당신의 노드는 휴대폰에 있다고 가정해 보겠습니다. 이제 휴대폰에서 송장을 생성한 다음, 어떻게든 컴퓨터로 송장을 전송하고 데이브에게 보내서 그가 당신에게 돈을 지불할 수 있도록 해야 합니다. 어색하고, 여전히 불편합니다.
마지막으로, 이 문제를 해결하기 위한 몇 가지 제안을 살펴보겠습니다.
LNURL
하지만 그럼에도 불구하고, 저는 여전히 결제 시나리오에 주로 집중하고 있으며, 당분간 출금 시나리오는 고려하지 않겠습니다. 따라서 "LNURL"은 간단하고 아름답습니다. LNURL은 기본적으로 앨리스와 데이브가 서로 상호 작용할 수 있는 다양한 통신 방법을 명시하는 일련의 명세입니다. LNURL이 명시하는 모든 통신 방법은 라이트닝 네트워크 외부에서 이루어집니다. LNURL이 할 수 있는 것은 결제 시나리오에서 데이브가 "dave.com/payme"와 같은 정적 네트워크 엔드포인트를 가진 HTTP 서버를 사용할 수 있다는 것입니다. 이 HTTP 서버는 데이브의 노드와 통신합니다.
이제 앨리스는 이 엔드포인트에 대해 아는 것만으로도 충분합니다. 보시다시피, 엔드포인트는 변경할 필요가 없습니다. 고정된 상태일 수도 있고, 인쇄할 수도 있고, 몸에 문신을 할 수도 있습니다. 앨리스가 이 엔드포인트를 방문하면 HTTP 서버는 데이브의 노드에 송장을 생성하여 다시 보내도록 요청하고, 이 송장은 앨리스의 클라이언트로 전달됩니다. 누구든 이 엔드포인트를 방문하여 자신이 받는 송장이 고유한지 확인할 수 있습니다. 보시다시피, 이 기능은 정말 훌륭하고 간단하면서도 아름답습니다.
비슷한 아이디어를 출금 프로세스에도 적용할 수 있습니다. 더 자세한 내용은 위의 Coincorner 팀에 문의하세요. Coincorner 카드는 "LNURL-withdrawal" 프로토콜을 사용합니다. 기본적으로 이 프로토콜을 통해 이와 같은 코드를 제시하고 고객에게 안전하게 보여줄 수 있습니다. BOLT11 송장은 안전하지 않으므로 그렇게 할 수 없습니다. 네, LNURL을 사용하면 정적 엔드포인트를 사용하는 것이 안전합니다.
흥미로운 점은 송장의 매개변수를 변경해도 엔드포인트 자체는 변경할 필요가 없다는 것입니다. 예를 들어, 오늘은 맥주 가격을 10사토시로 책정하고, 내일은 20사토시로 책정한다고 가정해 보겠습니다. 하지만 엔드포인트 자체는 변경할 필요가 없겠죠?
다음은 "LNURL-pay" 프로토콜용 작은 플러그인으로, "라이트닝 주소"라고 합니다. 원리는 완전히 동일하며, 전화로 설명하기가 더 쉽고 이메일 주소처럼 보입니다.
장단점
놀랍도록 간단하며 이미 서비스 중입니다. 많은 지갑이 이미 LNURL을 통합했습니다. 라이트닝 네트워크나 BOLT11을 변경할 필요가 없습니다. 라이트닝 네트워크 외부에서 통신이 이루어지기 때문입니다. 더 작은 QR 코드에 넣을 수 있는 고정 송장이 제공되며, 결제 절차도 간단하고 이해하기 쉽습니다.
가장 큰 단점 중 하나는, 사람들이 흔히 말하듯이 LNURL을 사용하여 결제를 받으려면 HTTP 서버가 필요하다는 것입니다. 게다가 Tor를 사용하지 않으면 도메인 이름과 TLS 인증서 등을 이해하지 못하게 됩니다. 네, 휴대폰 노드에도 적합하지 않습니다(예를 들어).
또 다른 문제는 Tor를 사용하지 않으면 발신자와 수신자 모두 이 서버를 사용하기 때문에 개인 정보가 유출될 수 있다는 것입니다. 앞서 앨리스는 데이브가 결제 수단의 출처를 모르기 때문에 익명성을 매우 중시한다고 말씀드렸습니다. 하지만 이제 앨리스는 먼저 이 HTTP 서버에 요청을 보내므로 IP 주소가 노출됩니다.
권하다
BOLT12는 "Offer"로 더 잘 알려져 있는데, Blockstream의 엔지니어인 Rusty Russell이 제안한 매우 방대한 규모의 제안서입니다. 네, 매우 추상적인 관점에서 보면 워크플로와 최종 결과 측면에서 LNURL과 매우 유사합니다. 다만 한 가지 차이점이 있습니다. LNURL 섹션에서 언급했던 송장 검색이 네트워크 내에서 이루어지기 때문에 추가 HTTP 서버가 필요하지 않습니다. 따라서 모바일 사용자도 사용할 수 있습니다. 이 기능의 장점은 다른 것이 필요하지 않다는 것입니다. 노드를 시작하면 바로 사용할 수 있습니다.
아주 간단한 예를 하나 들어보겠습니다. 이번에 데이브가 할 일은 "제안"이라는 것을 만드는 것입니다. 이 제안은 정적일 수 있으며, 앨리스가 라이트닝 네트워크에서 데이브를 찾을 수 있을 만큼 충분한 정보를 포함하지만, 계속 변경되어야 하는 내용은 포함하지 않습니다. 즉, 정적일 수 있습니다.
앨리스는 이 정보를 사용하여 라이트닝 네트워크에서 데이브를 찾아 "송장 요청"을 보낼 수 있습니다. 데이브의 노드가 이 메시지를 수신하면 송장을 다시 보내는데, 이 역시 라이트닝 네트워크를 통해 전송됩니다. 이제 앨리스는 송장을 지불할 수 있습니다.
좋습니다. 정말 멋지고 간단해 보이지만, 이 송장 검색 프로그램을 라이트닝 네트워크에서 작동시키려면 아직 해야 할 일이 대량. 자세히 살펴보겠습니다.
먼저, 이런 메시지를 보낼 수 있어야 합니다. 라이트닝 네트워크로 통신해야 하죠. 좋아요, 그럼 기존 메시징 패턴을 활용할 수 있을까요?
현재 라이트닝 네트워크에서는 "가십 메시지"가 사용됩니다. 브로드캐스트하고 싶은 메시지가 있고, 전체 네트워크에 플러딩되기를 원합니다. 전체 네트워크에 "안녕하세요, 새로운 채널입니다. 저는 새로운 노드입니다. 채널 사용 요건이 업데이트되었습니다"와 같은 메시지를 전달하고 싶을 수 있습니다. 하지만 이는 송장을 요청하는 이상적인 방법이 아닙니다. 전체 네트워크에 송장을 요청한다는 사실을 알리고 싶지 않고, 또한 전체 네트워크에 이 송장이 노출되는 것도 원치 않습니다. 또한, 가십 메시지는 전송 속도에 상당한 제한이 있습니다. 대량 노드가 전송하려는 가십 메시지를 일괄 처리해야 하므로 속도가 매우 느립니다. 또한 오랜 시간 기다려야 하므로 저희 시나리오에서는 바람직하지 않습니다.
결제 전용 메시지라는 또 다른 유형의 메시지가 있습니다. 이전 예를 사용해 보겠습니다. 결제를 보낼 때 Alice는 Bob과 Charlie에게 결제를 어디로 전달할지, 어떤 채널을 사용할지 알려야 합니다. 이 방법은 Alice가 선택한 특정 경로를 따라 메시지를 보내기 때문에 우리가 원하는 것에 더 가깝습니다. 하지만 문제는 이 메시지가 결제 전용 메시지라는 점인데, 이로 인해 HTLC 추가 프로세스와 HTLC 무효화 프로세스가 트리거됩니다. 이 방법을 사용하여 메시지를 보내려면 결제를 생성해야 합니다. 하지만 실제로 사람들은 이런 방식으로 Lightning Network에서 데이터를 보냈습니다. 가짜 결제를 하고 임의의 해시 값을 입력하기만 하면 됩니다. Dave는 그 값이 오는지 전혀 모릅니다. 보낼 데이터를 결제 전용 메시지에 추가하고 암호화하여(Dave만 해독할 수 있도록) Dave에게 보냅니다. Dave가 메시지를 받으면 비밀 값을 전혀 가지고 있지 않다는 것을 알지만, 메시지에 첨부한 정보를 해독하여 결제를 실패하게 만들 수 있습니다. 이렇게 메시지가 전송됩니다. 소량의 유동성만 잠그면 되고, 데이브가 온라인 상태인 한 문제가 없습니다. 하지만 데이브가 오프라인 상태라면 각 채널의 HTLC 상대 시간 잠금이 하나씩 만료될 때까지 기다려야 하므로 네트워크에 좋지 않습니다.
즉, Offer가 작동하려면 이러한 새로운 유형의 메시지를 전송할 완전히 새로운 메시징 시스템이 필요합니다. 바로 이 부분에서 "라이트닝 어니언 메시징"이 등장합니다. 네, BOLT12는 어니언 메시징을 기반으로 구축되었습니다. 이름 그대로, 앨리스가 라이트닝 네트워크의 노드로 메시지를 보낼 수 있도록 해주며, 메시지의 경로는 앨리스가 결정합니다.
어떤 사람들은 이것이 사기라고 말할지도 모릅니다. 로컬 기능이 작동하려면 양파 메시지를 이해할 수 있도록 전체 네트워크를 업데이트해야 하기 때문입니다. 하지만 저는 이것이 큰 문제가 아니라고 생각합니다. 라이트닝 네트워크의 규모가 제한적이더라도 이를 통해 많은 이점을 얻을 수 있다면 빠르게 업그레이드할 수 있기 때문입니다. 그리고 사람들은 정말 빠르게 업그레이드합니다.
양파 메시지로는 앞서 언급했던 송장 요청 메시지와 송장 반송 메시지 외에도 훨씬 더 많은 작업을 할 수 있습니다. 어떤 메시지든 보낼 수 있다는 점을 생각해 보세요. 할 수 있는 일은 많지만, 여기서는 자세히 설명하지 않겠습니다. 이 부분에 집중하시면 됩니다.
특히 트위터에서 들어보셨을 법한 다른 관점 있습니다. 사람들은 이 기능(어니언 메시징)이 DoS(서비스 거부 공격)를 허용할 수 있기 때문에 추가해서는 안 된다고 종종 주장합니다. 누군가 네트워크를 폭격할 수도 있고, 라이트닝 네트워크를 통해 영화를 스트리밍할 수도 있습니다. 이는 사람들이 크게 우려하는 부분이며, 현재 제안된 내용에 대한 해결책은 아직 없습니다.
또 다른 문제는 앨리스가 - 적어도 현재로서는 - 메시지가 전달되었는지 알 수 없다는 것입니다. 이 또한 어느 정도 문제가 됩니다. 또 다른 문제는 밥과 찰리가 앨리스를 무료로 돕고 있다는 것입니다. 앨리스의 메시지는 결제와 관련이 없기 때문에, "이번에는 내가 널 도왔고, 앞으로도 네가 나를 도울 거야"라는 생각에서 비롯된 것이 아니라면, 메시지를 전달할 실질적인 동기가 없습니다. 비트코인 네트워크에서 거래를 전달하는 경우에도 이러한 상황이 발생한다는 것을 우리는 알고 있습니다.
또한, 이 공간에 계속 주목해 주시기 바랍니다. 지난 2주 동안 DoS 공격으로부터 인터페이스를 보호하기 위한 몇 가지 제안이 있었습니다.
이 상품에는 정말 멋진 추가 기능이 몇 가지 있습니다.
먼저, 홉 힌트와 그 문제점에 대해 이미 설명했습니다(원래 비공개로 유지하려던 UTXO가 공개될 예정입니다). 따라서 Offer는 홉 힌트 대신 "블라인드 경로"를 사용합니다. 이는 기본적으로 Dave가 Alice에게 자신을 찾는 방법을 알려주는 방식입니다. Dave는 Alice가 네트워크에서 자신의 위치를 공개하지 않고도 자신에게 연락할 수 있도록 블라인드 경로를 제공합니다. 자세히 설명하지는 않겠지만, 정말 살펴볼 가치가 있습니다. 그리고 이 기능은 Alice가 Dave에게 돈을 지불하기 위해 Dave의 정확한 위치를 알 필요가 없다는 점에서 매우 유용합니다. 따라서 Alice가 환불을 원할 경우, 익명성을 포기하지 않도록 블라인드 경로를 제공할 수 있습니다.
또 다른 멋진 기능은 "수취인 증명(Proof of Payee)"입니다. 앨리스가 네트워크를 통해 데이브에게 보내는 송장 요청에는 "지불자 키(Payer Key)"라는 자신의 키가 포함되어 있습니다. 데이브가 송장을 다시 보낼 때, 앨리스가 이전에 보낸 메시지를 확인하고 앨리스의 키에도 커밋해야 합니다. 즉, 앨리스가 해시 값 뒤에 숨겨진 비밀 값인 S 받으면, 이 S 값이 앨리스가 결제를 보낸 사람임을 증명할 수 있습니다. 송장 자체가 앨리스가 결제를 요청했음을 증명하기 때문입니다. 따라서 이는 훌륭한 결제 증명입니다.
또한, 제안, 송장 및 송장 요청 메시지에 대한 서명이 있습니다. 서명되는 것은 송장 전체가 아닌 머클 루트 값입니다. 머클 트리는 송장의 모든 필드로 구성됩니다. 따라서 누군가에게 송장을 보여줘야 할 경우, 보여주고 싶은 부분만 보여줄 수 있습니다.
지불 지연 없음
음, Offer가 결제 중단 문제를 해결하지는 못하지만, 먼저 설명해 드리겠습니다. 결제 중단이란 무엇일까요? 카페에 들어가 송장을 받고 결제를 시작했는데, 결제가 중단되었습니다. 그래서 매장에 다시 송장을 보내달라고 요청했고, 제 노드는 다른 경로를 통해 결제를 시작했는데, 이번에는 성공했습니다. 하지만 이 시점에서는 첫 번째 결제도 성공으로 보고되었습니다.
매장에서는 제가 한 번만 결제하고 싶다는 것을 알 수 없습니다. 따라서 Offer도 이 점을 고려합니다. 따라서 두 번째 송장 요청을 할 때 "첫 번째 송장을 교체하고 싶습니다."라고 말할 수 있습니다. 여전히 가능하지만, 그럴듯한 거부 기능을 추가하면 됩니다.
흥미로운 점은 비트코인이 아닌 다른 통화로 금액을 지정할 수 있다는 점입니다. 이는 특히 가격 변동이 심한 정적 엔드포인트에 유용합니다. 이제 정적 엔드포인트가 생겼고, "결제 금액을 미국 달러로 표시하겠습니다"라고 말할 수 있습니다. 그러면 이 엔드포인트를 항상 사용할 수 있습니다. 결제자의 지갑은 결제를 위해 환율이 필요합니다.
Offer는 구독을 지원하는 데에도 사용할 수 있습니다. 예를 들어, Offer는 매달 구독료를 제공한다는 의미입니다. 이런 식으로 말이죠. 하지만 현재 시간적 문제로 인해 이 기능은 삭제되었습니다.
장단점
Offer의 장점은 라이트닝 네트워크에서 기본적으로 제공된다는 것입니다. 노드를 시작하는 순간부터 추가 서버 사용에 대한 걱정 없이 이러한 이점을 누릴 수 있습니다. 블라인드 경로 덕분에 지불자와 수신자 모두 더 나은 개인 정보 보호 기능을 누릴 수 있습니다. 또한, 정적 엔드포인트 덕분에 더 나은 사용자 경험과 더 나은 결제 증명 기능을 제공합니다.
물론, 전체 네트워크를 업그레이드해야 한다는 등 몇 가지 단점도 있는데, 이미 언급했듯이 저는 개인적으로 큰 문제라고 생각하지 않습니다. 또한, 현재 문제는 DoS 보호를 위해 설계된 솔루션이 없다는 것입니다. 사람들이 자주 언급하는 또 다른 점은 여러 가지 요소에 따라 달라진다는 것입니다. 양파 메시지와 블라인드 경로에 대해서는 이미 언급했습니다. 네, 오퍼를 사용하려면 많은 것을 구현해야 합니다. 그리고 네트워크에 애플리케이션 수준의 기능들을 추가해야 하는데, 일부 사람들은 이를 좋아하지 않습니다. 예를 들어, 앞서 언급했듯이 다른 통화를 사용하여 금액을 지정하는 것과 같은 문제가 있습니다.
원자 다중 경로 결제(AMP)
먼저, AMP의 진정한 강점은 모든 채널 또는 일부 채널을 원자적으로 사용하여 결제를 시작할 수 있다는 것입니다. 게다가, 정적 송장도 사용할 수 있습니다.
단일 경로 시나리오
먼저 정적 송장에 대해 설명하겠습니다. 단일 경로 결제 시나리오를 예로 들어 보겠습니다. 원래 Dave는 BOLT11 송장을 만들고 싶어 했습니다. BOLT11 송장에 포함된 내용은 이미 설명했습니다. 매번 새 송장을 만들어야 하는 이유는 결제 보안을 위해 결제 해시를 변경해야 하기 때문입니다.
하지만 AMP를 사용하면 결제 해시는 의미가 없습니다. Dave는 송장의 기능 비트를 사용하여 Alice에게 이 송장이 AMP 송장이며 여러 번 안전하게 결제할 수 있음을 알려줍니다. 물론, 결제자 노드는 이 기능을 이해해야 합니다.
지금까지 데이브는 항상 비밀 값을 생성하고 해시 값을 계산하여 앨리스에게 전송해야 한다고 가정했습니다. 하지만 AMP는 상황을 반대로 바꿉니다. 앨리스는 비밀 값을 생성하고 해시 값을 계산합니다. 그리고 데이브만 복호화할 수 있도록 비밀 값을 암호화합니다. 그런 다음 결제 전용 메시지를 생성합니다. 결제 전용 메시지가 데이브에게 전달되면, 데이브는 메시지를 복호화하고 메시지에 숨겨진 비밀 값을 가져와 결제를 수령하다 할 수 있습니다. 그리고 비밀 값은 다시 전송됩니다.
좋습니다. 두 가지를 얻을 수 있습니다. 첫째, 앨리스는 데이브에게 미리 알리지 않고도 직접 결제를 시작할 수 있습니다. 이를 통해 자발적인 결제가 가능합니다. 둘째, 앨리스는 결제 증명을 받을 수 없습니다. 앨리스는 처음부터 비밀 값을 알고 있었기 때문에, 결국 그녀가 돌려받는 비밀 값은 의미가 없습니다.
이제 AMP의 진정한 장점을 보여드리고, 이미지를 통해 작동 방식을 보여드리고 싶습니다.
앨리스는 여러 채널에 분산된 잔액 사용하여 데이브에게 지불하고 싶어할 수 있습니다. 따라서 먼저 대용량 데이터인 "루트 시드"를 생성합니다. 그런 다음 네 개의 서로 다른 비밀 값을 결정론적으로 생성하고 각 비밀 값의 해시 값을 계산합니다. 왜 네 개일까요? 네 개의 채널을 모두 사용하고 싶기 때문입니다. 이제 루트 시드를 네 부분으로 나눕니다. 지불을 전송하는 첫 번째 경로에서, 앨리스는 첫 번째 해시 값으로 HTLC를 생성하고 루트 시드의 첫 번째 부분을 첨부합니다. 이 지불이 전달되면 데이브는 해시 값에 숨겨진 비밀 값을 알지 못하기 때문에 지불을 수령하다 할 수 없습니다.
네 번의 결제가 모두 도착해야만 데이브는 루트 시드를 재구성하고, 네 개의 비밀 값을 결정론적으로 생성한 후 결제를 수령하다. 바로 이것이 이 프로그램의 매력입니다.
장점과 단점
다시 말씀드리지만, 고정 송장입니다. 앨리스와 데이브만 AMP를 지원하면 됩니다. 이를 통해 앨리스는 데이브에게 먼저 연락하지 않고도 직접 결제할 수 있습니다. 또한 BOLT11 송장을 재사용할 수 있습니다. 모든 채널을 사용할 수 있는데, 이는 매우 유용합니다. 신규 사용자가 유입될 경우 "채널"이 무엇인지 전혀 알 수 없기 때문입니다. 앱에는 잔액 만 표시되고, 사용자는 실제로 전체 잔액 에 접근할 수 있습니다. 하지만 가장 큰 단점은 결제 증빙이 없다는 것입니다.
결론
좋아요, 그게 전부입니다. 이 발표는 추상적인 수준에서 다양한 해결책을 비교하는 것일 뿐입니다. 그럼 몇 가지 질문을 드리겠습니다.
먼저 라이트닝 네트워크의 내부 계층을 살펴보겠습니다. 현재 BOLT1부터 BOLT11까지는 네트워킹, 메시지 전송, 결제, 송장 작성 등 기본적으로 이러한 계층을 포괄합니다. 이 시점에서 송장 통신은 피할 수 없습니다. 여기에 더해 애플리케이션 개발도 가능합니다. 그렇다면 위에서 언급한 세 가지 솔루션은 어떤 계층에 속할까요?
LNURL은 송장 통신만 명시하는데, 앞서 언급했던 "LNURL-pay" 프로토콜은 이 기능만 수행합니다. AMP는 단지 새로운 결제 방식일 뿐입니다. 하지만 Offer는 여러 계층을 포괄하며, 여러 측면에 영향을 미칩니다.
Offer 사양 자체에는 이 기능이 포함되어 있지 않지만, Onion Messaging을 사용합니다. 또한 BOLT11과는 다른 송장 형식을 사용하므로 새로운 송장 구조가 포함되어 있습니다. 또한 송장 통신을 명시하고, 다른 통화로 결제 금액을 지정하는 것과 같은 애플리케이션 계층 관련 기능도 포함되어 있습니다.
그래서 논의할 몇 가지 사항이 있습니다. 트위터에서 토론을 지켜보시면 사람들이 자주 논의하는 몇 가지 사항을 알 수 있습니다.
첫 번째는 지불 증명의 중요성입니다. BOLT11 송장에서 제공하는 현재 지불 증명은 상대적으로 취약하다고 말씀드렸습니다. AMP는 지불 증명 기능이 없습니다. Taproot와 PTLC(포인트 타임락 컨트랙트)는 이러한 상황을 바꿔놓을 것이며, 매우 강력한 지불 증명 기능을 제공할 것입니다. 하지만 여전히 이 문제에 대해 논쟁이 벌어지고 있습니다. 한쪽에서는 "네, 지불 증명은 분명 매우 중요합니다. 네트워크 규모가 매우 커지면 지불 증명이 정말, 정말, 정말 필요해질 테니까요."라고 주장합니다. 반면 다른 한쪽에서는 "사람들이 지금 지불 증명을 어떻게 사용하고 얼마나 자주 사용하나요?"라고 묻습니다. 아시다시피, 많은 지갑은 사용자에게 지불 사전 이미지조차 표시하지 않습니다. 이처럼 양측은 계속해서 논쟁을 벌여 왔습니다.
또 다른 논쟁거리는 의정서에 무엇을 포함해야 하고 무엇을 포함하지 말아야 할 것인가입니다. 그 경계는 어디까지로 정해야 할까요?
그리고, 청구 시스템을 하나만 유지해야 할까요? 여러 시스템을 섞어서 사용할 수는 없을까요?
모든 유형의 사용자를 지원할 수 있는 시스템이 필요할까요? 예를 들어, LNURL은 상시 서버를 운영하기 때문에 판매자에게는 매우 친화적이지만, 휴대폰에서 지갑만 사용하려는 사용자에게는 그다지 친화적이지 않다고 합니다. 네, LNURL은 판매자 측에서는 매우 잘 작동하고, Offer는 휴대폰에서 라이트닝 네트워크를 사용하는 사용자에게 매우 친화적입니다. 그렇다면 둘 다 가질 수 있을까요? 해결책을 하나만 정해야 할까요?
저는 이 질문들에 매우 관심이 있어서 여러분께 질문드리겠습니다. 감사합니다.
(위에)
