Lightning Routing

Anna ingin membayar kopi, tetapi tidak memiliki kanal dengan kedai. Ia memiliki kanal dengan Pavel, sementara Pavel memiliki kanal lain dengan kedai tersebut. Pembayaran pun dapat melewati Pavel: di kanal pertama, sebagian saldo beralih dari Anna ke Pavel; di kanal kedua, dari Pavel ke kedai. Bukan koin yang sama yang berpindah antarkanal, melainkan saldo setiap kanal berubah melalui langkah-langkah yang saling terkait. Karena itu, Pavel memerlukan dana miliknya sendiri yang dapat digunakan pada sisi tempat ia membayar kedai. Dompet atau node pengirim memilih jalur menuju penerima dan menyiapkan petunjuk untuk setiap tahap. Penerima memberikan data yang diperlukan dan fitur yang didukung; informasi tentang bagian akhir yang tidak dipublikasikan juga dapat disertakan. Node perantara meneruskan pembayaran sesuai petunjuk, bukan mencari sendiri seluruh jalur menuju tujuan setiap kali. [1] [4]

Gossip adalah cara menyebarkan informasi antar-node. BOLT #7 menjelaskan pengumuman kanal dan pembaruan per arah: biaya dasar dan proporsional, selisih waktu kedaluwarsa CLTV, jumlah minimum dan maksimum, serta penanda ketersediaan. Ketentuan yang diumumkan tidak membuktikan bahwa node lawan sedang online atau memiliki dana yang cukup. Di sini, CLTV merujuk pada tenggat yang dinyatakan sebagai ketinggian blok Bitcoin, yaitu posisi blok dalam rantai, bukan waktu yang tepat pada jam. Selisih tenggat memberi perantara waktu untuk bertindak jika penerusan pembayaran terhenti. [2]

Kapasitas total kanal tidak menunjukkan berapa banyak yang dapat dikirim masing-masing pihak saat ini. Pengirim mengetahui kanalnya sendiri, tetapi memakai perkiraan dan riwayat keberhasilan serta kegagalan untuk kanal lain. Perangkat lunak mempertimbangkan biaya sekaligus peluang pembayaran berhasil lewat. Sementara itu, pembayaran lain dapat mengubah likuiditas, yaitu dana yang dapat dikirim ke arah yang diperlukan. [4] [5]

Tahap-tahap tersebut dihubungkan oleh HTLC, yaitu pembayaran bersyarat yang memerlukan pengungkapan nilai rahasia yang sesuai agar dapat diselesaikan. Jika pembayaran belum selesai, dananya dapat diambil kembali setelah tenggat berlalu. Perhitungan dimulai dari jumlah yang harus diterima penerima, lalu bergerak mundur. Setiap perantara perlu menerima jumlah untuk node berikutnya ditambah biayanya sendiri. HTLC yang masuk harus kedaluwarsa cukup lama setelah HTLC yang keluar, sesuai selisih CLTV yang disyaratkan. Jalur lebih panjang dapat menambah biaya dan waktu dana tertahan bila terjadi masalah. [1] [2]

Onion routing menurut BOLT #4 memakai konstruksi Sphinx: setiap tahap menerima petunjuk yang dienkripsi secara terpisah. Perantara mengetahui mitra sebelum dan sesudahnya serta petunjuknya sendiri. Paket itu sendiri tidak mengungkap seluruh rute, panjangnya, atau posisi pasti node. Namun, analisis lalu lintas atau kerja sama antar-node tetap dapat mengurangi privasi. [1]

Kanal dapat gagal sementara, biaya terlalu rendah, CLTV keliru, atau mitra berikutnya tidak tersedia maupun tidak dikenal. Pengirim hanya menerima informasi kesalahan yang terbatas. Perangkat lunaknya dapat menurunkan penilaian rute, menghitung ulang, lalu mencoba kembali. Ini bukan denda yang dibayarkan kepada node, dan satu hasil bukan penilaian keandalan yang berlaku selamanya. [1] [4]

Menemukan koneksi saja tidak cukup: setiap tahap harus menerima HTLC dan memiliki cukup dana yang dapat digunakan ke arah yang diperlukan. Sebagian saldo mungkin disisihkan sebagai cadangan atau tertahan dalam pembayaran yang belum selesai. Kolom teknis htlc_minimum_msat dan htlc_maximum_msat juga menetapkan batas bawah dan atas jumlah satu HTLC dalam arah tersebut. Satuan msat adalah seperseribu satoshi; satoshi merupakan satuan nilai terkecil pada blockchain Bitcoin. Batas yang diumumkan tinggi sekalipun tidak membuktikan bahwa likuiditas yang diperlukan tersedia saat ini. Karena itu, satu kanal yang tidak sesuai dapat menghambat seluruh rute. [2]

Jika penerima mendukung basic MPP, yaitu satu pembayaran yang dibagi menjadi beberapa bagian, pengirim dapat membagi jumlah total, yang disebut total_msat dalam protokol, ke beberapa rute. Penerima menunggu bagian-bagian yang diperlukan lalu menyelesaikannya bersama. Cara ini memanfaatkan likuiditas yang tersebar di beberapa kanal, tetapi MPP tidak menciptakan likuiditas baru. Jumlah HTLC dan percobaan bertambah, begitu pula biaya dalam beberapa keadaan. [1]

Route hints dalam BOLT #11 dapat melengkapi data pengirim tentang tahap-tahap terakhir yang tidak diumumkan. Sebagai gantinya, route blinding yang digunakan dalam BOLT #12 menyediakan bagian akhir terenkripsi melalui node masuk, introduction point. Pengirim tetap harus menemukan jalur yang dapat dipakai menuju titik tersebut dan memenuhi gabungan syarat biaya serta CLTV. Privasi yang lebih baik tidak menjamin pembayaran sampai. [3] [6] [1]

Untuk pembayaran sehari-hari, dompet menangani pencarian rute. Rincian berikut terutama berguna bagi operator node dan untuk menyelidiki masalah yang berulang. Catat perangkat lunak dan versinya, jumlah pembayaran, batas biaya dan CLTV, jumlah percobaan, rute yang dipakai, waktu penyelesaian, serta penyebab kegagalan yang tepat. Bandingkan pasangan node yang sama pada waktu yang berdekatan. Keberhasilan menggambarkan pembayaran tertentu dalam keadaan jaringan tertentu, bukan skor global yang berlaku selamanya. [4] [5]