Membuka Kunci Cawan Suci: Tantangan dan Solusi Enkripsi Homomorfik Sepenuhnya pada Rantai

)

Ide inti:

1. FHE berjanji untuk menjadi “Cawan Suci Kriptografi,” namun ada banyak masalah kinerja, pengalaman pengembang, dan keamanan yang membatasi penerapannya saat ini.

2. Seperti yang ditunjukkan pada grafik di atas, FHE perlu digunakan bersama ZKP dan MPC untuk membangun sistem negara bersama yang benar-benar rahasia dan aman.

3.FHE berkembang pesat; Pengembangan kompiler baru, perpustakaan, perangkat keras, dll. Belum lagi, FHE sangat mendapat manfaat dari R&D perusahaan Web2 (Intel, Google, DARPA, dll.).

4. Seiring dengan semakin matangnya FHE dan ekosistem di sekitarnya, kami berharap “FHE yang dapat diverifikasi” menjadi standar. Aplikasi FHE dapat memilih untuk melakukan outsourcing komputasi dan verifikasi ke koprosesor FHE.

5. Batasan mendasar FHE onchain adalah “siapa yang memegang kunci dekripsi?” Dekripsi ambang batas dan MPC menawarkan solusi, namun umumnya terikat oleh trade-off kinerja & keamanan.

Pengantar:

Sifat transparan dari blockchain adalah pedang bermata dua; Meskipun ada keindahan dalam keterbukaan dan kemudahan pengamatannya, hal ini merupakan hambatan mendasar dalam penerapannya di dunia usaha.

Privasi onchain telah menjadi salah satu masalah paling menantang dalam kripto selama hampir satu dekade. Meskipun ada banyak tim yang membangun sistem berbasis ZK untuk mencapai privasi onchain; mereka tidak dapat mendukung status bersama dan terenkripsi. Mengapa? Jawaban singkatnya adalah karena program-program ini merupakan fungsi dari serangkaian ZKP dan dengan demikian, tidak mungkin bagi siapa pun untuk menerapkan logika sewenang-wenang pada keadaan saat ini. Apa artinya ini? Pada dasarnya kami tidak dapat membangun aplikasi negara bersama yang bersifat rahasia (pikirkan Uniswap pribadi) hanya dengan menggunakan ZKP.

Namun, terobosan baru-baru ini menunjukkan bahwa menggabungkan ZKP dengan Enkripsi Homomorfik Sepenuhnya (FHE) dapat menghasilkan DeFi rahasia yang dapat digeneralisasikan sepenuhnya. Bagaimana? FHE adalah bidang kriptografi yang sedang berkembang yang memungkinkan komputasi sewenang-wenang atas data terenkripsi (terdengar gila bukan?!) Seperti yang ditunjukkan pada grafik di atas, ZKP dapat membuktikan integritas input dan komputasi pengguna, dan FHE dapat memproses komputasi itu sendiri.

Meskipun FHE menjanjikan untuk menjadi “Cawan Suci Kriptografi,” kami berupaya memberikan analisis obyektif mengenai bidang ini dan berbagai tantangan serta kemungkinan solusinya. Kami membahas topik FHE onchain berikut:

• Skema FHE, Perpustakaan dan Kompiler
• Dekripsi Ambang Aman
• ZKP untuk Input Pengguna + Pihak Komputasi
• Lapisan DA yang Dapat Diprogram dan Dapat Diskalakan
• Perangkat Keras FHE

Skema FHE, Perpustakaan dan Kompiler

Tantangan: Skema, Perpustakaan, dan Penyusun FHE yang Baru Lahir

Hambatan mendasar dari FHE onchain terletak pada peralatan/infra-nya pengembang yang tertinggal. Berbeda dengan ZKP atau MPC, FHE baru ada sejak tahun 2009, sehingga memiliki waktu jatuh tempo yang jauh lebih singkat.

Keterbatasan utama dalam FHE DevEx adalah:

• Bahasa front-end yang mudah digunakan bagi pengembang untuk membuat kode tanpa banyak pengetahuan tentang kriptografi backend
• Kompiler FHE yang berfungsi penuh yang dapat menangani semua pekerjaan kotor. (Pemilihan parameter, optimasi SIMD untuk BGV/BFV dan optimasi paralel)
• Skema FHE yang ada (khususnya TFHE) sekitar 1000x lebih lambat dibandingkan dengan komputasi biasa

