"Perutean Bawang" di Jaringan Petir dan cara kerjanya

Pengarang: LORENZO

Komputer dalam jaringan berkomunikasi satu sama lain sesuai dengan protokol. Di sini, "protokol" mengacu pada sistem aturan yang menentukan bagaimana pesan harus dikirim dan ditafsirkan. Bagian transmisi pesan pembayaran dari protokol jaringan kilat dijelaskan oleh BOLT#4, juga dikenal sebagai "Protokol Perutean Bawang (Onion Routing Protocol)".

Onion Routing adalah teknologi yang mendahului Lightning Network selama 25 tahun. Itu juga digunakan di Tor, dari situlah nama "Tor" ("The Onion Router") berasal. Lightning Network menggunakan versi yang sedikit dimodifikasi yang disebut "perutean bawang berbasis asal", disingkat "SPHINX". Pada artikel ini, kita akan berbicara tentang cara kerja perutean bawang.

Mengapa menggunakan perutean bawang?

Ada banyak protokol komunikasi yang berbeda di dunia, tetapi karena Lightning Network adalah jaringan pembayaran, masuk akal untuk memilih protokol yang mengungkapkan informasi sesedikit mungkin tentang pembayaran yang diteruskan.

Jika Jaringan Petir menggunakan protokol yang sama dengan Internet, setiap perantara akan tahu siapa pengirim pembayaran, siapa penerima, dan siapa perantara lain di sepanjang jalur itu. Perutean bawang adalah pilihan yang baik karena karakteristiknya menjamin node perantara:

  • Hanya ketahui node Anda sebelumnya (yang mengirimi Anda pesan) dan node berikutnya (tempat Anda ingin meneruskan pesan).
  • tidak mengetahui panjang seluruh jalur;
  • Tidak tahu di mana Anda berada di jalan.

Ikhtisar perutean bawang

Mari kita gunakan parsel sebagai analogi untuk menjelaskan cara kerja perutean bawang.

Misalkan Alice ingin membayar Dina. Pertama, Alice perlu menemukan jalur yang layak untuk pembayarannya:

Alice→Bob→Chan→Dina

Kemudian, dia membuat "bawang". Dia mulai dengan Dina (dari ujung jalan). Dia memasukkan pesan rahasia (konten pembayaran) ke dalam paket yang dikirim ke Dina, dan menguncinya dengan kunci yang hanya diketahui oleh dia dan Dina. Sekarang, dia meletakkan paket ini di paket lain untuk dikirim ke Chan, dan mengunci paket itu ke Chan dengan kunci yang hanya diketahui olehnya dan Chan. Benar dan seterusnya.

Alice mengirimkan bawang (paket) terakhir ke perantara pertama di jalan, Bob. Bob membuka paketnya dengan kuncinya sendiri, dan melihat bahwa paket berikutnya adalah untuk Chan. Jadi dia meneruskan paket itu ke Chan. Begitu pula dengan Chan, setelah membongkar bungkusan itu, ia meneruskan bungkusan yang ada di dalamnya kepada Dina. Akhirnya Dina membuka paketnya sendiri dan menemukan pesan pembayaran di dalamnya.

Dalam perutean bawang merah, perantara seperti Bob dan Chan tidak mengetahui isi pesan ke Dina, maupun panjang keseluruhan jalur pembayaran. Satu-satunya hal yang mereka ketahui adalah siapa yang meneruskan paket tersebut kepada mereka, dan siapa yang akan menerimanya selanjutnya. Ini menjamin privasi pesan dan kerahasiaan jalur. Setiap perantara hanya dapat menyentuh lapisan pesan yang dibuat khusus untuk TA.

Dalam perutean bawang berbasis sumber Lightning Network, pengirim memilih jalur pembayaran dan membuat bawang lengkap untuk jalur itu, yang dapat dilihat sebagai lubang privasi (Catatan Penerjemah: Lokasi jaringan penerima harus diekspos ke pengirim). Skema perutean lain, seperti "perutean buta" (terjemahan bahasa Mandarin), selesaikan masalah ini dengan mengaburkan sebagian jalur pembayaran ke pengirim. Namun, dalam artikel ini, kami fokus secara eksklusif pada SPHINX.

