Lightning 유동성

Anna와 Pavel에게는 용량이 1,000,000 sat인 채널이 있습니다. sat은 Bitcoin 체인에서 가장 작은 단위인 사토시를 뜻합니다. 단순화해서 Anna가 800,000 sat, Pavel이 200,000 sat을 갖고 있다고 합시다. 원리를 보기 위해 일단 준비금, 수수료, 처리 중인 결제는 제외합니다. Anna는 자기 쪽 자금으로 Pavel에게 보내고, Pavel에게서 받을 때는 그의 쪽 자금을 받습니다. 따라서 총용량이 100만이어도 Pavel은 이 채널로 Anna에게 300,000 sat을 보낼 수 없습니다. 돈이 사라진 것이 아니라, 현재 배분으로는 그 결제를 할 수 없는 것입니다. [1] [3]

보내는 방향의 유동성은 나에게서 밖으로 결제하는 데 쓸 수 있는 금액입니다. 예에서는 Anna의 800,000 sat 잔액이 기준이지만, 실제 한도는 준비금, 수수료, 처리 중인 결제 때문에 보통 더 낮습니다. Anna가 Pavel이 아닌 다른 사람에게 보내도 첫 단계는 여전히 자신의 채널 중 하나를 거칩니다. 노드는 채널을 관리하고 Lightning 결제를 처리하는 프로그램입니다. 이후 노드들은 다음 단계에 쓸 자기 자금이 필요합니다. 채널 밖에 bitcoin이 있다고 보내는 방향의 유동성이 자동으로 늘지는 않습니다. 지갑이 적절한 방법으로 그 가치를 Lightning으로 옮겨야 합니다. [1] [3]

받는 방향의 유동성은 상대가 나에게 보낼 수 있는 금액입니다. Anna가 채널을 열고 거의 모든 자금을 소유한다면 보내기는 좋지만 받을 여유는 적습니다. 새 결제 요청을 만들어도 배분은 바뀌지 않습니다. 상대 쪽에 쓸 수 있는 잔액이 있는 채널이 필요합니다. 일부 지갑은 서비스 제공자를 통해 이를 마련하고 복잡한 과정을 사용자에게 드러내지 않지만, 수수료가 붙는 경우가 많습니다. 받을 수 있는 용량은 Anna가 이미 가진 추가 재산이 아니라, 앞으로 결제를 받을 가능성을 뜻합니다. [1] [3] [5]

이제 Anna가 Pavel에게 100,000 sat을 냅니다. 단순화한 예에서 잔액은 Anna 700,000 sat, Pavel 300,000 sat으로 바뀝니다. 용량은 여전히 1,000,000 sat입니다. Anna는 보낼 수 있는 금액이 줄지만 돌려받을 수 있는 금액은 늘고, Pavel은 반대입니다. 지갑에 채널이 여러 개라면 결제에 실제 사용된 채널이 바뀝니다. 그래서 방향이 항상 중요합니다. 아침의 유동성 수치가 저녁에도 보낼 수 있는 금액을 그대로 나타내지는 않습니다. [1] [3]

멀리 있는 수신자에게 가는 결제는 여러 채널을 차례로 통과합니다. 각 채널에는 올바른 방향의 충분한 유동성이 있어야 하며, 이후 단계의 수수료도 포함해야 합니다. 한 단계라도 결제를 넘길 수 없으면 다른 채널의 용량이 커도 그 경로는 실패합니다. 지갑은 다른 경로를 시도하거나, 지원되는 결제를 여러 부분으로 나눌 수 있습니다. 그래도 부족한 자금이 생기지는 않습니다. 금액뿐 아니라 기한도 확인합니다. HTLC는 특정 비밀을 알고 있음을 증명하면 완료할 수 있는 조건부 결제입니다. CLTV와 관련된 규칙은 블록을 기준으로 기한을 정합니다. 단계별 기한에 차이를 두면 전달이 멈추더라도 중개자가 Bitcoin 체인에서 정산할 시간을 확보할 수 있습니다. [1] [2]