Untuk benar-benar memahami seluk-beluk pengintegrasian FHE, mari kita telusuri perjalanan pengembang:

Langkah pertama untuk mengintegrasikan FHE ke dalam aplikasi Anda adalah memilih skema FHE yang akan digunakan. Bagan berikut menjelaskan skema utama:

Seperti yang ditunjukkan pada tabel di atas, sirkuit boolean seperti FHEW & TFHE memiliki bootstrapping tercepat dan dapat menghindari prosedur pemilihan parameter yang rumit dan rumit, dan dapat digunakan dalam perhitungan arbitrer/generik tetapi relatif lambat; Meskipun BGV/BFV mungkin cocok untuk DeFi umum karena lebih efisien dalam komputasi aritmatika presisi tinggi, namun pengembang harus mengetahui kedalaman sirkuit terlebih dahulu untuk menyiapkan semua parameter skema. Di sisi lain, CKKS mendukung perkalian homomorfik yang memungkinkan kesalahan presisi, sehingga optimal untuk kasus penggunaan yang tidak presisi seperti ML.

Sebagai pengembang, Anda harus memilih solusi FHE dengan sangat hati-hati karena akan mempengaruhi semua keputusan desain dan kinerja di masa depan. Selain itu, ada beberapa parameter utama yang penting untuk menyiapkan skema FHE dengan benar, seperti pilihan ukuran modul dan peran derajat polinomial.

Beralih ke perpustakaan, fitur dan kemampuan perpustakaan FHE populer dapat dilihat pada tabel di bawah ini:

Namun perpustakaan juga memiliki hubungan yang berbeda dengan skema dan kompiler seperti yang ditunjukkan di bawah ini:

Setelah memilih solusi FHE, pengembang perlu menetapkan parameter. Pemilihan parameter yang tepat akan berdampak besar pada kinerja skema FHE. Lebih sulit lagi, hal ini memerlukan pemahaman tentang aljabar abstrak, operasi khusus FHE seperti relinearisasi dan peralihan analog-ke-digital, dan rangkaian aritmatika atau biner. Terakhir, untuk pemilihan parameter yang efektif, diperlukan pemahaman konseptual tentang pengaruhnya terhadap skema FHE.

Pada titik ini, pengembang mungkin bertanya:

Seberapa besar ruang teks biasa yang saya perlukan? Berapa besar ciphertext yang dapat diterima? Di mana saya bisa memparalelkan komputasi? Dan masih banyak lagi…

Selain itu, meskipun FHE dapat mendukung komputasi arbitrer, pengembang perlu mengubah pola pikir mereka saat menulis program FHE. Misalnya, seseorang tidak dapat menulis cabang (if-else) bergantung pada variabel dalam program, karena program tidak dapat membandingkan variabel secara langsung seperti data biasa. Sebaliknya, pengembang perlu mengubah kode mereka dari cabang ke semacam komputasi yang dapat menggabungkan kondisi semua cabang. Demikian pula, hal ini mencegah pengembang menulis loop dalam kode mereka.

Singkatnya, bagi pengembang yang belum mengenal FHE, hampir mustahil untuk mengintegrasikan FHE ke dalam aplikasi mereka. Dibutuhkan perangkat/infra pengembangan yang signifikan untuk menghilangkan kompleksitas yang ditimbulkan oleh FHE.

Larutan:

1. Kompiler FHE Khusus Web3

Meskipun sudah ada kompiler FHE yang dibuat oleh Google dan Microsoft, mereka adalah:

• Tidak dirancang dengan mempertimbangkan kinerja, menambahkan overhead 1000x vs sirkuit penulisan secara langsung
• Dioptimalkan untuk CKKS (alias ML) dan tidak bermanfaat untuk BFV/BGV yang dibutuhkan untuk DeFi
• Tidak dibuat untuk Web3. Tidak mendukung kompatibilitas dengan skema ZKP, rangkaian program, dll.

