Inbound Liquidity

Petr mengelola kafe dan menerima pembayaran Lightning Network. Node-nya, perangkat lunak yang menangani pembayaran, menunjukkan dana, tetapi pelanggan tidak bisa membayar. Kekurangan likuiditas masuk bisa menjadi salah satu sebab. Kanal pembayaran adalah kesepakatan dua node tentang pembagian bitcoin yang disetorkan. Bagian Petr disebut local balance, sedangkan bagian mitranya remote balance. Saat menerima pembayaran, nilai berpindah dari sisi mitra ke Petr. Jadi, sisi mitra harus memiliki dana yang bisa berpindah. Remote balance tetap milik mitra: memperoleh kemampuan menerima bukan hadiah bitcoin atau pendapatan yang sudah diperoleh. [1] [6]

Bayangkan kanal berkapasitas 1000000 sat. Sat adalah singkatan satoshi, satuan kecil bitcoin. Petr memiliki local balance 800000 sat dan mitra remote balance 200000 sat. Sebelum memperhitungkan batas lain, Petr dapat menerima 200000 sat. Jika Petr menerima 100000 sat, sisinya naik menjadi 900000 sat dan mitra menyisakan 100000 sat. Petr memperoleh pembayaran, tetapi ruang menerima berikutnya menyusut. Agar mudah dipahami, contoh ini mengabaikan cadangan, biaya, dan pembayaran tertunda bernama HTLC yang dijelaskan di bawah. Jika Petr mendanai kanal baru sendirian tanpa transfer awal kepada mitra, yang terutama diperoleh adalah kemampuan mengirim. Konfirmasi pembukaan kanal tidak membalik arah itu. [1] [2]

Pada hari yang ramai, uang di sisi Petr bertambah sementara ruang masuk kanal yang digunakan berkurang. Saldo yang lebih besar bisa berjalan bersamaan dengan kemampuan menerima yang lebih kecil. Infrastruktur sendiri memerlukan pemantauan kanal yang bisa dipakai, jumlah yang diperkirakan, pembayaran berjalan, dan biaya menambah likuiditas. Beberapa dompet menangani sebagian tugas tersebut untuk pengguna, tetapi mekanismenya tetap ada. Petr bahkan mungkin tidak melihat percobaan gagal: pembayaran bisa berhenti sebelum mencapai node-nya. Invoice yang diterbitkan atau angka kapasitas lama bukan konfirmasi penerimaan dana. [6]

Ketika Petr membayar pemasok lewat Lightning, local balance kanal yang dipakai turun dan remote balance naik. Ini bisa membuka ruang untuk pemasukan berikutnya. Loop Out bekerja serupa: melalui swap, pertukaran antarlapisan pembayaran, ia mengirim nilai dari Lightning dan menerima bitcoin pada alamat di blockchain. Kanal tidak harus ditutup. Loop In berjalan sebaliknya, mengubah dana di blockchain menjadi saldo Lightning yang bisa dibelanjakan. Keduanya tidak menciptakan bitcoin. Membandingkan hasil berarti menghitung biaya perutean, layanan swap, dan transaksi blockchain, serta memastikan operasinya benar-benar selesai. [1] [4]

Mitra juga bisa mendanai kanal ke Petr. Petr memperoleh ruang masuk tanpa menerima dana mitra sebagai hadiah. Dokumentasi Lightning Pool menjelaskan pasar kesepakatan ini: bid adalah permintaan likuiditas, ask adalah penawaran untuk menyediakannya. Sewa memiliki jangka waktu dalam blok serta premi dan biaya lain. Blok adalah kumpulan transaksi yang ditambahkan ke blockchain, riwayat transaksi publik Bitcoin. Karena itu, jangka sewa mengikuti penambahan blok, bukan jumlah jam yang pasti. Ini bukan pembelian seluruh saldo di sisi mitra. Jangka waktu yang disepakati juga tidak berarti jumlah yang sama selalu bisa diterima sepanjang periode itu, karena pembayaran mengubah pembagian saldo. Ketersediaan kanal selamanya setelah kesepakatan berakhir pun tidak boleh diasumsikan. [1] [5]

Petr mungkin memiliki beberapa kanal dan membutuhkan ruang masuk pada mitra lain. Circular rebalancing, penyeimbangan melingkar, mengirim pembayarannya ke jaringan melalui satu kanal lalu membawanya kembali melalui kanal miliknya yang lain. Kanal pengirim memperoleh ruang masuk; kanal penerima menghabiskannya. Dana berpindah di antara sisi-sisi Petr pada kanal, tanpa menciptakan modal baru, dan perutean memerlukan biaya. Operasi ini membutuhkan rute yang bisa dipakai. Jika semua sisi mitra kanalnya kekurangan dana, tidak ada kanal untuk menerima bagian pembayaran yang kembali. Penyeimbangan melingkar saja tidak memperbaikinya. [1]

Sebagian dana harus tetap menjadi cadangan demi operasi kanal yang aman. Dana lain mungkin sementara terikat dalam HTLC, komitmen pembayaran bersyarat. Penerima bisa mengambilnya dengan mengungkap nilai rahasia yang menghasilkan hash pembayaran yang disepakati, yaitu nilai untuk verifikasi. Jika pembayaran gagal, pihak pengirim memiliki cara untuk mengambil kembali dana setelah tenggat. BOLT 2, spesifikasi pengelolaan kanal, juga membatasi jumlah minimum, banyaknya HTLC bersamaan, dan total nilainya. Karena itu, seluruh remote balance belum tentu tersedia untuk pembayaran lain. Menjumlahkan saldo di sisi mitra lalu mengurangi cadangan seragam tidak cukup; setiap kanal dan keadaan terkini penting. [2]

Pembayaran biasanya melewati beberapa node. Meskipun Petr punya ruang penerimaan, ruas sebelumnya bisa terputus atau kekurangan dana. BOLT 7 menjelaskan pesan channel_update, yang dipakai node untuk mengumumkan kondisi perutean dalam satu arah kanal. Isinya mencakup biaya dan htlc_maximum_msat, batas atas satu pembayaran bersyarat dalam msat, seperseribu satoshi. Itu bukan janji tentang saldo terkini sepanjang rute. Karena itu, total ruang masuk Petr tidak menjamin ia bisa menerima jumlah tersebut dari setiap pengirim tertentu. Likuiditas penerima adalah bagian yang diperlukan, bukan satu-satunya bagian solusi. [3]