Pengantar

Titik sakit utama bagi pengguna kripto web3 adalah kurangnya privasi. Fakta bahwa semua transaksi terlihat di buku besar publik, dan semakin: terkait dengan satu nama ENS yang dapat dibaca, merupakan disinsentif bagi pengguna untuk melakukan aktivitas tertentu, atau menyebabkan mereka melakukan aktivitas tersebut dengan cara yang menghasilkan peningkatan gesekan UX. Salah satu contohnya adalah hanya mentransfer dana dari dompet panas ke dompet dingin atau sebaliknya. Pengguna mungkin tidak ingin memiliki satu dompet yang terhubung ke yang lain, karena mereka mungkin tidak ingin saldo dompet dingin mereka terlihat. Saat ini, alamat Ethereum tidak berfungsi seperti rekening bank pribadi, karena semua orang dapat melihat dompet Anda, dan semakin, aktivitas sosial Anda (SBT, pengesahan, aktivitas di berbagai dapps, dll.). Karena alasan inilah Vitalik menyebut privasi sebagai salah satu tiga transisi teknis utamabahwa Ethereum perlu mengalami agar bermanfaat bagi pengguna rata-rata.

Menggunakan solusi privasi yang sudah ada, seperti Tornado Cash, adalah pengalaman yang agak kurang optimal karena beberapa alasan. Pertama, pengguna dengan alasan yang benar akan khawatir tentang alamat mereka yang dimasukkan dalam daftar hitam di bursa terpusat atau platform lainnya. Kedua, pengalaman pengguna dalam berinteraksi dengan layanan seperti Tornado Cash tidak begitu ramah pengguna dan sebenarnya hanya cocok untuk pengguna yang sangat mahir.

Alamat tersembunyi memberikan cara untuk memberikan pengguna privasi yang mereka anggap sebagai kebiasaan dengan akun bank pribadi, dan dengan cara yang mudah dipahami. Selain itu, inovasi seputar alamat tersembunyi berarti bahwa kita berpotensi dapat melakukannya dengan cara yang tetap mematuhi peraturan AML di berbagai yurisdiksi.

Permintaan Pengguna untuk Privasi

Sementara penelitian mengenai sikap terhadap privasi di antara pengguna web dan web3 tidak banyak tersedia, penelitian di bawah ini ditemukan melalui pencarian di seluruh web, dan hasilnya secara umum sejalan, dan menunjukkan bahwa ada minat yang jelas terhadap privasi transaksi.

1. Sebuah survei yang dilakukan pada tahun 2022 dan diterbitkan oleh Simin Ghesmati dkk. dalam sebuah makalah berjudul: Privasi yang dirasakan pengguna dalam blockchain, menyatakan bahwa "setengah dari orang yang diwawancarai menentukan bahwa privasi transaksi sangat penting bagi mereka". Meskipun penelitian ini lebih terkait dengan Bitcoin daripada Ethereum, kemungkinan ada sikap serupa dengan pengguna Ethereum juga. Ukuran sampel untuk penelitian ini cukup kecil (14 peserta).
2. Sebuah potongan penelitian menarik lainnya dari tahun 2022, diterbitkan di Frontiers, berjudul Sikap politik, ekonomi, dan tata kelola pengguna blockchain, lebih komprehensif, dengan 3.710 pengguna kripto yang disurvei. Hasilnya menunjukkan bahwa sekitar seperempat responden mengindikasikan bahwa privasi adalah “fitur paling penting dari blockchain dan kripto”.

1. Dalam hal sikap terhadap privasi secara umum, Consensysmenerbitkan penelitian berjudulSurvei global Web3 dan kripto tahun 2023, di mana mereka melakukan survei online terhadap 15.158 orang di 15 negara tentang berbagai topik yang berkaitan dengan web, bukan hanya kripto. Survei menemukan bahwa 83% responden menganggap privasi data penting, sementara hanya 45% responden yang menyatakan bahwa mereka percaya bagaimana layanan Internet saat ini menggunakan data dan informasi pribadi mereka.
2. Sebuah survei yang dilakukan oleh Skema Kompensasi Layanan Keuangan Inggris, yang diterbitkan pada April 2023 menyoroti bahwa 9% dari responden menyebutkan 'keinginan akan anonimitas/privasi' sebagai alasan mereka untuk berinvestasi dalam cryptocurrency.

Adopsi Protokol Transaksi Stealth

Railgunmemiliki angka yang mengesankan, dengan penggunaan protokol yang tampaknya terus meningkat seiring waktu, mencapai puncak lebih dari $70 juta TVL dan $2 miliar dalam volume pada November 2024.

TVL (USD) Railgun pada Ethereum utama - sumber:Railgun - DefiLlama

Umbrajuga telah melihat peningkatan stabil dalam jumlah orang yang menggunakan protokol mereka (orang mendaftar alamat tersembunyi ke ENS mereka), dengan hampir 77.000 pada November 2024:

Pendaftar Kumulatif Umbra (Cross Chain) — sumber: dune.com

Jika kita melihat protokol privasi yang paling terkenal (dan sekarang sayangnya terkenal buruk) di Ethereum, yaitu Tornado cash, kita dapat melihat bahwa protokol ini masih banyak digunakan, meskipun alamat kontraknya sebenarnya ada dalam daftar SDN OFAC.

Grafik di bawah ini menunjukkan TVL Tornado Cash dari waktu ke waktu. Kita dapat melihat bahwa penurunan besar pertama dalam TVL dari puncaknya sekitar Oktober 2021 bersamaan dengan penjualan lebih luas di pasar kripto, dengan penurunan besar kedua pada Agustus 2022 sesuai dengan Tornado Cash yang ditempatkan dalam daftar SDN oleh OFAC, dan penurunan besar ketiga sesuai dengan pengalihan kembali oleh OFAC pada November 2022. Namun, sejak saat itu, Tornado Cash telah mengalami pertumbuhan yang stabil, meskipun ada sanksi, mencapai hampir $600 juta dalam TVL. Ini merupakan bukti yang cukup kuat bahwa ada permintaan untuk privasi transaksi dasar dalam Ethereum.

TVL (USD) Tornado Cash di Ethereum utama — sumber: Tornado Cash — DefiLlama

Lanskap Alamat Rahasia

Penelitian ini telah mengidentifikasi 4 solusi utama untuk rantai EVM yang berada dalam produksi saat ini, yaitu:

• Fluidkey
• Umbra
• Labirin
• Railgun

Keduanya Fluidkey dan Umbra didasarkan pada standar Ethereum, yaitu:

• ERC-5564: Protokol Alamat Rahasia
• ERC-6538: Registrasi Alamat Meta-Stealth

