Beberapa bulan yang lalu, tim kripto di a16z menerbitkan Tantangan Nakamoto, daftar masalah paling penting untuk dipecahkan di blockchain. Yang keempat secara khusus menarik perhatian kami: "Compliant Programmable Privacy", karena kami telah secara aktif memikirkan hal ini selama beberapa waktu. Hari ini, kami mengusulkan solusi pertama menggunakan enkripsi homomorfik dan protokol kontrak pintar rahasia fhEVM kami (jika Anda tidak terbiasa dengan fhEVM, Anda dapat membaca artikel kami tentang rahasia token ERC20danlelang buta.

fhEVM adalah EVM biasa dengan beberapa precompile yang memungkinkan komputasi pada status terenkripsi menggunakan perpustakaan enkripsi homomorfik TFHE-rs kami. Dari sudut pandang pengembang, tidak ada kriptografi yang terlibat: mereka hanya menulis kode Solidity menggunakan jenis data terenkripsi yang kami sediakan (euint32, ebool, dll). Salah satu keuntungan besar fhEVM dibandingkan dengan solusi privasi lainnya adalah bahwa semua data dan komputasi terjadi onchain. Ini berarti Anda dapat memiliki tingkat komposabilitas dan ketersediaan data yang sama seperti kontrak reguler, teks polos.

Properti ini adalah kunci untuk membangun privasi yang dapat diprogram, karena semua logika kontrol akses dapat ditentukan dalam kontrak itu sendiri. Tidak ada yang perlu dimasukkan secara kaku ke dalam protokol, dan tidak ada yang harus dilakukan pengguna di luar rantai untuk patuh. Aplikasi dapat menegakkan kepatuhan secara langsung, hanya dengan beberapa baris kode Solidity!

Dalam artikel ini, kami akan menunjukkan cara membangun token ERC20 yang patuh, menggunakan DIDs onchain. Kode sumber untuk tutorial ini dapat ditemukan di folder contoh dari repositori fhEVM.

Abstraksi identitas melalui DIDs yang rahasia di onchain

Pengenal Terdesentralisasi (DID) adalah identitas digital unik yang dikeluarkan oleh entitas seperti pemerintah, pendaftar, perusahaan, atau pengguna itu sendiri. DID ini dapat dikaitkan dengan kunci kriptografi yang membuktikan pengguna memiliki DID, seperti dompet EVM. Tetapi juga dapat menyimpan sejumlah besar atribut, seperti usia pengguna, kebangsaan, nomor jaminan sosial, dll. Atribut-atribut ini pada gilirannya kemudian dapat digunakan untuk membuktikan bahwa Anda memenuhi beberapa kondisi (disebut "pengesahan"), seperti berusia di atas 18 tahun atau tidak menjadi warga negara Narnia.

Sebagian besar DIDs diimplementasikan oleh klien, dan menggunakan bukti pengetahuan nol untuk menghasilkan pernyataan. Meskipun hal ini baik dalam banyak kasus, namun menjadi rumit dengan cepat ketika Anda memiliki banyak pengguna yang terlibat dalam transaksi, ketika Anda harus menerapkan aturan kompleks pada DID, atau ketika Anda perlu mempertahankan seperangkat aturan umum untuk semua orang mengikuti. Ini pada dasarnya adalah tradeoff yang sama seperti dalam aplikasi edge vs cloud.

Namun, memiliki registri DID terpusat akan menyelesaikan masalah ini, karena Anda dapat meminta registri untuk memeriksa apakah semua orang patuh. Ini juga akan membuatnya lebih mudah untuk melacak peraturan, karena Anda hanya perlu menerapkannya di satu tempat. Blockchain akan menjadi infrastruktur yang sempurna untuk ini, karena akan memungkinkan komposabilitas antara DID dan aplikasi yang memerlukan kepatuhan, serta komposabilitas antara peraturan itu sendiri.

Masalah: semua orang akan melihat identitas semua orang!

Untungnya, kita memiliki solusi: enkripsi homomorfik, dan lebih khusus lagi fhEVM! Berkat kemampuan untuk memiliki komposabilitas pada status terenkripsi, kita dapat menyimpan DIDs pengguna langsung di rantai dalam bentuk terenkripsi, dan memiliki aplikasi yang patuh memverifikasi atribut menggunakan panggilan kontrak sederhana. Kemampuan untuk mengelola identitas melalui kontrak pintar, yang kita sebut 'Abstraksi Identitas', mirip dengan bagaimana seseorang dapat mengelola dana melalui kontrak pintar dengan Abstraksi Akun.

Tutorial ini terdiri dari 3 bagian:

• Abstraksi Identitas dilakukan melalui kontrak registri yang bertanggung jawab atas pengelolaan identitas dan tanda pengesahan. Di sini kita mengasumsikan bahwa DIDs adalah ID resmi pemerintah. Registri itu sendiri dikelola oleh otoritas pusat (misalnya AFNIC) yang dapat membuat registrar (misalnya perusahaan KYC seperti Onfido, Jumio, dll.) yang kemudian dapat membuat DIDs pengguna. Pengguna kemudian melalui registrar mereka untuk mengelola dan memperbarui DIDs mereka.
• Regulasi didefinisikan dalam sebuah kontrak yang mengkodekan serangkaian aturan untuk transfer token antara individu, berdasarkan informasi yang terkandung dalam DIDs mereka. Ini pada dasarnya menegakkan regulasi pada tingkat kontrak daripada tingkat pengguna.
• Transfer Kepercayaan yang Patuh diimplementasikan dalam kontrak ERC20 yang patuh yang menggunakan kontrak regulasi untuk menegakkan kepatuhan dalam transfer token, tanpa perubahan apa pun pada API ERC20 itu sendiri. Dalam contoh ini, kami menggunakan kontrak ERC20 yang rahasia, di mana saldo dan jumlahnya tersembunyi, tetapi akan berfungsi sama baiknya dengan token ERC20 reguler, teks polos.

Arsitektur Protokol DID Rahasia Onchain Kami

Kontrak registri identitas

Kontrak IdentityRegistry adalah register DID pengguna yang diterbitkan oleh registrar dan mencakup seperangkat pengidentifikasi terenkripsi, seperti kewarganegaraan, usia, nomor kartu identitas, dll. Pengidentifikasi ini disimpan sebagai nilai 32 bit terenkripsi (euint32).

Kontrak juga menangani izin, seperti:

• Memungkinkan pemilik kontrak (misalnya AFNIC) untuk menambahkan, menghapus, atau memperbarui registrar.
• Mengaktifkan registrar untuk menambahkan, menghapus, atau memperbarui DIDs pengguna yang mereka buat.
• Mengizinkan pengguna memberikan akses kontrak pintar ke atribut-atribut spesifik dari DIDs mereka. Penting untuk dicatat di sini bahwa pengguna bertanggung jawab untuk tidak memberikan akses kepada kontrak jahat, sama seperti mereka bertanggung jawab untuk tidak membiarkan kontrak jahat menghabiskan token mereka.

Sebagai langkah pertama, mari kita implementasikan logika untuk membuat dan mengelola DIDs:

Sekarang langkah berikutnya adalah mengimplementasikan logika untuk pengidentifikasi dan kontrol akses.

Pengenal hanyalah string (misalnya "tanggal lahir") dan nilai 32 bit terenkripsi. Itu dapat dibuat atau diperbarui hanya oleh registrar. Pengguna tidak dapat membuat ID mereka sendiri, karena kami ingin mereka disertifikasi oleh registrar.

Karena pengidentifikasi terenkripsi, pengguna perlu memberikan izin kepada kontrak untuk mengakses nilai-nilai tertentu, yang akan kami atasi melalui mekanisme kontrol akses sederhana yang mirip dengan cara Anda dapat mengizinkan kontrak untuk menghabiskan token ERC20 Anda.

kontrak IdentityRegistry adalah EIP712WithModifier, Ownable

Sekarang kita dapat menyelesaikan kontrak registri identitas kami dengan menambahkan getter yang diperlukan, dengan beberapa kondisi dan penanganan kesalahan.

kontrak IdentityRegistry adalah EIP712WithModifier, Ownable

Kontrak regulasi

Langkah selanjutnya adalah membuat kontrak regulasi kita.

Ketika mengimplementasikan seperangkat aturan untuk transfer antara dua individu, penting untuk menyadari bahwa aturan-aturan ini dapat berkembang seiring waktu. Memiliki kontrak pintar tunggal yang menentukan semua regulasi untuk konteks tertentu seperti transfer uang berarti bahwa kontrak ERC20 tidak perlu melacak regulasi itu sendiri. Pemerintah dapat dengan mudah memperbarui kontrak ini, dan secara otomatis akan menyebar ke semua token yang mengimplementasikannya.

Pada intinya, kontrak regulasi hanyalah sekumpulan kondisi yang dicocokkan dengan atribut identitas yang dienkripsi. Untuk menghindari penyalahgunaan, pengguna tidak akan langsung memberikan akses ke kontrak regulasi, tetapi lebih memilih memberikan akses ke kontrak token ERC20, yang kemudian melakukan panggilan delegasi ke kontrak regulasi. Pendekatan ini memastikan bahwa hanya kontrak ERC20, yang dipercayai oleh pengguna, yang dapat mengakses informasi mereka. Ingatlah bahwa baik pengirim maupun penerima harus memberikan izin kepada kontrak ERC20 sebelum transfer dapat terjadi di antara mereka.

Pada contoh ini, kami akan menerapkan beberapa aturan dasar:

• Transfer dalam negeri tidak terbatas, tetapi transfer ke luar negeri dibatasi hingga 10.000 token.
• Pengguna yang masuk daftar hitam tidak dapat mentransfer atau menerima token.
• Pengguna tidak dapat mentransfer token ke negara yang masuk daftar hitam.

Daripada kegagalan transaksi, yang dapat mengungkap informasi sensitif, kami akan hanya menetapkan jumlah transfer ke 0 jika salah satu kondisi tidak terpenuhi. Ini menggunakan operator ternary homomorfik yang disebut cmux: nilai = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse

Kontrak ERC20 rahasia yang patuh

Sekarang bahwa kami memiliki register identitas dan kontrak regulasi, kami akhirnya dapat membuat kontrak token yang patuh dan menjaga privasi. Kontrak ini akan disebut CompliantERC20 dan memiliki fitur kunci berikut:

• Saldo pengguna dan jumlah transfer dienkripsi.
• Kepatuhan ditegakkan dalam transfer dengan memanggil kontrak regulasi.
• Visibilitas saldo tertentu dapat diberikan kepada alamat yang masuk daftar putih (misalnya regulator)

Kontrak regulasi dipanggil melalui panggilan sederhana. Ini berarti bahwa pengguna harus memberikan akses ke kontrak ERC20 sebelum memulai transfer apa pun; jika tidak, transfer akan dikembalikan.

Akhirnya, sekarang kita dapat membuat kontrak ERC20 kita:

Sama seperti pengguna memberikan izin kepada protokol DeFi untuk menghabiskan token mereka, mereka akan perlu memberikan izin kepada kontrak untuk mengakses pengenal yang diperlukan oleh kontrak regulasi. Ini dilakukan melalui panggilan ke Identity.grantAccess(contractAddress, pengenal), yang dapat diambil dengan memanggil metode tampilan ERC20.identifiers(). Daftar ini berasal langsung dari kontrak ERC20Rules untuk memungkinkan pembaruan properti.

Kepatuhan dan privasi dapat hidup berdampingan!

Semoga tutorial ini telah menunjukkan kepada Anda bahwa kepatuhan bukanlah hal yang sulit untuk dibangun jika alat-alat yang tepat tersedia. Ketika awalnya kami membangun fhEVM untuk memungkinkan privasi dalam blockchain, kami dengan cepat menyadari bahwa teknologi ini dapat digunakan untuk manajemen identitas dan dengan demikian kepatuhan yang dapat diprogram.

Rancangan yang diusulkandi sinijauh dari sempurna, tetapi kami percaya itu dapat dengan mudah ditingkatkan dan diluncurkan sebagai kasus penggunaan dunia nyata, sehingga kepatuhan tidak lagi harus menjadi sinonim dari surveilans!

Tautan tambahan

• Bintang Repositori Github fhEVM Zamauntuk mendukung pekerjaan kami.
• Review Dokumentasi fhEVM Zama.
• Dapatkan dukungan pada saluran komunitas.
• Bantu memajukan ruang FHE dengan Program Hadiah Zama: Membuat permainan on-chain yang menjaga keadaan privat tetap tersembunyi menggunakan privasi yang dapat diprogram fhEVM Zama (15.000€ dalam hadiah).

Disclaimer：

1. Artikel ini dicetak ulang dari [zama]. Semua hak cipta milik penulis asli [fhEVM]. Jika ada keberatan terhadap pencetakan ulang ini, silakan hubungi Belajar Gatetim, dan mereka akan menanganinya dengan cepat.
2. Penafian Tanggung Jawab: Pandangan dan opini yang diungkapkan dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.