Itu sampai kompiler Sunscreen FHE. Ini adalah kompiler asli Web3 yang menawarkan beberapa kinerja terbaik untuk operasi aritmatika (pikirkan DeFi) tanpa akselerator perangkat keras. Seperti dibahas di atas, pemilihan parameter bisa dibilang merupakan bagian tersulit dalam penerapan skema FHE; Tabir surya tidak hanya memiliki pemilihan parameter otomatis, tetapi juga pengkodean data, pemilihan kunci, mengimplementasikan relinearisasi dan peralihan modulus, mengatur sirkuit dan mengimplementasikan operasi gaya SIMD.

Seiring berjalannya waktu, kami berharap dapat melihat optimalisasi lebih lanjut tidak hanya pada compiler Sunscreen, namun juga tim lain yang membangun implementasi mereka sendiri yang mendukung bahasa tingkat tinggi lainnya.

1. Perpustakaan FHE baru

Sementara para peneliti terus mengeksplorasi skema baru yang kuat, perpustakaan FHE dapat memungkinkan lebih banyak pengembang untuk mengintegrasikan FHE.

Mari kita ambil kontrak pintar FHE sebagai contoh. Meskipun sulit untuk memilih dari perpustakaan FHE yang berbeda, akan lebih mudah jika kita berbicara tentang FHE onchain karena hanya ada sedikit bahasa pemrograman yang mendominasi di Web3.

Misalnya, fhEVM Zama mengintegrasikan perpustakaan sumber terbuka TFHE-rs Zama ke dalam EVM biasa, memperlihatkan operasi homomorfik sebagai kontrak yang telah dikompilasi sebelumnya. Secara efektif memungkinkan pengembang untuk menggunakan data terenkripsi dalam kontrak mereka, tanpa perubahan apa pun pada alat kompilasi.

Untuk skenario spesifik lainnya, beberapa infrastruktur lain mungkin diperlukan. Misalnya, perpustakaan TFHE yang ditulis dalam C++ tidak dirawat dengan baik seperti versi Rust. Meskipun TFHE-rs dapat mendukung ekspor untuk C/C++, jika pengembang C++ menginginkan kompatibilitas dan kinerja yang lebih baik, mereka harus menulis versi perpustakaan TFHE mereka sendiri.

Terakhir, alasan utama kurangnya infrastruktur FHE di pasar adalah kurangnya cara yang efisien untuk membangun FHE-RAM. Salah satu solusi yang mungkin adalah bekerja pada FHE-EVM tanpa opcode tertentu.

Dekripsi Ambang Aman

Tantangan: Dekripsi Ambang Batas Tidak Aman/Terpusat

Setiap sistem negara yang rahasia dan dibagikan didasarkan pada kunci enkripsi/dekripsi. Tidak ada satu pihak pun yang dapat dipercaya, oleh karena itu kunci dekripsi dibagikan ke peserta jaringan.

Salah satu aspek paling menantang dari onchain FHE (Threshold FHE) adalah membangun protokol dekripsi ambang batas yang aman dan berkinerja baik. Ada dua hambatan utama: (1) Komputasi berbasis FHE menimbulkan overhead yang signifikan, akibatnya memerlukan node berperforma tinggi yang secara inheren mengurangi ukuran potensial set validator (2) Seiring dengan meningkatnya jumlah node yang berpartisipasi dalam protokol dekripsi, latensi pun meningkat.

Setidaknya untuk saat ini, protokol FHE bergantung pada mayoritas yang jujur di antara validator, namun seperti disebutkan di atas, Threshold FHE menyiratkan kumpulan validator yang lebih kecil dan oleh karena itu, kemungkinan kolusi dan perilaku jahat lebih tinggi.

Bagaimana jika node ambang batas berkolusi? Mereka akan dapat melewati protokol dan pada dasarnya mendekripsi apa pun, mulai dari input pengguna hingga data onchain apa pun. Selain itu, penting untuk dicatat bahwa protokol dekripsi dapat terjadi secara tidak terdeteksi di sistem saat ini (alias “serangan diam-diam”).

Solusi: Peningkatan Dekripsi Ambang Batas atau MPC Dinamis

Ada beberapa cara untuk mengatasi kekurangan dekripsi ambang batas. (1) Aktifkan ambang batas n/2 yang akan mempersulit kolusi (2) Jalankan protokol dekripsi ambang batas di dalam HSM (3) Gunakan jaringan dekripsi ambang batas berbasis TEE yang dikendalikan oleh rantai terdesentralisasi untuk autentikasi yang memungkinkan dinamika manajemen kunci.