Labyrinth dan Railgun didasarkan pada protokol zerocash (yang Zcashjuga didasarkan pada), yang menggunakan kolam terlindungi di mana pengguna menyetor dana. Zerocash menggunakan konsep “catatan”, yang pada dasarnya adalah representasi kriptografis nilai yang memungkinkan transaksi pribadi. Setiap catatan termasuk nilai tersembunyi, kunci pemilik, dan nomor unik (nullifier), dengan zk-SNARKs digunakan untuk memverifikasi kepemilikan tanpa mengungkapkan rincian, dan oleh karena itu mentransfer nilai dalam catatan. Ketika sebuah catatan dihabiskan, nullifiernya terungkap untuk mencegah pengeluaran ganda, sementara catatan baru diciptakan untuk penerima(s), membentuk sistem UTXO di dalam kolam terlindungi.

Secara umum, alamat menyamar bekerja berdasarkan prinsip dasar bahwa pihak ketiga dapat mengirim dana ke alamat yang sebelumnya tidak pernah ada, tetapi penerima yang dimaksud dapat mengetahuinya dan mengontrolnya (yaitu kemudian dapat menghabiskan dana tersebut).

Standar erc-5564 menentukan mekanisme di mana penerima dapat menerbitkan alamat meta-stealth, dari mana alamat Ethereum baru dapat diturunkan. Siapa pun yang ingin mengirim dana ke penerima, dapat menghasilkan alamat baru dari alamat meta-stealth, dan memungkinkan penerima mengetahui tentang dana-dana ini tanpa adanya komunikasi langsung yang pernah terjadi. Semua implementasi alamat stealth bekerja berdasarkan prinsip dasar ini.

Bagaimana Alamat Rahasia Bekerja

Alamat meta stealth pada dasarnya adalah penggabungan dari 2 kunci publik yang dikompresi, yang disebut sebagai "kunci pengeluaran" dan "kunci peninjauan". Alamat meta stealth menggunakan format alamat khusus rantai EIP-3770, dengan tambahan awalan "st:". Berikut adalah contoh alamat stealth:

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

Untuk mempermudah, alamat siluman ini dapat dikaitkan dengan alamat Ethereum normal (dan karenanya ENS), sehingga lebih mudah untuk mengirim dana ke pemilik alamat siluman. Untuk mengirim dana, pengirim akan menyelesaikan alamat di atas, dan menggunakan standar EIP-5564, akan membuat kunci publik sementara, dari mana mereka kemudian mendapatkan alamat siluman. Pengirim mengirim dana ke alamat siluman baru, biasanya melalui kontrak tunggal yang didengarkan oleh semua penerima alamat siluman untuk acara. Kontrak ini memancarkan peristiwa "Pengumuman" langganan penerima. Setiap kali acara pengumuman dipancarkan, penerima akan memeriksa kunci publik sementara dalam pengumuman, menggabungkannya dengan kunci pribadi tampilan mereka, dan menentukan apakah mereka memiliki kemampuan untuk membelanjakan dana yang dikirim ke alamat tersembunyi. Jika mereka melakukannya, dompet / klien yang mereka gunakan akan mengingat alamat siluman dan dana masing-masing, menambahkannya ke saldo yang ditampilkan pengguna. Untuk benar-benar membelanjakan dana, mereka dapat menandatangani transaksi menggunakan kunci pengeluaran pribadi.

Diagram berikut menggambarkan proses dari awal hingga akhir semoga sedikit lebih jelas:

Ingat bahwa proses ini terjadi sepenuhnya non-interaktif, yang berarti bahwa pengirim dan penerima tidak pernah memiliki komunikasi langsung, sehingga tidak ada tautan sama sekali antara pengirim dan penerima yang dapat diamati oleh pihak ketiga.

Namun, agar ini bekerja, penerima harus membuat alamat rahasia mereka diketahui oleh pengirim. Salah satu cara untuk melakukannya adalah dengan menggunakan Eip-6538 Pendaftaran Stealth Meta-Address. Ini adalah kontrak singleton yang memungkinkan pengguna mendaftarkan meta-alamat terselubung ke alamat Ethereum normal, yang kemudian dapat dicari oleh pengirim. Ini memungkinkan pengirim untuk menyelesaikan alamat normal dari ENS, dan kemudian mencari meta-alamat terselubung yang terkait dari registri.

Skema ini memutuskan hubungan antara pengirim dan penerima, memberikan mereka kedua privasi dari seluruh dunia yang mengetahui urusan mereka. Ada beberapa catatan:

• Ketika penerima pergi untuk menghabiskan dana, siapa pun yang mentransfer dana tersebut akan melihat bahwa dana tersebut berasal dari pengirim asli (yaitu mereka dapat melihat alamat dana yang ditransfer dari dan siapa yang sebelumnya mengirim dana ke alamat tersebut). Artinya, rantai transfer tetap utuh dan dapat dilacak, tetapi mereka hanya tidak terkait dengan penerima yang bersangkutan (kecuali penerima melakukan sesuatu seperti mengirim dana ke salah satu alamat non-stealth yang dikenal mereka). Perhatikan bahwa ini hanya berlaku untuk implementasi erc-5564, bukan untuk Railgun atau Labyrinth.
• Salah satu efek samping dari masalah di atas adalah bahwa untuk menjaga privasi yang optimal, pengguna kemungkinan perlu meninggalkan dana di alamat tersembunyi yang awalnya dikirimkan hingga mereka benar-benar membutuhkannya, daripada menggabungkannya menjadi satu alamat. Hal ini mewakili beban untuk mengingat alamat-alamat tersebut, dan kemudian menghabiskan dana di alamat-alamat tersebut, karena jumlah yang ingin Anda transfer harus berasal dari kombinasi dana di berbagai alamat lainnya.
• Untuk mentransfer dana dari alamat ini, penerima perlu mendanai alamat tersebut dengan sejumlah ETH untuk membayar gas, dan ini berpotensi membuat penerima kehilangan anonimitasnya. Ini adalah masalah yang diketahui dengan alamat tersembunyi, dan salah satu alasan mengapa sejumlah implementasi telah mengimplementasikan dukungan untuk eip-4337 dan paymaster.
• Salah satu kelemahan dari skema alamat siluman adalah bahwa penerima perlu memantau blockchain untuk acara Pengumuman dan memeriksa setiap pengumuman untuk menentukan apakah mereka telah mengirim dana. Ini jelas merupakan overhead yang tidak praktis bagi sebagian besar pengguna, terutama ketika datang untuk menerima dana di beberapa jaringan. Untuk membuat proses ini lebih efisien, standar menentukan "tag tampilan", yang merupakan hash terpotong yang berasal dari rahasia bersama, dan dapat digunakan untuk dengan cepat membuang transaksi yang jelas tidak dimaksudkan untuk mereka. Dengan menggunakan viewtag, kinerjanya tidak terlalu buruk di desktop, namun bisa agak lebih terlihat di perangkat seluler. Satu-satunya saat kinerja benar-benar terlihat adalah jika dompet sedang dipulihkan, dalam hal ini dompet perlu memindai setiap alamat sejak kontrak on-chain digunakan, yang memakan waktu.
• Untuk mengatasi hal ini, pengguna dapat secara opsional berbagi kunci pandangan pribadi dengan pihak ketiga yang dipercaya. Layanan pihak ketiga ini dapat memantau berbagai jaringan dan dapat memberi tahu pengguna ketika mereka menerima dana. Tentu saja ini datang dengan suatu pertukaran: meskipun pihak ketiga sebenarnya tidak dapat menghabiskan dana pengguna (mereka tidak memiliki kunci pengeluaran pribadi untuk melakukannya), mereka dapat melihat semua dana yang dikirim ke penerima tertentu, yang berarti pengguna perlu mempercayai mereka dengan privasinya. Fluidkey melakukan ini secara default.
• Protokol alamat sembunyi standar, yaitu ERC-5564, dirancang untuk memfasilitasi transfer yang menjaga privasi, namun, penggunaan non-keuangan seperti memanggil fungsi kontrak pintar sewenang-wenang memerlukan sedikit lebih banyak rekayasa, dan biasanya spesifik implementasi.

