Likuiditas Lightning

Kapasitas kanal adalah bitcoin yang dikunci dalam output pendanaan. Likuiditas hanya bagian yang saat ini dapat digunakan dalam satu arah. Karena itu, kanal berkapasitas 1.000.000 sats dapat menyimpan hampir semuanya di satu sisi dan gagal membawa pembayaran besar ke arah sebaliknya. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

Likuiditas keluar adalah jumlah yang dapat dikirim simpul lokal melalui kanal setelah memperhitungkan cadangan protokol, kewajiban biaya transaksi commitment dan HTLC tertunda. Jumlahnya turun ketika membayar atau meneruskan keluar, lalu naik ketika nilai datang dari rekan. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

Likuiditas masuk adalah jumlah yang dapat dikirim rekan menuju simpul lokal. Ini diperlukan untuk menerima melalui kanal tersebut, tetapi mengubah permintaan pembayaran tidak menciptakannya. Nilainya harus ada dalam saldo jarak jauh atau disediakan melalui operasi pengelolaan likuiditas. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

Pembayaran melalui rute hanya berhasil jika setiap lompatan yang dipilih memiliki likuiditas yang dapat digunakan dalam jumlah cukup dan arah yang benar, serta menerima HTLC sesuai aturan biaya, jumlah minimum dan maksimum, dan batas waktu CLTV. Satu kanal yang kehabisan likuiditas dapat menghalangi rute yang selebihnya terhubung dengan baik. [BOLT #2 — Peer Protocol for Channel Management] [BOLT #7 — P2P Node and Channel Discovery]

channel_reserve_satoshis, biaya transaksi commitment, anchor outputs, aturan dust, max_htlc_value_in_flight_msat, max_accepted_htlcs dan HTLC yang sudah tertunda dapat mengurangi jumlah yang tersedia untuk pembayaran baru. Saldo dompet, kapasitas kanal dan jumlah yang segera dapat dirutekan karena itu merupakan tiga angka berbeda. [BOLT #2 — Peer Protocol for Channel Management]

BOLT #7 memungkinkan pengumuman kanal beserta aturan penerusannya. Kapasitas dapat diketahui dari output pendanaan yang diidentifikasi pada rantai; ini tidak mengungkap pembagian saldo privat. Pengirim memperkirakan rute berdasarkan informasi sendiri, hasil terdahulu dan percobaan pembayaran. Penjelajah publik tidak dapat memastikan bahwa rute yang dipilih akan membawa jumlah tertentu tepat saat ini. [BOLT #7 — P2P Node and Channel Discovery]

Pembayaran yang diselesaikan menggeser saldo pada setiap kanal yang digunakan: likuiditas keluar turun dan likuiditas masuk naik di sisi pengirim, dengan perubahan sebaliknya di ujung lain. Pembayaran membagi ulang kapasitas yang sudah ada tanpa menambah kapasitas total. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

Simpul penerusan membutuhkan likuiditas masuk pada satu kanal dan likuiditas keluar pada kanal berikutnya untuk HTLC yang sama. Jumlah sats total yang besar tidak cukup jika berada pada kanal atau sisi yang salah. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]

Pembayaran yang diterima, penyeimbangan melingkar, pembukaan atau penutupan kanal, swap dan splicing dapat memindahkan likuiditas. Semuanya berbeda dalam biaya, jejak pada rantai, waktu, kepercayaan kepada pihak lawan dan risiko kegagalan; tidak ada metode yang menciptakan likuiditas gratis. Pembayaran beberapa bagian dapat menggabungkan rute, tetapi tetap memerlukan kapasitas arah gabungan yang mencukupi. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Managing Liquidity]

Pada simpul sendiri, periksa saldo lokal dan jarak jauh setiap kanal, cadangan, HTLC tertunda dan penyangga biaya, lalu uji jumlah yang direncanakan. Catat arah, jumlah, waktu dan implementasi: likuiditas berubah setelah setiap pembayaran dan bukan satu skor permanen untuk seluruh jaringan. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity] [Lightning Labs — Managing Liquidity]