Daripada memanfaatkan dekripsi ambang batas, MPC dapat digunakan sebagai gantinya. Contoh protokol MPC yang dapat digunakan dalam FHE onchain mencakup 2PC-MPC baru dari Odsy, algoritma MPC pertama yang nonkolusif dan terdesentralisasi secara besar-besaran.

Pendekatan yang berbeda adalah dengan hanya menggunakan kunci publik pengguna untuk mengenkripsi data. Validator kemudian memproses operasi homomorfik, dan pengguna sendiri dapat mendekripsi hasilnya jika diperlukan. Meskipun hanya layak untuk kasus penggunaan khusus, kita dapat menghindari asumsi ambang batas sama sekali.

Ringkasnya, FHE onchain memerlukan implementasi MPC yang efisien yang: (1) Bekerja bahkan ketika ada pelaku jahat (2) Memperkenalkan latensi minimal (3) Memungkinkan masuknya node tanpa izin/fleksibel.

Bukti tanpa pengetahuan (ZKP) Untuk Input Pengguna dan Pihak Komputasi

Tantangan: Verifikasi Input Pengguna + Perhitungan:

Di web2, saat kami meminta tugas komputasi dilakukan, kami sepenuhnya percaya bahwa perusahaan tertentu akan menjalankan tugas persis seperti yang mereka janjikan di balik layar. Di web3, modelnya terbalik sepenuhnya; daripada mengandalkan reputasi perusahaan dan sekadar percaya bahwa mereka akan bertindak jujur, kami kini beroperasi di lingkungan yang tidak dapat dipercaya, artinya pengguna tidak perlu memercayai siapa pun.

Meskipun FHE memungkinkan pemrosesan data terenkripsi, FHE tidak dapat memverifikasi kebenaran input atau komputasi pengguna. Tanpa kemampuan untuk memeriksa keduanya, FHE tidak akan berguna dalam konteks blockchain.

Solusi: ZKP untuk Input Pengguna + Pihak Komputasi:

Meskipun FHE memungkinkan siapa pun melakukan penghitungan sewenang-wenang atas data terenkripsi, ZKP memungkinkan seseorang membuktikan sesuatu itu benar tanpa mengungkapkan informasi mendasarnya. Jadi bagaimana hubungannya?

Ada tiga cara utama FHE dan ZKP bersatu:

1. Pengguna perlu menyerahkan bukti bahwa ciphertext masukannya terbentuk dengan baik. Artinya ciphertext memenuhi persyaratan skema enkripsi dan bukan hanya rangkaian data yang sembarangan.
2. Pengguna perlu menyerahkan bukti bahwa teks biasa yang mereka masukkan memenuhi ketentuan aplikasi tertentu. Mantan. jumlah_saldo > jumlah_transfer
3. Node validator (alias pihak komputasi) perlu membuktikan bahwa mereka telah mengeksekusi komputasi FHE dengan benar. Hal ini disebut sebagai “FHE yang dapat diverifikasi” dan dapat dilihat sebagai analogi ZKP yang diperlukan untuk rollup.

Untuk mengeksplorasi lebih jauh penerapan ZKP:

1. ZKP dari Cipherteks

FHE dibangun di atas kriptografi berbasis kisi, artinya konstruksi primitif kriptografi melibatkan kisi-kisi, yang aman PQ (pasca-kuantum). Sebaliknya, ZKP populer seperti SNARKS, STARKS, dan Bulletproofs tidak bergantung pada kriptografi berbasis kisi.

Untuk membuktikan bahwa ciphertext FHE pengguna terbentuk dengan baik, kita perlu menunjukkan bahwa ciphertext tersebut memenuhi beberapa persamaan matriks-vektor dengan entri dari ring, dan bahwa nilai numerik dari elemen-elemen ini kecil. Pada dasarnya, kita memerlukan sistem bukti verifikasi on-chain yang hemat biaya yang dirancang untuk menangani hubungan berbasis kisi, yang merupakan area penelitian terbuka.

1. ZKP Input Teks Biasa

Selain membuktikan ciphertext yang terbentuk dengan baik, pengguna perlu membuktikan input plaintext mereka memenuhi persyaratan aplikasi. Untungnya, tidak seperti langkah sebelumnya, kita dapat memanfaatkan SNARK umum untuk membuktikan validitas masukan pengguna, sehingga memungkinkan pengembang untuk memanfaatkan skema ZKP, perpustakaan, dan infrastruktur yang ada.