Matriks Perbandingan

Ada berbagai cara yang dapat kita gunakan untuk membandingkan empat implementasi alamat menyamar yang dieksplorasi dalam posting ini. Semua implementasi memiliki perbedaan halus dan kompromi, tetapi mungkin poin yang paling penting untuk dicatat adalah seputar penelusuran dan penyamaran nilai.

Sementara Fluidkey dan Umbra memungkinkan dana untuk ditransfer ke alamat Ethereum standar sambil melanggar tautan apa pun ke identitas penerima, mereka masih mempertahankan keterlacakan transaksi, yang berarti pengirim dapat dilihat oleh siapa saja yang memeriksa riwayat transaksi alamat siluman. Ini berarti bahwa jika Anda menerima dana di alamat tersembunyi, orang yang Anda putuskan untuk mengirim dana tersebut akan melihat dari mana asalnya. Selanjutnya, nilai aktual yang ditransfer juga terlihat. Railgun dan Labyrinth menyembunyikan pengirim, serta nilai yang dikirim, tetapi dengan trade-off bahwa ini semua terjadi di dalam satu kontrak, dan bukan sebagai transaksi normal ke alamat Ethereum normal.

Gambar di bawah ini menunjukkan bagaimana protokol yang kami perhatikan dalam posting ini dibandingkan satu sama lain dalam dua dimensi perbandingan penting ini.

Untuk menjelajahi perbedaan secara lebih rinci, di bawah ini adalah matriks perbandingan dari empat protokol alamat sembunyi utama di enam dimensi utama:

1. Privasi lengkap dari awal hingga akhir (hanya pengirim dan penerima yang melihat pembayaran)
2. Forward-secrecy. Mengirim dana yang diterima melalui transaksi menyamar tidak memungkinkan penerima kedua untuk melihat asal dana tersebut
3. Mengikuti standar erc-5564 dan erc-6538
4. Menerapkan arsitektur modular yang dapat diperluas yang memungkinkan integrasi dengan aplikasi pihak ketiga
5. Apakah implementasi menawarkan SDK yang dapat digunakan oleh pengembang untuk integrasi?
6. Apakah solusi ini menyediakan tingkat kepatuhan melalui dukungan de-anonimisasi?
7. Apakah desain mendukung pengaburan jumlah / nilai yang ditransfer?

| Protokol | Privasi E2E | Rahasia Maju | Standar Terbuka | Arsitektur Modular | SDK | Dukungan De-anonimisasi | Jumlah Tersembunyi |

|—————-|——————-|————————-|————————|———————————|———|—————————————|————————|

| Umbra | ✅ | ⛔️ | ✅ | ⛔️ | ⛔️ | ⛔️ | ⛔️ |

| Fluidkey | ⛔️ | ⛔️ | ✅ | ✅ | segera | ✅ | ⛔️ |

| Labyrinth | ✅ | ✅ | ⛔️ | ✅ | ✅ | ✅ | ✅ |

| Railgun | ✅ | ✅ | ⛔️ | ✅ | ✅ | sukarela | ✅ |

Beberapa nuansa dan perbedaan lainnya dijelaskan dengan lebih detail dalam bagian berikut. Setiap implementasi memiliki perbedaan halus yang menarik yang mungkin atau mungkin tidak membuat perbedaan tergantung pada kasus penggunaan Anda.

Sebagai contoh: di Fluidkey: semua transfer langsung menuju alamat tersembunyi on-chain, dengan Umbra: hanya ETH yang menuju alamat tersembunyi on-chain, sedangkan token menuju kontrak pusat, dan dengan Railgun dan Labyrinth, semua transaksi menuju kontrak inti, tidak langsung menuju alamat tersembunyi on-chain.

Mendalam tentang Implementasi Alamat Rahasia

Fluidkey

Fluidkeyadalah implementasi erc-5564 yang memungkinkan pengguna untuk mengirim, menerima, menukar, dan jembatani ETH dan token erc-20. Pada saat penulisan, Fluidkey diterapkan di Base, Optimism, Arbitrum, Polygon, Gnosis, dan Ethereum mainnet.

Pengguna berinteraksi dengan Fluidkey melalui antarmuka web mereka. Ketika mereka pertama kali masuk menggunakan dompet mereka, mereka menandatangani pesan pembuatan kunci yang berasal dari kunci tampilan dan pengeluaran mereka. Kunci-kunci yang sama ini dihasilkan ulang dengan cara yang sama setiap kali pengguna masuk ke aplikasi.

Ada beberapa cara di mana Fluidkey berbeda dari implementasi lainnya. Salah satu cara di mana Fluidkey berbeda dari implementasi lain dari alamat sembunyi adalah pengguna membagikan kunci pandang pribadi mereka dengan Fluidkey (sebenarnya sebuahBIP-32simpul turunan kunci untuk menjadi pedantik). Ini memungkinkan Fluidkey untuk menghasilkan alamat sembunyi untuk pengguna dan juga untuk memberi tahu pengguna saat mereka menerima pembayaran ke alamat tersebut. Namun, ini memang berarti bahwa Fluidkey berada dalam posisi untuk melihat transaksi masuk dan saldo pengguna, yang merupakan kompromi. Namun, itu tetap sepenuhnya self-custodial.

Aspek menarik lain dari desain Fluidkey adalah bahwa ia menggunakan akun kontrak pintar untuk setiap alamat tersembunyi baru. Hal ini terjadi secara kontrafaktual hanya ketika dana dari alamat tersembunyi dihabiskan. Akun pintar tersebut adalah akun Safe 1/1, dan memungkinkan hal-hal seperti sponsor gas, sehingga lebih mudah untuk mengelola berbagai alamat tersembunyi bersama. Terdapat detail lengkap mengenai hal ini dalam Panduan Teknis.

