Menghubungkan kunci-kunci kriptografi dengan identitas telah menjadi masalah sejak pengenalan teknologiTantangannya adalah menyediakan dan mempertahankan pemetaan yang tersedia secara publik dan konsisten antara identitas dan kunci publik (yang mana identitas tersebut memiliki kunci privatnya). Tanpa pemetaan tersebut, pesan yang dimaksudkan untuk dirahasiakan dapat berjalan salah - terkadang dengan hasil yang sangat buruk. Tantangan yang sama juga ada di web3.

Saat ini ada tiga solusi yang mungkin ada. Dua pendekatan klasik adalah direktori kunci publik dan enkripsi berbasis identitas. Yang ketiga adalah enkripsi berbasis registrasi, yang sebelumnya sepenuhnya bersifat teoritis. Ketiga pendekatan tersebut menawarkan tradeoff yang berbeda antara anonimitas, interaktivitas, dan efisiensi, yang mungkin terlihat jelas pada awalnya, tetapi pengaturan blockchain memperkenalkan kemungkinan dan batasan baru. Tujuan dari postingan ini, kemudian, adalah untuk mengeksplorasi ruang desain ini dan membandingkan pendekatan ini ketika diterapkan pada blockchain. Ketika pengguna membutuhkan transparansi dan anonimitas onchain, skema RBE yang praktis adalah pemenang yang jelas - mengatasi asumsi kepercayaan yang kuat pada enkripsi berbasis identitas, tetapi dengan biaya tertentu.

Tiga Pendekatan Singkat

Pendekatan klasik untuk menghubungkan kunci kriptografi dengan identitas adalah infrastruktur kunci publik (PKI), dengan direktori kunci publik sebagai intinya. Pendekatan ini memerlukan pengirim potensial untuk berinteraksi dengan pihak ketiga yang terpercaya (pemelihara direktori, atau otoritas sertifikat) untuk mengirim pesan. Selain itu, dalam pengaturan web2, memelihara direktori ini dapat mahal, membosankan, dan cenderung kesalahan, dan pengguna berisiko penyalahgunaan oleh otoritas sertifikat.

Kriptografer telah menyarankan alternatif untuk mengatasi masalah dengan PKI. Pada tahun 1984, Adi Shamir menyarankanenkripsi berbasis identitas (IBE), di mana identifier pihak — nomor telepon, surel, nama domain ENS — berfungsi sebagai kunci publik. Hal ini menghilangkan kebutuhan untuk mempertahankan direktori kunci publik namun datang dengan biaya memperkenalkan pihak ketiga yang dipercayai (penyedia kunci). Dan Boneh dan Matthew Franklin memberikankonstruksi IBE praktis pertamapada tahun 2001, namun IBE belum mendapatkan adopsi yang luas kecuali dalam ekosistem tertutup seperti perusahaan atau penempatan pemerintah, mungkin karena asumsi kepercayaan yang kuat. (Seperti yang akan kita lihat di bawah, asumsi ini dapat dikurangi secara parsial dengan mengandalkan kuorum terpercaya dari pihak-pihak yang ada, yang dapat dengan mudah difasilitasi oleh blockchain).

Pilihan ketiga, enkripsi berbasis registrasi (RBE), adalah diusulkan pada tahun 2018. RBE mempertahankan arsitektur umum yang sama dengan IBE tetapi menggantikan generator kunci tepercaya dengan "kurator kunci" transparan yang hanya melakukan perhitungan pada data publik (khususnya, ia mengakumulasi kunci publik menjadi semacam "intisari" yang tersedia untuk umum). Transparansi kurator utama ini membuat pengaturan blockchain – di mana kontrak pintar dapat mengisi peran kurator – sangat cocok untuk RBE. RBE bersifat teoritis hingga 2022, ketika rekan penulis saya dan saya memperkenalkan konstruksi RBE yang pertama secara praktis efisien.

Mengevaluasi Kompromi

