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.
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:
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 kunci membentuk pandangan kami tentang bagaimana kami percaya infrastruktur privasi dalam blockchain dapat berkembang:
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:
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:
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:
Mari kita bahas pertanyaan-pertanyaan ini lebih detail.
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:
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:
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:
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.
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:
Koktail privasi lengkap terdiri dari:
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.
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.
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.
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).
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).
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:
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.
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:
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:
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.
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:
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 kunci membentuk pandangan kami tentang bagaimana kami percaya infrastruktur privasi dalam blockchain dapat berkembang:
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:
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:
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:
Mari kita bahas pertanyaan-pertanyaan ini lebih detail.
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:
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:
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:
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.
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:
Koktail privasi lengkap terdiri dari:
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.
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.
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.
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).
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).
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:
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.
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:
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: