BOLT 12는 무엇인가요? 여러 가지 기능과 요소들이 결합되어 여러 가지 일을 수행하기 위한 것입니다 — 정적 QR 코드, 모듈식 송장, 지불을 받는 사람의 프라이버시 보호.
하지만 전체 패키지는 무엇인가요? 단일 QR 코드를 가지고, “제안”을 통해 프라이버시를 유지하며 노드에서 송장을 가져오고, 원격 노드가 송장을 지불하도록 요청하는 등의 기능을 제공합니다.
LNURL에 익숙한 사람이라면 “이건 LNURL과 매우 비슷하게 들린다”고 생각할 것입니다. 하지만 LNURL이 무엇인지 또는 어떻게 작동하는지 모르는 분들을 위해 간단히 설명하겠습니다.
LNURL이란?
LNURL은 HTTP를 사용하여 Lightning Network에서 지불을 수행하는 데 필요한 정보를 조정하기 위한 간단한 프로토콜의 집합입니다. LNURL 프로토콜 조각의 전체 목록은 여기에서 확인할 수 있지만, BOLT 12와 겹치는 몇 가지 핵심 사용 사례에 대해서만 설명하겠습니다.
LNURL 프로토콜의 세 가지 핵심 요소는 서비스에 로그인하기 위해 공개 키를 사용할 수 있는 인증 스킴, 지갑이 정적 QR 코드를 통해 서버에 요청을 보내 송장을 검색할 수 있는 송장 요청 스킴, 그리고 지갑이 서버에 요청을 보내 지갑이 제공한 송장을 지불하도록 요청할 수 있는 인출 요청 스킴입니다. Lightning 송장은 온체인 비트코인 주소보다 훨씬 길며, 지불 자체가 양 당사자가 온라인 상태여야 하는 상호작용 프로세스이므로, 네트워크 연결을 통해 상호작용적으로 지불 세부정보를 조정하는 것이 합리적입니다.
인증 프로토콜은 서버가 무작위로 생성된 숫자를 제공하고 사용자의 지갑이 새로 생성된 키로 서명하는 방식입니다. 서명된 무작위 값이 서버에 수신되면, 서버는 향후 로그인에 사용할 수 있도록 관련 키를 저장합니다.
송장 요청 기능은 사용자가 지불하고자 하는 송장 형식이 아닌 정보를 제공하는 방법입니다. 이는 지불에 대한 설명, 서비스가 예상하는 최소 및 최대 금액, 실제 송장을 요청할 지갑의 URL을 제공합니다. 여기서 지갑은 이 정보를 사용자에게 표시하여 최종 금액을 설정하고 송장을 요청할 수 있도록 합니다. 송장 요청을 보내고 서버로부터 송장을 받으면, 지갑은 사용자가 설정한 금액과 일치하는지 확인하고 송장을 지불합니다.
인출 요청은 서비스를 핑하고, 응답으로 설명, 송장을 보낼 URL, 무작위 문자열(또는 계정이나 사용자에 연결된 결정론적 문자열), 인출할 수 있는 최소 및 최대 금액을 받는 방식으로 작동합니다. 적절한 값을 입력한 후, 지갑은 서버에 송장을 반환하고, 유효하고 금액 매개변수 내에 있다면 서비스는 송장을 지불합니다. LNURL 인증 프로토콜은 이와 함께 사용되어 의도된 사용자만 LNURL 링크를 통해 성공적으로 인출할 수 있도록 보장할 수 있습니다.
LNURL은 Lightning Network 사용에 대한 사용자 경험을 개선하고 원활하게 만들어주지만, 이를 활용하기 위해서는 웹 서버가 필요합니다. 모든 요청과 응답은 HTTP를 통해 처리되며, 이러한 간소화된 지불 조정 방식을 처리하기 위해서는 Lightning 노드 자체 외에 추가 인프라가 필요합니다. 이는 온라인 서비스 제공자나 상인에게는 합리적인 요구 사항이지만, 단순히 원활한 경험을 원하는 비기술적 최종 사용자에게는 부담스럽고 잠재적으로 위험한 요구 사항이 될 수 있습니다.
BOLT 12란?
BOLT 12는 웹 서버 사용 없이 LNURL이 제공하는 핵심 기능을 달성하려는 시도를 제공합니다. 제안은 송장을 요청하기 위해 노드에 도달하는 데 필요한 데이터를 인코딩합니다. 이는 노드 ID 또는 그 노드로 가는 블라인드 경로(양파 경로의 마지막 몇 홉, 미리 계산되고 암호화된)를 포함합니다. 또한 지불할 최소 금액, 지불 통화, 만료 시간 및 최소/최대 수량 숫자를 인코딩할 수 있습니다.
이는 제안을 발행한 노드에서 실제 송장을 가져오는 데 필요한 모든 정보입니다. 송장을 지불하고자 하는 사람은 양파 메시지를 통해 이를 수행합니다. 이는 BOLT 12의 핵심 기능 중 하나입니다. 이를 통해 노드 간에 Lightning 채널을 포함하지 않는 직접적이고 종단 간 암호화된 연결을 만들 수 있습니다. Lightning 지불과 마찬가지로, 이러한 메시지를 양파 경로로 사용할 수 있습니다. 제안을 받은 후, 지불자는 인코딩된 정보를 사용하여 송장 요청 메시지를 보냅니다. 제안의 생성자는 실제 송장으로 응답합니다.
또한 수신자가 제안의 생성자로부터 지불을 요청할 수 있는 사용자별 고유 제안을 생성하는 기능도 지원됩니다. 이는 LNURL의 인출 요청 기능과 유사합니다. BOLT 12 송장은 고유한 지불자 키에 대한 약속을 하며, 이는 환불을 발행할 경우 실제로 송장을 지불한 사람임을 증명하는 데 사용될 수 있습니다. 이는 인출 제안과 결합하여 올바른 사람만 송장을 지불할 수 있도록 보장하는 데도 사용될 수 있습니다.
이 두 가지 제안의 사용은 웹 서버를 운영할 필요 없이 LNURL의 송장 및 인출 요청과 동일한 기능을 효과적으로 수행합니다.
LNURL 또는 BOLT 12? 모든 것은 트레이드오프에 관한 것입니다
LNURL과 BOLT 12는 모두 동일한 일반 기능을 수행하므로, 이들 간의 실제 차이는 무엇인가요? LNURL이 이미 존재하는데 BOLT 12가 필요한 이유는 무엇인가요? 주요 차별점은 웹 서버입니다. 웹 서버는 더 많은 인프라, 도메인 이름, TLS 인증서 및 이러한 것들을 관리할 전문 지식을 요구합니다.
이는 대부분의 비즈니스와 서비스에 있어 언급할 가치조차 없는 문제일 수 있지만, 일반 비기술적 최종 사용자에게는 큰 문제입니다. 사용자가 Lightning 노드 위에 추가 인프라를 유지해야 한다는 것은 합리적인 기대가 아닙니다. DNS의 중앙화 문제도 있습니다; 도메인은 소유자가 진정으로 제어할 수 없는 것입니다.
이러한 문제를 제외하고도 두 가지는 공존할 수 있습니다. LNURL은 잘 작동하며, 이미 Lightning 생태계에서 매우 널리 채택되고 있습니다. 이는 비즈니스나 서비스 이외의 사용자에게는 현실적인 솔루션이 아닙니다. BOLT 12가 채택됨에 따라 그 격차를 메우고, 비즈니스가 아닌 가정의 최종 사용자에게 동일한 원활한 사용자 경험을 제공할 수 있습니다.
두 솔루션은 서로 다른 사용자 클래스에 대해 대략 동일한 작업을 수행하며, 이는 괜찮습니다.
이 글은 Shinobi의 게스트 포스트입니다. 표현된 의견은 전적으로 그들의 것이며, BTC Inc 또는 Bitcoin Magazine의 의견을 반드시 반영하지는 않습니다.
