Submarine Swap은 블록체인에 보유한 비트코인으로 Lightning Network를 통해 결제하는 방법입니다. 블록체인은 비트코인의 공개 거래 기록이며, Lightning은 각각의 결제를 여기에 따로 기록하지 않고 빠르게 처리하는 방식입니다. 반대 방향은 Reverse Submarine Swap이라고 합니다. 다른 화폐를 사는 것이 아니라 수수료를 뺀 자금을 이 두 결제 방식 사이에서 옮깁니다. 암호학적 조건과 시간 조건이 두 결제를 연결합니다. 앱은 조건을 검증하고 제때 교환을 끝내거나 자금을 돌려받는 절차를 진행해야 합니다.
안나는 일반 지갑에 비트코인을 보관하고 있습니다. 그런데 가게가 준 것은 결제 요청인 Lightning 인보이스입니다. 일반 스왑에서는 합의한 조건으로 블록체인에 비트코인을 잠그고, 서비스가 그 대가로 인보이스를 지불합니다. Lightning 잔액을 블록체인 주소로 옮기려면 반대 방향인 Reverse Submarine Swap, 예를 들어 Loop Out을 이용합니다. 자기 결제 채널을 닫을 필요는 없습니다. 다만 새 돈을 만들어 내는 것은 아니며 Lightning 결제에 이용 가능한 경로가 있어야 합니다. [1] [4]
어떤 비밀값의 디지털 지문은 확인할 수 있지만 지문에서 비밀값을 역산하는 것은 사실상 불가능하다고 생각해 보세요. 이 비밀값을 preimage라고 하며, 디지털 지문은 hash, 즉 해시입니다. SHA256으로 이 값을 계산합니다. HTLC라는 조건부 결제가 이 지문과 기한을 결합합니다. 역방향 스왑에서는 안나의 앱이 비밀값을 만듭니다. 서비스는 Lightning 결제를 보류하고 해당 비트코인을 블록체인에 잠급니다. 안나가 claim, 즉 자금 수령 작업을 하면 비밀값을 블록체인에 공개하거나 협력 과정에서 서비스에 전달합니다. 그러면 서비스가 연결된 결제를 확정할 수 있습니다. 대기 중이라는 말은 결제 완료가 아닙니다. [1] [4]
서비스의 알림과 목적지 지갑에 돈이 들어오는 것은 다릅니다. Boltz 문서에 따르면 역방향 스왑의 invoice.settled는 preimage 전달과 Lightning 인보이스 정산 뒤에 나타날 수 있습니다. 서비스는 안나의 앱이 실제로 claim 거래를 전파했는지 추적하지 않습니다. 따라서 목적지 출력, 즉 자신의 지갑에 배정된 구체적인 비트코인과 필요한 블록 확인을 검증해야 합니다. 블록은 블록체인에 추가되는 거래 묶음입니다. 거래가 블록에 포함되면 첫 확인을 얻고, 그 뒤에 새 블록이 연결될 때마다 확인 수가 늘어납니다. 상태가 불분명하다고 같은 결제를 즉시 다시 보내서는 안 됩니다. [1] [2]
일반 스왑에서는 인보이스가 미납이어도 안나의 비트코인이 이미 블록체인에 잠겨 있을 수 있습니다. 환불인 refund에는 앱이 만들고 전파하는 거래가 필요합니다. 서비스가 협력하지 않으면 합의한 시간 조건인 timelock을 기다려야 합니다. 반대 방향의 미정산 Lightning 결제는 대기 HTLC가 취소되어 안나의 온체인 refund 거래 없이 잔액이 풀릴 수 있습니다. 그렇다고 preimage 공개 후 이미 정산된 결제가 저절로 되돌아오지는 않습니다. 방향과 현재 단계가 중요합니다. [1] [3]
안나는 보내는 금액과 실제 도착하는 금액을 비교합니다. 차이에는 서비스, Lightning 라우팅, 블록체인 거래 수수료가 포함될 수 있습니다. 일반 스왑에 실패하면 환불 거래 비용도 더해질 수 있습니다. 시간도 중요합니다. claim을 공개하면 블록 확인 전에 preimage가 드러날 수 있습니다. Loop 문서는 timeout이 가까워지면 자금을 회수하는 sweep 거래의 수수료를 처음 한도보다 높일 수 있다고 설명합니다. 암호학적 연결이 즉시, 무료, 무위험 교환을 약속하지는 않습니다. [5] [6]
다른 지갑의 복구 단어로 진행 중인 스왑이 복원되지 않을 수 있습니다. 앱에 따라 refund 키나 rescue key와 잠긴 출력, 기한 등을 포함한 스왑 데이터가 필요합니다. Boltz Swap Restore는 자체 백업에서 키를 파생하고 관련 스왑을 찾습니다. 검색에는 확장 공개키인 xpub를 사용합니다. 이 키로 이력이 드러날 수는 있지만 그 자체로 서명하거나 돈을 쓰지는 못합니다. 개인키는 앱이 해당 조건에 따라 거래에 서명할 때 사용하는 비밀값입니다. 이 키들은 기기에 남습니다. 송금 전에 백업으로 무엇을 복구하며 어디에 보관하는지 알아야 합니다. [7] [3]
사용자가 암호학적 조건을 손으로 계산할 필요는 없지만 앱은 검증해야 합니다. 프로그램이 데이터를 주고받는 인터페이스인 API에서 반환한 주소를 그대로 믿기만 해서는 안 됩니다. 클라이언트는 네트워크, 금액과 수수료, hash, 키, 기한을 확인합니다. 지출 규칙인 스크립트나 Taproot의 규칙 트리와 그로부터 만든 주소도 검증합니다. Lightning 인보이스는 약속한 지문과 금액에 맞아야 합니다. 올바른 방식도 엉뚱한 곳에 돈을 보내는 프로그램까지 구해 주지는 못합니다. [2]
Taproot에서는 양측이 MuSig2로 공동 서명을 만들 수 있습니다. 이 key-path 경로는 비용이 적게 들 수 있으며 스왑 조건을 공개할 필요도 없습니다. 앱에는 상대가 협력하지 않을 때 조건을 직접 사용하는 script-path 경로도 있어야 합니다. 방향에 따라 claim이나 refund에 사용합니다. 일반 스왑이 실패했을 때 공동 서명한 refund로는 더 빨리 돈을 돌려받을 수 있습니다. 하지만 안나가 서비스의 협력 없이 자금을 되찾으려면 합의한 timelock이 환불을 허용할 때까지 기다려야 합니다. 블록체인에 보이는 정보가 줄어든다고 교환을 중개한 서비스에까지 익명이 되는 것도 아닙니다. [3] [4]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Lightning Network, HTLC, Inbound Liquidity, Taproot, MuSig2, CLTV. 다음 항목에서도 이 글을 참조합니다 Lightning 유동성, Inbound Liquidity, Boltz, Lightning Service Provider.