라이트닝 trampoline routing이 경량 지갑의 경로 계산을 줄이는 법

트램펄린 라우팅은 경량 sender가 전체 public channel graph를 내려받고 최종 경로를 직접 계산하는 대신, 자신이 도달 가능한 trampoline node까지만 경로를 만들고 그 노드에 목적지까지의 routing을 맡기는 방식입니다. 안쪽 onion에는 최종 목적지와 위임 조건을, 바깥쪽 onion에는 첫 trampoline까지의 일반 hop 지시를 넣는 계열의 설계입니다. 다만 2026년 9월 27일 기준 기본 Lightning BOLTs의 보편적 최종 규격으로 간주할 수 없고 구현·proposal별 feature와 payload가 다르므로 sender와 trampoline의 실제 호환성을 확인해야 합니다.

경로 탐색 비용을 전문 노드에 넘깁니다

일반 source routing sender는 BOLT 7 gossip으로 public graph를 관리하고 liquidity를 추정해 전체 route를 고릅니다. 모바일 지갑에는 graph 저장·동기화와 반복 pathfinding 비용이 큽니다. Trampoline 계열은 sender가 가까운 service node까지 payment를 전달하고 그 node가 목적지까지 다음 route를 계산하도록 역할을 나눕니다.

이 방식은 단순한 invoice 전달 프록시가 아닙니다. Trampoline은 자신이 선택할 하위 경로의 forwarding amount, CLTV와 fee budget을 계산해야 하고 실패하면 sender가 이해할 수 있는 형태로 재시도 단서를 돌려줘야 합니다. 경량화의 대가로 경로 선택 권한과 관찰 정보가 위임 노드에 모입니다.

트램펄린은 목적지까지 대신 순간이동시키는 기능이 아니라, 다음 구간의 길 찾기를 맡아 주는 라우팅 대리인입니다.

JOBCOIN 해설

VISUAL GUIDE체인 사이의 검증 과정

1. 01
   경로 탐색 비용을 전문 노드에 넘깁니다

   일반 source routing sender는 BOLT 7 gossip으로 public graph를 관리하고 liquidity를 추정해 전체 route를 고릅니다.

2. 02
   바깥 onion과 안쪽 지시를 분리합니다

   대표적인 proposal 흐름에서 sender는 trampoline node가 해석할 별도의 payload 또는 nested onion을 준비하고, 이를 일반 BOLT 4 onion 의 해당 hop payload 안에 전달합니다.

3. 03
   금액과 CLTV 예산을 사전 예산을 초과할 수 있습니다

   가정 예로 최종 수신액 100,000 msat, trampoline 이후 예상 fee budget 3,000 msat, 그 앞 경로 fee 1,000 msat라면 sender는 최소 104,000 msat 수준의 출발 HTLC 를 설계합니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

바깥 onion과 안쪽 지시를 분리합니다

대표적인 proposal 흐름에서 sender는 trampoline node가 해석할 별도의 payload 또는 nested onion을 준비하고, 이를 일반 BOLT 4 onion의 해당 hop payload 안에 전달합니다. 바깥 route의 중간 노드는 여전히 자기 next hop 정보만 보며, trampoline은 안쪽 지시를 열어 최종 node 또는 다음 trampoline을 향한 route를 새로 구성합니다.

구체 TLV type, error wrapping과 fee 계산은 채택된 proposal·구현 버전에 종속됩니다. 기본 BOLT 4만 지원하는 node가 임의의 trampoline payload를 이해한다고 가정하면 안 됩니다. Invoice feature bits, peer capability와 wallet release notes를 확인하고 알 수 없는 even TLV가 실패를 만드는 규칙도 고려해야 합니다.

금액과 CLTV 예산을 사전 예산을 초과할 수 있습니다

가정 예로 최종 수신액 100,000 msat, trampoline 이후 예상 fee budget 3,000 msat, 그 앞 경로 fee 1,000 msat라면 sender는 최소 104,000 msat 수준의 출발 HTLC를 설계합니다. 정확한 값은 trampoline이 선택한 route의 base fee·proportional fee와 rounding에 따라 달라져 사전 예산을 초과할 수 있습니다.

CLTV도 최종 invoice 요구 delta, trampoline 이후 구간과 sender 앞 구간을 모두 포함해야 합니다. 지나치게 작은 budget은 중간에서 실패하고, 과도한 budget은 trampoline에 더 큰 탐색 여지를 주는 대신 sender 자금을 더 오래 잠급니다. 구현이 제공하는 max fee·max delay 상한을 명시적으로 설정합니다.

• Invoice와 feature bits에서 trampoline 지원 조건을 읽습니다.
• 신뢰할 첫 trampoline까지 도달 가능한 경로를 계산합니다.
• 최종 금액에 위임 구간·앞 구간 fee budget을 더합니다.
• 최종 CLTV와 두 구간 delta를 합산해 상한과 비교합니다.
• 실패가 trampoline 전인지 위임 구간인지 구분해 재시도합니다.

경량화와 프라이버시의 교환을 평가합니다

Trampoline은 sender가 목적지까지 전체 route를 이미 알고 보내는 기본 onion과 달리 최종 목적지와 위임 예산을 알아야 경로를 계산할 수 있습니다. 한 서비스에 결제를 반복 위임하면 timing·amount·destination metadata가 집중됩니다. 복수 trampoline 선택, retry 분산과 route blinding 결합 가능성을 구현 수준에서 평가합니다.

Route blinding은 recipient가 introduction node 뒤의 경로를 sender에게 숨기는 별도 proposal입니다. 이를 지원하는 invoice라면 trampoline이 보는 최종 식별 범위를 줄일 여지가 있지만, 두 기능을 조합한 privacy guarantee는 구체 protocol version과 구현에 달려 있습니다. 기능 이름만 보고 목적지 은닉이 보장된다고 결론 내리지 않습니다.

아직 구현별 기능이라는 전제로 배포합니다

LND 저장소의 trampoline routing 논의는 구현 요청·설계 과제로 남아 있고, Eclair 설정에는 실험적 trampoline relay 옵션과 별도 조건이 나타납니다. 이는 아이디어와 구현이 존재한다는 근거이지 모든 Lightning node 사이에서 같은 wire format으로 작동한다는 증거는 아닙니다.

운영자는 사용 지갑 버전, 선택한 trampoline service와 invoice 생성 측의 지원 조합을 테스트해야 합니다. Unsupported feature, fee budget 초과, 위임 node offline과 final route 없음 오류를 분리해 기록하고 일반 source routing fallback이 가능한지 정합니다. 외부 서비스 SLA 없이 결제 성공률을 보장해서는 안 됩니다.

자주 묻는 질문