Halaman ini merangkum dan menganalisis paper Lightning Network asli sebagai bahan referensi. Ini bukan reproduksi verbatim, dan CryptoGloss tidak mengklaim sebagai penulis dokumen sumber. Paper resmi tersedia melalui tautan di atas.
| Penulis | Poon, Joseph; Dryja, Thaddeus |
|---|---|
| Tahun | 2016 |
| Proyek | Lightning Network |
| Lisensi | Tidak disebutkan dalam sumber |
| Sumber Resmi | The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments (PDF resmi) |
Dokumen 59 halaman yang dihosting diberi label Draft Version 0.5.9.2 dan bertanggal 14 Januari 2016. Dokumen ini mengusulkan pemindahan pembayaran Bitcoin berulang ke luar blockchain, sementara Bitcoin tetap digunakan untuk penyelesaian dan penegakan aturan. Ini adalah proposal desain historis; implementasi berikutnya dirinci dan disempurnakan melalui dokumen protokol yang terus berkembang.
Masalah dan Proposal
Paper ini berangkat dari kompromi penskalaan: jika setiap pembayaran dicatat pada ledger bersama Bitcoin, node harus memproses dan menyimpan data blockchain yang dihasilkan. Alih-alih mengubah konsensus layer dasar Bitcoin, Poon dan Dryja mengusulkan saluran pembayaran bilateral. Peserta mendanai saluran on-chain, bertukar pembaruan saldo bertanda tangan secara privat, lalu menggunakan Bitcoin untuk menyelesaikan saldo saat saluran ditutup atau ketika kerja sama gagal. Cara ini dapat mengurangi frekuensi pembayaran saluran biasa yang memerlukan transaksi on-chain, tetapi tidak menghapus kebutuhan akan konfirmasi Bitcoin, ruang blok, atau biaya.
Cara Kerja Saluran Pembayaran
- Membuka dan mendanai: Dua peserta membuat transaksi Bitcoin on-chain yang mengunci dana ke output saluran bersama.
- Memperbarui saldo: Mereka bertukar transaksi komitmen bertanda tangan yang mewakili keadaan saluran terbaru yang disepakati. Pembaruan ini dapat berlangsung tanpa menyiarkan masing-masing transaksi ke Bitcoin.
- Menutup dan menyelesaikan: Peserta dapat menyepakati penutupan bersama. Jika salah satu pihak berhenti bekerja sama, pihak lain dapat menyiarkan transaksi komitmen dan menggunakan jangka waktu serta skrip protokol untuk menyelesaikan saluran on-chain. Force close dan pembayaran tertunda dapat memerlukan transaksi tambahan; penutupan tidak selalu hanya terdiri dari satu transaksi pembukaan dan satu transaksi penutupan.
Dalam desain paper ini, data pencabutan membuat keadaan lama dapat dikenai penalti jika lawan pihak menyiarkannya. Mekanisme ini bukan alasan untuk mengabaikan data saluran atau tenggat pemantauan. Spesifikasi berikutnya menjelaskan aturan saluran dan format transaksi saat ini, termasuk protokol pengelolaan saluran BOLT #2 dan format transaksi Bitcoin BOLT #3.
Pembayaran Multi-Hop dan Privasi Routing
Paper ini menjelaskan routing pembayaran melalui saluran yang saling terhubung. Hash time-locked contract (HTLC) membuat pembayaran bergantung pada pengungkapan rahasia oleh penerima, sedangkan timelock bertahap memberi peserta waktu untuk menyelesaikan atau mengembalikan pembayaran yang terhubung. Desain ini memungkinkan perantara meneruskan pembayaran tanpa harus dipercaya untuk mengambil hak asuh atas jumlah akhirnya. Dalam praktiknya, rute tetap membutuhkan likuiditas yang cukup ke arah yang diperlukan, dan setiap hop menerapkan aturan serta biayanya sendiri.
Paper asli menjelaskan pembayaran multi-hop; spesifikasi onion routing BOLT #4 yang lebih baru merinci paket berbasis Sphinx untuk membatasi informasi yang diketahui node penerus tentang bagian lain dari rute. Onion routing adalah langkah privasi, bukan jaminan anonimitas: endpoint, metadata pembayaran, waktu, dan analisis lalu lintas masih dapat mengungkapkan informasi.
Dari Draf 2016 ke Spesifikasi Berikutnya
Draf ini mengusulkan soft fork Bitcoin dan perilaku tanda tangan baru untuk mengatasi malleability transaksi dalam rancangan saluran tersebut. Proposal historis itu tidak sama dengan desain Segregated Witness yang muncul kemudian. Operasi Lightning saat ini ditentukan oleh spesifikasi berikutnya yang terus berkembang, bukan oleh paper ini saja. Paper asli paling tepat dibaca sebagai proposal desain awal, bukan panduan lengkap untuk setiap dompet atau node saat ini. BIP 141 mendokumentasikan desain SegWit berikutnya dan motivasi terkait malleability transaksi.
Kompromi dan Risiko Operasional
- Dana terikat di saluran: Pembukaan memerlukan transaksi on-chain dan mengunci dana dalam susunan saluran; penutupan juga bergantung pada Bitcoin.
- Likuiditas memengaruhi routing: Pembayaran dapat gagal jika rute yang dapat digunakan tidak memiliki saldo cukup ke arah yang diperlukan, meskipun saldo pengirim yang terlihat tampak cukup. Kapasitas saluran tidak sama dengan likuiditas masuk yang dapat dibelanjakan.
- Biaya dan konfirmasi bergantung pada kondisi: Biaya on-chain berubah, node penerus dapat mengenakan biaya, dan penutupan saluran bersaing mendapatkan ruang blok.
- Pengguna memerlukan rencana pemulihan: Keadaan saluran harus dilindungi dan aturan keselamatan diikuti. Watchtower yang dikonfigurasi dapat memantau pelanggaran saat node offline, tetapi tidak menghilangkan seluruh risiko operasional. Lihat panduan watchtower Lightning Labs.
- Privasi terbatas: Onion routing membatasi informasi rute yang diketahui sebuah hop penerus; cara ini tidak menyembunyikan semua metadata dari peserta, endpoint, atau pengamat.
Mengapa Paper Ini Penting
Kontribusi utamanya adalah cara menghubungkan saluran pembayaran bilateral menjadi jaringan sehingga peserta dapat membayar pihak di luar mitra saluran langsungnya. Desain ini memindahkan banyak pembaruan saldo ke luar blockchain sambil mempertahankan transaksi Bitcoin sebagai mekanisme penyelesaian dan sengketa. Ini tidak berarti setiap pembayaran instan, gratis, privat, atau pasti berhasil dirutekan.
Sentimen Media Sosial
Diskusi online menunjukkan dua pandangan yang berulang. Pendukung menghargai kemungkinan melakukan pembayaran berulang tanpa mencatat setiap pembaruan saldo di Bitcoin. Pengkritik mempertanyakan apakah pembayaran yang dirutekan sebanding dengan biaya likuiditas, pengelolaan saluran, keandalan, dan pengalaman pengguna. Sebuah diskusi Reddit menggambarkan perbedaan pendapat tentang saluran yang dirutekan dibandingkan saluran pembayaran langsung yang lebih sederhana; ini hanya contoh perdebatan komunitas, bukan survei yang mewakili semua pengguna. Spesifikasi teknis menjelaskan cara kerja protokol, tetapi tidak membuktikan tingkat adopsinya atau kecocokannya untuk pembayaran tertentu.
Terakhir diperbarui: 2026-10
Istilah Terkait
Lihat Juga
- Bitcoin: Sistem Pembayaran Elektronik Peer-to-Peer — layer dasar yang dirancang untuk diperluas oleh Lightning.
- Plasma: Smart Contract Otonom yang Dapat Diskalakan — proposal terpisah untuk penskalaan aktivitas blockchain ke luar blockchain utama.
- Celer Network: Bring Internet Scale to Every Blockchain — desain lain yang mencakup penskalaan off-chain dan state channel.
Referensi
- Poon, J., & Dryja, T. (2016). The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments (Draft Version 0.5.9.2). PDF paper resmi — sumber utama untuk proposal saluran, HTLC, dan routing asli.
- Lightning Network Developers. BOLT #2: Peer Protocol for Channel Management. Spesifikasi pengelolaan saluran — menjelaskan pembentukan, pembaruan, dan penutupan saluran.
- Lightning Network Developers. BOLT #3: Bitcoin Transaction and Script Formats. Spesifikasi transaksi — merinci transaksi pendanaan, komitmen, dan transaksi terkait.
- Lightning Network Developers. BOLT #4: Onion Routing Protocol. Spesifikasi routing — menjelaskan paket onion dan informasi yang dapat diketahui node penerus.
- Bitcoin Improvement Proposals. BIP 141: Segregated Witness (Consensus layer). Spesifikasi BIP 141 — mendokumentasikan desain SegWit berikutnya dan motivasi malleability-nya.
- Lightning Labs. Configuring Watchtowers. Dokumentasi watchtower — menjelaskan pemantauan opsional atas pelanggaran saluran saat node offline.
- Reddit, r/btc. “Honest question: name one use case for Lightning Network that isn’t handled better by (unbroken) L1 + regular Satoshi-style payment channels”. Diskusi komunitas — contoh perdebatan tentang manfaat routing dan kompleksitas, bukan survei yang mewakili pengguna.