Pengantar

Peta jalan Ethereum menggabungkan teknologi penskalaan yang disebut Pengambilan Sampel Ketersediaan Data (DAS) 6. DAS memperkenalkan<a href="https://notes.ethereum.org/ @djrtwo /das-requirements">persyaratan baru 4 ke tumpukan jaringan Ethereum, sehingga memerlukan penerapan protokol jaringan khusus 7 . Satu protokol <a href="https://notes.ethereum.org/@dankrad /S-Kademlia-DAS"> yang menonjol proposal 4 menggunakan Tabel Hash Terdistribusi (DHT) berdasarkan Kademlia 2 untuk menyimpan dan mengambil sampel data.

Namun, DHTs 4 rentan terhadap serangan Sybil: Penyerang yang mengontrol node DHT dalam jumlah besar dapat membuat sampel DAS tidak tersedia. Untuk mengatasi ancaman ini, lapisan jaringan dengan kepercayaan tinggi dapat dibuat, yang hanya terdiri dari validator rantai suar. Tindakan keamanan seperti itu secara signifikan meningkatkan penghalang bagi penyerang, karena mereka sekarang harus mempertaruhkan ETH mereka sendiri untuk menyerang DHT.

Dalam postingan ini, kami memperkenalkan protokol bukti validator, yang memungkinkan peserta DHT untuk menunjukkan, tanpa pengetahuan, bahwa mereka adalah validator Ethereum.

Motivasi: Serangan “Contoh persembunyian” pada DAS

Di bagian ini, kami memotivasi lebih jauh protokol pembuktian validator dengan menjelaskan serangan Sybil terhadap Pengambilan Sampel Ketersediaan Data.

Protokol DAS berkisar pada pembuat blok yang memastikan bahwa data blok tersedia sehingga klien dapat mengambilnya. Pendekatan saat ini melibatkan partisi data ke dalam sampel, dan peserta jaringan hanya mengambil sampel yang berkaitan dengan kepentingan mereka.

)

Pertimbangkan skenario di mana penyerang Sybil ingin mencegah peserta jaringan mengambil sampel dari node korban, yang bertanggung jawab menyediakan sampel. Seperti yang digambarkan pada gambar di atas, penyerang menghasilkan banyak ID node yang dekat dengan ID node korban. Dengan mengelilingi node korban dengan node mereka sendiri, penyerang menghalangi klien untuk menemukan node korban, karena node jahat akan dengan sengaja menyembunyikan informasi tentang keberadaan korban.

Untuk informasi lebih lanjut tentang serangan Sybil, lihat makalah penelitian terbaru 2 tentang serangan DHT Eclipse. Selanjutnya, <a href="https://notes.ethereum.org/ @dankrad /S-Kademlia-DAS#SKademlia-modifications">Dankrad's Proposal protokol jaringan DAS 8 menjelaskan bagaimana protokol S/Kademlia DHT mengalami serangan tersebut dan menunjukkan perlunya protokol bukti validator.

Bukti Validator

Serangan di atas memotivasi perlunya protokol bukti validator: Jika hanya validator yang dapat bergabung dengan DHT, maka penyerang yang ingin meluncurkan serangan Sybil juga harus mempertaruhkan ETH dalam jumlah besar.

Dengan menggunakan protokol bukti validator, kami memastikan bahwa hanya validator rantai suar yang dapat bergabung dengan DHT dan setiap validator mendapatkan identitas DHT yang unik.

Selain itu, untuk ketahanan DoS validator, kami juga bertujuan untuk menyembunyikan identitas validator pada lapisan jaringan. Artinya, kami tidak ingin penyerang dapat mengetahui node DHT mana yang sesuai dengan validator mana.

Untuk memenuhi tujuan tersebut, protokol bukti validator harus memenuhi persyaratan berikut:

