Terima kasih khusus kepada Liraz Siri, Yoav Weiss, dan pengembang ImToken, Metamask, dan OKX atas masukan dan ulasan mereka.
Lapisan penting dari tumpukan infrastruktur Ethereum yang sering diremehkan oleh peneliti dan pengembang inti L1 adalah dompet. Dompet adalah jendela antara pengguna dan dunia Ethereum, dan pengguna hanya bisa mendapatkan keuntungan dari desentralisasi, ketahanan sensor, keamanan, privasi, atau atribut lain yang ditawarkan oleh Ethereum dan aplikasinya jika dompet itu sendiri juga memiliki atribut tersebut.
Baru-baru ini, kami melihat dompet Ethereum membuat kemajuan besar dalam meningkatkan pengalaman pengguna, keamanan, dan fungsionalitas. Tujuan artikel ini adalah untuk memberikan pendapat saya sendiri mengenai beberapa fitur yang harus dimiliki oleh dompet Ethereum yang ideal. Ini bukanlah daftar yang lengkap; ini mencerminkan kecenderungan saya terhadap cypherpunk, berfokus pada keamanan dan privasi, dan hampir pasti tidak lengkap dalam hal pengalaman pengguna. Namun, menurut saya daftar keinginan tidak seefektif penerapan dan pengulangan berdasarkan umpan balik dalam mengoptimalkan pengalaman pengguna, jadi menurut saya fokus pada atribut keamanan dan privasi adalah hal yang paling berharga.
Pengalaman pengguna untuk transaksi lintas L2
Saat ini ada peta jalan yang semakin mendetail untuk meningkatkan pengalaman pengguna lintas L2, dengan bagian jangka pendek dan jangka panjang. Di sini, saya akan membahas bagian jangka pendek: ide-ide yang bahkan masih dapat diterapkan secara teori hari ini.
Inti pemikirannya adalah (i) built-in pengiriman lintas L2, dan (ii) alamat dan permintaan pembayaran spesifik rantai. Dompet Anda harus dapat memberikan Anda alamat (mengikuti gaya draf ERC ini), seperti:
Ketika seseorang (atau beberapa aplikasi) memberikan alamat dalam format ini kepada Anda, Anda harus dapat menempelkannya ke dalam kolom 'penerima' dompet dan kemudian mengklik 'kirim'. Dompet harus dapat secara otomatis menangani pengiriman data dengan cara apa pun yang memungkinkan:
Jika Anda sudah memiliki cukup jenis token yang diperlukan di rantai target, silakan kirim token langsung.
Jika Anda memiliki jenis token yang diperlukan di rantai lain (atau beberapa rantai lain), gunakan protokol seperti ERC-7683 (yang pada dasarnya adalah DEX lintas rantai) untuk mengirim token.
Jika Anda memiliki jenis token yang berbeda di rantai yang sama atau di rantai lain, gunakan bursa terdesentralisasi untuk mengonversinya menjadi mata uang yang benar di rantai yang benar dan kirim. Ini seharusnya memerlukan izin eksplisit dari pengguna: pengguna akan melihat seberapa banyak biaya yang mereka bayar, dan seberapa banyak biaya yang diterima oleh penerima.
Model antarmuka dompet yang mungkin dengan dukungan alamat lintas rantai
Konten di atas berlaku untuk kasus penggunaan 'Anda menyalin dan menempel alamat (atau ENS, seperti vitalik.eth @ optimism.eth) dan seseorang membayar Anda'. Jika dapp meminta deposit (misalnya, lihat contoh Polymarket ini) maka alur ideal adalah memperluas API web3 dan memungkinkan dapp untuk mengeluarkan permintaan pembayaran spesifik rantai. Kemudian, dompet Anda akan dapat memenuhi permintaan tersebut dengan cara apa pun yang diperlukan. Untuk memberikan pengalaman pengguna yang baik, permintaan getAvailableBalance juga perlu distandarisasi, dan dompet harus mempertimbangkan dengan serius di rantai mana aset pengguna disimpan secara default, untuk memaksimalkan keamanan dan kenyamanan transfer.
Permintaan pembayaran spesifik rantai juga dapat dimasukkan ke dalam kode QR, dengan dompet bergerak dapat memindai kode QR tersebut. Dalam skenario pembayaran konsumen secara langsung (atau online), penerima akan menghasilkan kode QR atau panggilan API web3, yang menunjukkan 'Saya ingin X unit token YZ di rantai, dengan ID referensi atau callback W', dompet akan dapat memenuhi permintaan tersebut dengan cara apa pun yang diperlukan. Pilihan lain adalah protokol tautan klaim, di mana dompet pengguna menghasilkan kode QR atau URL yang berisi otorisasi klaim untuk mendapatkan sejumlah dana dari kontrak rantai mereka, pekerjaan penerima adalah mencari tahu bagaimana mengalihkan dana tersebut ke dompet mereka sendiri.
Topik terkait lainnya adalah pembayaran gas. Jika Anda menerima aset di L2 yang belum memiliki ETH, dan perlu mengirim transaksi di L2 tersebut, dompet harus dapat secara otomatis menggunakan protokol (seperti RIP-7755) untuk membayar gas di rantai di mana Anda memiliki ETH. Jika dompet ingin Anda melakukan lebih banyak transaksi di L2 di masa depan, dompet juga seharusnya hanya menggunakan DEX untuk mengirim, misalnya, ETH senilai jutaan gas sehingga transaksi di masa depan dapat langsung menghabiskan gas di sana (karena lebih murah).
Keamanan akun
Salah satu cara saya untuk mengkonseptualisasikan tantangan keamanan akun adalah bahwa dompet yang baik harus berfungsi pada dua aspek: (i) melindungi pengguna dari peretasan atau serangan jahat oleh pengembang dompet, dan (ii) melindungi pengguna dari kesalahan mereka sendiri.
Kesalahan di sebelah kiri adalah tanpa sengaja. Namun, ketika saya melihatnya, saya menyadari bahwa itu sangat cocok dengan konteks, jadi saya memutuskan untuk mempertahankannya.
Solusi pilihan saya untuk ini, selama lebih dari satu dekade, adalah pemulihan sosial dan dompet multisignature dengan kontrol akses bertingkat. Akun pengguna memiliki dua lapisan kunci: kunci utama dan N pengawas (misalnya N = 5). Kunci utama mampu melakukan operasi nilai rendah dan non-keuangan. Sebagian besar pengawas diperlukan untuk melakukan (i) operasi nilai tinggi, seperti mengirim semua nilai di akun, atau (ii) mengubah kunci utama atau pengawas mana pun. Jika perlu, kunci utama dapat diizinkan untuk melakukan operasi nilai tinggi melalui penguncian waktu.
Di atas adalah desain dasar yang dapat diperluas. Kunci sesi dan mekanisme izin seperti ERC-7715 dapat membantu mendukung keseimbangan yang berbeda antara kenyamanan dan keamanan untuk aplikasi yang berbeda. Arsitektur pengawas yang lebih kompleks, seperti memiliki beberapa durasi penguncian waktu di bawah ambang batas yang berbeda, dapat membantu memaksimalkan peluang untuk memulihkan akun yang sah dengan sukses, sambil meminimalkan risiko pencurian.
Di atas adalah desain dasar yang dapat diperluas. Kunci sesi dan mekanisme izin seperti ERC-7715 dapat membantu mendukung keseimbangan yang berbeda antara kenyamanan dan keamanan untuk aplikasi yang berbeda. Arsitektur pengawas yang lebih kompleks, seperti memiliki beberapa durasi penguncian waktu di bawah ambang batas yang berbeda, dapat membantu memaksimalkan peluang untuk memulihkan akun yang sah dengan sukses, sambil meminimalkan risiko pencurian.
Siapa atau apa yang seharusnya menjadi pengawas?
Untuk pengguna crypto yang berpengalaman dalam komunitas pengguna crypto berpengalaman, pilihan yang layak adalah kunci teman dan keluarga Anda. Jika Anda meminta setiap orang untuk memberikan alamat baru, maka tidak ada yang perlu tahu siapa mereka - sebenarnya, pengawas Anda bahkan tidak perlu tahu satu sama lain. Namun, untuk sebagian besar pengguna baru, opsi ini tidak tersedia.
Pilihan kedua adalah pengawas institusi: perusahaan yang menawarkan layanan yang hanya menandatangani transaksi setelah menerima informasi konfirmasi lainnya atas permintaan Anda: seperti kode konfirmasi, atau panggilan video untuk pengguna nilai tinggi. Orang-orang telah lama berusaha membuat ini, seperti yang saya lakukan pada tahun 2013 dengan CryptoCorp. Namun, sejauh ini, perusahaan-perusahaan ini belum sangat sukses.
Pilihan ketiga adalah beberapa perangkat pribadi (misalnya ponsel, desktop, dompet perangkat keras). Ini bisa bekerja, tetapi sulit untuk diatur dan dikelola bagi pengguna yang tidak berpengalaman. Ada juga risiko kehilangan atau pencurian perangkat secara bersamaan, terutama jika mereka berada di lokasi yang sama.
Baru-baru ini, kami mulai melihat lebih banyak solusi berbasis kunci universal. Kunci hanya dapat dicadangkan di perangkat Anda, menjadikannya solusi perangkat pribadi, dan juga dapat dicadangkan di cloud, dengan keamanan yang bergantung pada kombinasi keamanan kata sandi yang kompleks, institusi, dan asumsi perangkat keras tepercaya. Pada kenyataannya, kunci adalah keuntungan keamanan yang berharga bagi pengguna biasa, tetapi hanya mengandalkan mereka belum cukup untuk melindungi tabungan seumur hidup pengguna.
Untungnya, dengan ZK-SNARK, kami juga memiliki pilihan keempat: ID terpusat yang dibungkus ZK. Jenis ini termasuk zk-email, Anon Aadhaar, Myna Wallet, dan sebagainya. Pada dasarnya, Anda dapat mengambil ID terpusat dalam berbagai bentuk (perusahaan atau pemerintah) dan mengonversinya menjadi alamat Ethereum, di mana Anda hanya dapat mengirim transaksi dengan menghasilkan bukti kepemilikan ID terpusat menggunakan ZK-SNARK.
Dengan tambahan ini, kami sekarang memiliki berbagai pilihan, dan ID terpusat yang dibungkus ZK memiliki 'teman baru' yang unik.
Untuk itu, ia perlu mencapainya melalui UI yang disederhanakan dan terintegrasi: Anda harus dapat hanya menentukan bahwa Anda ingin 'example@gmail.com' sebagai pengawas, dan seharusnya secara otomatis menghasilkan alamat zk-email Ethereum yang sesuai di bawah kap. Pengguna tingkat lanjut harus dapat memasukkan email mereka (serta mungkin nilai garam privasi yang disimpan dalam email tersebut) ke dalam aplikasi pihak ketiga sumber terbuka dan mengonfirmasi bahwa alamat yang dihasilkan benar. Hal yang sama harus berlaku untuk jenis pengawas lain yang didukung.
Perlu dicatat bahwa tantangan praktis yang dihadapi zk-email saat ini adalah ketergantungannya pada tanda tangan DKIM, yang menggunakan kunci yang diputar setiap beberapa bulan, dan kunci tersebut sendiri tidak ditandatangani oleh lembaga lain. Ini berarti zk-email saat ini memiliki tingkat kepercayaan yang melampaui penyedia itu sendiri; jika zk-email menggunakan TLSNotary dalam perangkat keras tepercaya untuk memverifikasi kunci yang diperbarui, ini dapat mengurangi masalah ini, tetapi itu bukan solusi ideal. Saya berharap penyedia email dapat mulai langsung menandatangani kunci DKIM mereka. Saat ini, saya merekomendasikan seorang pengawas untuk menggunakan zk-email, tetapi tidak merekomendasikan sebagian besar pengawas untuk menggunakannya: jangan menyimpan dana di zk-email yang rusak berarti Anda tidak dapat menggunakan dana dalam pengaturan tersebut.
Pengguna baru dan dompet dalam aplikasi
Pengguna baru sebenarnya tidak ingin memasukkan banyak pengawas saat pertama kali mendaftar. Oleh karena itu, dompet harus memberi mereka pilihan yang sangat sederhana. Salah satu cara yang alami adalah menggunakan zk-email pada alamat email mereka, kunci yang disimpan secara lokal di perangkat pengguna (mungkin kunci universal), dan kunci cadangan yang dipegang oleh penyedia, untuk memilih 2-dari-3. Seiring pengguna menjadi lebih berpengalaman atau mengumpulkan lebih banyak aset, pada suatu saat mereka harus diberi tahu untuk menambahkan lebih banyak pengawas.
Integrasi dompet ke dalam aplikasi tidak dapat dihindari, karena aplikasi yang berusaha menarik pengguna non-kriptografi tidak ingin pengguna harus mengunduh dua aplikasi baru secara bersamaan (aplikasi itu sendiri, ditambah dompet Ethereum), yang akan menciptakan pengalaman pengguna yang membingungkan. Namun, banyak pengguna dompet aplikasi harus dapat menghubungkan semua dompet mereka, sehingga mereka hanya perlu khawatir tentang satu 'masalah kontrol akses'. Cara termudah adalah menggunakan skema bertingkat, di mana ada proses 'penghubungan' cepat yang memungkinkan pengguna untuk mengatur dompet utama mereka sebagai pengawas untuk semua dompet dalam aplikasi.
Secara default, pemulihan akun Warpcast Anda dikendalikan oleh tim Warpcast. Namun, Anda dapat 'mengambil alih' akun Farcaster Anda dan mengubah pemulihan ke alamat Anda sendiri.
Melindungi pengguna dari penipuan dan ancaman eksternal lainnya
Selain keamanan akun, dompet saat ini juga melakukan banyak pekerjaan untuk mengidentifikasi alamat palsu, phishing, penipuan, dan ancaman eksternal lainnya, dan berusaha melindungi pengguna dari ancaman tersebut. Sementara itu, banyak langkah mitigasi masih cukup primitif: misalnya, meminta klik untuk mengirim ETH atau token lainnya ke alamat baru, tidak peduli apakah yang Anda kirim adalah $100 atau $100,000. Di sini tidak ada satu solusi ajaib. Ini adalah serangkaian perbaikan dan peningkatan yang lambat dan berkelanjutan untuk berbagai kategori ancaman. Namun, terus berupaya untuk memperbaiki di sini memiliki banyak nilai.
Privasi
Sekarang saatnya untuk mulai lebih serius tentang privasi di Ethereum. Teknologi ZK-SNARK sekarang sangat maju, dan teknologi privasi yang tidak bergantung pada pintu belakang untuk mengurangi risiko regulasi (seperti kolam privasi) semakin matang, dan infrastruktur lapisan kedua seperti Waku dan mempool ERC-4337 juga perlahan menjadi lebih stabil. Namun, hingga saat ini, melakukan transfer pribadi di Ethereum memerlukan pengguna untuk secara eksplisit mengunduh dan menggunakan 'dompet privasi', seperti Railway (atau untuk alamat tidak terlihat Umbra). Ini menambah ketidaknyamanan besar dan mengurangi jumlah orang yang bersedia melakukan transfer pribadi. Solusinya adalah bahwa transfer pribadi perlu terintegrasi langsung ke dalam dompet.
Implementasi sederhana adalah sebagai berikut. Dompet dapat menyimpan sebagian dari aset pengguna sebagai 'saldo pribadi' di kolam privasi. Ketika pengguna melakukan transfer, mereka akan otomatis keluar dari kolam privasi. Jika pengguna perlu menerima dana, dompet dapat secara otomatis menghasilkan alamat yang tidak terlihat.
Selain itu, dompet dapat secara otomatis menghasilkan alamat baru untuk setiap aplikasi yang diikuti pengguna (misalnya, protokol defi). Setoran akan berasal dari kolam privasi, dan penarikan akan langsung masuk ke kolam privasi. Ini memungkinkan aktivitas pengguna di satu aplikasi tidak dapat ditautkan dengan aktivitas mereka di aplikasi lain.
Salah satu keuntungan dari teknologi ini adalah bahwa itu tidak hanya merupakan cara alami untuk memindahkan aset dengan perlindungan privasi, tetapi juga cara alami untuk melindungi identitas dengan privasi. Identitas sudah terjadi di rantai: setiap aplikasi yang menggunakan identifikasi berbasis kunci (seperti Hibah Gitcoin), setiap obrolan berbasis token, protokol berbasis Ethereum, dan sebagainya merupakan identitas di rantai. Kami ingin ekosistem ini juga melindungi privasi. Ini berarti aktivitas pengguna di rantai tidak boleh dikumpulkan di satu tempat: setiap proyek harus disimpan secara terpisah, dan dompet pengguna harus menjadi satu-satunya yang memiliki 'pandangan global' yang dapat melihat semua bukti Anda sekaligus. Ekosistem asli di mana setiap pengguna memiliki beberapa akun membantu mencapai tujuan ini, begitu juga dengan protokol bukti off-chain seperti EAS dan Zupass.
Ini mewakili visi pragmatis untuk privasi Ethereum dalam jangka menengah. Meskipun beberapa fitur dapat diperkenalkan di L1 dan L2 untuk membuat perlindungan privasi transfer lebih efisien dan dapat diandalkan, itu sudah dapat dilakukan sekarang. Beberapa advokat privasi berpendapat bahwa satu-satunya hal yang dapat diterima adalah privasi lengkap dari semua hal: enkripsi seluruh EVM. Saya pikir ini mungkin hasil ideal jangka panjang, tetapi itu memerlukan pemikiran kembali yang lebih mendasar tentang model pemrograman, dan saat ini belum berada pada tingkat kematangan yang siap untuk diterapkan di Ethereum. Kita memang perlu privasi default untuk mendapatkan kumpulan anonim yang cukup besar. Namun, memfokuskan perhatian pertama pada (i) transfer antar akun, dan (ii) identitas serta kasus penggunaan terkait identitas (seperti bukti pribadi) adalah langkah pragmatis pertama yang lebih mudah dicapai, dan dompet sekarang dapat mulai menggunakannya.
Dompet Ethereum juga perlu menjadi dompet data
Salah satu konsekuensi dari setiap solusi privasi yang valid adalah bahwa, baik untuk pembayaran, identitas, atau kasus penggunaan lainnya, itu akan menghasilkan kebutuhan bagi pengguna untuk menyimpan data di luar rantai. Ini terlihat jelas dalam Tornado Cash, yang meminta pengguna untuk menyimpan 'kwitansi' yang mewakili setoran 0.1-100 ETH. Protokol privasi yang lebih modern kadang-kadang menyimpan data yang terenkripsi di rantai dan mendekripsinya dengan satu kunci pribadi. Ini berisiko, karena jika kunci bocor, atau komputer kuantum menjadi layak, data tersebut akan terbuka sepenuhnya. Permintaan untuk penyimpanan data di luar rantai menjadi lebih jelas dengan bukti off-chain seperti EAS dan Zupass.
Dompet tidak hanya perlu menjadi perangkat lunak penyimpanan akses rantai, tetapi juga perangkat lunak penyimpanan data pribadi Anda. Dunia non-kriptografi juga semakin menyadari hal ini; lihat saja pekerjaan terbaru Tim Berners-Lee dalam penyimpanan data pribadi. Semua yang perlu kita selesaikan di sekitar jaminan akses yang kuat, kita juga perlu menyelesaikan di sekitar jaminan aksesibilitas data yang kuat dan tidak bocor. Mungkin solusi-solusi ini dapat ditumpuk: jika Anda memiliki N pengawas, gunakan berbagi rahasia M-dari-N di antara N pengawas Anda untuk menyimpan data Anda. Data pada dasarnya lebih sulit untuk dilindungi karena Anda tidak dapat mencabut bagian data seseorang, tetapi kita harus mengusulkan solusi hosting terdesentralisasi yang seaman mungkin.
Akses rantai yang aman
Saat ini, dompet mempercayai penyedia RPC mereka untuk memberi tahu mereka tentang informasi apa pun tentang rantai. Ini adalah celah, dengan dua aspek:
Penyedia RPC mungkin mencoba mencuri uang dengan memberikan informasi palsu kepada mereka, seperti tentang harga pasar.
Penyedia RPC dapat menarik informasi pribadi tentang aplikasi dan akun lain yang digunakan pengguna.
Idealnya, kami ingin menutup dua celah ini. Untuk mengatasi masalah pertama, kami memerlukan klien ringan yang distandarisasi untuk L1 dan L2, yang dapat memverifikasi konsensus blockchain secara langsung. Helios telah melakukan ini untuk L1 dan telah melakukan beberapa pekerjaan awal untuk mendukung beberapa L2 tertentu. Untuk benar-benar mencakup semua L2, kami memerlukan standar di mana kontrak konfigurasi yang mewakili L2 (yang juga digunakan untuk alamat spesifik rantai) dapat menyatakan fungsi, mungkin dengan cara yang mirip dengan ERC-3668, yang mencakup logika untuk mendapatkan akar status terbaru dan memverifikasi bukti untuk negara bagian dan tanda terima untuk akar-akar tersebut. Dengan cara ini, kita dapat memiliki klien ringan universal yang memungkinkan dompet untuk memverifikasi status atau peristiwa di L1 dan L2 dengan aman.
Untuk privasi, metode nyata satu-satunya saat ini adalah menjalankan node penuh Anda sendiri. Namun, sekarang L2 semakin menjadi perhatian, menjalankan node penuh untuk segalanya menjadi semakin sulit. Di sini, yang setara dengan klien ringan adalah pencarian informasi pribadi (PIR). PIR melibatkan server yang menyimpan salinan semua data dan klien yang mengirim permintaan terenkripsi ke server. Server melakukan perhitungan pada semua data, mengembalikan data yang diminta klien, dan mengenkripsi ke kunci klien, tanpa mengungkapkan kepada server data mana yang diakses klien.
Untuk menjaga kejujuran server, proyek basis data individu itu sendiri adalah cabang Merkle, sehingga klien dapat menggunakan klien ringan untuk memverifikasinya.
PIR memiliki beban perhitungan yang sangat besar. Ada beberapa cara untuk mengatasi masalah ini:
Dengan kekuatan bruteforce: perbaikan algoritma atau perangkat keras khusus dapat membuat PIR berjalan cukup cepat. Teknologi ini mungkin bergantung pada pra-pemrosesan: server dapat menyimpan data yang terenkripsi dan diacak untuk setiap klien, dan klien dapat mengajukan permintaan untuk data tersebut. Tantangan utama dalam lingkungan Ethereum adalah menyesuaikan teknologi ini dengan kumpulan data yang berubah dengan cepat (seperti negara). Ini membuat biaya perhitungan waktu nyata lebih rendah, tetapi kemungkinan besar meningkatkan total biaya perhitungan dan penyimpanan.
Mengurangi kebutuhan privasi: misalnya, hanya dapat memiliki 1 juta 'mixins' per pencarian, sehingga server akan tahu satu juta nilai yang mungkin diakses klien, tetapi tidak tahu granularitas yang lebih halus.
PIR multiserver: Jika Anda menggunakan beberapa server, dan asumsi kejujuran antar server adalah 1-dari-N, maka algoritma PIR biasanya akan lebih cepat.
Anonimitas bukannya kerahasiaan: permintaan dapat dikirim melalui jaringan campuran, menyembunyikan pengirim permintaan, alih-alih menyembunyikan isi permintaan. Namun, melakukan ini secara efektif tidak dapat dihindari akan menambah latensi, yang memperburuk pengalaman pengguna.
Menemukan kombinasi teknologi yang tepat untuk memaksimalkan privasi di lingkungan Ethereum, sambil tetap menjaga kegunaan, adalah masalah penelitian terbuka, dan saya menyambut baik upaya para kriptografer untuk melakukan ini.
Dompet kunci penyimpanan yang ideal
Selain transfer dan akses status, alur kerja penting lainnya yang perlu berjalan lancar dalam konteks lintas L2 adalah mengubah konfigurasi verifikasi akun: baik itu mengubah kunci mereka (misalnya pemulihan), atau melakukan perubahan yang lebih mendalam terhadap logika seluruh akun. Di sini ada solusi tiga lapisan, diurutkan berdasarkan peningkatan kesulitan:
Pembaruan replay: Ketika pengguna mengubah konfigurasi mereka, pesan yang mengotorisasi perubahan ini akan diputar ulang di setiap rantai yang terdeteksi dompet di mana pengguna memiliki aset. Mungkin, format pesan dan aturan validasi dapat independen dari rantai, sehingga dapat diputar ulang secara otomatis di sebanyak mungkin rantai.
Kunci penyimpanan di L1: Informasi konfigurasi berada di L1, dan dompet di L2 menggunakan L1SLOAD untuk membacanya atau memanggil secara statis dari jarak jauh. Dengan cara ini, hanya perlu memperbarui konfigurasi di L1, konfigurasi akan secara otomatis berlaku.
Kunci penyimpanan di L2: Informasi konfigurasi berada di L2, dan dompet di L2 membacanya menggunakan ZK-SNARK. Ini sama dengan (2), kecuali pembaruan kunci penyimpanan mungkin lebih murah, tetapi di sisi lain pembacaan lebih mahal.
Solusi (3) sangat kuat karena dapat bekerja dengan baik dengan privasi. Dalam 'solusi privasi' yang normal, pengguna memiliki rahasia s, menerbitkan 'nilai daun' L di rantai, pengguna membuktikan L = hash(s, 1) dan N = hash(s, 2) untuk beberapa rahasia (yang tidak pernah diungkapkan) yang mereka kendalikan. Nilai tidak valid N diterbitkan sehingga memastikan pengeluaran masa depan dari daun yang sama akan gagal tanpa mengungkapkan L yang bergantung pada keamanan s pengguna. Solusi privasi yang ramah pemulihan akan mengatakan: s adalah lokasi (misalnya alamat dan slot penyimpanan) di rantai, pengguna harus membuktikan kueri status: L = hash(sload(s), 1).
Keamanan dapp
Tautan terlemah dalam keamanan pengguna biasanya adalah dapp. Sebagian besar waktu, pengguna berinteraksi dengan aplikasi melalui situs web, yang secara implisit mengunduh kode antarmuka pengguna dari server secara waktu nyata dan mengeksekusinya di browser. Jika server diretas, atau DNS diretas, pengguna akan mendapatkan salinan antarmuka yang palsu, yang dapat menipu pengguna untuk melakukan tindakan sembarangan. Fungsi dompet seperti simulasi transaksi sangat membantu dalam mengurangi risiko, tetapi mereka masih jauh dari sempurna.
Idealnya, kita akan memindahkan ekosistem ke kontrol versi konten rantai: pengguna akan mengakses dapp melalui nama ENS mereka, yang akan menyertakan nilai hash IPFS untuk antarmuka. Memperbarui antarmuka membutuhkan transaksi rantai dari multisignature atau DAO. Dompet akan menunjukkan kepada pengguna apakah mereka berinteraksi dengan antarmuka rantai yang lebih aman atau antarmuka Web2 dengan keamanan lebih rendah. Dompet juga dapat menunjukkan kepada pengguna apakah mereka berinteraksi dengan rantai yang aman (misalnya fase 1+, beberapa audit keamanan).
Untuk pengguna yang mementingkan privasi, dompet juga dapat menambahkan mode paranoid, yang meminta pengguna untuk mengklik untuk menerima permintaan HTTP, bukan hanya operasi web3:
Model antarmuka mode paranoid yang mungkin
Pendekatan yang lebih maju adalah melampaui HTML + Javascript, dan menulis logika bisnis dapp menggunakan bahasa khusus (mungkin lapisan tipis relatif pada Solidity atau Vyper). Kemudian, browser dapat secara otomatis menghasilkan UI untuk semua fungsi yang diperlukan. OKContract sudah melakukan hal ini.
Arah lain adalah pertahanan informasi ekonomi terenkripsi: pengembang dapp, perusahaan keamanan, penyebar rantai, dan lainnya dapat membangun obligasi, yang jika dapp diretas atau merugikan pengguna dengan cara yang sangat menyesatkan, obligasi tersebut akan dibayarkan kepada pengguna yang terkena dampak (yang ditentukan) oleh beberapa DAO arbitrase di rantai. Dompet dapat menunjukkan kepada pengguna skor berdasarkan ukuran obligasi.
Masa depan jangka panjang
Semua di atas dilakukan dalam konteks antarmuka tradisional, yang melibatkan menunjuk dan mengklik hal-hal serta memasukkan hal-hal ke dalam kolom teks. Namun, kita juga berada di ambang perubahan paradigma yang lebih mendalam:
Kecerdasan buatan, yang dapat menyebabkan kita beralih dari paradigma mengetik berbasis klik ke paradigma 'katakan apa yang ingin Anda lakukan, robot akan mengerti'.
Antarmuka otak-mesin, dengan metode "lembut" seperti pelacakan gerakan mata dan teknologi yang lebih langsung bahkan invasif (lihat: pasien Neuralink pertama tahun ini).
Pertahanan aktif klien: Browser Brave secara aktif melindungi pengguna dari iklan, pelacak, dan berbagai objek jahat lainnya. Banyak browser, plugin, dan dompet crypto memiliki tim yang berdedikasi untuk melindungi pengguna dari berbagai ancaman keamanan dan privasi. 'Pelindung aktif' ini hanya akan semakin kuat dalam dekade mendatang.
Ketiga tren ini bersama-sama akan menyebabkan pemikiran yang lebih mendalam tentang cara kerja antarmuka. Melalui input bahasa alami, pelacakan mata, atau akhirnya antarmuka otak-mesin yang lebih langsung, ditambah dengan riwayat Anda (mungkin termasuk pesan teks, selama semua data diproses secara lokal), 'dompet' dapat dengan jelas dan intuitif memahami apa yang ingin Anda lakukan. Kemudian, kecerdasan buatan dapat mengubah intuisi ini menjadi 'rencana tindakan' konkret: serangkaian interaksi di rantai dan di luar rantai untuk menyelesaikan apa yang ingin Anda lakukan. Ini dapat secara signifikan mengurangi kebutuhan akan antarmuka pengguna pihak ketiga. Jika pengguna memang berinteraksi dengan aplikasi pihak ketiga (atau pengguna lain), kecerdasan buatan harus melakukan pemikiran antagonis atas nama pengguna, mengidentifikasi ancaman apa pun dan mengusulkan rencana tindakan untuk menghindari ancaman tersebut. Idealnya, kecerdasan buatan ini harus memiliki ekosistem terbuka yang dihasilkan oleh kelompok dengan berbagai bias dan struktur insentif.
Ide-ide yang lebih radikal ini tergantung pada teknologi yang saat ini sangat belum matang, jadi saya tidak akan menempatkan aset saya di dompet yang bergantung padanya. Namun, hal-hal serupa tampaknya jelas merupakan tren masa depan, sehingga layak untuk mulai mengeksplorasi ke arah ini dengan lebih agresif.
