Apakah Channel Jamming Sebuah Ancaman Bagi Jaringan Lightning Bitcoin?

(Terima kasih khusus kepada Antoine Riard dan Gleb Naumenko, yang penelitian terbaru adalah dasar dari artikel ini.)

Kemacetan saluran adalah salah satu masalah luar biasa dari Lightning Network dalam hal hal-hal yang dapat mengganggu keberhasilan pembayaran yang disalurkan melaluinya. Ini adalah masalah yang diketahui secara luas di kalangan pengembang yang telah dipahami sejak sebelum jaringan itu sendiri benar-benar ditayangkan di mainnet dan mulai memproses bahkan satu satoshi.

Sejauh ini masalah tersebut belum benar-benar memiliki efek negatif pada jaringan, tetapi ketika mempertimbangkan fakta itu, penting untuk diingat bahwa jaringan masih, dalam skema besar, relatif kecil. Prosesor pedagang telah mulai mendukungnya, seperti halnya beberapa pertukaran dan banyak layanan dan bisnis asli Lightning/Bitcoin, tetapi pada kenyataannya, itu tidak banyak. Jaringan masih merupakan hal kecil yang sebagian besar digunakan oleh Bitcoiner, dan itu sama sekali bukan bagian dunia yang sangat besar.

Lebih jauh lagi, jumlah Bitcoiner yang secara teratur menghabiskan dan menggunakan bitcoin mereka dalam pengaturan perdagangan adalah bagian yang lebih kecil dari kelompok yang sudah kecil itu. Hanya karena serangan yang mungkin tidak terjadi sekarang, orang tidak boleh berasumsi bahwa itu berarti mereka tidak akan terus terjadi ketika jaringan tumbuh ke skala yang lebih besar. Semakin besar, semakin kompetitif dan bermusuhan.

Apa itu Jamming Saluran?

Konsep dasar kemacetan saluran adalah mengarahkan pembayaran melalui saluran Lightning yang ingin Anda macet dari diri Anda sendiri ke diri Anda sendiri, dan kemudian tidak menyelesaikannya dengan melepaskan pragambar ke hash pembayaran di kontrak kunci waktu hash (HTLC). Korban tidak akan dapat menghapus HTTPS dari saluran mereka sampai setelah batas waktu pengembalian dana telah berakhir, karena mereka tidak akan memiliki cara untuk menegakkan klaim mereka atas uang yang mereka miliki jika pragambar dilepaskan setelah menghapusnya. Jika Anda benar-benar macet saluran dengan melakukan ini, maka saluran itu tidak akan mampu merutekan pembayaran apa pun sampai setelah batas waktu berakhir pada semua pembayaran berbahaya.

Ada dua strategi berbeda yang dapat digunakan di sini untuk melakukan serangan. Anda dapat mencoba dan macet jumlah yang dapat dirutekan yang tersedia di saluran, atau Anda dapat mencoba dan macet semua slot HTLC individu dalam saluran. Saluran Lightning hanya dapat memiliki 483 HTLC tertunda di setiap arah yang dapat dirutekannya — ini karena ada batas ukuran maksimum seberapa besar transaksi Bitcoin dapat dilakukan. Jika Anda menambahkan lebih dari 483 HTLC per arah di saluran, transaksi untuk menutup saluran jika diperlukan akan terlalu besar dan tidak valid untuk dikirim ke jaringan. Ini akan membuat semua yang ada di saluran tidak dapat diterapkan pada rantai.

Jadi, penyerang dapat mencoba dan mengunci semua likuiditas di saluran, atau mencoba dan mengunci semua slot HTLC di saluran. Strategi mana pun akan membuat saluran tidak dapat digunakan, tetapi jamming slot umumnya akan lebih murah daripada jumlah jamming. Penyerang harus memiliki koin di jaringan untuk melakukan serangan ini, jadi merutekan nilai minimum yang diizinkan untuk HTCL berkapasitas 483 akan lebih hemat biaya daripada mencoba mengunci semua likuiditas yang tersedia di saluran.

Mengapa Seseorang Ingin Menonton Saluran Pencahayaan?

Ada banyak alasan untuk melakukan serangan ini. Pertama, entitas jahat yang ingin menyerang Bitcoin itu sendiri dapat membuat macet semua saluran utama di "inti" jaringan untuk membuat sebagian besar jaringan tidak dapat digunakan untuk merutekan pembayaran, kecuali untuk node yang sangat terhubung satu sama lain. . Ini akan membutuhkan lebih banyak koin untuk tampil pada skala ini, tetapi bukan sesuatu yang harus diabaikan sebagai kemungkinan dengan semakin banyak Bitcoin tumbuh dan menjadi alternatif uang dan sistem pembayaran yang disetujui pemerintah.

