Lightning 채널에는 두 잔액이 있고 그 합은 채널 용량으로 제한됩니다. 사용 가능한 로컬 잔액은 송신 유동성을, 원격 잔액은 수신 유동성을 이룹니다. 준비금, commitment 거래 수수료, 대기 중인 HTLC, 채널 규칙, 각 홉의 사용 가능 용량이 특정 금액의 실제 경로 통과 여부를 결정합니다.
채널 용량은 자금 조달 출력에 잠긴 비트코인입니다. 유동성은 지금 한 방향으로 쓸 수 있는 부분뿐입니다. 따라서 용량이 1,000,000 sats인 채널도 거의 전부가 한쪽에 있으면 반대 방향의 큰 결제를 전달하지 못할 수 있습니다. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
송신 유동성은 프로토콜 준비금, commitment 거래 수수료 부담, 대기 중인 HTLC를 반영한 뒤 로컬 노드가 채널로 보낼 수 있는 금액입니다. 외부로 결제하거나 전달하면 줄고 상대 노드에서 가치가 들어오면 늘어납니다. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
수신 유동성은 상대가 로컬 노드로 보낼 수 있는 금액입니다. 해당 채널로 받으려면 필요하지만 결제 요청을 바꾼다고 생기지 않습니다. 원격 잔액에 존재하거나 유동성 관리 작업을 통해 마련되어야 합니다. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
경로를 따르는 결제가 성공하려면 선택한 모든 홉에 올바른 방향의 충분한 사용 가능 유동성이 있어야 하고, 수수료 규칙과 최소·최대 금액 및 CLTV 시간 제한에 따라 HTLC를 받아야 합니다. 고갈된 채널 하나가 다른 연결은 양호한 경로를 막을 수 있습니다. [BOLT #2 — Peer Protocol for Channel Management] [BOLT #7 — P2P Node and Channel Discovery]
channel_reserve_satoshis, commitment 거래 수수료, anchor outputs, dust 규칙, max_htlc_value_in_flight_msat, max_accepted_htlcs와 이미 대기 중인 HTLC는 새 결제에 쓸 수 있는 금액을 줄일 수 있습니다. 따라서 지갑 잔액, 채널 용량, 즉시 경로로 보낼 수 있는 금액은 서로 다른 세 숫자입니다. [BOLT #2 — Peer Protocol for Channel Management]
BOLT #7은 채널과 전달 규칙을 공개할 수 있게 합니다. 용량은 체인에서 식별한 자금 조달 출력으로 알 수 있지만, 비공개 잔액 배분까지 드러나는 것은 아닙니다. 송신자는 자신의 정보, 과거 결과와 결제 시도로 경로를 추정합니다. 공개 탐색기는 선택한 경로가 지금 특정 금액을 전달할 수 있는지 확정해 주지 못합니다. [BOLT #7 — P2P Node and Channel Discovery]
정산된 결제는 사용한 각 채널의 잔액을 이동시킵니다. 보내는 쪽의 송신 유동성은 줄고 수신 유동성은 늘며 반대쪽에서는 반대 변화가 일어납니다. 결제는 기존 용량을 재배분할 뿐 전체 용량을 늘리지 않습니다. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
전달 노드는 같은 HTLC를 위해 한 채널의 수신 유동성과 다음 채널의 송신 유동성이 필요합니다. sats 총액이 많아도 잘못된 채널이나 잘못된 쪽에 있으면 충분하지 않습니다. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
수신 결제, 순환 재조정, 채널 개설이나 폐쇄, 스왑과 splicing은 유동성을 옮길 수 있습니다. 수수료, 체인에 남기는 흔적, 시간, 상대방 신뢰와 실패 위험이 다르며 어떤 방법도 무료 유동성을 만들지 않습니다. 여러 부분으로 나눈 결제는 경로를 결합할 수 있지만 여전히 충분한 방향별 총용량이 필요합니다. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Managing Liquidity]
자신의 노드에서 각 채널의 로컬·원격 잔액, 준비금, 대기 중인 HTLC와 수수료 여유분을 확인한 다음 계획한 금액을 시험하세요. 방향, 크기, 시각과 구현을 기록하세요. 유동성은 결제마다 바뀌며 네트워크 전체의 영구적인 단일 점수가 아닙니다. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity] [Lightning Labs — Managing Liquidity]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Lightning Network, Payment Channel, Lightning Routing, Inbound Liquidity, Bitcoin, HTLC. 다음 항목에서도 이 글을 참조합니다 Payment Channel, Lightning Routing, 변동성, 시가총액.