Ruang desain ini kompleks, dan membandingkan skema-skema ini memerlukan mempertimbangkan banyak dimensi. Untuk menjaga hal-hal lebih sederhana, saya akan membuat dua asumsi:

1. Pengguna tidak memperbarui atau mencabut kunci mereka.
2. Kontrak pintar tidak menggunakan layanan ketersediaan data off-chain (DAS) atau data blob.

Saya akan membahas pada akhir bagaimana setiap pertimbangan tambahan ini dapat mempengaruhi tiga solusi potensial kami.

Direktori Kunci Publik

Ringkasan: Siapa pun dapat menambahkan entri (id, pk) ke tabel on-chain (direktori) dengan memanggil kontrak pintar, asalkan ID belum diklaim.

Sebuah PKI terdesentralisasi pada dasarnya adalah kontrak pintar yang memelihara direktori identitas dan kunci publik yang sesuai. Sebagai contoh, Registrasi Layanan Nama Ethereum (ENS)memelihara pemetaan nama domain ("identitas") dan metadata yang sesuai, termasuk alamat tempat mereka diterjemahkan (dari transaksi mana kunci publik dapat diturunkan). PKI terdesentralisasi akan memberikan fungsi yang lebih sederhana: daftar yang dipelihara oleh kontrak hanya akan menyimpan kunci publik yang sesuai dengan setiap ID.

Untuk mendaftar, pengguna menghasilkan sepasang kunci (atau menggunakan sepasang kunci yang sebelumnya telah dihasilkan) dan mengirimkan ID dan kunci publiknya ke kontrak (mungkin beserta pembayaran tertentu). Kontrak memeriksa bahwa ID belum diklaim, dan jika belum, kontrak menambahkan ID dan kunci publik ke direktori. Pada titik ini, siapa pun dapat mengenkripsi pesan untuk pengguna terdaftar dengan meminta kontrak untuk kunci publik yang sesuai dengan ID. (Jika pengirim telah mengenkripsi sesuatu ke pengguna ini sebelumnya, tidak perlu lagi meminta kontrak.) Dengan kunci publik, pengirim dapat mengenkripsi pesannya seperti biasa dan mengirimkan teks sandi ke penerima, yang dapat menggunakan kunci rahasia yang sesuai untuk mengembalikan pesan tersebut.

Mari kita lihat properti dari metode ini.

Di sisi negatif buku besar:

• Tidak singkat. Direktori kunci lengkap perlu disimpan di-chain sehingga selalu tersedia untuk semua orang (ingat, untuk saat ini kita berasumsi tidak ada DAS). Untuk ~900K nama domain unik terdaftar di ENS pada saat penulisan ini, ini berarti hampir 90MB penyimpanan persisten. Pihak yang mendaftar perlu membayar untuk penyimpanan yang digunakan entri mereka, sekitar 65K gas (saat ini sekitar $1 — lihat evaluasi kinerja di bawah).
• Enkripsi yang agak interaktif. Pengirim perlu membaca rantai untuk mengambil kunci publik pengguna, tetapi hanya jika ini adalah pertama kalinya pengirim mengenkripsi pesan ke pengguna tertentu itu. (Ingat, kita berasumsi pengguna tidak memperbarui atau mencabut kunci mereka).
• Tidak pengirim-anonim. Ketika Anda mengambil kunci publik seseorang, Anda mengaitkan diri Anda dengan penerima, menunjukkan bahwa Anda memiliki semacam hubungan dengan mereka. Bayangkan misalnya bahwa Anda mengambil kunci publik untuk WikiLeaks: Ini bisa menciptakan kecurigaan bahwa Anda sedang bocor dokumen-dokumen kelasifikasi. Masalah ini dapat dikurangi dengan "lalu lintas penutup" (mengambil sejumlah besar kunci, sebagian besar tidak akan Anda gunakan) atau serupa dengan menjalankan node penuh, atau dengan pengambilan informasi pribadi (PIR).