• Keunikan: Setiap validator rantai suar harus dapat memperoleh satu pasangan kunci yang unik. Properti ini tidak hanya membatasi jumlah node yang dapat dihasilkan oleh penyerang Sybil, namun juga memungkinkan peserta jaringan untuk menghukum node yang berperilaku buruk secara lokal dengan memblokir keypair turunannya.
• Privasi: Musuh harus tidak dapat mengetahui validator mana yang sesuai dengan kunci publik turunan tertentu
• Waktu Verifikasi: Proses verifikasi protokol harus efisien, membutuhkan waktu kurang dari 200 ms per node, memungkinkan setiap node mempelajari setidaknya lima node baru per detik

Protokol bukti validator seperti itu akan digunakan oleh Bob selama pembuatan koneksi di lapisan DHT, sehingga Alice mengetahui bahwa dia sedang berbicara dengan validator.

Bukti protokol Validator

Protokol bukti validator kami secara efektif merupakan skema kredensial anonim sederhana. Tujuannya adalah untuk memungkinkan Alice menghasilkan kunci turunan unik, yang dinotasikan sebagai D, jika dan hanya jika dia adalah seorang validator. Selanjutnya, Alice menggunakan kunci turunan D ini di dalam lapisan jaringan.

Dalam merancang protokol ini, tujuan kami adalah menciptakan solusi yang mudah diterapkan dan dianalisis, memastikan solusi tersebut memenuhi persyaratan yang diuraikan dengan cara yang efisien.

Ikhtisar protokol

Protokol ini menggunakan subprotokol bukti keanggotaan, di mana Alice membuktikan bahwa dia adalah seorang validator dengan mendemonstrasikan pengetahuan tentang gambar awal hash rahasia menggunakan bukti ZK. Alice kemudian membuat pasangan kunci unik yang berasal dari preimage hash rahasia tersebut.

Subprotokol bukti keanggotaan dapat dibuat melalui metode yang berbeda. Dalam postingan ini, kami menunjukkan protokol menggunakan pohon Merkle dan protokol kedua menggunakan pencarian.

Meskipun kedua pendekatan tersebut menunjukkan efisiensi yang dapat diterima, keduanya memiliki trade-off yang berbeda. Pohon Merkle mengandalkan fungsi hash yang ramah SNARK seperti Poseidon (yang mungkin dianggap eksperimental). Di sisi lain, protokol pencarian yang efisien mengandalkan pengaturan tepercaya yang kuat dengan ukuran yang sama dengan ukuran kumpulan validator (saat ini 700 ribu validator tetapi terus bertambah).

Sekarang mari selami protokolnya:

Pendekatan #1: Pohon Merkle

Pohon Merkle telah banyak digunakan sebagai bukti keanggotaan (misalnya lihat Semafor 3). Berikut adalah ruang tradeoff ketika merancang bukti keanggotaan menggunakan pohon Merkle:

• Positif: Tidak perlu pengaturan tepercaya
• Positif: Mudah dimengerti
• Negatif: Mengandalkan fungsi hash yang ramah SNARK seperti Poseidon
• Negatif: Pembuatan bukti lebih lambat

Di bawah ini kami menjelaskan bukti protokol validator berdasarkan pohon Merkle:

Protokol pembuktian validator menggunakan pohon Merkle

)

Di akhir protokol, Alice dapat menggunakan D di DHT untuk menandatangani pesan dan mendapatkan identitas simpul DHT uniknya.

Sekarang mari kita lihat solusi yang sedikit lebih rumit, namun jauh lebih efisien, menggunakan pencarian.

Pendekatan #2: Pencarian

Berikut adalah ruang tradeoff menggunakan protokol pencarian 2 seperti Caulk 2:

• Positif: Pembuatan bukti yang sangat efisien (menggunakan fase pra-pemrosesan)
• Positif: Protokol dapat diadaptasi untuk menggunakan fungsi hash biasa, bukan Poseidon
• Negatif: Memerlukan pengaturan tepercaya dengan ukuran besar (idealnya sama dengan ukuran validator)

Di bawah ini kami menjelaskan bukti nyata protokol validator:

Bukti protokol validator menggunakan pencarian