Namun, tantangannya adalah kita perlu “menghubungkan” kedua sistem pembuktian tersebut. Hubungkan seperti yang kita perlukan untuk memastikan pengguna menggunakan masukan yang sama untuk kedua sistem pembuktian; jika tidak, pengguna jahat dapat menipu protokol. Sekali lagi, ini adalah prestasi kriptografi yang sangat sulit dan merupakan area terbuka untuk penelitian awal.

Tabir surya juga telah meletakkan dasar dengan kompiler ZKP mereka yang menawarkan dukungan untuk Antipeluru karena paling mudah terhubung dengan SDLP. Pengembangan di masa depan sedang dilakukan untuk “menghubungkan” kompiler FHE dan ZKP.

Mind Network telah memelopori integrasi ZKP untuk memastikan input dan output tanpa kepercayaan serta memanfaatkan FHE untuk komputasi yang aman.

1. ZKP Perhitungan yang Benar

FHE yang dijalankan pada perangkat keras yang ada sangatlah tidak efisien dan mahal. Seperti yang telah kita lihat dinamika trilema skalabilitas yang terjadi sebelumnya, jaringan dengan kebutuhan sumber daya node yang lebih tinggi tidak dapat mencapai tingkat desentralisasi yang memadai. Solusi yang mungkin bisa dilakukan adalah proses yang disebut “FHE yang Dapat Diverifikasi”, yaitu proses di mana pihak komputasi (validator) menyerahkan ZKP untuk membuktikan pelaksanaan transaksi yang jujur.

Prototipe awal FHE yang dapat diverifikasi dapat ditampilkan oleh proyek bernama SherLOCKED. Pada dasarnya komputasi FHE diturunkan ke Bonsai Risc ZERO yang memproses komputasi melalui data terenkripsi offchain dan mengembalikan hasilnya dengan ZKP dan memperbarui status onchain.

Contoh terbaru dalam memanfaatkan koprosesor FHE dapat dilihat pada demo lelang onchain Aztec. Seperti yang telah kita bahas sebelumnya, rantai FHE yang ada mengenkripsi seluruh negara bagian dengan kunci ambang batas, yang berarti sistem tersebut hanya sekuat komite ambang batasnya. Sebaliknya, di Aztec, pengguna memiliki datanya sendiri, dan karenanya tidak tunduk pada asumsi keamanan ambang batas.

Terakhir, penting untuk membahas di mana pengembang dapat membangun aplikasi FHE. Pengembang dapat membangun aplikasi mereka pada L1 yang didukung FHE, rollup FHE, atau membangun rantai EVM apa pun dan memanfaatkan koprosesor FHE. Setiap desain memiliki kelebihannya masing-masing, namun kami lebih condong ke arah rollup FHE yang dirancang dengan baik (dipelopori oleh Fhenix) atau koprosesor FHE karena keduanya mewarisi keamanan dari Ethereum dan manfaat lainnya.

Hingga saat ini, mendapatkan bukti penipuan pada data terenkripsi FHE merupakan hal yang rumit, namun baru-baru ini tim di Fhenix.io mendemonstrasikan cara mendapatkan bukti penipuan menggunakan tumpukan Arbitrum Nitro yang dipasangkan dengan kompilasi logika FHE ke WebAssembly.

Ketersediaan Data (DA) Lapisan FHE

Tantangan: Kurangnya Kemampuan Kustomisasi dan Throughput

Meskipun penyimpanan telah menjadi komoditas di web2, hal yang sama tidak berlaku di Web3. Mengingat FHE mempertahankan ledakan data yang besar sebesar 10.000x+, kita perlu mencari tahu di mana menyimpan ciphertext FHE yang besar. Jika setiap operator node dalam lapisan DA tertentu mengunduh dan menyimpan data setiap rantai FHE, hanya operator institusional yang mampu memenuhi permintaan tersebut, sehingga berisiko terjadinya sentralisasi.

Mengenai throughput, Celestia memiliki kecepatan tertinggi 6,7mb/s, jika kita ingin menjalankan FHEML dalam bentuk apa pun, kita memerlukan n GBs+/detik dengan mudah. Berdasarkan data terbaru yang dibagikan oleh 1k(x), lapisan DA yang ada tidak dapat mendukung FHE karena keputusan desain yang membatasi throughput (dengan sengaja).