Kedua, simpul perutean, atau pedagang, dapat mencoba melakukan serangan terhadap pesaing untuk mendorong biaya kepada mereka sebagai lawan dari persaingan. Pedagang yang menjual produk serupa dapat menghambat saluran pesaing untuk mencegah pelanggan melakukan pembelian di sana, dengan harapan dapat mendorong mereka untuk berbelanja di toko mereka. Node perutean yang memiliki konektivitas saluran yang sama dengan simpul lain dapat mengganggu saluran simpul perutean yang bersaing agar tidak dapat digunakan untuk merutekan pembayaran. Seiring waktu, ini akan menghancurkan reputasi node tersebut dalam hal keandalan perutean, dan karena konektivitas yang serupa, semakin besar kemungkinan dompet pengguna akan memilih node penyerang untuk merutekan pembayaran di seluruh jaringan.

Serangan-serangan ini dapat menjadi lebih efisien modal bagi penyerang jika mereka secara melingkar melalui satu saluran beberapa kali. Jika mereka cukup dekat dengan korban di jaringan, mereka dapat membuat rute pembayaran yang berputar dan terus melalui saluran korban. Ada batasan berapa lama rute pembayaran, jadi ini tidak dapat dilakukan tanpa batas, tetapi melakukan rute pembayaran berulang seperti ini dapat secara drastis menurunkan jumlah koin yang dibutuhkan penyerang untuk benar-benar macet di saluran korban.

Mengurangi Serangan Gangguan Saluran

Beberapa mitigasi dasar dan parsial dapat diterapkan untuk meningkatkan biaya bagi penyerang dan mengurangi kerusakan bagi para korban. Yang pertama adalah proses multi-tahap untuk menangani HTTPS.

Saat ini, setiap HTTPC secara individual menambahkan output baru dalam transaksi komitmen untuk status saluran saat ini. Proses dua tahap dapat membuat satu keluaran tambahan dalam transaksi komitmen, dan kemudian memiliki transaksi kedua setelah itu yang memiliki HTLC aktual yang ditambahkan ke dalamnya. Ini akan memungkinkan maksimum 483 dikalikan dengan 483 slot HTLC per saluran (atau 233,289 slot). Namun, ini tidak benar-benar memperbaiki apa pun dengan sendirinya, dan akan memerlukan perpanjangan waktu karena Anda menambahkan transaksi tambahan untuk menegakkan sesuatu secara on-chain, dan sebenarnya dapat membantu penyerang lebih dari korban jika mereka menggunakan struktur transaksi baru ini dan korban tidak. Namun, ini akan membantu dalam kombinasi dengan teknik lain yang dijelaskan sebentar lagi.

Yang kedua adalah strategi reaktif, di mana node yang menjadi korban jamming dapat dengan mudah membuka saluran baru ke rekan yang sama dengan yang sedang macet. Namun, ini akan membutuhkan modal tambahan untuk melakukannya, tidak memperbaiki biaya peluang karena saluran lain macet dan kehilangan pendapatan biaya, dan saluran baru selanjutnya dapat macet juga jika penyerang memiliki modal yang tersedia untuk melakukannya. .

Teknik ketiga adalah memasukkan slot HTTPS. Saat ini ada 483 slot, dan ini adalah batas slot tunggal yang diterapkan secara universal untuk semua pembayaran terlepas dari nilai pembayarannya. Node dapat membuat ember terpisah dengan batas slot yang lebih kecil dan menerapkannya pada pembayaran dengan nilai yang berbeda, yaitu, pembayaran 100,000 sat atau lebih kecil hanya dapat memiliki akses ke 150 slot. Jadi, merutekan pembayaran dengan nilai yang lebih kecil tidak dapat menggunakan semua slot HTTP yang tersedia.

Pembayaran 100,000 sat hingga 1 juta sat dapat mengakses 300 slot, dan 1 juta sat hingga 10 juta sat dapat mengakses 483 slot penuh. Ini akan secara signifikan meningkatkan biaya modal penyerang untuk slot jam, karena mereka tidak lagi dapat menggunakan semua 483 slot dengan pembayaran nilai sekecil mungkin. Selain itu, karena output HTLC di bawah ambang batas debu (saat ini, 546 sat) bahkan tidak dapat disiarkan dan diterapkan secara berantai, apa pun di bawah batas ini dapat ditangani sebagai "0 bucket" karena tidak ada output HTLC yang dibuat. Node dapat dengan mudah memberlakukan batasan pada transaksi ini berdasarkan sumber daya CPU yang digunakan atau metrik lain untuk mencegahnya menjadi risiko penolakan layanan, tergantung pada seberapa besar kerugian yang dapat mereka tanggung jika tidak diselesaikan dengan jujur.

