Di Lightning Network, sender biasanya menyusun rute. Dari public gossip graph, data recipient, dan hasilnya sendiri, ia memperkirakan path ke tujuan; amount, fee, dan CLTV tiap hop dihitung mundur, instruksi dibungkus dalam onion packet, lalu path lain dicoba setelah gagal. Karena graph publik tidak menampilkan pembagian balance terkini, routing adalah keputusan probabilistik atas informasi yang tidak lengkap dan cepat berubah.
Routing dimulai pada payer: wallet atau node memilih candidate path ke payee dan menentukan channel berikutnya bagi setiap perantara. Recipient memberikan identity, features, dan mungkin route hints atau blinded paths; bagian publik biasanya dihitung sender.
BOLT #7 menyebarkan channel announcements dan directional channel updates berisi base fee, proportional fee, CLTV delta, minimum, maksimum, dan availability. Data ini menggambarkan policy dan topology yang diumumkan, bukan bukti peer online atau liquidity saat ini.
Public gossip tidak mengungkap pembagian balance channel. Router menggabungkan local liquidity yang diketahui, capacity, keberhasilan, kegagalan, penalty, dan scoring implementasi. Path termurah secara teori belum tentu paling mungkin berhasil.
Amount dan expiry disusun mundur dari payee ke payer. Setiap hop menerima amount berikut plus fee sendiri dan CLTV lebih tinggi sebesar delta; lebih banyak hops menaikkan total fee dan margin timelock.
BOLT #4 memakai onion routing: payer membuat Sphinx packet dengan payload terenkripsi terpisah untuk tiap hop. Perantara mengetahui peer tetangga dan instruksinya, bukan seluruh path, panjang, atau posisinya; traffic analysis dan kolusi tetap berisiko.
Temporary channel failure, fee kurang, CLTV salah, atau next peer tidak dikenal mengembalikan failure signal terbatas. Implementasi dapat memberi penalty, menghitung ulang, dan retry; satu hasil tidak menggambarkan channel secara permanen.
Setiap hop harus menerima HTLC dan memiliki liquidity arah yang tepat setelah reserve, pending HTLC, serta batas htlc_minimum_msat dan htlc_maximum_msat. Aggregate capacity besar atau banyak connections tidak menghapus satu channel bottleneck.
Jika invoice mendukung basic MPP, payer membagi total_msat ke beberapa paths yang diselesaikan recipient sebagai satu set. MPP memakai liquidity tersebar, tetapi menambah HTLC, attempt, dan fees serta tidak menciptakan capacity.
BOLT 11 route hints dapat mengungkap hops privat terakhir; BOLT 12 dan route blinding memberi ekor terenkripsi lewat introduction point. Payer tetap harus menemukan rute ke titik pertama dan mematuhi fee serta CLTV agregat.
Catat implementasi dan versi, amount, fee maksimum dan batas CLTV, jumlah attempt, paths, waktu selesai, dan failure reason. Bandingkan pasangan nodes sama pada waktu berdekatan: success milik payment dan network state tertentu. Sumber: BOLT #4 — Onion Routing Protocol; BOLT #7 — P2P Node and Channel Discovery; BOLT #11 — Lightning Payment Encoding; Lightning Labs — Pathfinding; LDK — Routing and Route Parameters.
Untuk gambaran yang lebih utuh, baca entri ini bersama Lightning Network, HTLC, Likuiditas Lightning, Payment Channel, Bitcoin, Inbound Liquidity. Entri ini juga dirujuk dari HTLC, Likuiditas Lightning, BOLT 12, Inbound Liquidity.