Bagian 1 dari seri privasi kami Membahas apa yang dimaksud dengan "privasi", bagaimana privasi dalam jaringan blockchain berbeda dari privasi Web2, dan mengapa sulit dicapai dalam blockchain.

Argumen utama dalam posting ini adalah bahwa jika tujuan akhir yang diinginkan adalah memiliki infrastruktur privasi yang dapat diprogram yang dapat menangani status privat bersama tanpa adanya satu titik kegagalan tunggal pun, maka semua jalan menuju ke MPC. Kami juga mengeksplorasi kematangan MPC dan asumsi kepercayaannya, menyoroti pendekatan alternatif, membandingkan tradeoff, dan memberikan gambaran industri.

Apakah kita semua membangun hal yang sama? Terus membaca untuk mengetahui.

Terima kasih kepadaAvishay (SodaLabs), Lukas (Taceo), Michael (Keseimbangan) dan Nico (Arcium) untuk diskusi yang membantu membentuk pos ini.

Apa yang dapat terjadi, terbebas dari apa yang telah terjadi

Infrastruktur privasi yang ada di blockchain dirancang untuk menangani kasus penggunaan yang sangat spesifik, seperti pembayaran pribadi atau pemungutan suara. Ini adalah pandangan yang sangat sempit dan sebagian besar mencerminkan apa yang saat ini digunakan untuk blockchain (perdagangan, transfer, dan spekulasi).Tom Walpo menempatkannya- Crypto menderita paradoks Fermi:

Selain meningkatkan kebebasan individu, kami percaya bahwa privasi adalah prasyarat untuk memperluas ruang desain blockchain di luar meta spekulatif saat ini. Banyak aplikasi memerlukan beberapa status pribadi dan/atau logika tersembunyi untuk berfungsi dengan baik:

• Keadaan tersembunyi: Sebagian besar kasus penggunaan keuangan membutuhkan (setidaknya) privasi dari pengguna lain dan banyak permainan multiplayer jauh lebih tidak menyenangkan untuk dimainkan tanpa beberapa keadaan tersembunyi (misalnya jika semua orang di meja poker melihat kartu satu sama lain).
• Logika tersembunyi: Beberapa kasus penggunaan memerlukan penyembunyian beberapa logika sambil masih memungkinkan orang lain untuk menggunakan aplikasi, seperti mesin pencocokan, strategi perdagangan on-chain, dll.

Analisis empiris (dari web2 dan web3) menunjukkan bahwa sebagian besar pengguna tidak bersedia membayar lebih atau melompati lebih banyak rintangan untuk privasi tambahan, dan kami setuju bahwa privasi bukanlah faktor penjualan itu sendiri. Namun, itu memungkinkan kasus penggunaan baru dan (semoga) lebih bermakna untuk ada di atas blockchain - memungkinkan kita untuk keluar dari Paradox Fermi.

