Bitcoin Lightning vs pembayaran on-chain: biaya, konfirmasi, dan kanal

Keduanya dapat memindahkan nilai dalam Bitcoin, tetapi cara memakai lapisan dasar berbeda. Pembayaran on-chain membuat transaksi yang disebarkan oleh node Bitcoin dan dapat dimasukkan penambang ke dalam blok. Pembayaran Lightning melewati rute kanal pembayaran; setiap pembayaran tidak ditulis sebagai transaksi Bitcoin tersendiri di blockchain.

Perbedaan ini memengaruhi biaya, ketersediaan, privasi, dan status yang ditampilkan dompet. Lightning bukan koin lain, dan istilah “off-chain” tidak berarti tanpa aturan atau risiko. Peserta kanal memakai transaksi Bitcoin untuk membuka kanal dan, bila perlu, menyelesaikan saldonya.

Dompet memilih output yang dapat dibelanjakan, menyusun dan menandatangani transaksi, lalu menyiarkannya ke node Bitcoin. Node dapat meneruskan transaksi dan menyimpannya di mempool masing-masing sampai penambang memasukkannya ke blok. Biaya jaringan bergantung pada ukuran transaksi dan tarif yang ditawarkan, bukan hanya jumlah Bitcoin yang dikirim. Lihat panduan pemrosesan pembayaran Bitcoin Developer Guide.

ID transaksi membantu memeriksa transaksi yang telah disiarkan, tetapi tampilnya transaksi bukan berarti sudah dikonfirmasi. Satu konfirmasi berarti transaksi masuk ke suatu blok; blok berikutnya menambah jumlah konfirmasi. Penerima atau layanannya menentukan ambang konfirmasi sesuai jumlah dan konteks. Waktu blok dan target konfirmasi bukan janji bahwa dana tersedia pada menit tertentu.

Penerima dapat memberikan invoice Lightning yang mengodekan permintaan pembayaran, biasanya termasuk jumlah, tujuan, keterangan, dan masa berlaku. Dompet pengirim membacanya lalu mencari rute dengan kapasitas dan batas yang sesuai. Spesifikasi invoice BOLT 11 menjelaskan bidang permintaan; BOLT 7 menjelaskan pengumuman kanal dan pembaruan perutean.

Pembayaran yang dirutekan menggunakan transfer bersyarat yang disebut HTLC. Setiap node perantara menerima jumlah dan syarat waktu untuk bagian berikutnya; penerima akhir mengungkap rahasia yang menyelesaikan pembayaran. Rute dapat gagal jika likuiditas pada arah yang dibutuhkan kurang, pembaruan sudah usang, batas tercapai, atau peer tidak tersedia. Pembayaran Lightning yang berhasil dapat selesai tanpa menunggu blok baru, tetapi tidak semua invoice dijamin berhasil.

Kanal pembayaran dimulai dengan transaksi pendanaan on-chain dan memiliki kapasitas total. Saat peserta saling membayar, saldo berubah tanpa memublikasikan transaksi Bitcoin terpisah untuk setiap pembaruan. Jumlah yang dapat dikirim salah satu pihak bergantung pada saldo di arah tersebut, cadangan, batas pembayaran, dan rute yang dipilih. Protokol peer BOLT 2 menjelaskan parameter kanal dan batas HTLC.

Kanal dengan kapasitas total yang cukup tetap bisa kekurangan likuiditas keluar untuk pembayaran tertentu. Penerima juga mungkin tidak memiliki jalur masuk yang sesuai untuk jumlah itu. Membuka kanal, memindahkan likuiditas, atau menutup kanal dapat membutuhkan transaksi dan biaya on-chain. BOLT 5 tentang penanganan on-chain menjelaskan penutupan bersama dan sepihak. Ilustrasi memisahkan pembayaran berulang di kanal dari pendanaan dan penutupan yang diselesaikan di Bitcoin.

Biaya on-chain membayar ruang blok. Jumlahnya bergantung pada ukuran transaksi dan tarif yang dipilih untuk kondisi saat ini; transaksi yang lebih besar dapat lebih mahal walau mengirim Bitcoin lebih sedikit. Perkiraan dompet berubah seiring waktu dan tidak memesan tempat di blok mendatang.

Biaya penerusan Lightning ditetapkan operator kanal dan dapat menggabungkan biaya dasar dengan bagian proporsional. Panjang rute, kebijakan, likuiditas, dan perilaku dompet memengaruhi total. Sebagian dompet juga dapat menambahkan biaya layanan atau likuiditas. Lightning mungkin lebih murah dalam kondisi tertentu, tetapi tidak selalu gratis atau lebih murah daripada on-chain. Periksa jumlah akhir, rincian biaya, dan syarat rute sebelum menyetujui.

Dompet on-chain dapat menampilkan status disiarkan, menunggu, atau terkonfirmasi. Transaksi dan blok tercatat secara publik di blockchain, dan penerima dapat menerapkan ambang konfirmasi sesuai jumlah dan konteks. Transaksi bisa belum dikonfirmasi lebih lama dari perkiraan; estimasi biaya tidak menentukan pilihan penambang.

Di Lightning, invoice dianggap terbayar setelah rute selesai dan dompet menerima status sukses. Pembayaran itu tidak dimasukkan satu per satu ke blok Bitcoin. Percobaan yang gagal bukan konfirmasi, dan layar yang belum jelas bukan bukti bahwa membayar lagi aman. Sebelum mencoba kembali, periksa status akhir di dompet pengirim serta invoice atau tanda terima dari penerima.

Data on-chain bersifat publik dan dapat dianalisis, meski sebuah alamat tidak otomatis menunjukkan nama seseorang. Onion routing Lightning dirancang agar tiap node penerus hanya mengetahui sebagian rute, tetapi tidak membuat semua pembayaran anonim. Spesifikasi onion routing BOLT 4 dan pembaruan kanal publik di BOLT 7 menjelaskan sebagian model privasi ini.

Dompet juga berbeda dalam hal siapa yang mengendalikan kunci serta bagaimana kanal dipantau, dicadangkan, dan dipulihkan. Dompet kustodi mandiri dan akun Lightning kustodian memiliki tanggung jawab dan risiko gangguan yang berbeda. Koneksi internet, ketersediaan peer, status kanal, pemulihan, dan ketentuan penyedia dapat berpengaruh. Nama “Lightning” saja tidak menjelaskan kustodi atau perlindungan cadangan.

On-chain dapat cocok jika penerima memberi alamat Bitcoin dan memerlukan transaksi yang bisa diperiksa di blockchain. Lightning dapat cocok untuk pembayaran antar-dompet yang kompatibel bila invoice dan rute dengan likuiditas cukup tersedia. Pembayaran kecil yang berulang dapat memakai kanal yang sama, tetapi pembukaan, pengelolaan, dan penutupan kanal memiliki biaya serta batasnya sendiri.

Sebelum mengirim, periksa jenis pembayaran, jaringan, jumlah, masa berlaku invoice, penerima, biaya yang ditampilkan, dan batasnya. Jangan menempel invoice Lightning ke kolom alamat on-chain atau memakai jalur yang tidak diminta penerima. Gunakan fallback on-chain hanya jika invoice dan dompet secara jelas menyediakannya. Bacaan terkait: biaya transaksi Bitcoin, konfirmasi deposit, dan daftar periksa transfer kripto.

Rujukan teknis primer: Bitcoin Developer Guide: pemrosesan pembayaran; BOLT 2: protokol peer; BOLT 4: onion routing; BOLT 5: transaksi on-chain; BOLT 7: informasi perutean; BOLT 11: pengodean invoice.