Persis seperti dalam pendekatan Merkle, setiap validator i mendaftarkan nilai pi baru pada blockchain sehingga:

Efisiensi

Kami membandingkan runtime protokol bukti keanggotaan kami (tautan 6 ke kode benchmark 5) dalam hal pembuatan dan verifikasi bukti. Perhatikan bahwa meskipun bukti keanggotaan hanyalah salah satu bagian dari protokol bukti validator kami, kami memperkirakan bukti tersebut akan mendominasi waktu berjalan secara keseluruhan.

Di bawah ini kami berikan hasil benchmark bukti keanggotaan pohon merkle menggunakan sistem bukti Halo2 dengan IPA sebagai skema komitmen polinomial. IPA adalah skema yang lebih lambat dibandingkan KZG tetapi tidak memerlukan pengaturan tepercaya yang memaksimalkan keuntungan dari pendekatan pohon merkle.

Kami mengamati bahwa waktu pembuktian dan pemverifikasi selaras dengan persyaratan efisiensi kami. Karena alasan ini, kami memutuskan untuk tidak melakukan benchmarking pada pendekatan berbasis Caulk, karena kinerjanya diharapkan jauh lebih baik di semua kategori (terutama waktu pembuktian dan ukuran pembuktian).

Tolok ukur dikumpulkan pada laptop yang menjalankan Intel i7-8550U (CPU berusia lima tahun).

Diskusi

Memutar identitas

Properti keunikan protokol bukti validator memastikan bahwa setiap peserta jaringan memiliki pasangan kunci turunan yang berbeda. Namun, untuk protokol jaringan tertentu, mungkin akan lebih menguntungkan jika validator dapat memiliki identitas yang dirotasi, dimana kunci turunannya berubah secara berkala, mungkin setiap hari.

Dalam skenario seperti itu, jika Hawa berperilaku buruk pada hari tertentu, Alice dapat memasukkan dia ke dalam daftar blokir untuk hari itu. Namun, pada hari berikutnya, Eve dapat menghasilkan kunci turunan baru, yang tidak masuk daftar blokir. Jika kami ingin dapat memblokir validator secara permanen berdasarkan identitas rotasinya, kami memerlukan skema kredensial anonim yang lebih canggih seperti SNARKBlock 1.

Mengapa tidak menggunakan kunci publik identitas BLS12-381?

Pendekatan alternatif (mungkin lebih sederhana) adalah dengan membangun komitmen dari semua kunci identitas validator BLS12-381 dan melakukan bukti keanggotaan pada komitmen tersebut.

Namun, pendekatan ini mengharuskan validator untuk memasukkan kunci pribadi identitasnya ke dalam sistem bukti ZK untuk membuat bukti keanggotaan yang valid dan menghitung kunci turunan unik.

Kami memutuskan untuk tidak mengambil pendekatan ini karena memasukkan kunci identitas sensitif ke dalam protokol kriptografi yang rumit bukanlah praktik yang baik, dan juga akan mempersulit validator untuk menyimpan kunci identitas utama mereka secara offline.

Arah penelitian di masa depan

• Bisakah kita menghindari rangkaian SNARK sepenuhnya dan melakukan pembuktian keanggotaan dan derivasi kunci dengan cara aljabar murni?
• Terkait: Bisakah kita memiliki bukti protokol keanggotaan yang efisien tanpa pengaturan yang tepercaya dan tanpa bergantung pada fungsi hash yang ramah SNARK?

Ucapan Terima Kasih

Terima kasih kepada Enrico Bottazzi, Cedoor, Vivian Plasencia, dan Wanseob atas bantuannya dalam menjelajahi web basis kode bukti keanggotaan.

Penafian:

1. Artikel ini dicetak ulang dari [ethresear]. Semua hak cipta milik penulis asli [George Kadianakis, Mary Maller, Andrija Novakovic, Suphanat Chunhapanya]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Th
   Pandangan dan opini yang dikemukakan dalam artikel ini sepenuhnya merupakan milik penulis dan bukan merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.