Di sisi positif:

• Dekripsi non-interaktif. Pengguna mendekripsi pesan dengan kunci rahasia yang disimpan secara lokal, sehingga tidak memerlukan interaksi apa pun.
• Transparan. Daftar pengguna dan kunci-kunci tersebut sepenuhnya publik, sehingga siapa pun dapat memeriksa apakah mereka terdaftar dengan benar atau tidak.
• Setelan ID sembarang. Domain ID tidak terbatas secara a priori oleh konstruksi; dalam teori, ID bisa menjadi string sewenang-wenang(hingga terbatas oleh implementasi kontrak tertentu dan penyimpanannya).

Kapan Anda mungkin ingin menggunakan direktori kunci publik? Direktori kunci publik yang terdesentralisasi mudah diatur dan dikelola, jadi ini adalah pilihan dasar yang baik. Namun, jika biaya penyimpanan atau privasi menjadi perhatian, salah satu opsi lain di bawah ini mungkin merupakan pilihan yang lebih baik.

(Threshold) Enkripsi Berbasis Identitas (IBE) Gate

Ringkasan: Identitas pengguna adalah kunci publik mereka. Pihak ketiga yang tepercaya diperlukan untuk mengeluarkan kunci dan menyimpan rahasia master (pintu belakang) untuk seumur hidup sistem.