Solusi: Penskalaan Horizontal + Kemampuan Penyesuaian

Kita membutuhkan lapisan DA yang dapat mendukung skalabilitas horizontal. Arsitektur DA yang ada menyebarkan semua data ke setiap node di jaringan yang merupakan kendala utama skalabilitas. Sebaliknya, dengan skalabilitas horizontal, semakin banyak node DA yang memasuki sistem, setiap node akan menyimpan 1/n data, sehingga meningkatkan performa dan biaya seiring dengan tersedianya lebih banyak ruang blok.

Secara terpisah, mengingat besarnya ukuran data yang terkait dengan FHE, masuk akal untuk menawarkan tingkat kemampuan penyesuaian yang lebih tinggi kepada pengembang di sekitar ambang batas pengkodean penghapusan. yaitu Berapa banyak sistem DA yang Anda rasa nyaman untuk dijamin? Baik pembobotan berbasis pasak atau pembobotan berbasis desentralisasi.

Arsitektur EigenDA berfungsi sebagai dasar tampilan lapisan DA untuk FHE. Sifat penskalaan horizontal, pengurangan biaya struktural, pemisahan DA dan konsensus, dll. semuanya memberi jalan pada tingkat skalabilitas yang suatu hari nanti dapat mendukung FHE.

Terakhir, ide tingkat tinggi adalah membangun slot penyimpanan yang dioptimalkan untuk menyimpan teks sandi FHE karena teks sandi mengikuti skema pengkodean tertentu, sehingga memiliki slot penyimpanan yang dioptimalkan dapat membantu penggunaan penyimpanan yang efisien dan pengambilan yang lebih cepat.

Perangkat Keras Enkripsi Homomorfik Sepenuhnya (FHE).

Tantangan: Perangkat Keras FHE Berkinerja Rendah

Dalam promosi aplikasi enkripsi homomorfik penuh (FHE) on-chain, masalah utama adalah latensi yang signifikan karena overhead komputasi, yang membuat menjalankan FHE menjadi tidak praktis pada perangkat keras pemrosesan standar apa pun. Keterbatasan ini berasal dari banyaknya interaksi dengan memori akibat banyaknya jumlah data yang perlu diproses oleh prosesor. Selain interaksi memori, perhitungan polinomial yang rumit dan operasi pemeliharaan ciphertext yang memakan waktu juga membawa banyak overhead.

Untuk lebih memahami keadaan akselerator FHE, kita perlu mengungkap ruang desain: Akselerator FHE khusus aplikasi vs. akselerator FHE yang dapat digeneralisasikan.

Inti dari kompleksitas komputasi dan desain perangkat keras untuk FHE selalu terkait dengan jumlah perkalian yang diperlukan untuk aplikasi tertentu, yang disebut sebagai “kedalaman operasi homomorfik”. Dalam kasus khusus aplikasi, kedalamannya diketahui, sehingga parameter sistem dan komputasi terkait tetap. Oleh karena itu, desain perangkat keras untuk kasus khusus aplikasi ini akan lebih mudah dan biasanya dapat dioptimalkan untuk kinerja yang lebih baik daripada desain akselerator yang dapat digeneralisasikan. Dalam kasus umum, ketika FHE diperlukan untuk mendukung jumlah perkalian yang berubah-ubah, bootstrapping diperlukan untuk menghilangkan sebagian noise yang terakumulasi dalam operasi homomorfik. Bootstrapping mahal dan memerlukan sumber daya perangkat keras yang besar termasuk memori on-chip, bandwidth memori, dan komputasi, yang berarti desain perangkat keras akan sangat berbeda dari desain khusus aplikasi. Oleh karena itu, meskipun pekerjaan yang dilakukan oleh pemain besar di bidang ini, termasuk Intel, Duality, SRI, DARPA, dan banyak lainnya tidak diragukan lagi telah melampaui batas dengan desain berbasis GPU dan ASIC mereka, hal tersebut mungkin tidak dapat diterapkan secara 1:1 pada mendukung kasus penggunaan blockchain.

