Inbound Liquidity는 Lightning 노드가 자신의 채널을 통해 결제를 받을 수 있는 여력입니다. Lightning은 비트코인을 빠르게 주고받는 데 쓰입니다. 노드는 결제를 처리하는 프로그램이며, 채널은 자금 배분을 합의한 노드 사이의 연결입니다. 수취 여력은 결제 때 자기 쪽으로 넘어올 수 있는 상대편의 자금을 바탕으로 합니다. 이미 자신이 쓸 수 있는 잔액은 아닙니다. 채널 규칙, 처리 중인 결제, 송신자에게서 이어지는 경로도 실제 수취액을 제한합니다.
페트르는 카페를 운영하며 Lightning Network 결제를 받습니다. 결제를 처리하는 프로그램인 노드에 자금이 표시되는데도 손님이 결제하지 못합니다. 수취 유동성 부족이 한 가지 원인일 수 있습니다. 결제 채널은 예치한 비트코인을 어떻게 나눌지 두 노드가 정한 약속입니다. 페트르 쪽을 local balance, 상대 쪽을 remote balance라고 합니다. 결제를 받으면 상대편 가치의 일부가 페트르에게 넘어옵니다. 그러려면 상대 쪽에 넘어올 자금이 있어야 합니다. Remote balance는 여전히 상대의 돈입니다. 수취 능력을 확보했다고 비트코인을 선물받거나 매출을 이미 얻은 것은 아닙니다. [1] [6]
용량이 1000000 sat인 채널을 생각해 봅시다. Sat는 비트코인의 작은 단위인 satoshi의 줄임말입니다. 페트르의 local balance가 800000 sat, 상대의 remote balance가 200000 sat라면, 제한을 빼기 전 수취 여력은 200000 sat입니다. 페트르가 100000 sat를 받으면 자기 쪽은 900000 sat가 되고 상대에게는 100000 sat가 남습니다. 돈은 받았지만 다음 결제를 받을 여력은 줄었습니다. 설명을 단순하게 하려고 준비금, 수수료, 아래에서 설명할 대기 중인 HTLC 결제는 생략했습니다. 페트르 혼자 새 채널을 만들고 처음에 상대에게 자금을 넘기지 않았다면 주로 보내기 능력을 얻습니다. 채널 개설이 확정되어도 이 방향이 뒤집히지는 않습니다. [1] [2]
장사가 잘되는 날에는 페트르 쪽 자금이 늘어나는 반면 사용한 채널의 수취 여력은 줄어듭니다. 잔액이 많아질수록 다음 결제를 받기 어려워질 수도 있습니다. 자체 인프라를 운영한다면 쓸 수 있는 채널, 예상 금액, 진행 중인 결제, 유동성을 보충하는 비용을 살펴야 합니다. 일부 지갑은 이 작업을 대신하지만 구조 자체가 사라지지는 않습니다. 실패한 결제가 노드에 오기 전에 멈춰 페트르가 시도조차 보지 못할 수도 있습니다. 발행한 인보이스나 오래된 용량 수치는 입금 확인이 아닙니다. [6]
페트르가 Lightning으로 공급업체에 지불하면 사용한 채널의 local balance가 줄고 remote balance가 늘어납니다. 앞으로 받을 공간을 확보할 수 있는 것입니다. Loop Out도 비슷하게 작동합니다. 결제 계층 간 교환인 스왑을 통해 Lightning에서 가치를 보내고 블록체인 주소에서 비트코인을 받습니다. 채널을 닫을 필요는 없습니다. Loop In은 반대로 블록체인의 자금을 쓸 수 있는 Lightning 잔액으로 바꿉니다. 어느 쪽도 새 비트코인을 만들지 않습니다. 결과를 비교할 때는 라우팅, 스왑 서비스, 온체인 거래 수수료를 포함하고 작업이 실제로 끝났는지도 확인해야 합니다. [1] [4]
상대가 페트르와 연결되는 채널에 자금을 댈 수도 있습니다. 페트르는 수취 여력을 얻지만 상대의 돈을 선물받지는 않습니다. Lightning Pool 문서는 이런 계약의 시장을 설명합니다. bid는 유동성을 구하는 주문이고 ask는 제공하는 주문입니다. 임대 기간은 블록 수로 정하며 프리미엄과 기타 수수료가 듭니다. 블록은 비트코인의 공개 거래 기록인 블록체인에 추가되는 거래 묶음입니다. 따라서 임대 기간은 새 블록이 생기는 속도에 따라 달라지며, 정확히 정해진 시간 수를 뜻하지는 않습니다. 원격 잔액 전체를 사는 것이 아닙니다. 계약 기간 내내 같은 금액을 받을 수 있다는 뜻도 아닙니다. 결제로 잔액의 분포가 바뀌기 때문입니다. 계약이 끝난 뒤에도 채널을 계속 이용할 수 있다고 가정해서는 안 됩니다. [1] [5]
페트르에게 채널이 여러 개 있고 다른 상대 쪽에 수취 여력이 필요할 수 있습니다. Circular rebalancing, 즉 순환 리밸런싱은 한 채널로 자기 결제를 네트워크에 보내고 다른 자기 채널로 되돌려 받는 방식입니다. 보낸 채널은 수취 여력이 늘고 받은 채널은 그 여력을 소비합니다. 자신의 채널 잔액 사이에서 자금이 옮겨갈 뿐 새 자본이 생기지 않으며 라우팅 수수료가 듭니다. 이용 가능한 경로도 필요합니다. 모든 채널의 상대편에 자금이 없다면 돌아오는 결제를 받을 통로가 없습니다. 순환 리밸런싱만으로는 이를 해결하지 못합니다. [1]
안전한 채널 운영을 위해 일부 자금은 준비금으로 남아야 합니다. 다른 자금은 HTLC라는 조건부 결제 약정에 일시적으로 묶일 수 있습니다. 수취인은 합의된 결제 해시가 계산되는 비밀값을 공개해 자금을 받을 수 있습니다. 해시는 여기서 조건이 맞는지 확인하는 데 쓰는 값입니다. 결제가 실패하면 보낸 쪽이 기한이 지난 뒤 자금을 돌려받는 경로를 이용할 수 있습니다. 채널 관리 명세 BOLT 2는 최소 금액, 동시 HTLC 개수, 합계 금액도 제한합니다. 따라서 다음 결제에 remote balance 전부를 쓸 수 있는 것은 아닙니다. 원격 잔액을 모두 더한 뒤 공통 준비금 하나를 빼는 방식으로는 부족합니다. 각 채널의 현재 상태를 봐야 합니다. [2]
결제는 보통 여러 노드를 거칩니다. 페트르에게 수취 여력이 있어도 앞쪽 구간이 오프라인이거나 자금이 부족할 수 있습니다. BOLT 7은 노드가 채널의 한 방향에 대한 라우팅 조건을 알리는 channel_update 메시지를 설명합니다. 수수료와 개별 조건부 결제의 상한인 htlc_maximum_msat 등이 포함됩니다. 단위 msat는 satoshi의 천분의 일입니다. 이 정보가 전체 경로의 현재 잔액을 보장하지는 않습니다. 따라서 페트르의 총 수취 여력만으로 모든 특정 송신자에게서 같은 금액을 받을 수 있다고 보장할 수 없습니다. 수취인 측 유동성은 필요한 조건 중 하나일 뿐 전부는 아닙니다. [3]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Lightning Network, Payment Channel, Lightning Routing, Submarine Swap, HTLC, Lightning Address. 다음 항목에서도 이 글을 참조합니다 Lightning 유동성, Lightning Routing, Lightning Address, Submarine Swap.