Dalam IBE, seorang pengguna tidak menghasilkan pasangan kunci mereka sendiri tetapi malah mendaftar dengan pembangkit kunci tepercaya. Pembangkit kunci memiliki pasangan kunci “induk” (msk, mpk dalam gambar). Diberikan ID pengguna, pembangkit kunci menggunakan kunci rahasia induk msk dan ID untuk menghitung kunci rahasia untuk pengguna. Kunci rahasia itu harus dikomunikasikan kepada pengguna melalui saluran yang aman (yang dapat dibangun dengan Protokol pertukaran kunci.

IBE mengoptimalkan pengalaman pengirim: Ia mengunduh mpk pembangkit kunci sekali, setelah itu dapat mengenkripsi pesan ke ID apa pun dengan menggunakan ID itu sendiri. Dekripsi juga mudah: pengguna terdaftar dapat menggunakan kunci rahasia yang diberikan kepadanya oleh pembangkit kunci untuk mendekripsi teks sandi.

Kunci rahasia utama pembangkit kunci lebih persisten daripada “limbah beracun” yang dihasilkan oleh upacara setup yang dipercayaidigunakan untuk beberapa SNARKs. Generator kunci membutuhkannya untuk mengeluarkan kunci rahasia baru, sehingga generator kunci tidak dapat menghapusnya setelah pengaturan seperti peserta dalam upacara SNARK lakukan. Ini juga merupakan informasi yang berbahaya. Siapa pun dengan msk dapat mendekripsi semua pesan yang dikirim ke pengguna mana pun dalam sistem. Ini berarti ada risiko konstan terhadap penggalian data dengan konsekuensi yang sangat buruk.

Meskipun msk tetap aman, setiap pengguna yang mendaftar dalam sistem perlu mempercayai pembangkit kunci untuk tidak membaca pesannya, karena pembangkit kunci dapat menyimpan salinan kunci rahasia pengguna atau menghitung ulang kuncinya dari msk kapan pun. Bahkan mungkin saja pembangkit kunci dapat mengeluarkan kunci rahasia yang cacat atau "terbatas" kepada pengguna yang mendekripsi semua pesan kecuali beberapa yang dilarang oleh pembangkit kunci.

Kepercayaan ini sebaliknya dapat didistribusikan di antara kuorum generator kunci, sehingga pengguna hanya perlu mempercayai jumlah ambang batas dari mereka. Dalam hal ini sejumlah kecil generator kunci berbahaya tidak dapat memulihkan kunci rahasia atau menghitung kunci buruk, dan penyerang harus masuk ke beberapa sistem untuk mencuri rahasia master penuh.

Jika pengguna setuju dengan asumsi kepercayaan ini, (ambang) IBE datang dengan banyak manfaat:

• Penyimpanan on-chain konstan/minimal. Hanya kunci publik master (elemen grup tunggal) yang perlu disimpan secara on-chain. Ini jauh lebih sedikit daripada penyimpanan yang dibutuhkan oleh direktori kunci publik on-chain. Untuk Boneh-Franklin IBE melalui kurva BN254, ini berarti menambahkan 64 byte penyimpanan on-chain persisten sekali selama fase penyiapan, yang mengharuskan layanan hanya menghabiskan 40K gas.
• Enkripsi non-interaktif. Pengirim hanya perlu kunci publik utama (yang diunduh sekali pada awal) dan ID penerima untuk mengenkripsi pesan. Ini berbeda dengan direktori kunci publik, di mana pengirim harus mengambil kunci untuk setiap pengguna baru yang ingin dia komunikasikan.
• Dekripsi non-interaktif. Sekali lagi, pengguna menggunakan kunci rahasia yang disimpan secara lokal untuk mendekripsi pesan.
• Pengirim-anonim. Pengirim tidak perlu mengambil informasi per-penerima dari rantai. Dalam perbandingan, dalam kasus registri kunci publik, pengirim harus berinteraksi dengan kontrak dengan cara yang bergantung pada penerima.
• Set ID sembarang. Seperti di registri kunci publik, ID dapat berupa string sembarang.

Tapi!

• Asumsi kepercayaan yang kuat. Berbeda dengan registri kunci publik, di mana pengguna menghasilkan kunci mereka sendiri, IBE membutuhkan pihak yang dipercaya atau kuorum dari pihak-pihak dengan rahasia utama (pintu belakang) untuk mengeluarkan kunci. Rahasia utama harus tetap ada sepanjang masa hidup sistem dan dapat mengompromikan semua pesan pengguna yang terdaftar jika bocor atau disalahgunakan.

Kapan Anda mungkin ingin menggunakan (threshold) IBE? Jika pihak ketiga yang terpercaya atau pihak ketiga tersedia dan pengguna bersedia mempercayainya, IBE menawarkan pilihan yang lebih efisien dalam penggunaan ruang (dan oleh karena itu lebih murah) dibandingkan dengan registrasi kunci on-chain.

Enkripsi Berbasis Registrasi (RBE)

Ringkasan: Mirip dengan IBE, identitas pengguna berfungsi sebagai kunci publik mereka, tetapi pihak ketiga / kuorum tepercaya diganti dengan akumulator transparan (disebut "kurator kunci").

Dalam bagian ini, saya akan membahas konstruksi RBE yang efisien dari kertas saya, karena berbeda dengan (menurut pengetahuan saya) hanya konstruksi praktis lainnya, saat ini dapat diterapkan pada blockchain (berbasis pasangan, bukan berbasis kisi). Setiap kali saya mengatakan "RBE" maksud saya konstruksi khusus ini, meskipun beberapa pernyataan mungkin benar tentang RBE secara umum.

Dalam RBE, seorang pengguna menghasilkan pasangan kunci sendiri dan menghitung beberapa "nilai pembaruan" (a dalam gambar) yang berasal dari kunci rahasia dan string referensi umum (CRS). Meskipun adanya CRS berarti pengaturan tersebut tidak sepenuhnya tidak dipercaya, CRS adalah powers-of-taukonstruksi, yang bisa menjadidihitung secara kolaboratif on-chain dan aman selama ada satu kontribusi yang jujur.

Kontrak pintar disiapkan untuk jumlah pengguna N yang diharapkan, dikelompokkan ke dalam bucket. Ketika pengguna mendaftar di sistem, ia mengirimkan ID, kunci publik, dan nilai pembaruan ke kontrak pintar. Kontrak pintar mempertahankan seperangkat parameter publik pp (berbeda dari CRS), yang dapat dianggap sebagai "intisari" ringkas dari kunci publik dari semua pihak yang terdaftar dalam sistem. Ketika menerima permintaan pendaftaran, ia melakukan pemeriksaan pada nilai pembaruan dan mengalikan kunci publik ke dalam bucket pp yang sesuai.

Pengguna terdaftar juga perlu menyimpan beberapa "informasi tambahan" secara lokal, yang mereka gunakan untuk membantu dekripsi dan yang ditambahkan kapan saja pengguna baru mendaftar di bucket yang sama. Mereka dapat memperbarui ini sendiri dengan memantau blockchain untuk pendaftaran di ember mereka, atau kontrak pintar dapat membantu dengan mempertahankan daftar nilai pembaruan yang diterimanya dari pendaftaran terbaru (katakanlah, dalam seminggu terakhir), yang dapat ditarik pengguna secara berkala (setidaknya seminggu sekali).

Pengirim dalam sistem ini mengunduh CRS sekali dan kadang-kadang mengunduh versi terbaru parameter publik. Yang penting dari sudut pandang pengirim adalah bahwa parameter publik tersebut mencakup kunci publik penerima yang dimaksud; tidak perlu menjadi versi terbaru. Pengirim kemudian dapat menggunakan CRS dan parameter publik, bersama dengan ID penerima, untuk mengenkripsi pesan kepada penerima.

Setelah menerima pesan, pengguna memeriksa informasi tambahan yang disimpan secara lokal untuk nilai yang melewati beberapa pemeriksaan. (Jika tidak ditemukan, berarti perlu mengambil pembaruan dari kontrak.) Dengan menggunakan nilai ini dan kunci rahasia, pengguna dapat mendekripsi teks sandi.

Jelas, skema ini lebih kompleks daripada dua lainnya. Tetapi ini membutuhkan lebih sedikit penyimpanan on-chain daripada direktori kunci publik sambil menghindari asumsi kepercayaan IBE yang kuat.

• Parameter-parameter yang ringkas. Ukuran parameter yang akan disimpan on-chain adalah sublinear terhadap jumlah pengguna. Ini jauh lebih kecil daripada total penyimpanan yang diperlukan untuk direktori kunci publik (linear terhadap jumlah pengguna), tetapi masih tidak konstan dan oleh karena itu lebih buruk dibandingkan dengan IBE.
• Enkripsi yang agak interaktif. Untuk mengirim pesan, pengirim memerlukan salinan parameter publik yang berisi penerima yang dimaksud. Ini berarti perlu memperbarui parameter pada suatu titik setelah penerima yang dimaksud mendaftar, tetapi tidak selalu untuk setiap penerima yang mendaftar, karena satu pembaruan mungkin mencakup kunci beberapa penerima. Secara keseluruhan, pengiriman pesan lebih interaktif daripada IBE tetapi kurang interaktif daripada direktori.
• Dekripsi agak interaktif. Mirip dengan kasus enkripsi, penerima memerlukan salinan informasi tambahan yang "cocok" dengan versi parameter publik yang digunakan untuk enkripsi. Lebih khusus lagi, parameter publik dan bucket aux diperbarui setiap kali pengguna baru mendaftar di bucket tersebut, dan nilai yang mampu mendekripsi ciphertext adalah nilai yang sesuai dengan versi pp yang digunakan untuk mengenkripsi. Seperti pembaruan parameter publik, pengguna dapat memutuskan untuk mengambil pembaruan aux hanya secara berkala, kecuali ketika dekripsi gagal. Tidak seperti pembaruan parameter publik, mengambil pembaruan aux lebih sering tidak secara inheren membocorkan informasi.
• Pengirim-anonim. Seperti pada kasus direktori, pengirim dapat mengenkripsi pesan sepenuhnya sendiri (asalkan memiliki parameter terbaru) tanpa memerlukan informasi yang spesifik untuk penerima. Informasi yang dibaca dari rantai, bila diperlukan, tidak tergantung pada penerima yang dimaksud. (Untuk mengurangi komunikasi, pengirim dapat meminta hanya satu pp bucket tertentu, bocor informasi parsial.)
• Bening. Meskipun sistem perlu diatur menggunakan upacara penyiapan tepercaya (berpotensi didistribusikan dan / atau dikelola secara eksternal) yang mengeluarkan CRS yang tertusuk, sistem ini tidak bergantung pada pihak tepercaya atau kuorum setelah penyiapan selesai: meskipun bergantung pada pihak ketiga yang mengoordinasikan (kontrak), itu benar-benar transparan dan siapa pun dapat menjadi koordinator atau memeriksa bahwa mereka berperilaku jujur dengan mengkonfirmasi transisi keadaannya (itulah mengapa bisa diimplementasikan sebagai kontrak pintar). Selanjutnya, pengguna dapat meminta bukti singkat (non-) keanggotaan untuk memeriksa bahwa mereka (atau orang lain) terdaftar / tidak terdaftar dalam sistem. Ini berbeda dengan kasus IBE, di mana sulit bagi pihak / pihak tepercaya untuk benar-benar membuktikan bahwa mereka tidak secara diam-diam mengungkapkan kunci dekripsi (kepada diri mereka sendiri dengan membuat salinan rahasia atau kepada orang lain). Direktori kunci publik, di sisi lain, sepenuhnya transparan.
• Set ID terbatas. Saya telah menjelaskan versi "dasar" dari konstruksi RBE. Untuk menentukan secara transparan bucket mana yang termasuk dalam ID, ID harus memiliki urutan publik dan deterministik. Nomor telepon dapat dengan mudah ditertibkan, tetapi memesan string sewenang-wenang itu berat jika bukan tidak mungkin karena jumlah ember bisa sangat besar atau tidak terbatas. Ini dapat dikurangi dengan menawarkan kontrak terpisah yang menghitung pemetaan semacam itu atau dengan mengadopsi pendekatan cuckoo-hashing yang diusulkan dalam pekerjaan tindak lanjut ini.

Dengan ekstensi:

• Penerima-anonim. skema ini dapat diperluas sehingga teks terenkripsi tidak mengungkap identitas penerima.

Kapan Anda mungkin ingin menggunakan RBE? RBE menggunakan penyimpanan on-chain yang lebih sedikit daripada registri on-chain sambil menghindari asumsi kepercayaan yang kuat yang diperlukan oleh IBE. Dibandingkan dengan registri, RBE juga menawarkan jaminan privasi yang lebih kuat kepada pengirim. Namun, karena RBE baru saja menjadi pilihan yang layak untuk manajemen kunci, kami belum yakin pada skenario mana yang akan paling menguntungkan dari kombinasi properti ini. Mohon beritahu sayajika Anda memiliki ide apa pun.

Perbandingan Kinerja

Saya memperkirakan biaya (per 30 Juli 2024) untuk menerapkan ketiga pendekatan ini on-chain di notebook Colab ini. Hasil untuk kapasitas sistem ~900K pengguna (jumlah nama domain unik yang terdaftar di ENS pada saat penulisan iniditampilkan dalam tabel di bawah ini.

PKI tidak memiliki biaya setup dan biaya pendaftaran per pengguna yang rendah, sedangkan IBE memiliki biaya setup kecil dan pendaftaran per pengguna yang praktis gratis. RBE memiliki biaya setup yang lebih tinggi dan juga biaya pendaftaran yang tinggi secara tidak terduga, meskipun penampungan on-chain yang rendah.

Sebagian besar biaya pendaftaran (asumsi komputasi dilakukan pada L2) berasal dari fakta bahwa pihak-pihak harus memperbarui sebagian parameter publik di penyimpanan persisten, yang menambahkan biaya pendaftaran yang tinggi.

Meskipun RBE lebih mahal daripada alternatif lainnya, analisis ini menunjukkan bahwa RBE dapat diterapkan secara layak di Ethereum mainnet hari ini -- tanpa asumsi kepercayaan yang berpotensi berisiko dari PKI atau IBE. Dan itu terjadi sebelum optimasi seperti penerapan beberapa instansi yang lebih kecil (dan karena itu lebih murah) atau menggunakan data blob. Mengingat RBE memiliki keunggulan atas direktori kunci publik dan IBE dalam bentuk anonimitas yang lebih kuat dan asumsi kepercayaan yang berkurang, itu bisa menarik bagi mereka yang menghargai privasi dan pengaturan tanpa kepercayaan.

Noemi Glaeseradalah calon PhD di Ilmu Komputer di University of Maryland dan Max Planck Institute for Security & Privacy dan merupakan magang penelitian di a16z crypto selama musim panas '23. Dia adalah penerima NSF Graduate Research Fellowship, dan sebelumnya merupakan magang penelitian di NTT Research.

Lampiran: Pertimbangan Tambahan

Menangani pembaruan/pembatalan kunci

Dalam kasus direktori kunci publik, penanganan pembaruan kunci dan pencabutan adalah sederhana: untuk mencabut kunci, pihak meminta kontrak untuk menghapusnya dari direktori. Untuk memperbarui kunci, entri (id, pk) ditimpa dengan kunci baru menjadi (id, pk’).

Untuk pencabutan dalam IBE, Boneh dan Franklin menyarankan pengguna untuk secara berkala memperbarui kunci mereka (misalnya, setiap minggu), dan pengirim menyertakan periode waktu saat ini dalam string identitas saat mengenkripsi (misalnya, "Bob "). Karena sifat enkripsi non-interaktif, pengirim tidak memiliki cara untuk mengetahui kapan seorang pengguna mencabut kuncinya, sehingga beberapa pembaruan periode adalah intrinsik. Boldyreva, Goyal, dan Kumar memberikan sebuah mekanisme pencabutan yang lebih efisien berdasarkan IBE “Fuzzy” yang membutuhkan dua kunci untuk dekripsi: kunci "identitas" dan kunci "waktu" tambahan. Dengan cara ini, hanya tombol waktu yang harus diperbarui secara berkala. Kunci waktu pengguna diakumulasikan dalam pohon biner, dan pengguna dapat menggunakan node apa pun di sepanjang jalur (dalam kasus dasar, hanya root yang diperlukan dan itu satu-satunya bagian yang diterbitkan oleh generator kunci). Pencabutan kunci dicapai dengan tidak lagi menerbitkan pembaruan untuk pengguna tertentu (menghapus node di sepanjang jalur pengguna itu dari pohon), dalam hal ini ukuran pembaruan meningkat tetapi tidak pernah lebih dari logaritmik dalam jumlah pengguna.

Konstruksi RBE kami yang efisien tidak mempertimbangkan pembaruan dan pencabutan, a Pekerjaan tindak lanjutmemberi sebuah compiler yang dapat "meng-upgrade" skema kita untuk menambahkan fungsionalitas ini.

Memindahkan data off-chain dengan DAS

Menggunakan solusi ketersediaan data (DAS) untuk memindahkan penyimpanan on-chain ke off-chain hanya akan mempengaruhi kalkulasi untuk direktori kunci publik dan RBE, mengurangi keduanya menjadi jumlah penyimpanan on-chain yang sama. RBE akan tetap mempertahankan keuntungan menjadi lebih pribadi bagi pengirim, karena masih menghindari kebocoran identitas penerima melalui pola akses. IBE sudah memiliki penyimpanan on-chain minimal dan tidak akan mendapatkan manfaat dari DAS.

Disclaimer：

1. Artikel ini dicetak ulang dari [A16ZCRYPTO], Semua hak cipta milik penulis asli [Noemi Glaeser ]. Jika ada keberatan terhadap pencetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penolakan Tanggung Jawab Kewajiban: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.