Meskipun Fluidkey memiliki kompromi dalam mempertahankan visibilitas ke akun pengguna, ini sebenarnya bisa menjadi keuntungan dalam hal kepatuhan, meskipun kerangka kerja yang tepat tentang bagaimana Fluidkey akan menangani hal-hal seperti permintaan penegakan hukum potensial di masa depan belum tersedia untuk umum. Namun, mereka berbasis di Swiss, dan meskipun mereka harus mematuhi hukum setempat, hukum perlindungan data sangat jelas dan sangat kuat - harus ada kasus yang sangat jelas untuk berbagi data dan juga harus diperiksa oleh pengadilan.lihat postingan iniuntuk gambaran umum yang sangat baik tentang hukum privasi di Swiss).

Pengguna juga benar-benar bebas untuk mengekspor transaksi mereka, atau berbagi kunci melihat mereka dengan pihak ketiga (misalnya akuntan mereka), yang dapat sangat berguna, terutama untuk bisnis. Namun, perlu diingat bahwa dengan spesifikasi erc-5564, berbagi kunci publik adalah "semua atau tidak sama sekali", artinya itu tidak bisa mengungkapkan transaksi individu yang terisolasi dengan sendirinya. Juga, seperti halnya dengan semua implementasi erc-5564, pelacakan tidak rusak - hanya keterhubungan dengan pengguna - yang berarti bahwa riwayat transaksi setiap alamat sembunyi terungkap kepada siapa pun yang memiliki kunci melihat. Salah satu fitur Fluidkey yang tidak terlalu dikenal yang membantu memitigasi trade-off ini adalah kemampuan untuk memutar kunci melihat, yang akan memungkinkan pengguna menggunakan kunci melihat baru setiap bulan dan hanya membagikan akses tampilan ke bulan-bulan tertentu dengan pihak ketiga.

Salah satu manfaat bagus dari pendekatan Fluidkey adalah bahwa alamat rahasia itu sendiri tidak dihasilkan oleh pengirim, tetapi dihasilkan oleh Fluidkey secara pseudo acak setiap kali ENS ditanyakan. Ini jauh lebih cepat karena pengguna tidak perlu memindai melalui acara pengumuman untuk mengidentifikasi transaksi di mana mereka adalah penerima. Ini juga berarti bahwa pengirim tidak memerlukan dompet alamat rahasia untuk menghasilkan alamat rahasia bagi penerima — mereka hanya mengirim dana ke alamat seperti yang mereka lakukan pada alamat lainnya dan itu saja. Ini juga berarti bahwa tidak ada kontrak registrasi yang terlibat, yang merupakan desain unik Fluidkey, dan keuntungan besar.

Saya harus mengatakan bahwa Fluidkey berkomitmen untuk sepenuhnya mandiri, dan mereka telah mempublikasikan kode sumber perpustakaan Stealth Account Kit mereka, dan juga ada beberapa antarmuka pemulihan yang dikembangkan secara independen yang tersedia jika Fluidkey menghilang tiba-tiba, yang berarti dana tidak akan pernah terkunci atau terjebak.

Abstraksi Alamat

Dengan menggunakan akun kontrak pintar secara kontraproduktif, Fluidkey dapat secara otomatis mengabstraksi pengelolaan alamat tersembunyi individu. Ini berarti bahwa jika Anda ingin mentransfer jumlah tertentu ke penerima tertentu dari saldo Anda di berbagai alamat tersembunyi, Fluidkey dapat secara otomatis mencari tahu kombinasi alamat yang akan digunakan untuk mengumpulkan dana untuk transfer, menangani semua biaya gas dan implementasi kontrak, semuanya di balik layar. Fluidkey juga memungkinkan pengguna untuk mengendalikan beberapa alamat yang digabungkan menggunakan fitur menarik yang disebut label, yang memungkinkan pengguna menandai alamat ke dalam kategori yang berbeda.

Pemecahan ENS

Fluidkey mengharuskan pengguna untuk membuat nama ENS yang khusus untuk Fluidkey. Nama-nama statis ini memiliki dua bentuk: username.fkey.id dan username.fkey.eth, salah satunya adalah URL ke antarmuka web untuk mengirimkan dana kepada seseorang, dan yang lainnya adalah nama ENS standar yang dapat digunakan dengan dompet.

Pengaturan ENS menggunakan sebuahPenyelesaian offchain ENS (alias erc-3668: CCIP Baca) untuk mengembalikan alamat sembunyi. Setiap kali resolver off-chain ditanyai, itu menghasilkan dan mengembalikan alamat sembunyi baru untuk nama ENS yang bersangkutan. Ini adalah fitur bagus karena memungkinkan pengguna memiliki nama ENS yang dapat dibaca manusia tunggal sambil tetap mempertahankan privasi alamat sembunyi, karena alamat sembunyi yang dihasilkan tidak bisa dikaitkan dengan nama ENS secara retrospektif.

Biaya

Fluidkey gratis untuk digunakan dan tidak mengenakan biaya. Ada biaya untuk men-deploy kontrak Safe ke setiap alamat yang memiliki dana ketika Anda ingin menggunakan dana tersebut. Namun, meskipun relatif mahal di mainnet, di L2s biayanya sangat kecil, biasanya kurang dari 1 sen, bahkan ketika menggabungkan beberapa alamat stealth menjadi satu transfer.

Mereka juga dapat melakukan sponsor gas melalui Safe deployments — mereka menghitung berapa banyak gas yang akan dikenakan biaya, dan mengambilnya dari saldo pengguna, bahkan jika itu adalah token — dalam hal ini, relay deploys aman dan mentransfer token atas nama pengguna.

Umbra Cash

Umbra merupakan implementasi dari EIP-5564 + EIP6538 oleh Scopelift. Ketika pengguna masuk ke aplikasi Umbra, mereka melewati fase pengaturan, di mana mereka menandatangani pesan, dari mana kunci pengeluaran dan tampilan dan alamat meta-stealth yang sesuai berasal. Kemudian mereka mendaftarkan alamat meta-stealth ini ke alamat dompet utama mereka dalam registri on-chain. Inilah tempat implementasinya berbeda dari Fluidkey.

Implementasi erc-5564 oleh Umbra adalah yang paling dekat dengan spesifikasi, karena mereka tidak memiliki akses ke kunci pengguna. Meskipun ini berarti bahwa Umbra (atau siapa pun) tidak dapat melihat dana pengguna, ini juga berarti bahwa untuk mengirim dana, pengirim harus memiliki dompet yang kompatibel dengan erc-5564 (atau aplikasi Umbra) untuk menghasilkan meta-alamat yang tersembunyi.