Slot bucketing dalam kombinasi dengan penanganan HTLC dua tahap dapat digunakan untuk mengoptimalkan penerapan batas HTLC, yaitu, pembayaran dengan nilai yang lebih tinggi dapat menggunakan struktur dua tahap untuk membuat lebih banyak slot untuk mereka per saluran karena nilai pembayaran yang lebih tinggi meningkatkan biaya jamming mereka untuk penyerang, membuat penyalahgunaan batas slot yang lebih tinggi untuk melakukan penyerang jamming lebih kecil kemungkinannya.

Dalam penelitian mereka yang dikutip di atas, Riard dan Naumenko telah menunjukkan bahwa dengan kombinasi optimal slot bucketing dan ekstensi slot dua tahap, penyebab slot jamming dapat dibuat sama mahalnya dengan jumlah jamming. Ini tidak akan menyelesaikan masalah secara komprehensif, tetapi meningkatkan biaya minimum untuk melakukan serangan jika diterapkan secara luas oleh node di seluruh jaringan.

Dua solusi komprehensif yang telah mereka lihat adalah biaya di muka/tahan waktu untuk mengunci likuiditas, dan sistem reputasi menggunakan token Chaumian yang dibutakan. TLDR skema biaya adalah bahwa obligasi untuk biaya di muka akan dibayarkan untuk merutekan HTLC yang diperkirakan akan memakan waktu lama untuk diselesaikan, dan semakin lama tidak diselesaikan, itu akan melepaskan biaya ke setiap node perutean per potongan waktu yang telah berlalu tanpa penyelesaian. Masalahnya adalah bahwa menegakkan ini dapat menyebabkan kebutuhan untuk menutup saluran jika biaya tidak dikirim saat diperlukan, dan itu akan menyebabkan kasus penggunaan yang sah yang memerlukan waktu penguncian yang lama untuk membayar biaya yang lebih tinggi yang sama dengan penyerang yang mencoba jamming saluran.

Skema reputasi akan melibatkan “ikatan pasak” menggunakan bukti tanpa pengetahuan untuk membuktikan kendali Bitcoin sebagai pertahanan Sybil, dan kemudian menggunakan ikatan yang terkait dengan reputasi Anda untuk memperoleh token Chaumian yang dibutakan dari node perutean yang akan ditebus dan diterbitkan kembali pada HTLC berhasil menyelesaikan dengan cara yang menjaga privasi. Node akan mengeluarkan token satu kali per identitas, dan jika HTLC tidak diselesaikan atau dikembalikan pada waktu yang tepat, node dapat menolak untuk menerbitkan ulang token, sehingga mencegah pengguna merutekan melalui node mereka kecuali mereka menghabiskan waktu dan uang untuk membuat yang baru. mempertaruhkan obligasi dengan koin yang berbeda untuk diterbitkan dalam token baru.

Bagi mereka yang ingin membaca lebih lanjut tentang dua solusi ini, informasi lebih lanjut dapat ditemukan di bagian lima dan enam dalam penelitian Riard dan Naumenko.

Perlu juga dicatat bahwa jika perutean node mengadopsi sistem escrow berbasis pihak ketiga atau jalur kredit berbasis kepercayaan, seperti yang saya tulis tentang di sini, semua masalah yang terkait dengan gangguan saluran ini tidak akan lagi memengaruhi mereka. Ini akan menjadi perubahan besar dalam model kepercayaan untuk merutekan node, tetapi itu tidak akan berpengaruh pada orang yang menggunakan saluran Lightning nyata untuk mengirim dan menerima sats, keamanan dana mereka, atau kemampuan mereka untuk menerapkannya pada rantai.

Orang mungkin tidak ingin mendengarnya, tetapi pada akhirnya, jika solusi di atas untuk mengurangi kemacetan saluran untuk saluran yang sebenarnya tidak cukup, sistem pihak ketiga ini selalu menjadi pilihan potensial.

Ini adalah posting tamu oleh Shinobi. Pendapat yang diungkapkan sepenuhnya milik mereka sendiri dan tidak mencerminkan pendapat BTC Inc atau Majalah Bitcoin.