Lightning Routing

안나는 커피값을 내려고 하지만 카페와의 채널이 없습니다. 대신 파벨과 채널이 있고, 파벨은 카페와 또 다른 채널을 갖고 있습니다. 따라서 결제는 파벨을 거쳐 갈 수 있습니다. 첫 채널에서는 잔액 일부가 안나에게서 파벨에게로, 두 번째 채널에서는 파벨에게서 카페로 옮겨갑니다. 같은 코인이 채널 사이를 이동하는 것이 아니라 각 채널의 잔액이 서로 연결된 단계에 따라 바뀌는 것입니다. 그러므로 파벨은 카페에 지불하는 쪽에 자신이 사용할 수 있는 자금을 갖고 있어야 합니다. 송신자의 지갑이나 노드가 수취인까지의 경로를 선택하고 각 단계의 지시를 준비합니다. 수취인은 필요한 정보와 지원 기능을 알리며, 비공개 마지막 구간의 정보를 추가할 수도 있습니다. 중간 노드는 지시에 따라 결제를 전달합니다. 각 노드가 목적지까지의 전체 경로를 매번 새로 찾는 것은 아닙니다. [1] [4]

Gossip은 노드 사이에 정보를 퍼뜨리는 방식입니다. BOLT #7은 채널 공지와 방향별 갱신을 설명합니다. 기본 수수료와 금액 비례 수수료, CLTV 만료 간격, 최소·최대 금액, 사용 가능 표시가 포함됩니다. 공지된 조건만으로 상대 노드가 지금 온라인인지, 자금이 충분한지는 알 수 없습니다. 여기서 CLTV는 시계의 정확한 시각이 아니라 체인에서 블록의 순서를 뜻하는 Bitcoin 블록 높이로 나타낸 기한을 뜻합니다. 기한 사이의 간격은 전달이 멈췄을 때 중계 노드가 대응할 시간을 마련해 줍니다. [2]

채널의 총용량은 양쪽이 지금 각각 얼마를 보낼 수 있는지 보여 주지 않습니다. 송신자는 자신의 채널을 알지만, 나머지는 추정과 성공·실패 기록에 의존합니다. 따라서 소프트웨어는 수수료뿐 아니라 통과 가능성도 고려합니다. 그사이 다른 결제가 유동성, 즉 필요한 방향으로 보낼 수 있는 자금을 바꿀 수도 있습니다. [4] [5]

각 단계는 HTLC라는 조건부 결제로 연결됩니다. 완료하려면 해당 비밀값을 공개해야 하며, 완료되지 않은 결제의 자금은 기한이 지난 뒤 회수할 수 있습니다. 계산은 수취인이 받을 금액에서 시작해 거꾸로 진행됩니다. 각 중계 노드는 다음 노드에 전달할 금액과 자신의 수수료를 받아야 합니다. 들어오는 HTLC의 만료 시간은 요구되는 CLTV 간격에 맞게 나가는 HTLC보다 충분히 늦어야 합니다. 경로가 길어지면 비용이 늘고, 문제가 생겼을 때 자금이 묶이는 시간도 길어질 수 있습니다. [1] [2]

BOLT #4의 onion routing은 Sphinx 구조를 사용해 각 단계의 지시를 따로 암호화합니다. 중계 노드는 앞뒤 상대와 자신이 수행할 지시를 압니다. 패킷 자체는 전체 경로, 길이, 자신의 정확한 위치를 알려 주지 않습니다. 다만 통신 분석이나 여러 노드의 협력으로 프라이버시가 약해질 수는 있습니다. [1]

채널의 일시적 문제, 부족한 수수료, 잘못된 CLTV, 사용할 수 없거나 알 수 없는 다음 상대 때문에 실패할 수 있습니다. 송신자는 제한된 오류 정보만 받습니다. 소프트웨어는 경로의 평가 점수를 낮추고 다시 계산해 재시도할 수 있습니다. 이는 노드에 내는 벌금이 아니며, 한 번의 결과가 신뢰성에 대한 영구적인 평가도 아닙니다. [1] [4]

연결을 찾는 것만으로는 부족합니다. 각 단계가 HTLC를 받아들이고 필요한 방향으로 충분한 가용 자금을 갖고 있어야 합니다. 잔액 일부는 준비금으로 남겨 두거나 아직 끝나지 않은 결제에 묶여 있을 수 있습니다. 기술 필드 htlc_minimum_msat와 htlc_maximum_msat는 해당 방향에서 처리하는 개별 HTLC 금액의 하한과 상한도 정합니다. 단위 msat는 사토시의 천분의 일이며, 사토시는 Bitcoin 체인에서 가장 작은 금액 단위입니다. 공지된 상한이 높아도 필요한 유동성이 지금 있다는 뜻은 아닙니다. 따라서 적합하지 않은 채널 하나가 전체 경로를 막을 수 있습니다. [2]

수취인이 basic MPP, 즉 하나의 결제를 여러 부분으로 나누는 방식을 지원하면 송신자는 프로토콜에서 total_msat로 표시하는 총액을 여러 경로로 나눌 수 있습니다. 수취인은 필요한 부분이 모일 때까지 기다렸다가 함께 정산합니다. 여러 채널에 흩어진 유동성을 활용할 수 있지만, MPP가 새 유동성을 만드는 것은 아닙니다. HTLC와 시도 횟수가 늘고 수수료도 늘 수 있습니다. [1]

BOLT #11의 route hints는 공지되지 않은 마지막 단계의 정보를 송신자에게 보충해 줄 수 있습니다. BOLT #12에서 사용하는 route blinding은 그 대신 진입 노드인 introduction point를 통해 암호화된 마지막 구간을 제공합니다. 송신자는 여전히 진입점까지 사용 가능한 경로를 찾고 합산된 수수료와 CLTV 조건을 충족해야 합니다. 프라이버시가 좋아져도 전달 성공이 보장되지는 않습니다. [3] [6] [1]

일상적인 결제에서는 지갑이 경로를 찾습니다. 다음 세부 사항은 주로 노드 운영자나 반복되는 문제의 원인을 조사할 때 유용합니다. 소프트웨어와 버전, 금액, 수수료 및 CLTV 상한, 시도 횟수, 사용 경로, 완료 시간, 정확한 실패 원인을 기록하세요. 같은 노드 쌍을 비슷한 시각에 비교해야 합니다. 성공률은 특정 네트워크 상태에서의 특정 결제를 설명하는 것이지 영구적인 전체 점수가 아닙니다. [4] [5]