Ketika seseorang ingin kirimketika seseorang ingin mentransfer dana ke pengguna, biasanya mereka akan menggunakan aplikasi Umbra untuk melakukannya. Pada dasarnya aplikasi Umbra akan mencari alamat meta sembunyi yang terdaftar ke nama ENS / alamat dompet dan menghasilkan alamat sembunyi. Penerima dapat masuk ke aplikasi Umbra dan memindai dana yang dikirim ke alamat sembunyi milik mereka sejak terakhir kali mereka masuk. Berkat caching yang cerdas, ini hanya memerlukan waktu 10-15 detik untuk pemindaian mingguan, meskipun pengguna juga dapat secara opsional menentukan rentang blok untuk mempersempit pemindaian. Umbra v2 akan memasukkan penggunaan viewtags, yang akan mempercepat proses lebih lagi.

Relayer

Salah satu masalah dengan alamat Stealth yang sudah kita sebutkan sebelumnya adalah bahwa agar penerima dapat menghabiskan dana yang dikirim ke alamat stealth, alamat tersebut perlu memiliki ETH atau token gas yang diperlukan lainnya untuk membayar biaya transaksi. Pada sebagian besar jaringan, jika alamat stealth awalnya menerima ETH, ini biasanya bukan masalah. Namun, jika alamat stealth menerima token erc-20 atau NFT, maka tindakan pendanaan alamat dengan ETH untuk membayar gas dapat menghubungkan alamat tersebut ke alamat lain pengguna, menghilangkan privasinya.

Untuk mengatasi hal ini, Umbra menggunakan konstruksi yang melibatkan relayer. Ketika aset apa pun yang bukan ETH dikirim ke pengguna Umbra, sebenarnya dikirim ke kontrak khusus daripada langsung ke alamat yang tersembunyi. Pengguna dapat menghabiskan dana yang dikirim ke alamat tersembunyinya dengan mengirim meta-transaction (dari aplikasi Umbra) ke relayer Umbra, yang akan mentransfer dana keluar dari kontrak pintar atas nama pengguna. Relayer akan mengurangkan beberapa token untuk menutupi biaya gas, dan hanya sejumlah token tertentu yang didukung pada awalnya.

Biaya

Kontrak Umbra juga memberlakukan biaya kecil saat mentransfer dana pada jaringan dengan biaya transaksi rendah, untuk menghindari spam. Alasan di balik ini adalah bahwa spam akan meningkatkan biaya pemindaian transaksi untuk mengidentifikasi transaksi yang relevan, sehingga ini dianggap sebagai pengorbanan yang dapat diterima.

Jaringan yang Didukung

Umbra saat ini diterapkan di Ethereum mainnet, serta Optimism, Polygon, Gnosis Chain, dan Arbitrum.

Kontrak registri Umbra memiliki desain yang menarik. Metode implementasi menggunakan create2 dan pembuat deployer create2 standar, dan alamat kontrak pintar sama di semua jaringan. Ini berarti bahwa jika kontrak ada di jaringan tertentu, maka klien dapat yakin bahwa itu adalah kontrak yang benar. Klien dapat dikonfigurasi untuk menambahkan jaringan, dan siapa saja dapat melakukan implementasi ke jaringan apa pun. Mereka telah membuat bytecode yang terstandarisasi dan kontrak tidak memiliki pemilik, yang memungkinkan implementasi registry dan kontrak pengumuman tanpa izin pada setiap rantai oleh siapa saja.

Umbra v2

Scopelift saat ini sedang mengembangkanversi 2 dari Umbra, yang memperkenalkan arsitektur modular baru yang memungkinkan kontrak inti diperluas untuk mendukung standar token baru atau kasus penggunaan non-pembayaran. Dengan menggunakan arsitektur baru ini, pengembang pihak ketiga dapat membangun modul untuk jenis standar token apa pun, misalnya erc-1155, erc-7621, dukungan untuk paymasters erc-4337, atau apa pun yang Anda pikirkan. Saat ini, kontrak inti Umbra mendukung dua skenario, satu untuk ETH, dan satu untuk erc-20. V2 akan mendukung berbagai skenario yang berbeda.

Labirin

Labirinadalah sebuah protokol yang tidak didasarkan pada eip-5564 + eip6538, tetapi malah menggunakan bukti pengetahuan nol untuk menambahkan anonimitas dan privasi ke transaksi. Whitepaper Labyrinth menggambarkannya sebagai middleware “zkFi”: “zkFi menawarkan solusi terpadu yang bertindak sebagai middleware privasi dengan kepatuhan bawaan“. Kepatuhan bawaan mengacu pada “De-Anonimisasi Selektif” Labyrinth, yang merupakan solusi canggih yang memungkinkan beberapa transaksi untuk dianonimkan kepada aktor yang diotorisasi tertentu, yaitu otoritas hukum seperti interpol, dll. sambil tetap menjaga transparansi dan keterbukaan.

Kontrak pintar inti yang digunakan Labyrinth termasuk kolam multi-transaksional dan multi-aset yang memungkinkan pengguna melakukan transaksi multiple aset dalam satu transaksi. Untuk menghabiskan aset, pengguna memindai jaringan dan mengambil data catatan terenkripsi, mendekripsi catatan, dan menyaring aset yang ingin dihabiskan. Selanjutnya, pengguna membuat ZKP yang mencakup transaksi dan tanda tangan dari kunci penandatanganan yang terkait dengan catatan yang ingin dihabiskan transaksinya.

Sebagian dari kontrak inti Labrynth termasuk kontrak konverter, yang berinteraksi dengan kontrak proksi modular, yang pada dasarnya adalah proksi untuk kontrak eksternal. Jadi misalnya: jika seorang pengguna ingin menggunakan Labyrinth untuk berinteraksi dengan Uniswap, pengguna tersebut akan membuat transaksi yang akan menggunakan kontrak konverter untuk memanggil operasi pertukaran pada kolam Uniswap melalui kontrak proksi Uniswap.

Protokol zkFi Labyrinth menggunakan 'catatan' untuk melacak saldo dan transfer. Catatan pada dasarnya adalah struktur data yang menggambarkan sejumlah aset dan alamat yang dimilikinya. Klien menyimpan informasi yang diperlukan untuk membuat ulang catatan tersebut, dan menggunakannya untuk menghabiskan aset. Komitmen terhadap catatan (hash id aset, pemilik, dan nilai) disimpan dalam pohon merkle on-chain. Sebenarnya, Labyrinth menggunakan dua pohon merkle, satu untuk catatan, dan satu untuk alamat root.

Struktur data catatan berisi hal berikut:

• assetId: Identifier untuk aset (ETH, WBTC, MATIC, dll.) ini mewakili nilai dari catatan ini.
• nilai: Nilai atau jumlah yang diwakili oleh catatan.
• leafIndex: Indeks daun dari pohon merkle komitmen di mana catatan ini akan dimasukkan.
• blinding: Faktor penyilau acak.
• rootAddress: Alamat akar pengguna yang memiliki otoritas untuk menggunakannya.
• revoker: Titik kunci publik revoker yang dipilih.

