Penulis: Viktor Bunin, Penyusun Pakar Protokol Cloud Coinbase: Qianwen, ChainCatcher
Saya sudah lama tidak menggunakan Lightening (kemudian disebut "Lightning Network").
Terakhir kali saya menghabiskan waktu untuk mengerjakannya adalah pada tahun 2019 ketika saya bekerja sama dengan Elizabeth Stark dan pemimpin komunitas lainnya untuk menyelenggarakan Konferensi Jaringan Petir pertama di Berlin. Sejak itu, saya menghabiskan sebagian besar waktu saya mengerjakan protokol lain, dan sementara saya masih berteman dengan orang-orang seperti Elizabeth, pemahaman saya tentang cara kerja Lightning Network telah menurun. Setelah memeriksa ulang, saya menyadari bahwa itu bukan hanya saya, tetapi sebagian besar teman saya juga.
Posting ini untuk mereka yang belum pernah menggunakan Lightning Network baru-baru ini. Ini akan membahas kesalahpahaman saya atau orang lain yang saya lihat. Jika saya melewatkan poin bagus, tolong beri saya garis di Twitter.
**Kesalahpahaman 1: Anda harus menjalankan node Anda sendiri untuk menggunakan Lightning Network tanpa pengawasan, yang mencegah pengguna biasa menggunakan perangkat seluler. **
Ini benar beberapa tahun yang lalu, tetapi sekarang pengguna dapat menggunakan Jaringan Lightning di perangkat seluler melalui klien ringan yang tidak dikelola. Pengguna selalu mengendalikan kunci mereka, dan pengalaman dompet menggunakan Lightning Light Client sama dengan memanggil Alchemy atau Infura melalui RPC saat menggunakan Ethereum.
**Kesalahpahaman 2: Pengirim dan penerima harus online pada saat yang sama agar pembayaran Lightning berhasil (tidak ada pembayaran offline/sinkron). **
Situasi ini masih ada, tetapi dengan beberapa solusi yang rapi. Dompet seluler Lightning non-penahanan dapat menerima pembayaran melalui tugas latar belakang atau pemberitahuan telepon bahkan saat dompet tidak berjalan di latar depan. Namun, pendekatan ini dibatasi oleh sistem operasi seluler. Sistem operasi modern membatasi jumlah perhitungan yang dilakukan oleh aplikasi latar belakang untuk menghemat baterai. Menerima beberapa pembayaran LN baik-baik saja, tetapi jika terlalu banyak yang diterima dalam waktu singkat, mereka mulai kedaluwarsa karena kendala komputasi.
Dalam jangka panjang, pengembang protokol Lightning Network sedang mengerjakan spesifikasi Async Payments, yang akan mengaktifkan latensi tanpa kepercayaan yang panjang secara sewenang-wenang. Pada dasarnya, pembayaran dikreditkan dari node pengirim, tetapi jika node penerima offline, pembayaran tetap berada di LSP pengirim (Lightning Network/Penyedia Layanan Likuiditas, biasanya dijalankan oleh dompet itu sendiri), sampai penerima kembali online. ** Pembaruan ini diharapkan terjadi tahun depan, tetapi belum ada tanggal peluncuran resmi. **Namun, ini membutuhkan dompet yang berpartisipasi untuk memuat LSP, yang dapat menghambat pengadopsiannya sebagai solusi seluruh jaringan.
**Kesalahpahaman 3: Lightning Network mengharuskan kedua pengguna untuk menginvestasikan jumlah BTC yang sama di saluran untuk membuka saluran. **
Ini tidak berlaku. Pada sebagian besar klien Lightning Network, saluran dibuka satu arah secara default, jadi hanya pengirim yang perlu menginvestasikan dana di saluran, dan penerima pembayaran dapat berupa alamat kosong yang baru. Kesalahpahaman ini berasal dari buku putih Lightning Network, di mana contoh-contoh secara konsisten mengacu pada saluran pendanaan dua arah.
Ini sebenarnya didasarkan pada cerita latar yang menarik. Saluran pembayaran paling awal (Spilman) hanya mengizinkan pembayaran satu arah. Inovasi Lightning Network terletak pada realisasi dana ganda dan pembayaran dua arah, dan saluran tidak memiliki waktu kedaluwarsa. Ini mungkin mengapa makalah Jaringan Petir sangat berfokus pada hal itu. Ini adalah penemuan yang signifikan dibandingkan dengan desain protokol yang dikenal pada saat itu.
**Mitos 4: Lightning Network mengharuskan pengguna untuk menentukan faktur tujuan tunggal yang spesifik, yang merupakan pengalaman pengguna yang buruk. **
Ini memang benar pada awalnya. Tapi sekarang dengan alamat Jaringan Petir, itu pada dasarnya adalah ENS dari Jaringan Petir. Mereka diaktifkan oleh lnurl-pay, yang memungkinkan pengguna mengirim BTC ke viktor@example.com melalui Lightning Network, terlepas dari jumlah dan durasinya.
**Kesalahpahaman 5: Pengguna perlu memahami dan memilih Bitcoin dan Lightning Network saat mengirim BTC. **
Pasti begitu sebelumnya. Tapi sekarang berbeda. Sekarang, mereka memiliki kode QR terpadu yang dengan cerdik menggabungkan alamat on-chain dengan tagihan Lightning Network sehingga dompet pengirim dapat memilih rute yang benar. Buka CashApp, buka tab Bitcoin. Perhatikan bahwa meskipun Aplikasi Tunai mendukung Lightning Network, tidak ada opsi untuk memilih Lightning Network. Ini karena mereka menggunakan kode QR terpadu.
Namun, ini tidak menyelesaikan masalah satu saldo - saldo BTC pengguna masih dapat dibagi secara on-chain dan masuk ke Lightning Network. Masalah ini dapat diselesaikan sampai batas tertentu melalui Submarineswap dan/atau Penyambungan, tetapi pandangan jangka panjang saya adalah bahwa pengguna bahkan tidak akan menyadari bahwa ini adalah masalah, mereka juga tidak akan menyadari bahwa Lightning Network ada karena dompet dan vendor lain menangani kompleksitas mendasar yang akan tersembunyi di bawah pengalaman pengguna yang lancar.
**Mitos #6: Lightning Network adalah modal yang tidak efisien dan karena itu tidak layak. **
Diskusi ini sensitif, dan saya akan berusaha senetral mungkin.
Lightning Network menggunakan model hub-and-spoke. Porsi hub-to-hub dari jaringan sangat hemat modal karena rasio "alokasi modal per unit" yang tinggi dari saluran besar antara bursa, dompet kustodian, LSP, dan node perutean yang optimal.
Namun, di mana inefisiensi modal dari jaringan Lightning berada di tepi - pengguna non-penahanan. Untuk pengguna kustodian Lightning, dompet hanya perlu memelihara saluran besar dengan hub lain dan melakukan penghitungan saldo pengguna secara internal. Untuk pengguna non-penahanan, dompet harus memelihara saluran pendanaan terbuka yang terpisah dengan setiap pengguna. Tantangannya adalah bagaimana mempertahankan alokasi dan pengelolaan likuiditas yang berkelanjutan di seluruh saluran ini.
Untuk memberikan contoh nyata: Pengguna dompet non-penahanan ingin mengirim 0,1 BTC ke teman melalui Lightning Network. Dengan asumsi ada cukup likuiditas di saluran antara mereka dan penyedia dompet dan setiap node di sepanjang jalan, pembayaran akan berhasil. Tetapi sekarang dompet memiliki masalah - mereka memiliki 0,1 BTC di saluran di pihak mereka, jika pengguna tidak menerima pembayaran apa pun (sehingga menyeimbangkan kembali saluran), 0,1 BTC ini akan menganggur di sana, menyebabkan inefisiensi penyedia dompet menjadi rendah. Pada titik ini, penyedia dompet harus memutuskan apakah akan mempertahankan likuiditas, atau menarik likuiditas dengan menutup saluran (yang menciptakan pengalaman pengguna yang buruk) atau menyambungkan saluran (yang tidak terlihat oleh pengguna).
Untuk pengguna non-penahanan, masalah inefisiensi modal marjinal ini merupakan masalah pengoptimalan yang sangat mengganggu, yang secara objektif lebih buruk daripada model berbasis akun terlepas dari ukuran transaksinya. Namun, ini bukan masalah yang tidak bisa diselesaikan. Asalkan bukan tidak mungkin, pasti berhasil, yang juga menjadi motto komunitas pengembang Bitcoin.
Selain kesulitan optimalisasi modal, tantangan lain datang dari biaya yang terkait dengan manajemen saluran dan likuiditas, karena setiap penyambungan, penutupan saluran, dll. memerlukan transaksi on-chain. Anggaran keamanan Bitcoin bergantung pada peningkatan besar-besaran dalam biaya transaksi, tetapi jika biaya transaksi naik menjadi $30-$60, manajemen saluran akan sangat mahal dalam skala besar, dan Jaringan Lightning yang tidak dilindungi mungkin tidak tersedia untuk sebagian besar populasi dunia. Dompet Lightning yang dihosting saat ini memiliki keuntungan karena insentif yang ada di dalamnya, dan kemungkinan akan tumbuh lebih besar seiring dengan kenaikan biaya on-chain, karena model akun omnibus mereka membuat pengelolaan saluran jauh lebih jarang. Komunitas bekerja keras untuk memperbaikinya dan memastikan dompet Lightning non-penahanan terus menjadi warga negara kelas satu di jaringan, tetapi belum ada solusi yang jelas.
Lightning Network masih memiliki jalan panjang untuk menjadi sederhana, mulus, dan sepenuhnya abstrak. Masih banyak kasus ekstrem, dan pengguna yang tidak dikelola belum menikmati pengalaman pengguna terbaik. Namun, banyak masalah telah diselesaikan, dan masih banyak lagi yang akan diselesaikan dalam beberapa tahun mendatang. Sekarang petir telah datang, dapatkah guntur jauh di belakang?
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Mengklarifikasi 6 Kesalahpahaman Tentang Jaringan Petir Bitcoin
Penulis: Viktor Bunin, Penyusun Pakar Protokol Cloud Coinbase: Qianwen, ChainCatcher
Saya sudah lama tidak menggunakan Lightening (kemudian disebut "Lightning Network").
Terakhir kali saya menghabiskan waktu untuk mengerjakannya adalah pada tahun 2019 ketika saya bekerja sama dengan Elizabeth Stark dan pemimpin komunitas lainnya untuk menyelenggarakan Konferensi Jaringan Petir pertama di Berlin. Sejak itu, saya menghabiskan sebagian besar waktu saya mengerjakan protokol lain, dan sementara saya masih berteman dengan orang-orang seperti Elizabeth, pemahaman saya tentang cara kerja Lightning Network telah menurun. Setelah memeriksa ulang, saya menyadari bahwa itu bukan hanya saya, tetapi sebagian besar teman saya juga.
Posting ini untuk mereka yang belum pernah menggunakan Lightning Network baru-baru ini. Ini akan membahas kesalahpahaman saya atau orang lain yang saya lihat. Jika saya melewatkan poin bagus, tolong beri saya garis di Twitter.
**Kesalahpahaman 1: Anda harus menjalankan node Anda sendiri untuk menggunakan Lightning Network tanpa pengawasan, yang mencegah pengguna biasa menggunakan perangkat seluler. **
Ini benar beberapa tahun yang lalu, tetapi sekarang pengguna dapat menggunakan Jaringan Lightning di perangkat seluler melalui klien ringan yang tidak dikelola. Pengguna selalu mengendalikan kunci mereka, dan pengalaman dompet menggunakan Lightning Light Client sama dengan memanggil Alchemy atau Infura melalui RPC saat menggunakan Ethereum.
**Kesalahpahaman 2: Pengirim dan penerima harus online pada saat yang sama agar pembayaran Lightning berhasil (tidak ada pembayaran offline/sinkron). **
Situasi ini masih ada, tetapi dengan beberapa solusi yang rapi. Dompet seluler Lightning non-penahanan dapat menerima pembayaran melalui tugas latar belakang atau pemberitahuan telepon bahkan saat dompet tidak berjalan di latar depan. Namun, pendekatan ini dibatasi oleh sistem operasi seluler. Sistem operasi modern membatasi jumlah perhitungan yang dilakukan oleh aplikasi latar belakang untuk menghemat baterai. Menerima beberapa pembayaran LN baik-baik saja, tetapi jika terlalu banyak yang diterima dalam waktu singkat, mereka mulai kedaluwarsa karena kendala komputasi.
Dalam jangka panjang, pengembang protokol Lightning Network sedang mengerjakan spesifikasi Async Payments, yang akan mengaktifkan latensi tanpa kepercayaan yang panjang secara sewenang-wenang. Pada dasarnya, pembayaran dikreditkan dari node pengirim, tetapi jika node penerima offline, pembayaran tetap berada di LSP pengirim (Lightning Network/Penyedia Layanan Likuiditas, biasanya dijalankan oleh dompet itu sendiri), sampai penerima kembali online. ** Pembaruan ini diharapkan terjadi tahun depan, tetapi belum ada tanggal peluncuran resmi. **Namun, ini membutuhkan dompet yang berpartisipasi untuk memuat LSP, yang dapat menghambat pengadopsiannya sebagai solusi seluruh jaringan.
**Kesalahpahaman 3: Lightning Network mengharuskan kedua pengguna untuk menginvestasikan jumlah BTC yang sama di saluran untuk membuka saluran. **
Ini tidak berlaku. Pada sebagian besar klien Lightning Network, saluran dibuka satu arah secara default, jadi hanya pengirim yang perlu menginvestasikan dana di saluran, dan penerima pembayaran dapat berupa alamat kosong yang baru. Kesalahpahaman ini berasal dari buku putih Lightning Network, di mana contoh-contoh secara konsisten mengacu pada saluran pendanaan dua arah.
Ini sebenarnya didasarkan pada cerita latar yang menarik. Saluran pembayaran paling awal (Spilman) hanya mengizinkan pembayaran satu arah. Inovasi Lightning Network terletak pada realisasi dana ganda dan pembayaran dua arah, dan saluran tidak memiliki waktu kedaluwarsa. Ini mungkin mengapa makalah Jaringan Petir sangat berfokus pada hal itu. Ini adalah penemuan yang signifikan dibandingkan dengan desain protokol yang dikenal pada saat itu.
**Mitos 4: Lightning Network mengharuskan pengguna untuk menentukan faktur tujuan tunggal yang spesifik, yang merupakan pengalaman pengguna yang buruk. **
Ini memang benar pada awalnya. Tapi sekarang dengan alamat Jaringan Petir, itu pada dasarnya adalah ENS dari Jaringan Petir. Mereka diaktifkan oleh lnurl-pay, yang memungkinkan pengguna mengirim BTC ke viktor@example.com melalui Lightning Network, terlepas dari jumlah dan durasinya.
**Kesalahpahaman 5: Pengguna perlu memahami dan memilih Bitcoin dan Lightning Network saat mengirim BTC. **
Pasti begitu sebelumnya. Tapi sekarang berbeda. Sekarang, mereka memiliki kode QR terpadu yang dengan cerdik menggabungkan alamat on-chain dengan tagihan Lightning Network sehingga dompet pengirim dapat memilih rute yang benar. Buka CashApp, buka tab Bitcoin. Perhatikan bahwa meskipun Aplikasi Tunai mendukung Lightning Network, tidak ada opsi untuk memilih Lightning Network. Ini karena mereka menggunakan kode QR terpadu.
Namun, ini tidak menyelesaikan masalah satu saldo - saldo BTC pengguna masih dapat dibagi secara on-chain dan masuk ke Lightning Network. Masalah ini dapat diselesaikan sampai batas tertentu melalui Submarineswap dan/atau Penyambungan, tetapi pandangan jangka panjang saya adalah bahwa pengguna bahkan tidak akan menyadari bahwa ini adalah masalah, mereka juga tidak akan menyadari bahwa Lightning Network ada karena dompet dan vendor lain menangani kompleksitas mendasar yang akan tersembunyi di bawah pengalaman pengguna yang lancar.
**Mitos #6: Lightning Network adalah modal yang tidak efisien dan karena itu tidak layak. **
Diskusi ini sensitif, dan saya akan berusaha senetral mungkin.
Lightning Network menggunakan model hub-and-spoke. Porsi hub-to-hub dari jaringan sangat hemat modal karena rasio "alokasi modal per unit" yang tinggi dari saluran besar antara bursa, dompet kustodian, LSP, dan node perutean yang optimal.
Namun, di mana inefisiensi modal dari jaringan Lightning berada di tepi - pengguna non-penahanan. Untuk pengguna kustodian Lightning, dompet hanya perlu memelihara saluran besar dengan hub lain dan melakukan penghitungan saldo pengguna secara internal. Untuk pengguna non-penahanan, dompet harus memelihara saluran pendanaan terbuka yang terpisah dengan setiap pengguna. Tantangannya adalah bagaimana mempertahankan alokasi dan pengelolaan likuiditas yang berkelanjutan di seluruh saluran ini.
Untuk memberikan contoh nyata: Pengguna dompet non-penahanan ingin mengirim 0,1 BTC ke teman melalui Lightning Network. Dengan asumsi ada cukup likuiditas di saluran antara mereka dan penyedia dompet dan setiap node di sepanjang jalan, pembayaran akan berhasil. Tetapi sekarang dompet memiliki masalah - mereka memiliki 0,1 BTC di saluran di pihak mereka, jika pengguna tidak menerima pembayaran apa pun (sehingga menyeimbangkan kembali saluran), 0,1 BTC ini akan menganggur di sana, menyebabkan inefisiensi penyedia dompet menjadi rendah. Pada titik ini, penyedia dompet harus memutuskan apakah akan mempertahankan likuiditas, atau menarik likuiditas dengan menutup saluran (yang menciptakan pengalaman pengguna yang buruk) atau menyambungkan saluran (yang tidak terlihat oleh pengguna).
Untuk pengguna non-penahanan, masalah inefisiensi modal marjinal ini merupakan masalah pengoptimalan yang sangat mengganggu, yang secara objektif lebih buruk daripada model berbasis akun terlepas dari ukuran transaksinya. Namun, ini bukan masalah yang tidak bisa diselesaikan. Asalkan bukan tidak mungkin, pasti berhasil, yang juga menjadi motto komunitas pengembang Bitcoin.
Selain kesulitan optimalisasi modal, tantangan lain datang dari biaya yang terkait dengan manajemen saluran dan likuiditas, karena setiap penyambungan, penutupan saluran, dll. memerlukan transaksi on-chain. Anggaran keamanan Bitcoin bergantung pada peningkatan besar-besaran dalam biaya transaksi, tetapi jika biaya transaksi naik menjadi $30-$60, manajemen saluran akan sangat mahal dalam skala besar, dan Jaringan Lightning yang tidak dilindungi mungkin tidak tersedia untuk sebagian besar populasi dunia. Dompet Lightning yang dihosting saat ini memiliki keuntungan karena insentif yang ada di dalamnya, dan kemungkinan akan tumbuh lebih besar seiring dengan kenaikan biaya on-chain, karena model akun omnibus mereka membuat pengelolaan saluran jauh lebih jarang. Komunitas bekerja keras untuk memperbaikinya dan memastikan dompet Lightning non-penahanan terus menjadi warga negara kelas satu di jaringan, tetapi belum ada solusi yang jelas.
Lightning Network masih memiliki jalan panjang untuk menjadi sederhana, mulus, dan sepenuhnya abstrak. Masih banyak kasus ekstrem, dan pengguna yang tidak dikelola belum menikmati pengalaman pengguna terbaik. Namun, banyak masalah telah diselesaikan, dan masih banyak lagi yang akan diselesaikan dalam beberapa tahun mendatang. Sekarang petir telah datang, dapatkah guntur jauh di belakang?