Mengenai biaya pengembangan: Perangkat keras yang dapat digeneralisasi memerlukan lebih banyak modal untuk merancang dan memproduksi dibandingkan perangkat keras khusus aplikasi, namun fleksibilitasnya memungkinkan perangkat keras untuk digunakan dalam cakupan aplikasi yang lebih luas. Di sisi lain, dengan desain khusus aplikasi, jika kebutuhan aplikasi berubah dan memerlukan dukungan untuk komputasi homomorfik yang lebih dalam, maka perangkat keras khusus aplikasi perlu dikombinasikan dengan beberapa teknik perangkat lunak, seperti MPC, untuk mencapai hasil yang sama seperti perangkat keras yang dapat digeneralisasikan.

Penting untuk dicatat, FHE onchain jauh lebih sulit untuk dipercepat dibandingkan kasus penggunaan khusus aplikasi (mis. FHEML) karena memerlukan kemampuan untuk memproses komputasi yang lebih umum dibandingkan kumpulan yang lebih spesifik. Sebagai ilustrasi, fhEVM devnet saat ini dibatasi pada TPS satu digit.

Mengingat kita memerlukan akselerator FHE yang disesuaikan dengan blockchain, pertimbangan lainnya adalah seberapa dapatkah pekerjaan ditransfer dari perangkat keras ZKP ke perangkat keras FHE?

Ada beberapa modul umum antara ZKP dan FHE, seperti transformasi teori bilangan (NTT) dan operasi polinomial yang mendasarinya. Namun, lebar bit NTT yang digunakan dalam kedua kasus ini berbeda. Di ZKP, perangkat keras harus mendukung rentang lebar bit yang luas untuk NTT, seperti 64-bit dan 256-bit, sedangkan di FHE, operan untuk NTT lebih pendek karena direpresentasikan dalam sistem bilangan residu. Kedua, derajat NTT yang ditangani dalam ZKP secara umum lebih tinggi dibandingkan dengan kasus FHE. Karena dua alasan ini, bukanlah hal yang mudah untuk merancang modul NTT yang mencapai kinerja memuaskan baik untuk ZKP maupun FHE. Selain NTT, ada beberapa hambatan komputasi lain di FHE, seperti automorfisme, yang tidak terdapat di ZKP. Cara naif untuk mentransfer perangkat keras ZKP ke pengaturan FHE adalah dengan memindahkan tugas komputasi NTT ke perangkat keras ZKP dan menggunakan CPU atau perangkat keras lain untuk menangani sisa komputasi di FHE.

Untuk mengatasi tantangan ini, komputasi pada data terenkripsi dengan FHE biasanya 100.000 kali lebih lambat dibandingkan data teks biasa. Namun, berkat skema enkripsi yang lebih baru dan perkembangan terkini pada perangkat keras FHE, kinerja saat ini telah meningkat secara dramatis hingga sekitar 100x lebih lambat dibandingkan data teks biasa.

Solusi:

1. Peningkatan Perangkat Keras FHE

Ada banyak tim yang aktif membangun akselerator FHE, namun mereka tidak mengerjakan akselerator FHE yang khusus untuk komputasi blockchain yang dapat digeneralisasikan (yaitu TFHE). Contoh akselerator perangkat keras khusus blockchain adalah FPT, akselerator FPGA Titik Tetap. FPT adalah akselerator perangkat keras pertama yang secara besar-besaran mengeksploitasi gangguan bawaan yang ada dalam perhitungan FHE dengan menerapkan bootstrapping TFHE seluruhnya dengan perkiraan aritmatika titik tetap. Proyek lain yang mungkin berguna bagi FHE adalah BASALISC, rangkaian arsitektur akselerator perangkat keras yang bertujuan untuk mempercepat komputasi FHE secara signifikan di cloud.

Seperti disebutkan sebelumnya, salah satu hambatan utama dalam desain perangkat keras FHE adalah interaksi besar-besaran dengan memori. Untuk menghindari hambatan ini, solusi potensial adalah mengurangi interaksi dengan memori sebanyak mungkin. Pemrosesan dalam memori (PIM) atau komputasi dekat memori mungkin membantu dalam skenario ini. PIM adalah solusi yang menjanjikan untuk mengatasi tantangan “dinding memori” untuk sistem komputer masa depan, yang memungkinkan memori untuk melayani fungsi komputasi dan memori, menjanjikan renovasi radikal pada hubungan antara komputasi dan memori. Dalam dekade terakhir, kemajuan luar biasa telah dicapai dalam merancang memori non-volatil untuk tujuan ini, seperti RAM resistif, RAM magnetik torsi transfer putaran, dan memori perubahan fasa. Dengan menggunakan memori khusus ini, terdapat penelitian yang menunjukkan peningkatan komputasi yang signifikan dalam pembelajaran mesin dan enkripsi kunci publik berbasis kisi.