Pasang bawang

Sekarang, mari kita lihat spesifikasi perutean bawang. Pada awalnya, kita perlu mendefinisikan hal-hal ini:

  • Pengirim adalah "simpul awal" (Alice);
  • Penerima adalah "node terakhir" (Dina);
  • Setiap node perantara pada jalur pembayaran adalah "hop" (Bob dan Chan);
  • Informasi komunikasi antara setiap hop disebut "beban hop".

Bangun beban lompatan

Setelah Alice memilih jalur pembayaran, dia mendapatkan informasi untuk setiap saluran pembayaran dari protokol gosip untuk membuat muatan untuk setiap lompatan, yang pada dasarnya memberi tahu setiap lompatan cara membuat HTTP untuk pembayaran yang diteruskan ( kontrak kunci waktu hash).

Untuk membuat HTTPL yang tepat, setiap hop perlu:

  • Jumlah yang perlu diteruskan;
  • nilai rahasia dibayar;
  • ID saluran pembayaran yang melanjutkan pengiriman bawang;
  • Panjang waktu kunci.

Sebagian besar data ini berasal dari pesan "pembaruan saluran", yang berisi informasi tentang biaya perutean, permintaan acara, dan ID saluran pembayaran. Jumlah total yang perlu diteruskan adalah jumlah dari jumlah pembayaran ditambah biaya penanganan yang dibebankan untuk setiap hop berikutnya; sedangkan nilai rahasia pembayaran dihitung oleh Dina dan disematkan dalam faktur pembayaran (diinformasikan melalui pesan bawang ke masing-masing melompat).

Alice mulai dengan simpul terakhir Dina. Dia termasuk jumlah penerusan, nilai durasi kunci waktu, nilai rahasia pembayaran dan jumlah pembayaran dalam paket. Perhatikan bahwa dia tidak perlu menambahkan ID saluran, karena Dina adalah node terakhir dan tidak perlu meneruskan pembayaran ke orang lain.

Sepintas sepertinya mubazir untuk memberikan jumlah penerusan, karena jumlah ini sama dengan jumlah pembayaran.Namun, pembayaran multipath akan mengirimkan jumlah pembayaran melalui beberapa jalur, dan kemudian kedua nilai tersebut tidak akan cocok.

Di muatan Chan, Alice menambahkan ID saluran Chan dan Dina. Dia juga menambahkan jumlah penerusan dan nilai timelock. Terakhir, Alice membuat muatan untuk Bob. Chan menagih 100 Satoshi untuk pembayaran melalui saluran antara dirinya dan Dina, jadi Alice perlu memberi tahu Bob bahwa jumlah yang diteruskan adalah pembayaran ditambah biaya penanganan. Menurut pesan pembaruan saluran Chan, nilai timelock juga telah ditingkatkan sebesar 20 (dalam blok). Terakhir, Alice juga mempertimbangkan biaya penanganan Bob dan persyaratan penguncian waktu, dan memberinya HTTPL dengan panjang penguncian waktu 700040 dan nilai 100200 Satoshi.

Berbagi nilai rahasia dan pembuatan kunci

Selanjutnya, Alice menyiapkan bawang dengan membuat rahasia bersama untuk setiap lompatan (termasuk node terakhir). Nilai rahasia bersama ini dapat dihasilkan oleh Alice dan hop target masing-masing dengan mengalikan kunci privatnya sendiri dengan kunci publik pihak lain.

Nilai rahasia bersama diperlukan untuk perutean bawang, memungkinkan Alice dan setiap lompatan untuk mendapatkan kunci yang sama. Alice kemudian menggunakan kunci tersebut untuk mengaburkan setiap lapisan bawang, dan lompatan itu menggunakan kunci untuk mengaburkan.

