Likuiditas Lightning

Anna dan Pavel memiliki kanal berkapasitas 1.000.000 sat: sejuta satoshi, satuan terkecil pada rantai Bitcoin. Bayangkan kondisi sederhana dengan 800.000 sat milik Anna dan 200.000 sat milik Pavel. Agar mudah dipahami, kita abaikan dulu cadangan, biaya, dan pembayaran yang masih diproses. Anna mengirim kepada Pavel dari sisinya sendiri; untuk menerima dari Pavel, dana harus berasal dari sisi Pavel. Jadi, Pavel tidak bisa mengirim 300.000 sat kepada Anna melalui kanal ini meskipun kapasitas totalnya sejuta. Uangnya tidak hilang. Pembagiannya saja belum memungkinkan pembayaran itu. [1] [3]

Likuiditas keluar adalah jumlah yang bisa digunakan untuk pembayaran dari dirimu. Dalam contoh, dasarnya adalah saldo Anna sebesar 800.000 sat, tetapi batas sebenarnya biasanya lebih kecil karena cadangan, biaya, dan pembayaran yang masih diproses. Saat Anna membayar orang selain Pavel, langkah pertamanya tetap melewati salah satu kanal miliknya. Node adalah program yang mengelola kanal dan memproses pembayaran Lightning. Node berikutnya memerlukan dana mereka sendiri untuk langkah selanjutnya. Bitcoin di luar kanal tidak otomatis menambah likuiditas keluarnya; dompet harus menggunakan cara yang sesuai untuk memindahkan nilai itu ke Lightning. [1] [3]

Likuiditas masuk adalah jumlah yang bisa dikirim pihak lain kepadamu. Jika Anna membuka kanal dan hampir semua dananya menjadi miliknya, ia mudah mengirim tetapi hanya punya sedikit ruang untuk menerima. Membuat permintaan pembayaran baru tidak mengubah pembagian itu. Ia membutuhkan kanal dengan saldo yang bisa dipakai di sisi pihak lain. Sebagian dompet mengaturnya melalui penyedia layanan sehingga pengguna tidak perlu menangani kerumitannya, sering kali dengan biaya. Kapasitas masuk bukan tambahan kekayaan yang sudah dimiliki Anna, melainkan kemampuan menerima pembayaran mendatang. [1] [3] [5]

Sekarang Anna membayar Pavel 100.000 sat. Dalam contoh sederhana kita, saldo menjadi 700.000 sat untuk Anna dan 300.000 sat untuk Pavel. Kapasitas tetap 1.000.000 sat. Anna bisa mengirim lebih sedikit, tetapi menerima kembali lebih banyak; bagi Pavel berlaku sebaliknya. Jika dompet memiliki beberapa kanal, yang berubah adalah kanal yang benar-benar dipakai pembayaran itu. Arah selalu penting. Angka likuiditas pada pagi hari belum tentu menggambarkan jumlah yang bisa dikirim malam nanti. [1] [3]

Pembayaran kepada penerima yang jauh melewati serangkaian kanal. Setiap kanal membutuhkan likuiditas yang cukup dalam arah yang benar, termasuk jumlah untuk biaya langkah-langkah berikutnya. Jika satu langkah tidak bisa dilewati, rute itu gagal meskipun kanal lainnya berkapasitas besar. Dompet dapat mencoba rute lain atau membagi pembayaran menjadi beberapa bagian jika didukung. Itu tetap tidak menciptakan dana yang kurang. Bukan hanya jumlah uang yang diperiksa, tetapi juga batas waktunya. HTLC adalah pembayaran bersyarat yang dapat diselesaikan dengan membuktikan pengetahuan tentang suatu rahasia. Aturan terkait CLTV menetapkan tenggat berdasarkan blok; selisih tenggat antarlangkah memberi perantara waktu untuk menyelesaikan pembayaran pada rantai Bitcoin jika penerusannya terhenti. [1] [2]

