Dapatkah Proposal Jaringan Petir Antoine Riard Mengurangi Serangan Gangguan Saluran?

Ini adalah editorial opini oleh Shinobi, seorang pendidik otodidak di bidang Bitcoin dan pembawa acara podcast Bitcoin yang berorientasi pada teknologi.

Gangguan saluran adalah salah satu masalah luar biasa yang paling mengancam dengan Lightning Network. Ini menyajikan mekanisme terbuka untuk node serangan denial-of-service di jaringan untuk mencegah mereka dari perutean, kehilangan uang mereka saat likuiditas mereka terkunci dan tidak dapat meneruskan pembayaran yang akan memberi mereka biaya. Penyerang dapat merutekan pembayaran melalui node lain dari diri mereka sendiri ke diri mereka sendiri, dan menolak untuk menyelesaikan pembayaran. Hal ini membuat likuiditas tidak berguna untuk meneruskan pembayaran lain hingga timelock kontrak hash timelock (HTLC) berakhir dan pembayaran dikembalikan.

Bulan lalu, pengembang Lightning Antoine Riard mengusulkan spesifikasi formal untuk solusi masalah ini. Pada bulan Agustus, Riard dan Gleb Naumenko menerbitkan penelitian melihat masalah umum itu sendiri, serta sejumlah solusi berbeda yang dapat digunakan untuk mengurangi atau menyelesaikannya. Salah satu solusi yang diusulkan adalah bentuk kredensial anonim yang dapat digunakan node untuk membangun semacam sistem penilaian reputasi bagi pengguna yang merutekan pembayaran melalui mereka tanpa harus melakukan dox atau mengaitkan reputasi tersebut dengan pengidentifikasi statis yang akan berdampak negatif terhadap privasi orang. Solusi ini sekarang telah menjadi proposal protokol resmi dibuat oleh Riard bulan lalu.

Di dalam Proposal Mitigasi Kemacetan Saluran

Inti dari idenya adalah token ecash Chaumian. Ini adalah token terpusat yang dikeluarkan oleh otoritas mint dengan cara yang mencegah penerbitan token berkorelasi dengan penebusan token nanti. Ini dilakukan dengan menandatangani token dengan cara buta, memungkinkan penerima token untuk melepaskannya tanpa membatalkan tanda tangan. Penerbit kemudian dapat memverifikasi bahwa itu adalah token yang sah tanpa dapat menghubungkan token tersebut saat dikeluarkan.

Proposal menyarankan penggunaan token Chaumian ini, yang dikeluarkan oleh setiap node perutean di jaringan, sebagai bentuk bukti reputasi. Saat merutekan pembayaran, token ecash Chaumian yang dikeluarkan oleh setiap node dalam lompatan pembayaran akan dibungkus dalam bundel bawang merah untuk node tersebut di sepanjang pembayaran. Unit Token akan mewakili nilai HTTP yang diizinkan serta periode pengembalian dana. Sebelum meneruskan HTLC, setiap node akan memverifikasi bahwa token yang disertakan dalam gumpalan bawang mereka valid dan belum pernah ditebus sebelumnya, hanya meneruskan HTLC jika kedua kondisi tersebut benar.

Jika HTLC berhasil diselesaikan dengan preimage terungkap, maka setiap node di sepanjang jalur pembayaran memberi tanda dan menyertakan token Chaumian yang baru dikeluarkan untuk dikembalikan ke pengirim, bersama dengan preimage HTLC. Jika HTTP tidak berhasil menyelesaikan, maka node perutean "membakar" token dengan memasukkannya ke dalam tabel token yang dihabiskan dan tidak mengeluarkan token baru. Ini memaksa pengirim untuk mendapatkan token baru dari node tersebut untuk merutekan pembayaran melalui mereka lagi. Seluruh konsepnya adalah bahwa serangan jamming selalu gagal diselesaikan, jadi dalam skema ini, token yang dikeluarkan oleh setiap node yang Anda lewati akan dibakar jika Anda melakukan serangan jamming dan menimbulkan biaya untuk memperoleh lebih banyak untuk melakukannya lagi. Saat ini, serangan jamming hanya membutuhkan waktu, jadi ini akan menambah biaya ekonomis bagi mereka.

Jadi, saatnya untuk membahas gajah di dalam ruangan: bagaimana Anda mem-bootstrap penerbitan dan sirkulasi token ini di seluruh jaringan? Setiap node yang ingin Anda lewati akan membutuhkan token yang dikeluarkan oleh mereka. Solusinya: bayar untuk mereka. Solusi lain yang diusulkan untuk masalah gangguan saluran adalah biaya di muka, yaitu, membebankan biaya bahkan untuk mencoba merutekan pembayaran terlepas dari berhasil atau tidaknya. Jadi, pembayaran yang gagal pun akan dikenakan biaya untuk pengirim.