Teknologi peningkatan privasi (PET) dan solusi kriptografi modern ("kriptografi dapat diprogram“) adalah blok bangunan mendasar untuk mewujudkan visi ini (lihat lampiranuntuk informasi lebih lanjut tentang solusi yang tersedia dan kompromi yang ada).

Tiga Hipotesis yang Membentuk Pandangan Kita

Tiga hipotesis kunci membentuk pandangan kami tentang bagaimana kami percaya infrastruktur privasi dalam blockchain dapat berkembang:

1. Kriptografi akan diabstraksi dari para pengembang aplikasi: Sebagian besar pengembang aplikasi tidak ingin (atau tidak tahu cara) berurusan dengan kriptografi yang diperlukan untuk privasi. Tidak masuk akal mengharapkan mereka untuk mengimplementasikan kriptografi sendiri dan membangun rantai aplikasi pribadi (misalnya. ZcashatauNamada) atau aplikasi pribadi di atas rantai publik (misalnya Tornado Cash). Ini terlalu banyak kerumitan dan overhead, yang saat ini membatasi ruang desain untuk sebagian besar pengembang (tidak dapat membangun aplikasi yang memerlukan jaminan privasi). Karena itu, kami percaya bahwa kompleksitas pengelolaan bagian kriptografi harus diabstraksikan jauh dari pengembang aplikasi. Dua pendekatan di sini adalah infrastruktur privasi yang dapat diprogram (L1/L2 pribadi bersama) atau "kerahasiaan sebagai layanan" yang memungkinkan outsourcing komputasi rahasia.
2. Banyak kasus penggunaan (mungkin lebih dari yang kita pikirkan) memerlukan status pribadi bersama: Seperti disebutkan sebelumnya, banyak aplikasi memerlukan beberapa status dan/atau logika tersembunyi agar berfungsi dengan baik. Status privat bersama adalah bagian dari ini, di mana banyak pihak menghitung bagian yang sama dari status privat. Meskipun kita dapat mempercayai pihak terpusat untuk melakukannya untuk kita dan menyebutnya sehari, idealnya kita ingin melakukannya dengan cara yang diminimalkan kepercayaan untuk menghindari satu titik kegagalan. Zero knowledge proofs (ZKP) saja tidak dapat mencapai hal ini - kita perlu memanfaatkan alat tambahan seperti trusted execution environments (TEE), fully homomorphic encryption (FHE), dan/atau multi-party computation (MPC).
3. Set perisai yang lebih besar memaksimalkan privasi: Sebagian besar informasi terungkap ketika memasuki atau meninggalkanset yang terlindungi, sehingga kita harus mencoba untuk meminimalkannya. Memiliki beberapa aplikasi pribadi yang dibangun di atas blockchain yang sama dapat membantu memperkuat jaminan privasi dengan meningkatkan jumlah pengguna dan transaksi dalam satu set yang terlindungi yang sama.

Permainan Akhir Infrastruktur Privasi

Dengan asumsi di atas dalam pikiran - apa tujuan akhir infrastruktur privasi dalam blockchain? Apakah ada pendekatan yang cocok untuk setiap aplikasi? Teknologi peningkatan privasi tunggal untuk menguasai semuanya?

Tidak sepenuhnya. Semuanya memiliki kompromi yang berbeda dan kami sudah melihat kombinasinya dalam berbagai cara. Secara total, kami telah mengidentifikasi 11 pendekatan yang berbeda (lihat lampiran).

Hari ini, pendekatan terpopuler dalam membangun infrastruktur privasi di blockchain menggunakan ZKPs atau FHE. Namun, keduanya memiliki kelemahan mendasar:

• Protokol privasi berbasis ZK dengan pembuktian di sisi klien dapat menawarkan jaminan privasi yang kuat tetapi tidak memungkinkan beberapa pihak untuk menghitung pada keadaan pribadi yang sama. Hal ini membatasi ekspresivitas, yaitu jenis aplikasi apa yang dapat dikembangkan oleh para pengembang.
• FHE memungkinkan komputasi di atas data terenkripsi dan status pribadi bersama, tetapi menimbulkan pertanyaan tentang siapa yang memiliki status tersebut, yaitu siapa yang memegang kunci dekripsi. Hal ini membatasi kekuatan jaminan privasi dan seberapa banyak kita dapat mempercayai bahwa apa yang bersifat pribadi hari ini akan tetap demikian besok.

Jika tujuan akhir yang diinginkan adalah memiliki infrastruktur privasi yang dapat diprogram yang dapat menghandle status pribadi bersama tanpa ada satu titik kegagalan pun, maka kedua jalan menuju MPC:

Perhatikan bahwa meskipun kedua pendekatan ini pada akhirnya akan konvergen, MPC digunakan untuk hal-hal yang berbeda:

• Jaringan ZKP: MPC digunakan untuk menambahkan ekspresivitas dengan memungkinkan komputasi atas status pribadi bersama.
• Jaringan FHE: MPC digunakan untuk meningkatkan keamanan dan memperkuat jaminan privasi dengan mendistribusikan kunci dekripsi ke komite MPC (bukan pihak ketiga tunggal).

Sementara diskusi mulai beralih ke pandangan yang lebih nuansa, jaminan di balik pendekatan yang berbeda masih belum dieksplorasi sepenuhnya. Mengingat bahwa asumsi kepercayaan kita pada dasarnya sama dengan MPC, tiga pertanyaan kunci yang harus diajukan adalah:

1. Seberapa kuat jaminan privasi yang dapat disediakan protokol MPC di blockchain?
2. Apakah teknologi sudah cukup matang? Jika belum, apa hambatannya?
3. Dengan kekuatan jaminan dan biaya tambahan yang diperkenalkannya, apakah ini masuk akal dibandingkan dengan pendekatan alternatif?

Mari kita bahas pertanyaan-pertanyaan ini lebih detail.

Menganalisis Risiko dan Kelemahan dengan MPC

Setiap kali sebuah solusi menggunakan FHE, seseorang selalu perlu bertanya: “Siapa yang memegang kunci dekripsi?”. Jika jawabannya adalah “jaringan”, pertanyaan lanjutan adalah: “Entitas nyata mana yang membentuk jaringan ini?”. Pertanyaan terakhir ini relevan untuk semua kasus penggunaan yang bergantung pada MPC dalam satu bentuk atau lainnya.

Sumber: Percakapan Zama di ETH CC

Risiko utama dengan MPC adalah kolusi, yaitu cukup banyak pihak yang bertindak dengan jahat dan bersekongkol untuk mendekripsi data atau menyalahgunakan komputasi. Kolusi dapat disepakati di luar rantai dan hanya terungkap jika pihak-pihak jahat melakukan sesuatu sehingga menjadi jelas (memeras, mencetak token dari udara, dll). Tidak perlu dikatakan, ini memiliki implikasi signifikan bagi jaminan privasi yang dapat disediakan oleh sistem. Risiko kolusi bergantung pada:

• Berapa ambang pihak jahat yang dapat ditahan oleh protokol?
• Pihak-pihak mana yang membentuk jaringan dan seberapa dapat dipercaya mereka?
• Jumlah pihak yang berbeda yang berpartisipasi dalam jaringan dan distribusi mereka - Apakah ada vektor serangan umum?
• Apakah jaringannya bersifat tanpa izin atau berizin (berdasarkan kepemilikan ekonomi vs reputasi/hukum)?
• Apa hukuman untuk perilaku jahat? Apakah berkolusi permainan secara teoritis hasil yang optimal?

1. Seberapa kuat jaminan privasi yang dapat diberikan oleh protokol MPC dalam blockchain?

TLDR: Tidak sekuat yang kami inginkan, namun lebih kuat daripada hanya bergantung pada satu pihak ketiga terpusat.

Ambang batas yang diperlukan untuk mendekripsi tergantung pada skema MPC yang dipilih - sebagian besar adalah pengorbanan antara liveness ('pengiriman output yang dijamin') dan keamanan. Anda dapat memiliki skema N/N yang sangat aman tetapi akan berhenti berfungsi jika hanya satu node yang offline. Di sisi lain, skema N/2 atau N/3 lebih tangguh tetapi memiliki risiko kolusi yang lebih tinggi.

Kedua kondisi yang harus seimbang adalah:

1. Informasi rahasia tidak pernah bocor (mis. kunci dekripsi)
2. Informasi rahasia tidak pernah hilang (bahkan jika 1/3 dari pihak-pihak tiba-tiba pergi).

Skema yang dipilih bervariasi antara implementasi. Misalnya, Zama sedang mengincar N/3, sedangkan Arcium saat ini sedang mengimplementasikan sebuah skema N/Ntetapi kemudian bertujuan untuk juga mendukung skema dengan jaminan kehidupan yang lebih tinggi (dan asumsi kepercayaan yang lebih besar).

Salah satu kompromi di sepanjang garis batas ini akan menjadi solusi campuran:

• Komite yang sangat terpercaya yang menangani pengelolaan kunci dengan ambang batas N/3, misalnya.
• Komite komputasi yang bersifat rotasional dan memiliki misalnya ambang batas N-1 (atau beberapa komite komputasi yang berbeda dengan karakteristik yang berbeda untuk pengguna memilih).

Meskipun ini menarik dalam teori, hal ini juga memperkenalkan kompleksitas tambahan seperti bagaimana komite komputasi akan berinteraksi dengan komite kepercayaan tinggi.

Salah satu cara untuk memperkuat jaminan keamanan adalah menjalankan MPC dalam perangkat keras terpercaya sehingga bagian kunci tetap berada di dalam enclave yang aman. Hal ini membuat lebih sulit untuk mengekstrak atau menggunakan bagian kunci untuk hal lain selain yang ditentukan oleh protokol. Setidaknya ZamadanArciumsedang mengeksplorasi sudut TEE.

Risiko yang lebih rumit meliputi kasus-kasus tepi seputar hal-hal seperti rekayasa sosial, di mana misalnya seorang insinyur senior dipekerjakan oleh semua perusahaan yang termasuk dalam klaster MPC selama 10-15 tahun.

2. Apakah teknologinya sudah cukup matang? Jika belum, apa saja hambatannya?

Dalam hal kinerja, tantangan utama dengan MPC adalah biaya komunikasi. Biayanya akan semakin besar seiring dengan kompleksitas perhitungan dan jumlah node yang terlibat dalam jaringan (membutuhkan komunikasi bolak-balik yang lebih banyak). Dalam kasus penggunaan blockchain, ini menghasilkan dua implikasi praktis:

1. Set operator kecil: Agar overhead komunikasi tetap dapat dikelola, sebagian besar protokol yang ada saat ini dibatasi untuk set operator kecil. Misalnya, jaringan dekripsi Zama saat ini memungkinkan maksimal 4 node (meskipun mereka berencana untuk memperluas ke 16). Berdasarkan tolok ukur awal yang diterbitkan oleh Zama untuk jaringan dekripsi mereka (TKMS), dibutuhkan 0,5-1 detik untuk mendekripsi bahkan hanya dengan cluster 4-node (aliran e2e penuh membutuhkan waktu lebih lama). Contoh lain adalah Taceo Implementasi MPC untuk database iris Worldcoin, yang memiliki 3 pihak (dengan asumsi 2/3 pihak yang jujur).

1. Sumber: Pembicaraan Zama di ETH CC
2. Set operator yang diizinkan: Dalam kebanyakan kasus, set operator diizinkan. Ini berarti kita mengandalkan reputasi dan kontrak hukum daripada keamanan ekonomi atau kriptografi. Tantangan utama dengan set operator tanpa izin adalah bahwa tidak ada cara untuk mengetahui jika orang-orang berkolusi di luar jaringan. Selain itu, ini akan memerlukan bootstrapping atau redistribusi reguler dari bagian kunci agar node dapat masuk/keluar jaringan secara dinamis. Sementara set operator tanpa izin adalah tujuan akhir dan terus ada penelitian tentang cara memperluas mekanisme PoS untuk MPC ambang (misalnya oleh Zama), jalur yang diizinkan tampaknya menjadi cara terbaik untuk saat ini.

Pendekatan Alternatif

Koktail privasi lengkap terdiri dari:

• FHE untuk komputasi pribadi yang didelegasikan
• ZKP untuk verifikasi bahwa perhitungan FHE dijalankan dengan benar
• MPC untuk dekripsi ambang
• Setiap node MPC berjalan dalam TEE untuk keamanan tambahan

Ini sangat kompleks, memperkenalkan banyak kasus ujung yang belum dijelajahi, memiliki overhead yang tinggi, dan mungkin tidak praktis dilakukan selama bertahun-tahun ke depan. Risiko lain adalah rasa aman yang salah yang mungkin didapatkan seseorang dari penambahan konsep yang kompleks di atas konsep lainnya. Semakin kompleksitas dan asumsi kepercayaan yang kita tambahkan, semakin sulit untuk merenungkan tentang keamanan solusi secara keseluruhan.

Apakah itu layak? Mungkin, tetapi juga layak untuk menjelajahi pendekatan alternatif yang mungkin dapat memberikan efisiensi komputasi yang jauh lebih baik dengan mengorbankan jaminan privasi yang sedikit lebih lemah.Lyron dari Seismiccatatan - kita harus fokus pada solusi paling sederhana yang memenuhi kriteria kami untuk tingkat privasi yang diperlukan dan pertukaran yang dapat diterima, daripada berlebihan dalam teknik hanya demi itu.

1. Menggunakan MPC Langsung untuk Komputasi Umum

Jika baik ZK dan FHE pada akhirnya kembali ke asumsi kepercayaan MPC, mengapa tidak langsung menggunakan MPC untuk komputasi? Ini adalah pertanyaan yang valid dan sesuatu yang tim seperti Arcium, SodaLabs (digunakan oleh Cotiv2),Taceo, dan NillionMengenai apa yang sedang Anda coba lakukan. Perhatikan bahwa MPC memiliki banyak bentuk, tetapi dari tiga pendekatan utama, kami di sini mengacu pada pembagian rahasia dan protokol berbasis sirkuit tersembunyi (GC), bukan protokol berbasis FHE yang menggunakan MPC untuk dekripsi.

Sementara MPC sudah digunakan untuk komputasi sederhana seperti tanda tangan terdistribusi dan dompet yang lebih aman, tantangan utama dalam menggunakan MPC untuk komputasi yang lebih umum adalah overhead komunikasi (bertambah seiring kompleksitas komputasi dan jumlah node yang terlibat).

Ada beberapa cara untuk mengurangi overhead, seperti dengan melakukan pra-pemrosesan (yaitu bagian paling mahal dari protokol) sebelumnya dan offline - sesuatu yang dilakukan baik oleh Gate.io MPC.ArciumdanSodaLabssedang menjelajahi. Komputasi kemudian dieksekusi pada fase online, yang mengonsumsi sebagian dari data yang dihasilkan pada fase offline. Hal ini secara signifikan mengurangi biaya komunikasi secara keseluruhan.

Tabel di bawah ini oleh SodaLabs menunjukkan tolok ukur awal tentang berapa lama waktu yang dibutuhkan untuk mengeksekusi opcode yang berbeda 1.000 kali dalam gcEVM mereka (dicatat dalam mikrodetik). Meskipun ini adalah langkah ke arah yang benar, masih banyak pekerjaan yang harus dilakukan untuk meningkatkan efisiensi dan memperluas set operator di luar beberapa node.

Sumber: SodaLabs

Manfaat dari pendekatan berbasis ZK adalah Anda hanya menggunakan MPC untuk kasus penggunaan yang memerlukan komputasi pada keadaan pribadi bersama. FHE bersaing lebih langsung dengan MPC dan sangat bergantung pada akselerasi hardware.

2. Lingkungan Eksekusi Terpercaya

Baru-baru ini, minat terhadap TEE telah bangkit kembali, yang dapat dimanfaatkan baik secara terpisah (blockchain pribadi berbasis TEE atau co-prosesor) maupun dalam kombinasi dengan PET lain seperti solusi berbasis ZK (hanya menggunakan TEE untuk komputasi atas status pribadi bersama).

Meskipun TEE dalam beberapa hal lebih matang dan mengurangi overhead kinerja, tetapi tidak tanpa kekurangan. Pertama, TEE memiliki asumsi kepercayaan yang berbeda (1/N) dan menawarkan solusi berbasis hardware daripada software. Kritik yang sering terdengar adalah seputar masa lalu.kerentanan SGX, tetapi perlu dicatat bahwa TEE ≠ Intel SGX. TEE juga memerlukan kepercayaan terhadap penyedia perangkat keras dan perangkat keras tersebut mahal (tidak dapat diakses oleh kebanyakan orang). Salah satu solusi untuk mengurangi risiko serangan fisik bisa jadi adalah untuk jalankan TEE di luar angkasauntuk hal-hal yang krusial.

Secara keseluruhan, TEE tampak lebih cocok untuk kasus pengesahan atau penggunaan yang hanya membutuhkan privasi jangka pendek (dekrpsi ambang, buku pesanan gelap, dll). Untuk privasi permanen atau jangka panjang, jaminan keamanannya tampak kurang menarik.

3. DAC Pribadi dan pendekatan lain yang mengandalkan pihak ketiga terpercaya untuk privasi

Privasi yang diintermediasi dapat menawarkan privasi dari pengguna lain, tetapi jaminan privasi hanya datang dari kepercayaan pada pihak ketiga (titik kegagalan tunggal). Meskipun menyerupai "privasi web2" (privasi dari pengguna lain), ini dapat diperkuat dengan jaminan tambahan (kriptografis atau ekonomi) dan memungkinkan verifikasi pelaksanaan yang benar.

Komite ketersediaan data pribadi (DAC) adalah salah satu contoh ini; Anggota DAC menyimpan data di luar rantai dan pengguna percaya kepada mereka untuk menyimpan data dengan benar dan menerapkan pembaruan transisi status. Varian lain dari ini adalah Sequencer Francaisdiproposalkan oleh Tom Walpo.

Sementara pendekatan ini membuat pengorbanan besar dalam jaminan privasi, ini mungkin merupakan satu-satunya alternatif yang feasible untuk aplikasi dengan nilai rendah namun performa tinggi dalam hal biaya dan performa (setidaknya untuk saat ini). Sebagai contoh adalah Protokol Lens, yang berencana menggunakan DAC pribadi untuk mendapatkan feed pribadi. Untuk kasus penggunaan seperti sosial on-chain, tradeoff antara privasi dan biaya / kinerja mungkin masuk akal untuk saat ini (mengingat biaya dan overhead alternatif).

4. Alamat Rahasia

Alamat sembunyi dapat memberikan jaminan privasi yang sama seperti membuat alamat baru untuk setiap transaksi, tetapi prosesnya diotomatisasi di belakang layar dan diabstraksikan dari pengguna. Untuk informasi lebih lanjut, lihat iniikhtisar oleh Vitalikatau inipenelitian mendalam tentang pendekatan yang berbeda. Pemain utama dalam bidang ini termasuk PayungdanFluidkey.

Sementara alamat siluman menawarkan solusi yang relatif sederhana, kelemahan utamanya adalah mereka hanya dapat menambahkan jaminan privasi untuk transaksi (pembayaran dan transfer), bukan perhitungan tujuan umum. Ini membedakan mereka dari tiga solusi lain yang disebutkan di atas.

Selain itu, jaminan privasi yang diberikan oleh alamat tersembunyi tidak sekuat alternatif lainnya. Anonimitas dapat dilanggar dengan analisis pengelompokan sederhana, terutama jika transfer masuk dan keluar tidak dalam kisaran yang sama (misalnya menerima $10.000, tetapi menghabiskan rata-rata $10-100 untuk transaksi sehari-hari). Tantangan lain dengan alamat rahasia adalah meningkatkan kunci, yang saat ini perlu dilakukan secara individual untuk setiap dompet (rollup penyimpanan kunci bisa membantu mengatasi masalah ini). Dari sisi UX, protokol alamat rahasia juga membutuhkan abstraksi akun atau paymaster untuk menutupi biaya jika akun tidak memiliki token biaya (misalnya ETH).

Risiko Terhadap Tesis Kami

Dengan laju perkembangan yang cepat dan ketidakpastian umum seputar solusi teknis yang berbeda, ada beberapa risiko terhadap teori kami bahwa MPC akan menjadi akhir permainan. Alasan utama mengapa kita mungkin tidak membutuhkan MPC dalam bentuk apapun termasuk:

1. Status privasi bersama tidak sepenting yang kita pikirkan: Dalam kasus ini, infrastruktur berbasis ZK lebih mungkin untuk menang karena memiliki jaminan privasi yang lebih kuat dan biaya yang lebih rendah dibandingkan dengan FHE. Sudah ada kasus penggunaan di mana sistem berbasis ZK berfungsi dengan baik untuk kasus penggunaan terisolasi, seperti protokol pembayaran pribadiPayy.
2. Tradeoff dalam kinerja tidak sebanding dengan manfaat dalam jaminan privasi: Orang dapat berargumen bahwa asumsi kepercayaan dari jaringan MPC dengan 2-3 pihak yang diizinkan tidak jauh berbeda dari satu pemain terpusat dan bahwa peningkatan biaya / overhead yang signifikan tidak sepadan. Ini mungkin berlaku untuk banyak aplikasi, terutama yang bernilai rendah dan sensitif terhadap biaya (misalnya sosial atau game). Namun, ada juga banyak kasus penggunaan bernilai tinggi di mana kolaborasi saat ini sangat mahal (atau tidak mungkin) karena masalah hukum atau gesekan koordinasi yang besar. Yang terakhir adalah tempat solusi berbasis MPC dan FHE dapat bersinar.
3. Spesialisasi mengalahkan desain serba guna: Membangun rantai baru dan memulai komunitas pengguna dan pengembang adalah hal yang sulit. Oleh karena itu, infrastruktur privasi serba guna (L1/L2s) mungkin kesulitan untuk mendapatkan perhatian. Pertanyaan lainnya menyangkut spesialisasi; sangat sulit bagi desain protokol tunggal untuk mencakup seluruh ruang pertukaran. Di dunia ini, solusi yang menyediakan privasi untuk ekosistem yang sudah ada (kerahasiaan sebagai layanan) atau kasus penggunaan khusus (misalnya untuk pembayaran) akan mendominasi. Namun, kami skeptis tentang yang terakhir karena kompleksitas yang diperkenalkannya kepada pengembang aplikasi yang perlu mengimplementasikan beberapa kriptografi sendiri (daripada diabstraksikan).
4. Regulasi terus menghambat eksperimen seputar solusi privasi: Ini merupakan risiko bagi siapa pun yang membangun infrastruktur privasi dan aplikasi dengan beberapa jaminan privasi. Kasus penggunaan non-keuangan menghadapi risiko regulasi yang lebih rendah, tetapi sulit (bahkan tidak mungkin) untuk mengendalikan apa yang dibangun di atas infrastruktur privasi yang tanpa izin. Kita mungkin saja berhasil menyelesaikan masalah teknis sebelum masalah regulasi.
5. Overhead dari skema MPC dan FHE masih terlalu tinggi untuk sebagian besar kasus penggunaan: Sementara MPC lebih banyak menderita dari overhead komunikasi, tim FHE sangat mengandalkan akselerasi perangkat keras untuk meningkatkan performa mereka. Namun, jika kita dapat menggambarkan perkembangan perangkat keras khusus di sisi ZK, dibutuhkan waktu yang lebih lama daripada yang sebagian besar orang inginkan sebelum kita mendapatkan perangkat keras FHE yang siap untuk produksi. Contoh dari tim yang bekerja pada akselerasi perangkat keras FHE termasuk Optalysys, fheladan Niobium.

Ringkasan

Pada akhirnya, sebuah rantai hanya sekuat mata rantainya yang paling lemah. Dalam kasus infrastruktur privasi yang dapat diprogram, jaminan kepercayaan berakhir pada MPC jika kita menginginkannya mampu menangani status pribadi bersama tanpa titik kegagalan tunggal.

Meskipun bagian ini mungkin terdengar kritis terhadap MPC, sebenarnya tidak begitu. MPC menawarkan peningkatan besar terhadap status quo saat ini yang mengandalkan pihak ketiga terpusat. Masalah utama, menurut pandangan kami, adalah rasa percaya diri yang salah di seluruh industri dan masalah yang diabaikan. Sebaliknya, kita harus menghadapi masalah secara langsung dan fokus pada evaluasi potensi risiko.

Namun, tidak semua masalah perlu diselesaikan menggunakan alat yang sama. Meskipun kami percaya bahwa MPC adalah tujuan akhir, pendekatan alternatif adalah pilihan yang layak selama biaya overhead untuk solusi yang didukung oleh MPC tetap tinggi. Selalu layak untuk mempertimbangkan pendekatan mana yang paling cocok dengan kebutuhan/karakteristik khusus dari masalah yang kita coba selesaikan dan kompromi apa yang kita bersedia buat.

Bahkan jika Anda memiliki palu terbaik di dunia, tidak semuanya paku.

Lampiran 1: Pendekatan Berbeda Untuk Privasi Di Blockchain

Teknologi peningkatan privasi, atau PET, bertujuan untuk meningkatkan satu atau lebih aspek di atas. Lebih konkret, mereka adalah solusi teknis untuk melindungi data selama penyimpanan, komputasi, dan komunikasi.

Ada banyak PET yang berbeda untuk dipilih, tetapi yang paling relevan untuk industri blockchain termasuk sup tiga huruf - ZKP, MPC, FHE, dan TEE - bersama dengan metode tambahan seperti alamat siluman:

PET ini dapat digabungkan dalam berbagai cara untuk mencapai tradeoff dan asumsi kepercayaan yang berbeda. Kami juga memiliki solusi yang mengandalkan pihak ketiga yang terpercaya (privasi yang diintermediasi), seperti komite ketersediaan data pribadi (DAC). Ini dapat mengaktifkan privasi dari pengguna lain, tetapi jaminan privasi datang semata-mata dari kepercayaan pada pihak ketiga. Dalam hal ini, ini menyerupai "privasi web2" (privasi dari pengguna lain), tetapi dapat diperkuat dengan jaminan tambahan (kriptografi atau ekonomi).

Secara total, kami telah mengidentifikasi 11 pendekatan yang berbeda untuk mencapai beberapa jaminan privasi dalam jaringan blockchain. Beberapa tradeoff yang diamati termasuk:

• Kepercayaan vs privasi yang minimalkan kepercayaan (Apakah ada satu titik kegagalan? )
• Pendekatan Perangkat Keras vs Perangkat Lunak
• Instansi terisolasi vs kombinasi beberapa PET
• L1 vs L2
• Rantai baru vs Privasi tambahan untuk rantai yang sudah ada ("kerahasiaan sebagai layanan")
• Ukuran set terlindung (Multi-chain > Single-chain > Application > Single asset)

Lampiran 2: Ikhtisar Industri

Dalam 11 kategori ini, banyak perusahaan yang berbeda sedang mengerjakan satu atau lebih solusi. Di bawah ini adalah ikhtisar (tidak lengkap) tentang keadaan industri saat ini:

Penyangkalan:

1. Artikel ini dicetak ulang dari [keseimbangan], Semua hak cipta adalah milik penulis asli [Hannes Huitula]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang terdapat dalam artikel ini sepenuhnya merupakan pandangan penulis dan tidak merupakan nasihat investasi apa pun.
3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.