1. Perangkat lunak dan perangkat keras yang dioptimalkan

Dalam perkembangan terkini, perangkat lunak telah diakui sebagai komponen penting dalam proses akselerasi perangkat keras. Misalnya, akselerator FHE terkemuka seperti F1 dan CraterLake menggunakan kompiler untuk pendekatan desain bersama perangkat lunak/perangkat keras hybrid.

Seiring kemajuan dunia, kita dapat mengharapkan kompiler yang berfungsi penuh untuk dirancang bersama dengan kompiler FHE khusus blockchain. Penyusun FHE dapat mengoptimalkan program FHE berdasarkan model biaya skema FHE masing-masing. Kompiler FHE ini dapat diintegrasikan dengan kompiler akselerator FHE untuk meningkatkan kinerja end-to-end dengan menggabungkan model biaya dari aspek tingkat perangkat keras.

1. Jaringan Akselerator FHE: Pergeseran dari Scale-up ke Scale-out

Upaya akselerasi perangkat keras FHE yang ada sebagian besar berfokus pada “peningkatan”, yang berarti berfokus pada peningkatan satu akselerator secara vertikal. Di sisi lain, tempat “scale-out” berfokus pada menghubungkan beberapa akselerator FHE dengan jaringan secara horizontal, yang dapat meningkatkan kinerja secara drastis, mirip dengan pembuatan bukti paralel dengan ZKP.

Salah satu kesulitan utama dalam akselerasi FHE adalah masalah inflasi data: Mengacu pada peningkatan signifikan dalam ukuran data yang terjadi selama enkripsi dan komputasi, sehingga menimbulkan tantangan bagi perpindahan data yang efisien antara memori on-chip dan off-chip.

Inflasi data menimbulkan tantangan besar dalam menghubungkan beberapa akselerator FHE melalui jaringan secara horizontal. Oleh karena itu, desain bersama perangkat keras dan jaringan FHE akan menjadi arah penelitian yang menjanjikan di masa depan. Contohnya mencakup perutean jaringan adaptif untuk akselerator FHE: Menerapkan mekanisme perutean yang secara dinamis menyesuaikan jalur data antara akselerator FHE berdasarkan beban komputasi waktu nyata dan lalu lintas jaringan. Hal ini akan memastikan kecepatan transfer data yang optimal dan pemanfaatan sumber daya yang efisien.

Kesimpulan

FHE secara mendasar akan menata ulang cara kami mengamankan data di seluruh platform, membuka jalan bagi era baru privasi yang belum pernah terjadi sebelumnya. Untuk membangun sistem seperti itu diperlukan kemajuan yang signifikan tidak hanya di FHE, namun juga di ZKP dan MPC.

Saat kita memasuki era baru ini, upaya kolaboratif antara kriptografer, insinyur perangkat lunak, dan spesialis perangkat keras akan menjadi sangat penting. Belum lagi anggota parlemen, politisi, dll. Karena kepatuhan terhadap peraturan adalah satu-satunya jalan menuju adopsi arus utama.

Pada akhirnya, FHE akan berdiri di garis depan gelombang transformatif kedaulatan digital, mewujudkan masa depan di mana privasi dan keamanan data tidak lagi eksklusif tetapi menjadi satu kesatuan yang tidak dapat dipisahkan.

Terima kasih khusus：

Terima kasih banyak kepada Mason Song (Mind Network), Guy Itzhaki (Fhenix), Leo Fan (Cysic), Kurt Pan, Xiang Xie (PADO), Nitanshu Lokhande (BananaHQ) untuk ulasannya. Kami menantikan untuk membaca tentang pekerjaan dan upaya mengesankan yang dilakukan orang-orang ini di lapangan!

Penafian:

1. Artikel ini dicetak ulang dari [HashKey Capital]. Semua hak cipta milik penulis asli [Jeffrey Hu、Arnav Pagidyala]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya 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.