Untuk melindungi privasi Alice, dia membuat kunci sesi satu kali untuk bawang, daripada menggunakan kunci publik simpulnya sendiri, untuk mendapatkan nilai rahasia bersama. Dia menggunakan kunci sesi ini untuk lompatan pertama, dan kemudian, untuk setiap lompatan berikutnya, Alice secara deterministik mengacak kunci dengan mengalikan kunci terbaru dengan faktor yang menyilaukan. Ini digunakan untuk membuat kunci nilai rahasia bersama, yang kami sebut "kunci sesaat".

Bob, Chan, dan Dina, semuanya harus mendapatkan nilai rahasia yang sama dengan Alice, jadi mereka perlu mengetahui kunci sesaat untuk digunakan dalam sesi mereka. Alice hanya meletakkan kunci pertama di bawang merah untuk menyimpan ukuran pesan. Setiap hop menghitung kunci sesaat berikutnya dan menyematkannya di bawang untuk simpul berikutnya. Setiap hop dapat menggunakan kunci publiknya sendiri dan nilai rahasia bersama untuk menghitung faktor penyamaran yang digunakan oleh Alice untuk menentukan kunci sesaat berikutnya.

Seperti disebutkan sebelumnya, nilai rahasia bersama akan digunakan untuk menghasilkan beberapa kunci, dan Alice serta lompatan yang sesuai dapat menggunakan kunci ini untuk melakukan beberapa operasi pada bawang. Mari kita lihat apa yang dilakukan setiap tombol.

** Kunci Rho **

Kunci Rho digunakan oleh Alice untuk mengenkripsi lapisan bawang; ini akan mengaburkan isi muatan sehingga tidak dapat diuraikan oleh pihak luar. Hanya pemilik kunci rho yang dapat mendekripsi payload. Itulah yang harus dilakukan oleh node yang menerima bawang: gunakan nilai rahasia bersama dengan Alice untuk mendapatkan kunci rho, lalu dekripsi bawang dan baca isinya.

Mukey

Alice menggunakan kunci mu untuk membuat checksum untuk setiap payload. Dia juga memberikan checksum ke hop yang menerima bawang. Hop ini, pada gilirannya, menggunakan kunci mu untuk menghasilkan checksum dari payload yang diterima, memeriksa apakah cocok dengan yang diberikan oleh Alice. Ini untuk memeriksa integritas payload, memverifikasi bahwa itu belum dirusak.

Kunci papan

Kunci ini hanya digunakan oleh Alice untuk menghasilkan data "sampah" acak. Data ini juga merupakan bagian dari bawang, dan tidak ada hubungannya dengan panjang jalur pembayaran, berapa banyak hop yang telah dilalui bawang, dan menjaga agar bawang selalu dalam ukuran yang sama, meskipun beberapa isinya tidak relevan. Beginilah cara onion routing menyembunyikan panjang jalur, yang pada dasarnya melindungi privasi pengirim dan penerima.

Kunci

Kunci ini juga digunakan untuk memeriksa integritas data yang terkandung di dalam onion, tetapi hanya jika terjadi error. Iya, namanya "um" karena itu "mu" ditulis terbalik. Dalam kasus kesalahan pembayaran, lompatan yang menemukan kesalahan akan menggunakan kunci um untuk membuat checksum, dan ketika node sebelumnya menerima laporan kesalahan, itu juga akan menggunakan kunci um untuk memverifikasi integritas pesan.

Mengenkapsulasi lapisan bawang

Bungkus bawang terakhir terlihat seperti ini:

Alice sekarang memiliki muatan untuk setiap lompatan, dan nilai rahasia bersama untuk setiap lompatan. Mari kita lihat bagaimana Alice mengubah informasi ini menjadi bawang terakhir. Dia mulai dengan simpul terakhir dan berjalan mundur selangkah demi selangkah.