중개 노드는 한 채널로 받고 다른 채널로 연결된 결제를 보낼 수 있어야 합니다. 전체 잔액의 합이 큰 것만으로는 충분하지 않습니다. 자기 자금이라도 잘못된 채널에 있다면 선택한 경로에 쓰지 못할 수 있습니다. 받는 첫 채널에는 받는 방향의 유동성이, 전달하는 두 번째 채널에는 보내는 방향의 유동성이 필요합니다. 이 단계들은 HTLC 조건으로 연결됩니다. 결제 완료가 특정 비밀의 제시와 시간 규칙에 달려 있으므로, 중개자는 앞선 참여자가 나중에 돈을 주겠다는 약속만 믿는 것이 아닙니다. [1] [3]

들어오고 나가는 결제는 자연스럽게 유동성을 바꿉니다. 여러 채널의 운영자는 순환 리밸런싱을 할 수도 있습니다. 자신에게서 한 경로로 결제를 보내고 다른 경로로 다시 받아, 자기 채널 사이의 잔액을 옮기는 방식입니다. Swap은 체인상의 자금과 Lightning 자금을 맞바꾸며, 반대 방향도 가능합니다. Splicing은 지원하는 채널의 자금을 일반적인 폐쇄와 재개설 없이 조정합니다. 다른 채널을 새로 여는 방법도 있습니다. 방법마다 수수료, 시간, 체인에 남는 기록, 필요한 신뢰와 실패 위험이 다릅니다. 어느 것도 새 돈을 만들지 않습니다. 보내기, 받기, 또는 둘 다 필요한지에 따라 선택해야 합니다. [1] [4]

먼저 보내기와 받기 중 어느 쪽의 문제인지 구분하고 지갑과 상대 노드가 온라인인지 확인합니다. 자신의 노드에서는 채널별 로컬·원격 잔액, 준비금, 처리 중인 결제와 수수료를 비교합니다. 서비스가 관리하는 지갑이라면 표시된 사용 가능 금액이 정확히 무엇을 뜻하는지 확인하세요. 한 번의 실패만으로 돈을 잃었다고 판단할 수는 없습니다. 어느 단계의 유동성 부족, 한도 또는 일시적인 장애일 수 있습니다. 소액 시험 결제는 그 순간 그 금액만 확인할 뿐, 이후 모든 결제의 성공을 보장하지 않습니다. [1] [3] [4]

노드 운영자는 여러 제한을 구분해야 합니다. 트랜잭션 출력에는 금액과 그 돈을 쓰기 위한 조건이 담겨 있습니다. channel_reserve_satoshis는 준비금으로 남겨야 할 자금을 나타냅니다. 일부 자금은 아직 끝나지 않은 조건부 결제인 대기 중 HTLC에 묶일 수 있습니다. 다음 한도들은 상대 참여자가 제안한 HTLC에 적용됩니다. max_htlc_value_in_flight_msat는 그 총액을, max_accepted_htlcs는 개수를 제한합니다. msat은 Lightning 내부 계산에 쓰는 사토시의 1,000분의 1입니다. 채널 유형에 따라 채널을 닫는 commitment transaction의 수수료와, anchor outputs도 관련됩니다. 이는 후속 트랜잭션을 연결해 거래 묶음 전체의 확인 수수료를 높일 수 있도록 하는 특별한 출력입니다. Dust 규칙은 너무 작아서 해당 거래에 넣지 않는 출력을 정합니다. 따라서 획일적인 준비금을 빼는 대신, 구현과 채널 유형에 맞춰 실제 사용 가능한 최대 금액을 계산해야 합니다. [1] [6]

BOLT #7은 채널 공지와 결제 전달 정책을 설명합니다. 공지된 채널은 체인에서 자금 조달 출력과 용량을 찾을 수 있습니다. 하지만 참여자 사이의 현재 잔액 배분은 알 수 없습니다. 송신자는 자신의 정보, 과거 결과와 결제 시도를 바탕으로 경로를 고릅니다. 모든 실시간 잔액이 공개된 완전한 목록을 보고 고르는 것이 아닙니다. 그래서 탐색기에 큰 채널이 보여도, 지금 내 금액이 원하는 방향으로 통과한다는 확인은 되지 않습니다. [2]