Proposal Riard adalah membeli token ini langsung dari setiap node sebagai pembelian satu kali. Sejak saat itu, alih-alih membayar biaya di muka untuk setiap pembayaran, selama pembayaran sebelumnya berhasil dilunasi, Anda akan diterbitkan kembali "token perutean" yang memungkinkan pembayaran yang Anda usulkan berikutnya dialihkan tanpa biaya. Dengan cara ini, pembayaran yang berhasil hanya membayar biaya perutean yang sebenarnya, dan pembayaran yang gagal hanya membayar biaya di muka, mencegah semacam “biaya ganda” untuk pembayaran yang berhasil. Setidaknya secara ekonomi, anggap saja sebagai semacam jalan tengah kompromi antara keadaan saat ini di mana pembayaran yang gagal tidak memerlukan biaya apa pun dan hanya pembayaran yang berhasil yang membayar biaya, dan model biaya penuh di muka di mana semua pembayaran membayar biaya di muka dan yang sukses juga membayar biaya perutean.

Takeaways Dari Proposal

Secara pribadi, saya pikir pembayaran langsung untuk token semacam ini sebelumnya dapat menimbulkan gesekan UX tingkat besar ke dalam proses penggunaan Lightning Network. Namun, saya pikir ada solusi yang cukup sederhana untuk gesekan itu dengan sedikit mengutak-atik proposal.

Daripada harus secara khusus membayar setiap node secara langsung untuk token Chaumian sebelumnya, proposal dapat digabungkan lebih langsung dengan proposal biaya di muka. Jika Anda memiliki token untuk sebuah node, maka sertakan yang ada di gumpalan bawang, jika tidak cukup bayar biaya di muka langsung dalam proposal HTLC dan jika pembayaran berhasil diselesaikan, Anda akan diberikan token Chaumian kembali sebanding dengan apa yang Anda lakukan - biaya depan dulu. Dengan cara ini, alih-alih harus mengumpulkan token dari banyak node berbeda sebelumnya, Anda cukup mendapatkannya selama melakukan pembayaran awal sampai Anda memiliki koleksi bagus dari node berbeda yang sering Anda gunakan dan sangat jarang harus mengeluarkan biaya. biaya di muka untuk mencapainya.

Sumber gesekan potensial lainnya adalah untuk operator node, dan bermuara pada masalah mendasar dari ecash Chaumian itu sendiri. Untuk memastikan bahwa token hanya dibelanjakan sekali, penerbit perlu memelihara basis data dari semua token yang telah dibelanjakan. Ini tumbuh selamanya, membuat pencarian untuk memeriksa validitas token semakin mahal dan memakan waktu semakin besar pertumbuhan basis data. Karena itu, Riard mengusulkan agar token Chaumian ini kedaluwarsa secara berkala, pada ketinggian blok yang diiklankan di protokol gosip per node. Ini berarti bahwa pengirim perlu membeli kembali token ini secara berkala, atau jika implementasi mendukungnya, tukarkan token tersebut dengan token baru yang ditandatangani oleh kunci penandatanganan baru setelah yang sebelumnya kedaluwarsa.

Ini akan menimbulkan biaya ekonomi reguler pada pengirim pembayaran, atau mengharuskan mereka untuk secara berkala memeriksa untuk memastikan penerbitan ulang saat token lama kedaluwarsa. Dalam praktiknya, ini dapat diotomatisasi untuk orang yang menjalankan node Lightning mereka sendiri, dan untuk dompet apa pun yang dibangun di sekitar model penyedia layanan Lightning (LSP), LSP itu sendiri sebenarnya dapat menangani akuisisi dan pemeliharaan token atas nama penggunanya, menangani penyediaan token untuk pembayaran penggunanya. Namun, di pinggiran, tanpa node Lightning atau LSP penuh, ini bisa menjadi sedikit gangguan bagi pengguna dompet ringan.

Saya pikir proposal ini benar-benar dapat mengurangi kemacetan saluran sebagai vektor serangan, terutama jika digabungkan sedikit lebih erat dengan skema biaya di muka dasar, dan sebagian besar gesekan UX dapat ditangani dengan sangat mudah untuk pengguna LSP dan orang yang mengoperasikan node Lightning mereka sendiri. Dan bahkan jika biaya di muka memang menimbulkan gesekan tingkat tinggi, itu mungkin saja membuktikan kendali atas Bitcoin UTXO dapat digunakan sebagai pengganti membayar biaya untuk mendapatkan token.

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