Dia pertama kali membuat bidang kosong dengan panjang 1300 byte, yang merupakan panjang total semua muatan bawang. Dia kemudian menggunakan tombol pad untuk membuat string acak sepanjang 1300 byte, yang merupakan sampah yang tidak berguna untuk lompatan apa pun. Langkah ini dilakukan untuk memastikan bahwa setiap lapisan bawang terlihat sama, sehingga Anda tidak dapat melihat total panjang lintasan (berapa lompatan), maupun siapa pengirim dan siapa penerima.

Dia kemudian membuat checksum dari payload yang perlu digunakan dan meletakkannya di akhir payload. Dalam pesan ke simpul terakhir, checksum semuanya 0 untuk memberi tahu Dina bahwa dia adalah penerima terakhir dari bawang merah ini. Setelah menambahkan checksum ke akhir payload, Alice meletakkan payload (dan checksum) di awal sampah, dan menghapus bagian dari keseluruhan pesan yang melebihi 1300 byte, sehingga seluruh pesan panjangnya 1300 byte .

Kemudian, Alice menggunakan kunci rho untuk membuat string byte acak, dan menggunakan operasi eksklusif-atau (XOR) pada muatan bawang yang diperoleh pada langkah sebelumnya untuk mendapatkan muatan yang disamarkan. Teks asli muatan dapat diperoleh dengan menggunakan operasi XOR dari string byte acak ini pada teks yang disamarkan (Catatan Penerjemah: Dengan kata lain, XOR di sini adalah algoritme enkripsi simetris, dan string byte acak adalah kuncinya). Operasi XOR membandingkan muatan bawang dengan string byte acak (dihasilkan oleh kunci rho) sedikit demi sedikit, menghasilkan 1 hanya jika salah satu bit data adalah 1; ini menghasilkan muatan yang tidak jelas. Hal cerdas tentang operasi XOR adalah selama Anda mendapatkan string byte acak yang benar dan muatan yang dikaburkan, Anda hanya perlu menjalankan operasi XOR dengan keduanya lagi untuk mendapatkan muatan yang dikaburkan.

Karena node yang menerima bawang dapat memperoleh kunci rho yang sama, mereka dapat menghasilkan string byte acak yang sama seperti Alice. Beginilah cara setiap simpul di sepanjang jalan dapat mengurai kebingungan dan membaca isinya.

Setelah menyiapkan bawang kebingungan untuk satu lompatan, Alice mengulangi langkah yang sama untuk simpul berikutnya. Perbedaan utamanya adalah setelah bawang Dina matang, dia tidak perlu lagi menghasilkan sampah. Dia hanya menambahkan bawang yang dikaburkan dari langkah sebelumnya setelah payload dan checksum yang berguna, dan memangkas apa pun yang melebihi 1300 byte.

Terakhir, Alice mengambil bawang bombai terakhir dan menambahkan checksum sehingga Bob dapat memverifikasi keutuhan bawang tersebut. Alice kemudian menambahkan kunci publik sesi sehingga Bob dapat menggunakan kunci publik ini untuk menghitung nilai rahasia bersama. Terakhir, dia juga menambahkan sebuah byte yang mewakili versi, memberi tahu node lain bagaimana menginterpretasikan data di dalamnya. Untuk versi yang dijelaskan oleh BOLT #4, byte versi harus 0.

maju bawang

Untuk mengirimkan paket onion ini, pengirim membuat pesan update_add_htlc dengan kolom berikut:

  • ID Saluran: Saluran khusus yang terkait dengan pesan ini.
  • ID: Pengidentifikasi HTTP ini.
  • Jumlah: Nilai HTLC ini.
  • Pembayaran Hash: Dibuat oleh penerima pembayaran.
  • Waktu kedaluwarsa: HTTP ini akan kedaluwarsa setelah blok tertentu.
  • Bingkisan Bawang: Bawang yang dibuat untuk pembayaran ini, yang disebutkan di atas.
  • Data tambahan: digunakan untuk menentukan data tambahan.

