Trampoline Routing

일반 Lightning source routing은 송신자가 쓸 수 있는 네트워크 그래프를 알고 모든 hop을 직접 고른다고 가정한다. 자주 오프라인인 휴대전화는 결제 전에 channel gossip을 내려받아 정리하고 경로를 계산해야 한다. Trampoline Routing은 이 작업을 최신 네트워크 시야를 가진 여러 노드에 옮기며 키나 채널 보관을 맡기지 않는다. [6]

송신자는 첫 trampoline node를 고르고 금액, 최종 목적지, 수수료와 CLTV 예산을 정해 trampoline onion을 만든다. 일반 payment onion이 작은 onion을 전달하면 노드는 다음 trampoline hop 지시만 열고 일반 노드를 통한 구체적 경로를 찾아 남은 onion을 다음 구간용으로 다시 감싼다. [1]

두 trampoline nodes 사이에는 제안을 지원하지 않는 일반 Lightning 노드가 있을 수 있으며 BOLT #4에 따라 표준 onion과 HTLC를 처리한다. Trampoline node는 경로의 빈 구간을 채우지만 이후 검증 실패 없이 금액, 시간 조건 또는 최종 결제 비밀을 바꿀 수 없다. [2]

위임은 수탁이 아니다. Trampoline node는 seed, 개인 키, 채널 자금을 단독 지출할 권리를 받지 않는다. 그러나 결제를 거부하거나 늦추고, 나쁘거나 비싼 경로를 고르고, 자기 구간의 메타데이터를 볼 수 있다. 지갑은 수수료와 CLTV 예산, payment secret, 암호화 오류와 재시도를 강제해야 한다. [1]

2026년 시월 초 현재 공개 BOLTs 제안 #836은 열려 있지만 Eclair와 lightning-kmp는 새로 제안된 형식 구현과 이전 실험 프로토콜에서의 전환을 이미 언급한다. 이는 실제 배포를 뜻하지만 전체 네트워크 상호운용 완료는 아니다. 현재 Eclair 설정도 일반 결제 활성화와 prototype feature flag를 분리한다. [5]

BOLT #4는 onion 계층 내용을 보호하고 hop에 직전과 다음 노드만 드러내지만 모든 메타데이터를 자동으로 숨기지는 않는다. 단일 trampoline 제공자는 송신 클라이언트와 비지원 수신자에게 연결할 때 목적지를 알 수 있다. 여러 trampoline hops와 blinded path는 지식을 나누지만 시간, 금액, 재사용은 상관 신호로 남는다. [2]

Route blinding은 암호화 데이터에 outgoing_channel_id 대신 outgoing_node_id를 넣어 trampoline과 결합할 수 있다. Trampoline node는 다음 노드만 복호화해 그곳까지 경로를 계산한다. 수신자는 자기 구간을 숨기면서 일시적 유동성 부족 때 재탐색을 허용할 수 있다. [4]

지갑을 검증하려면 gossip을 실제로 줄이는지, trampoline nodes를 어떻게 고르는지, 어떤 feature bits와 onion TLV를 쓰는지, 형식이 이전판인지 제안판인지, 수수료와 CLTV 예산과 오류 및 MPP를 어떻게 처리하는지, 비지원 목적지가 예상보다 많은 정보를 노드에 드러내는지 확인해야 한다. [3]