Perantara harus bisa menerima lewat satu kanal dan mengirim pembayaran yang terkait lewat kanal lain. Jumlah seluruh saldo yang besar saja tidak cukup. Jika dananya berada di sisinya pada kanal yang salah, dana itu mungkin tidak bisa dipakai untuk rute pilihan. Ia membutuhkan likuiditas masuk di kanal pertama dan likuiditas keluar di kanal kedua. Kedua langkah dihubungkan oleh ketentuan HTLC: pembayaran bergantung pada pengetahuan tentang suatu rahasia dan aturan waktu. Jadi, perantara tidak sekadar mengandalkan janji bahwa peserta sebelumnya akan membayar nanti. [1] [3]

Pembayaran masuk dan keluar secara alami mengubah likuiditas. Pengelola beberapa kanal juga bisa melakukan penyeimbangan melingkar: mengirim pembayaran dari dirinya melalui satu rute lalu menerimanya kembali lewat rute lain untuk menggeser saldo antarkanal sendiri. Swap menukar dana pada rantai dengan dana Lightning, atau sebaliknya. Splicing memungkinkan perubahan pendanaan kanal yang mendukungnya tanpa proses penutupan dan pembukaan ulang biasa. Membuka kanal lain juga merupakan pilihan. Cara-cara ini berbeda dalam biaya, waktu, jejak pada rantai, kebutuhan akan kepercayaan, dan risiko kegagalan. Tidak satu pun menciptakan uang baru; pilih sesuai kebutuhan mengirim, menerima, atau keduanya. [1] [4]

Pertama, tentukan apakah masalahnya pada pengiriman atau penerimaan, lalu periksa apakah dompet dan node pihak lain sedang online. Pada node sendiri, bandingkan saldo lokal dan saldo pihak lain untuk setiap kanal, cadangan, pembayaran tertunda, serta biaya. Pada dompet yang dikelola layanan, pastikan arti sebenarnya dari jumlah tersedia yang ditampilkan. Satu pembayaran gagal tidak dengan sendirinya membuktikan uang hilang. Salah satu langkah mungkin kekurangan likuiditas, terkena batas, atau mengalami gangguan sementara. Pembayaran uji yang kecil hanya memeriksa jumlah itu pada saat itu, bukan menjamin semua pembayaran selanjutnya akan lewat. [1] [3] [4]

Operator node perlu membedakan beberapa pembatasan. Output transaksi menetapkan jumlah uang dan syarat untuk membelanjakannya. channel_reserve_satoshis menunjukkan dana yang harus tetap menjadi cadangan. Sebagian dana bisa terikat dalam HTLC yang tertunda, yaitu pembayaran bersyarat yang belum selesai. Batas berikut berlaku untuk HTLC yang ditawarkan oleh peserta lainnya. max_htlc_value_in_flight_msat membatasi total nilainya dan max_accepted_htlcs membatasi jumlahnya; msat adalah seperseribu satoshi yang dipakai dalam perhitungan internal Lightning. Tergantung jenis kanal, ada pula biaya commitment transaction, transaksi untuk menutup kanal, dan mungkin anchor outputs: output khusus yang memungkinkan penambahan transaksi lanjutan untuk menaikkan biaya konfirmasi seluruh paket. Aturan Dust menentukan output mana yang terlalu kecil untuk dimasukkan ke transaksi itu. Karena itu, hitung batas tersedia sesuai implementasi dan jenis kanal tertentu, bukan dengan mengurangi satu cadangan yang dianggap berlaku universal. [1] [6]

BOLT #7 menjelaskan pengumuman kanal dan kebijakan penerusan pembayaran. Untuk kanal yang diumumkan, output pendanaan dan kapasitasnya bisa ditemukan pada rantai. Namun, itu tidak mengungkap pembagian saldo terkini antara peserta. Pengirim memilih rute berdasarkan informasi sendiri, hasil sebelumnya, dan percobaan pembayaran, bukan daftar publik lengkap saldo terkini. Jadi, penjelajah jaringan dapat menampilkan kanal besar tanpa memastikan bahwa jumlahmu saat ini bisa melewatinya dalam arah yang benar. [2]