Setelah menyiapkan pesan, Alice mengirimkan pesan tersebut ke Bob. Setelah menerima pesan tersebut, Bob dapat mulai memecahkan kode bawangnya sendiri. Dia pertama kali mendapatkan kunci sesi dari pembungkus bawang, dan menggunakannya untuk mendapatkan nilai rahasia bersama dengan Alice.

Berbekal nilai rahasia bersama, Bob menghasilkan kunci mu untuk memverifikasi checksum dari payload yang disematkan dalam paket bawang. Jika payload belum dirusak, checksum harus cocok.

Untuk mencegah node lain di jalur mengetahui berapa panjang jalur tersebut, Bob menambahkan bidang 1300-byte yang diisi dengan nol ke paket bawang. Bob kemudian menghasilkan string byte acak sepanjang 2600 byte dari kunci rho. Bob menggunakan string byte acak ini untuk meng-XOR muatan bawang yang tidak diisi.

Ingat bagaimana saya memberi tahu Anda tentang beban bawang yang membingungkan? Gunakan muatan bawang yang dikaburkan sebagai masukan, dan jalankan operasi "XOR" dengan string byte yang sama untuk mendapatkan muatan bawang sebelum pengaburan. Karena Alice dan Bob menggunakan nilai rahasia bersama yang sama, menghasilkan kunci rho yang sama, Bob dapat melakukan unobfuscate. Ini memiliki bonus tambahan yang mengubah karakter pad panjang 1300 byte menjadi byte acak.

Muatan Bob yang tidak dikaburkan mencakup data muatan untuk lompatannya bersama dengan sidik jari. Bob menyimpan sidik jari ini agar dia bisa menambahkannya ke paket bawang yang dia kirim ke Chan. Setelah Bob memisahkan muatannya sendiri dari pesan bawang, dia mengubah paket bawang kembali ke ukuran aslinya 1300 byte dan mengacak kunci sesinya seperti yang dilakukan Alice. Terakhir, Bob menambahkan byte versi, kunci sesi, dan sidik jari yang ingin dia masukkan ke muatan bawang, dan meneruskan paket bawang ke Chan melalui pesan update_add_htlc.

Proses ini akan berlanjut hingga pesan terkirim ke node terakhir yaitu Dina. Ketika Dina menerima pesan update_add_htlc, dia dapat memasukkan nilai hash dari nilai rahasia yang dihasilkannya sendiri, yang berarti bahwa HTLC ini ditujukan untuknya. Jadi Dina hanya perlu memeriksa sidik jarinya, mengungkap pesan bawang, dan mengungkapkan muatannya sendiri.

Penyelesaian masalah

Kita berbicara tentang kisah sukses, kasus di mana semuanya berjalan sesuai rencana, tetapi jika terjadi kesalahan, Anda harus mengirim pesan kembali sepenuhnya untuk memberi tahu semua node bahwa ada yang tidak beres. Proses ini mirip dengan perutean bawang biasa. Menemukan node yang salah membutuhkan penurunan kunci um dari nilai rahasia bersama, menggunakannya untuk menghasilkan string byte acak, dan menggunakan operasi XOR untuk mengaburkan parsel bawang yang dikembalikan.

Node yang menemukan kesalahan akan mengirim pesan kembali ke node sebelumnya di jalur pembayaran. Setiap hop menggunakan kunci um dan kunci ammag untuk melakukan operasi yang sama hingga pengirim menerima paket. Terakhir, pengirim menggunakan kunci ammag dan kunci um untuk membuka penyamaran dan memverifikasi paket.

Kesalahan dapat disebabkan oleh paket, node, atau saluran bawang merah. Jika Anda sering menggunakan Jaringan Lightning, Anda mungkin mengalami kesalahan seperti "saluran tidak tersedia" atau "biaya tidak cukup".

Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
  • Hadiah
  • Komentar
  • Bagikan
Komentar
0/400
Tidak ada komentar
  • Sematkan
Perdagangkan Kripto Di Mana Saja Kapan Saja
qrCode
Pindai untuk mengunduh aplikasi Gate.io
Komunitas
Indonesia
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • ไทย
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)