Anda akan melihat bahwa struktur data di atas tidak mengandung referensi apapun terhadap pemilik aset, yang aneh, karena komitmen yang tercatat dalam pohon merkle catatan adalah hash dari id aset, nilai, dan pemilik. Pemilik sebenarnya dihitung dari alamat root, penghapus, dan faktor pengaburan acak, sehingga bagi pengamat eksternal, pemilik sebenarnya adalah alamat yang baru dibuat untuk setiap transaksi baru.

Kolam Terselubung

Apa yang benar-benar menarik tentang Labyrinth, yang juga sedikit berbeda dari protokol berbasis alamat stealth vanilla, adalah bahwa kolam aset sebenarnya adalah kolam yang diawetkan, yang menggunakan konsep catatan untuk membuat semacam kolam UTXO yang diawetkan yang memberikan kerahasiaan ke depan ke transaksi. Ingat bahwa dengan implementasi eip-5564, entitas kepada siapa pengguna mentransfer dana akan dapat melihat dari mana dana tersebut berasal. Dengan kata lain, Alice membayar Bob menggunakan alamat sembunyi, Bob membayar Charlie, jadi sekarang Charlie bisa melihat bahwa Bob awalnya menerima dana dari Alice, dan seterusnya. Ini tidak berlaku untuk kolam terlindungi Labyrinth.

Untuk memahami bagaimana kolam yang terlindungi ini bekerja, kita perlu melihat bagaimana dana ditransfer di dalam protokol:

Saldo pengguna di kumpulan terlindung adalah jumlah catatan dari masing-masing aset. Untuk menghabiskan catatan tersebut, pengguna perlu mengungkapkan "nullifiers" dari catatan tersebut. Nullifier unik untuk catatan, dan setelah catatan itu dibelanjakan, nullifier ditandai untuk mencegah pengeluaran ganda, dan catatan baru dibuat dari catatan yang dihabiskan itu. Beberapa catatan dari aset yang sama dapat digabungkan, dan beberapa catatan baru dapat dibuat. Nullifier hanyalah hash dari (l, c, δ), di mana l adalah indeks komitmen catatan di pohon merkle catatan, dan c adalah komitmen, dan δ adalah elemen acak juga disebut sebagai faktor menyilaukan.

Penerima transfer transaksi diam-diam mengidentifikasi transfer melalui cara yang sama seperti eip-5564, dalam arti mereka mendengarkan peristiwa yang dipancarkan dari kontrak inti, dan menentukan alamat diam-diam mana yang akan dapat mereka kirim dana dari, mencatatnya secara lokal. Identifikasi dana masuk juga lebih cepat dengan memanfaatkan tag tampilan dan dengan caching dan sinkronisasi lokal catatan secara asinkron selama masa hidup aplikasi.

Terdapat penelitian yang sedang berlangsung untuk membuat proses penemuan dana yang diterima menjadi lebih cepat, ambil contoh proposal ini dari Aztec misalnya:Permintaan Proposal: Protokol Penemuan Catatan - Aztec.

Untuk mengeluarkan dana, pengguna juga harus melakukan pembuatan bukti-zk, tidak seperti implementasi erc-6654, yang pada dasarnya adalah alamat Ethereum biasa. Pembuatan bukti memerlukan dompet yang kompatibel, dengan kinerja yang relatif baik, membutuhkan sekitar 20 detik atau lebih pada perangkat Android yang sedang.

Bundler dan Konverter

Ada beberapa fitur bagus yang ditawarkan Labyrinth yang dapat mengatasi beberapa masalah transaksi diam. Transaksi yang dikirim ke kontrak inti Labyrinth dikirim sebagai operasi pengguna melalui bundler erc-4337. Penyiapan ini memungkinkan untuk menghabiskan catatan tanpa ETH atau memerlukan token gas untuk transaksi, karena pengguna dapat memanfaatkan erc-4337 paymaster untuk membayar gas atas nama mereka, yang menambahkan lapisan privasi lebih lanjut. Satu-satunya pengecualian adalah deposit awal yang tidak dikirim sebagai userop. Penggunaan er-4337 paymaster juga memiliki manfaat tambahan yaitu dapat membayar gas melalui aset yang ditransfer, bahkan jika mereka adalah token erc-20, dan untuk ini Labyrinth mengekspos sebuah gas price oracle API.

Fitur lain yang sangat bagus yang dimiliki Labyrinth adalah arsitektur modular yang memungkinkan kontrak konverter bertindak sebagai proxy untuk aplikasi pihak ketiga. Hal ini memungkinkan pengguna tidak hanya mentransfer dana menggunakan transaksi sembunyi, tetapi juga berinteraksi dengan aplikasi pihak ketiga seperti DEXs, (misalnya Uniswap, Aave, Lido, dll.). Kontrak proxy 'konverter' ini pada dasarnya mengimplementasikan fungsi yang mengambil sejumlah aset, dan sejumlah aset keluar, dengan logika yang mendasarinya berada di kontrak pihak ketiga.

Solusi Kepatuhan

Labyrinth memastikan kepatuhan dan kepatuhan regulasi melalui kerangka kerja yang disebut De-Anonimisasi Selektif (SeDe).

Ingatlah bahwa struktur data dari sebuah catatan mengandung suatu bidang yang disebut “penarik kembali”. Penarik kembali adalah alamat dari entitas tertentu yang dapat memulai proses de-anonimisasi. Pengguna harus memilih setidaknya satu penarik kembali dari daftar yang telah ditentukan. Penarik kembali tidak hanya bertanggung jawab atas mengidentifikasi aktivitas yang berpotensi melanggar hukum atau ilegal, tetapi juga dapat merespons permintaan dari lembaga penegak hukum.

Revokers tidak memiliki kapasitas unilateral untuk mendek-anonimkan transaksi secara langsung, tetapi mereka bertanggung jawab untuk menginisiasi permintaan untuk mendek-anonimkan. Permintaan ini diposting secara publik kepada para penjaga, yang merupakan komite entitas yang mengawasi privasi dan kepatuhan. Penjaga harus merespons permintaan dengan memilih apakah akan memberikan izin untuk mendek-anonimkan transaksi tersebut. Jika penjaga dapat mencapai kuorum dan memilih mendukung, maka revoker dapat mendekripsi data transaksi, memungkinkan mereka untuk menghubungkan transaksi yang dimaksud dengan transaksi sebelumnya sampai rantai transaksi sepenuhnya mendek-anonimkan.

Sistem ini menciptakan serangkaian pemeriksaan dan keseimbangan, dalam arti para penjaga tidak dapat dengan sepihak memutuskan untuk mengungkapkan data transaksi, dan bahkan jika mereka berkolusi, mereka tidak dapat melakukan apa pun tanpa yang mencabut, dan yang mencabut sendiri tidak dapat melakukan apa pun dengan suara mayoritas penjaga.

Railgun

