Ini adalah source routing bertingkat: pengirim membuat trampoline onion internal berisi tujuan, jumlah, anggaran biaya dan CLTV, membawanya dalam onion biasa ke trampoline node pertama, lalu node itu menghitung jalur perantara konkret ke trampoline hop berikutnya atau penerima; setiap node delegasi hanya mengetahui bagiannya.
Lightning source routing biasa menganggap pengirim mengetahui graf jaringan yang dapat dipakai dan memilih setiap hop sendiri. Bagi ponsel yang sering offline, ini berarti mengunduh dan memangkas channel gossip serta menghitung rute sebelum membayar; Trampoline Routing memindahkan pekerjaan itu ke beberapa node dengan pandangan jaringan lebih baru, bukan menyerahkan penyimpanan kunci atau channel. [6]
Pengirim memilih trampoline node pertama, menetapkan jumlah, tujuan akhir, anggaran biaya dan CLTV, lalu membuat trampoline onion. Payment onion biasa membawa onion kecil itu ke node; node hanya membuka instruksi trampoline hop berikutnya, mencari jalur konkret melalui node biasa, dan membungkus ulang sisa onion untuk segmen berikutnya. [1]
Di antara dua trampoline nodes dapat ada node Lightning biasa yang tidak mendukung proposal: node tersebut memproses onion dan HTLC standar menurut BOLT #4. Trampoline node mengisi celah rute, tetapi tidak dapat mengubah jumlah, syarat waktu, atau rahasia pembayaran akhir tanpa membuat pemeriksaan selanjutnya gagal. [2]
Delegasi bukan kustodi. Trampoline node tidak memperoleh seed, private key, atau hak sepihak membelanjakan dana channel; namun dapat menolak atau menunda pembayaran, memilih jalur buruk atau mahal, dan mengamati metadata segmennya. Dompet harus menegakkan anggaran biaya dan CLTV, payment secret, error terenkripsi, dan percobaan ulang. [1]
Pada awal Oktober 2026, proposal publik BOLTs #836 masih terbuka, sementara Eclair dan lightning-kmp telah merujuk implementasi format usulan yang lebih baru dan migrasi dari protokol eksperimental lama. Ini membuktikan penerapan nyata, bukan interoperabilitas seluruh jaringan yang selesai; konfigurasi Eclair kini juga memisahkan pengaktifan pembayaran umum dari prototype feature flag. [5]
BOLT #4 melindungi isi lapisan dan hanya memperlihatkan pendahulu serta penerus kepada sebuah hop, tetapi tidak otomatis menyembunyikan semua metadata. Satu penyedia trampoline dapat mengetahui klien pengirim dan, ketika menjembatani penerima tanpa dukungan, tujuan; beberapa trampoline hops dan blinded path dapat membagi pengetahuan itu, sedangkan waktu, jumlah, dan pemakaian ulang tetap menjadi sinyal korelasi. [2]
Route blinding dapat digabungkan dengan trampoline dengan menaruh outgoing_node_id alih-alih outgoing_channel_id dalam data terenkripsi. Trampoline node hanya mendekripsi node berikutnya dan menghitung rute kepadanya; penerima dapat menyembunyikan segmennya sambil mengizinkan pencarian ulang saat likuiditas sementara kurang. [4]
Verifikasi dompet perlu memeriksa apakah gossip benar-benar dibatasi, cara memilih trampoline nodes, feature bits dan onion TLV yang dipakai, apakah format lama atau usulan, cara menegakkan anggaran biaya dan CLTV, menangani kegagalan dan MPP, serta apakah tujuan tanpa dukungan membocorkan lebih banyak kepada node daripada perkiraan pengguna. [3]
Untuk gambaran yang lebih utuh, baca entri ini bersama Lightning Network, Lightning Routing, Lightning Service Provider, HTLC, Payment Channel, Privasi Bitcoin.
01Dapatkah trampoline node mencuri pembayaran Lightning?+
Delegasi pencarian rute saja tidak memberinya private keys atau cara melewati syarat pembayaran. Node tetap dapat menolak, menunda, mencoba jalur mahal, atau mengumpulkan metadata. Dompet harus membatasi biaya dan CLTV, memvalidasi onion serta payment secret, dan mampu memilih node atau percobaan lain.
02Apakah Trampoline Routing sama dengan LSP?+
Tidak. LSP adalah peran operasional yang dapat menyediakan konektivitas, channel, dan likuiditas; trampoline node menghitung segmen rute terdelegasi. Satu operator dapat menjalankan keduanya, tetapi perannya berbeda dan pemusatan meningkatkan ketergantungan ketersediaan serta privasi.