RAILGUNadalah sistem privasi transaksi rahasia yang diterapkan pada Ethereum, BSC, Polygon, dan Arbitrum. Protokol ini mirip dengan Labyrinth dalam beberapa hal karena didasarkan pada catatan-catatan, yang disimpan dalam pohon merkle sebagai komitmen, dan membentuk set UTXO, yaitu catatan-catatan tersebut dapat dihabiskan dengan membuat catatan-catatan baru untuk penerima lainnya. Untuk menghabiskan catatan, nullifier ditambahkan ke status catatan tersebut, mencegah penggandaan pengeluaran. Hanya pemilik catatan yang dapat menghitung nullifier-nya, yang didasarkan pada hash dari kunci pengeluaran dan indeks catatan-catatan pada pohon merkle, artinya hanya pemilik catatan yang dapat menghabiskannya (dan hanya dapat menghabiskannya sekali).

Alamat meta rahasia dalam Railgun menggunakan awalan "0zk", dan seperti eip-5564, adalah penggabungan dari kunci tampilan publik dan kunci pengeluaran publik. Namun, Railgun menggunakan kunci Ed25519 pada kurva BabyJubJub bukan ECDSA & secp256k1. Dengan cara yang sama seperti eip-5564, pengguna memindai semua peristiwa yang terjadi dari kontrak Railgun dan menggunakan kunci tampilan mereka untuk menentukan peristiwa mana yang mewakili transfer ke dompet mereka.

Railgun menggunakan jaringan broadcaster, yang pada dasarnya adalah relayer yang menerima meta-transaksi dari pengguna dan menyiarkan transaksi sebenarnya ke blockchain yang bersangkutan, membayar biaya gas atas nama pengguna. Interaksi langsung dengan kontrak Railgun berasal dari jaringan broadcaster ini, melindungi anonimitas pengguna akhir. Transaksi yang dikirim dari pengguna ke broadcaster dienkripsi dengan kunci publik broadcaster tertentu dan dikomunikasikan menggunakan protokol Waku.

Railgun memiliki arsitektur modular yang memungkinkannya berinteraksi dengan kontrak pintar eksternal, memungkinkan fungsionalitas di luar transfer sederhana. Hal ini dilakukan melalui kontrak AdaptRelay, yang melindungi dan membuka perlindungan token sebelum dan setelah berinteraksi dengan kontrak eksternal, misalnya membuka perlindungan token A, pertukaran dengan token B di beberapa AMM, lalu melindungi token B kembali ke pemilik aslinya.

Dengan versi 3, Railgun berencana untuk memanfaatkan eip-4337 serta mendukung meta-transaksi warisan. Mereka berharap dengan mempertahankan eip-4337 userop mempool yang didedikasikan untuk Railgun, solver independen dapat berpartisipasi sebagai broadcaster. Saat ini mereka sedang bekerja sama dengan Umbra dalam penelitian ini, dan mengidentifikasi kasus-kasus terkait dan cara mengatasi mereka, lihat bagian Railgun v3 di bawah untuk lebih detail.

Biaya

Protokol Railgun mengambil biaya sebesar 0,25% untuk deposit dan penarikan. Biaya ini dikirim ke kas DAO, dan biaya ini dibayarkan dari waktu ke waktu kepada para pemegang token tata kelola RAIL. Selain biaya deposit dan penarikan sebesar 0,25%, penyiar umumnya juga menerapkan biaya mereka sendiri, yang biasanya sekitar 10% dari biaya gas untuk transaksi sesungguhnya di rantai.

Governance

Railgun memiliki sistem tata kelola yang memungkinkan setiap bentuk usulan untuk diajukan, dan tidak ada perubahan pada kontrak inti (termasuk kontrak perbendaharaan & tata kelola) yang dapat terjadi tanpa usulan DAO. Secara tidak lazim, instansi terpisah dari Railgun memiliki tata kelola mereka sendiri. Misalnya, Railgun di Ethereum, Polygon, dan Binance Chain memiliki sistem tata kelola dan token mereka sendiri.

SDK dan Cookbook

Railgun menawarkan SDK yang komprehensif dan terdokumentasi dengan baik yang dapat digunakan pengembang dompet atau dapp untuk membangun fungsionalitas alamat siluman melalui dukungan untuk Railgun. Railgun juga memiliki komunitas yang dikelola buku masakdengan “resep” yang memungkinkan pengembang dapp untuk menyediakan modul untuk Railgun yang memungkinkan pengguna berinteraksi dengan dapp mereka menggunakan Railgun. Misalnya, seorang pengembang dapat menulis resep untuk DEX yang memungkinkan pengguna dengan saldo token di Railgun untuk menukar token secara pribadi.

RailGun v3

Iterasi berikutnya dari Railgun akan membuat transaksi menjadi sekitar 50% - 60% lebih murah. Perubahan lain dalam versi 3 adalah beralih ke dukungan userops eip-4337 melalui mempool khusus. Selain itu, v3 akan memberikan dukungan untuk arsitektur berbasis intents, yang akan memungkinkan resolver bersaing untuk eksekusi terbaik, meskipun detailnya sangat tinggi pada saat penulisan. Mereka saat ini sedang bekerja dengan CowSwappada ini dan berencana menggunakan kait pra dan pasca untuk memungkinkan penyelesaian akses dana.

Koneksi Railgun

Argumen yang paling menarik yang diusulkan adalah sesuatu yang disebut Railgun Connect, yang digambarkan sebagai alat yang mirip dengan WalletConnect, dalam arti memungkinkan alamat 0zk untuk terhubung ke sebagian besar frontend untuk penggunaan pribadi, tanpa memerlukan dapps untuk secara khusus menyediakan integrasi eksplisit dengan Railgun melalui modul khusus.

Railgun Connect adalah ekstensi browser, dan apa yang dilakukannya sebenarnya adalah melakukan fork keadaan rantai secara lokal menggunakan HardHat di bawah tenda, dan menyuntikkan penyedia web3 sendiri ke dalam dapp, dengan titik akhir RPC dari versi HardHat lokal rantai. Ini kemudian memungkinkan Anda untuk melakukan interaksi dengan kontrak dapps seperti biasa, mencatat transaksi, kemudian mengumpulkannya dan membuat bukti snark, dan mengirimkannya ke kontrak Railgun yang sebenarnya pada rantai nyata. Meskipun deskripsi ini sedikit lebih sederhana, ini menyampaikan gagasan umum. Apa yang dilakukan adalah memungkinkan Anda untuk pada dasarnya berinteraksi dengan hampir semua dapp (dengan beberapa kasus tepi untuk dapp yang melakukan pemrosesan off-chain ekstra). Peringatannya adalah bahwa menyelamatkan keadaan rantai secara lokal adalah operasi yang berat, tetapi setelah selesai, itu berarti Anda dapat berinteraksi dengan dapps menggunakan alamat siluman Railgun tanpa melihat perbedaan dari menggunakan dompet normal.

Kesimpulan

Ada beberapa proposal menarik untuk mengabadikan alamat menyamar dalam protokol Ethereum. Misalnya, Inco Menggunakan ide "pembungkus" ERC-20, yang membungkus kontrak ERC-20 normal, dan mengenkripsi semua saldo. Transfer dan persetujuan semuanya dilakukan pada keadaan terenkripsi melalui enkripsi homomorfik sepenuhnya. Inco bergantung pada prekompilasi yang saat ini hanya ada di jaringannya sendiri, tetapi suatu hari nanti mungkin berhasil masuk ke Ethereum.

Ada juga proposal lain yang disebut EIP-7503: Zero-Knowledge Wormholesyang didasarkan pada desain yang disebut “proof-of-burn”, meskipun ini sepertinya tidak mendapat banyak daya tarik, mungkin karena ini memerlukan pembaruan untuk EVM, tanpa itu ini benar-benar hanya dapat diimplementasikan pada tingkat token, menggunakan desain erc-20 yang mendukung eip-7503 secara khusus (atau jika L2 memutuskan untuk menambahkan dukungan pada opcode EVM mereka).

Aztecmungkin teknologi privasi yang paling canggih di luar sana, tetapi itu memerlukan pengguna untuk memindahkan dana ke Aztec untuk menggunakannya, yang mungkin atau mungkin bukan merupakan pengalaman pengguna yang tidak dapat diterima bagi sebagian besar pengguna. Namun, jika permintaan untuk privasi transaksi dasar tumbuh di kalangan pengguna Ethereum, maka Aztec bisa memiliki usulan nilai yang unik yang membuatnya menjadi L2 yang sangat berharga saat dapps dan pengguna bermigrasi ke platform yang memberikan privasi secara default.

Demikian juga, Intmax adalah Ethereum L2 (berdasarkan desain Plasma) yang berfokus pada privasi, dan juga memiliki aspek yang mematuhi regulasi dengan memverifikasi keabsahan dana individu melalui bukti AML berbasis ZKP dan memberlakukan batasan pada jumlah transaksi. Intmax terbatas dalam hal memberikan privasi untuk transfer sementara operasi kontrak pintar EVM tidak privat. Namun, berbeda dengan Aztec, kontrak pintar dapat ditulis dalam Solidity, yang mungkin lebih disukai oleh beberapa pengembang (tergantung pada kasus penggunaannya).

Dukungan Dompet

Sementara kita sedang melihat adopsi yang meningkat dari protokol alamat tersembunyi, yang menjanjikan, masih ada beberapa tantangan. Tantangan paling penting adalah bahwa mereka belum sepenuhnya didukung di dompet Ethereum mainstream (setidaknya belum). Dompet mainstream mungkin memiliki beberapa pilihan untuk membuat jika mereka akan memberikan dukungan untuk alamat tersembunyi. Beberapa pilihan ini termasuk:

• Apakah mereka akan memberikan dukungan opini untuk satu implementasi, atau akan membangun dan memelihara semacam pengumpul komprehensif melintasi beberapa protokol? Yang terakhir kemungkinan akan sangat mahal dalam hal pengembangan dan pemeliharaan.
• Apakah akan ada pertimbangan peraturan, dan apakah mereka perlu mengambil posisi tentang tingkat dan mekanisme untuk de-anonimisasi selektif (yaitu seperti Labyrinth)?
• Alamat rahasia memerlukan komponen on-chain vis-a-vis kontrak registri (kecuali Fluidkey), sehingga ini berarti setiap jaringan EVM harus didukung secara eksplisit oleh dompet (meskipun desain Umbra memudahkan implementasi tanpa izin dari registri).
• Alamat sembunyi membuat integrasi yang ada dengan penjelajah blok (misalnya, Etherscan) menjadi lebih rumit. Misalnya, tombol “Lihat di Penjelajah” tidak akan berfungsi untuk meta-alamat sembunyi, di mana dompet menampilkan saldo agregat. Masalah ini mungkin juga ada untuk transfer. Kasus-kasus tepi yang beragam seperti ini perlu dipikirkan.
• Tergantung pada implementasi mendasar, pengguna hanya akan dapat menggunakan alamat sembunyi secara efektif dengan serangkaian dapps tertentu, yaitu yang didukung oleh protokol mendasar. Ini akan memungkinkan dengan arsitektur alamat sembunyi modular. Namun, tidak semua dapps akan didukung, dan hal ini perlu dikomunikasikan kepada pengguna dengan cara tertentu. Ini agak lebih mudah dengan eip-5506, tetapi masih memiliki komplikasi dan kasus-kasus tepi, dan hal ini seringkali akan bocor ke UX dompet.

Ada juga ruang untuk perbaikan dalam mencegah kebersihan privasi pengguna yang buruk, lihat makalah ini: "Analisis Anonimitas Skema Alamat Rahasia Umbra pada Ethereum” untuk bagaimana para penulis berhasil mendeanonimkan 48,5% transaksi stealth di Ethereum mainnet. Heuristik yang mereka gunakan untuk melakukan ini tidak ada hubungannya dengan protokol, dan lebih berkaitan dengan kebersihan privasi, misalnya pengguna mengirim dana ke alamat stealth yang mereka kendalikan, dan kemudian mengirim dana tersebut kembali ke alamat asalnya, dengan salah mengira bahwa jejaknya terputus. Secara keseluruhan, para penulis mengidentifikasi 6 heuristik yang berbeda yang dapat digunakan untuk mendeanonimkan transaksi alamat stealth, sebagian besar didasarkan pada tidak mengikuti praktik terbaik. Namun, ini adalah masalah UX yang krusial yang perlu ditangani.

Secara keseluruhan, saya cukup optimis tentang alamat menyamar dan privasi di Ethereum secara umum. Saya pikir kami telah membuat kemajuan yang cukup mengesankan, dan menemukan beberapa tantangan yang sangat dapat diperbaiki. Saya yakin bahwa dompet utama akan menemukan cara untuk menyediakan tingkat dukungan untuk alamat menyamar yang memungkinkan pengguna menggunakannya dengan gesekan dan pemikiran minimal, memberikan tingkat privasi normal yang diharapkan dan pantas oleh pengguna.

Teriakan besar untuk semua tim yang telah meluangkan waktu dan kerja keras untuk meneliti dan membangun infrastruktur alamat sembunyi, termasuk empat protokol yang saya bicarakan dalam posting ini. Kerja keras dan ketekunan mereka akan membuat perbedaan besar untuk Ethereum!

Penafian:

1. Artikel ini dicetak ulang dari [Medium]. Semua hak cipta milik penulis asli [Simon Brown]. Jika ada keberatan terhadap pencetakan ulang ini, silakan hubungi Gate Learntim, dan mereka akan menanganinya dengan segera.
2. Penolakan Tanggung Jawab Liabilitas: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Tim Belajar Gate melakukan terjemahan artikel ke bahasa lain. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.