Pengalaman pengguna dari transaksi lintas-L2

Saat ini ada rencana kerja yang semakin terperinci untuk meningkatkan pengalaman pengguna lintas L2, yang memiliki bagian jangka pendek dan bagian jangka panjang. Di sini, saya akan membahas bagian jangka pendek: ide-ide yang secara teori dapat diimplementasikan bahkan hari ini.

Idea inti adalah (i) pengiriman lintas-L2 bawaan, dan (ii) alamat khusus rantai dan permintaan pembayaran. Dompet Anda seharusnya dapat memberi Anda alamat yang (mengikuti gaya dari ERC konsep ini) terlihat seperti ini:

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

Ketika seseorang (atau aplikasi tertentu) memberi Anda alamat dalam format ini, Anda seharusnya dapat menempelkannya ke kolom "ke" dompet, dan klik "kirim". Dompet seharusnya secara otomatis memproses pengiriman tersebut dengan cara apa pun yang dapat dilakukannya:

• Jika Anda sudah memiliki cukup koin dari jenis yang dibutuhkan di rantai tujuan, kirim koin secara langsung.
• Jika Anda memiliki koin tipe yang dibutuhkan di rantai lain (atau beberapa rantai lain), gunakan protokol seperti ERC-7683 (efektifnya DEX lintas-rantai) untuk mengirim koin
• Jika Anda memiliki koin dengan jenis yang berbeda di rantai yang sama atau rantai lain, gunakan pertukaran terdesentralisasi untuk mengonversinya menjadi jenis koin yang tepat di rantai yang tepat dan kirimkan. Ini seharusnya memerlukan izin eksplisit dari pengguna: pengguna akan melihat seberapa banyak dari apa yang mereka bayar, dan seberapa banyak penerima yang akan menerima.

Mockup antarmuka dompet yang mungkin dengan dukungan alamat lintas rantai

Di atas adalah untuk “Anda menyalin dan paste alamat (atau ENS, misalnya,vitalik.eth@optimism.eth) untuk seseorang membayar Anda” gunakan kasus. Jika suatu dapp meminta deposit (misalnya lihat contoh Polymarket ini) maka alur yang ideal adalah memperluas API web3 dan memungkinkan dapp untuk membuat permintaan pembayaran khusus untuk suatu chain. Dompet Anda kemudian dapat memenuhi permintaan tersebut dengan cara apa pun yang diperlukan. Untuk membuat pengalaman pengguna berjalan dengan baik, juga diperlukan standardisasi permintaan getAvailableBalance, dan dompet perlu memikirkan dengan serius chain mana yang mereka simpan aset pengguna secara default untuk memaksimalkan keamanan dan kemudahan transfer.

Permintaan pembayaran khusus rantai juga bisa dimasukkan ke dalam kode QR, yang dapat dipindai dompet seluler. Dalam skenario pembayaran konsumen secara langsung (atau online), penerima akan membuat panggilan API kode QR atau web3 yang mengatakan “Saya ingin X unit token Y di rantai Z, dengan ID referensi atau panggilan balik W”, dan dompet bebas untuk memenuhi permintaan tersebut dengan cara apa pun. Opsi lainnya adalah protokol tautan klaim, di mana dompet pengguna menghasilkan kode QR atau URL yang berisi otorisasi untuk mengklaim sejumlah dana dari kontrak onchain mereka, dan tugas penerima adalah mencari tahu bagaimana cara untuk kemudian memindahkan dana tersebut ke dompet mereka sendiri.

Topik terkait lainnya adalah pembayaran gas. Jika Anda menerima aset di L2 di mana Anda belum memiliki ETH, dan Anda perlu mengirim transaksi di L2 tersebut, dompet seharusnya dapat secara otomatis menggunakan protokol (misalnya. RIP-7755) untuk membayar gas di suatu rantai di mana Anda memiliki ETH. Jika dompet mengharapkan Anda melakukan lebih banyak transaksi di L2 tersebut di masa depan, dompet juga sebaiknya menggunakan DEX untuk mengirim sejumlah gas ETH yang bernilai beberapa juta, sehingga transaksi di masa depan dapat langsung menggunakan gas tersebut (karena lebih murah).

Keamanan akun

Salah satu cara saya memahami tantangan keamanan akun adalah bahwa dompet yang baik seharusnya secara bersamaan baik dalam dua hal: (i) melindungi pengguna dari pengembang dompet yang diretas atau bersifat jahat, dan (ii) melindungi pengguna dari kesalahan mereka sendiri.

Kesalahan ketik 'mistakles' di sebelah kiri tidak disengaja. Namun, setelah melihatnya saya menyadari bahwa itu sangat sesuai dengan konteksnya, jadi saya memutuskan untuk tetap mempertahankannya.

Solusi yang saya pilih untuk ini, untuk lewatsepuluhtahunTelah dilakukan pemulihan sosial dan dompet multisig, dengan kontrol akses bertingkat. Akun pengguna memiliki dua lapisan kunci: kunci utama, dan N penjaga (misalnya N = 5). Kunci utama dapat melakukan operasi dengan nilai rendah dan non-keuangan. Mayoritas penjaga diperlukan untuk melakukan (i) operasi dengan nilai tinggi, seperti mengirim seluruh nilai dalam akun, atau (ii) mengubah kunci utama atau salah satu penjaga. Jika diinginkan, kunci utama dapat diizinkan untuk melakukan operasi dengan nilai tinggi dengan penguncian waktu.

Di atas adalah desain dasar, dan dapat diperkuat. Kunci sesi, dan mekanisme izin seperti ERC-7715Dapat membantu mendukung keseimbangan yang berbeda antara kenyamanan dan keamanan untuk aplikasi yang berbeda. Arsitektur pengawal yang lebih rumit, seperti memiliki beberapa durasi kunci waktu pada ambang batas yang berbeda, dapat membantu memaksimalkan peluang pemulihan akun yang sah sambil meminimalkan risiko pencurian.

Siapa atau apa seharusnya menjadi penjaga?

Bagi pengguna kripto berpengalaman yang berada di dalam komunitas pengguna kripto berpengalaman, opsi yang layak adalah kunci dari teman dan keluarga Anda. Jika Anda meminta masing-masing dari mereka untuk memberi Anda alamat baru, maka tidak ada yang perlu tahu siapa mereka sebenarnya - bahkan, penjaga Anda bahkan tidak perlu tahu siapa satu sama lain. Kemungkinan bahwa mereka akan berkolusi tanpa seorang pun dari mereka memberi tahu Anda sangat kecil. Namun, bagi sebagian besar pengguna baru, opsi ini tidak tersedia.

Opsi kedua adalah wali institusional: perusahaan yang mengkhususkan diri dalam memberikan layanan hanya untuk menandatangani transaksi jika mereka mendapatkan konfirmasi lain bahwa permintaan berasal dari Anda: misalnya kode konfirmasi, atau untuk pengguna dengan nilai tinggi, panggilan video. Orang telah mencoba membuat ini dalam waktu yang lama, misalnya. Saya memprofil CryptoCorp pada tahun 2013Namun, sejauh ini perusahaan-perusahaan tersebut belum begitu sukses.

Opsi ketiga adalah beberapa perangkat pribadi (misalnya telepon, desktop, dompet keras). Ini bisa berhasil, tetapi juga sulit untuk diatur dan dikelola bagi pengguna yang tidak berpengalaman. Ada juga risiko perangkat hilang atau dicuri pada saat yang sama, terutama jika mereka berada di lokasi yang sama.

Baru-baru ini, kita mulai melihat lebih banyak dompet berbasis kunci sandi. Kunci sandi dapat dipulihkan hanya pada perangkat Anda, menjadikannya sebagai solusi perangkat pribadi, atau dipulihkan di cloud, menjadikan keamanannya bergantung pada rumit hybridKeamanan kata sandi, asumsi perangkat keras institusional dan terpercaya. Secara realistis, kunci sandi adalah keuntungan keamanan berharga bagi pengguna biasa, tetapi mereka sendiri tidak cukup kuat untuk melindungi tabungan hidup pengguna.

Untungnya, dengan ZK-SNARKs, kita memiliki opsi keempat: ID terpusat yang dibungkus ZK. Genre ini mencakup gate.zk-email, Anon Aadhaar, Dompet Myna, dan banyak lainnya. Pada dasarnya, Anda dapat mengambil banyak bentuk ID terpusat (korporat atau pemerintah), dan mengubahnya menjadi alamat Ethereum, yang hanya dapat Anda kirim transaksi dari dengan menghasilkan bukti kepemilikan ZK-SNARK dari ID terpusat.

Dengan penambahan ini, kami sekarang memiliki beragam pilihan, dan ID terpusat yang dibungkus ZK ini secara unik "ramah pemula".

Untuk ini bekerja, ini perlu diimplementasikan dengan antarmuka pengguna yang terintegrasi dan lancar: Anda harus dapat hanya menentukan bahwa Anda ingin "example@gmail.comSebagai penjaga, dan seharusnya secara otomatis menghasilkan alamat Ethereum zk-email yang sesuai di bawah kap mesin. Pengguna lanjutan seharusnya dapat memasukkan email mereka (bersama dengan mungkin nilai salt untuk privasi, yang akan disimpan dalam email tersebut) ke dalam aplikasi pihak ketiga sumber terbuka, dan mengonfirmasi bahwa alamat yang dihasilkan benar. Hal yang sama seharusnya berlaku untuk jenis penjaga lain yang didukung.

Mockup antarmuka Safe yang mungkin

Perlu diingat bahwa saat ini, tantangan praktis dengan zk-email khususnya adalah bahwa itu bergantung pada Tanda tangan DKIM, yang menggunakan kunci yang diputar sekali setiap beberapa bulan, dan kunci-kunci ini sendiri tidak ditandatangani oleh otoritas lain. Ini berarti bahwa zk-email hari ini memiliki tingkat kebutuhan kepercayaan di luar penyedia itu sendiri; ini bisa dikurangi jika zk-email menggunakanTLSNotarydi dalam perangkat keras yang terpercaya untuk memverifikasi kunci yang diperbarui, tetapi ini tidak ideal. Semoga penyedia email akan mulai menandatangani kunci DKIM mereka secara langsung. Hari ini, saya akan merekomendasikan menggunakan zk-email untuk satu wali, tetapi tidak untuk sebagian besar wali Anda: jangan menyimpan dana dalam konfigurasi di mana zk-email rusak berarti Anda kehilangan akses ke dana Anda.

Pengguna baru dan dompet dalam aplikasi

Pengguna baru realistis tidak akan ingin memasukkan sejumlah besar wali dalam pengalaman pendaftaran pertama mereka. Oleh karena itu, dompet seharusnya menawarkan opsi yang sangat sederhana. Salah satu pilihan alami adalah 2 dari 3 menggunakan zk-email pada alamat email mereka, kunci yang disimpan secara lokal pada perangkat pengguna (yang bisa menjadi kunci sandi), dan kunci cadangan yang dipegang oleh penyedia. Ketika pengguna semakin berpengalaman, atau mengumpulkan lebih banyak aset, pada suatu titik mereka harus diminta untuk menambahkan lebih banyak wali.

Dompet yang terintegrasi dalam aplikasi tidak dapat dihindari, karena aplikasi yang mencoba menarik pengguna non-kripto tidak menginginkan pengalaman pengguna yang membingungkan dengan meminta pengguna mereka untuk mengunduh dua aplikasi baru (aplikasi itu sendiri, ditambah dompet Ethereum) pada saat yang sama. Namun, pengguna dari banyak dompet aplikasi seharusnya dapat menghubungkan semua dompet mereka bersama, sehingga mereka hanya perlu memikirkan satu "hal pengendali akses". Cara termudah untuk melakukannya adalah skema hierarkis, di mana ada proses "penghubung" cepat yang memungkinkan pengguna untuk menetapkan dompet utama mereka sebagai penjaga dari semua dompet dalam aplikasi mereka. Klien Farcaster Warpcast sudah mendukung hal ini:

Secara default, pemulihan akun Warpcast Anda dikendalikan oleh tim Warpcast. Namun, Anda dapat "mengambil kedaulatan atas" akun Farcaster Anda, dan mengubah pemulihan ke alamat Anda sendiri.

Melindungi pengguna dari penipuan dan ancaman eksternal lainnya

Selain keamanan akun, dompet saat ini melakukan banyak hal untuk mengidentifikasi alamat palsu, phishing, penipuan, dan ancaman eksternal lainnya, dan berusaha melindungi penggunanya dari ancaman tersebut. Pada saat yang sama, banyak tindakan pencegahan masih cukup primitif: misalnya, memerlukan klik untuk mengirim ETH atau token lain ke alamat baru apa pun, terlepas dari apakah Anda mengirim $100 atau $100.000. Di sini, tidak ada solusi ajaib tunggal; ini adalah serangkaian perbaikan perlahan dan peningkatan terhadap berbagai kategori ancaman. Namun, ada banyak nilai dalam terus melakukan pekerjaan keras untuk memperbaiki hal ini.

Privasi

Sekarang saatnya untuk mulai serius mengenai privasi di Ethereum. Teknologi ZK-SNARK kini sangat canggih, teknologi privasi yang mengurangi risiko regulasi tanpa bergantung pada pintu belakang, seperti Kolam Renang Privasi, semakin matang, dan infrastruktur sekunder seperti Wakudan mempool ERC-4337 mulai menjadi lebih stabil secara perlahan-lahan. Namun, hingga saat ini, melakukan transfer pribadi di Ethereum memerlukan pengguna untuk secara eksplisit mengunduh dan menggunakan “dompet privasi”, seperti Kereta api(atau Umbrauntukalamat tersembunyiIni menambahkan ketidaknyamanan besar dan mengurangi jumlah orang yang bersedia melakukan transfer pribadi. Solusinya adalah transfer pribadi perlu diintegrasikan langsung ke dalam dompet.

Sebuah implementasi sederhana adalah sebagai berikut. Sebuah dompet bisa menyimpan sebagian dari aset pengguna sebagai "saldo pribadi" dalam kolam privasi. Ketika pengguna melakukan transfer, itu akan secara otomatis menarik dana dari kolam privasi terlebih dahulu. Jika seorang pengguna perlu menerima dana, dompet bisa secara otomatis menghasilkan alamat sembunyi.

Selain itu, dompet bisa secara otomatis menghasilkan alamat baru untuk setiap aplikasi yang diikuti pengguna (misalnya protokol defi). Deposit berasal dari kolam privasi, dan penarikan langsung masuk ke dalam kolam privasi. Hal ini memungkinkan aktivitas pengguna di setiap aplikasi tidak terhubung dengan aktivitas mereka di aplikasi lainnya.

Salah satu keuntungan dari teknik ini adalah bahwa ini adalah jalur alami tidak hanya untuk transfer aset yang menjaga privasi, tetapi juga identitas yang menjaga privasi. Identitas terjadi di dalam jaringan: aplikasi apa pun yang menggunakan pintu gerbang bukti kepemilikan pribadi (misalnya, Gitcoin Grants), obrolan yang hanya dapat diakses dengan token, Ethereum Ikuti Protokol, dan banyak lagi semuanya adalah identitas onchain. Kami ingin ekosistem ini juga menjaga privasi. Ini berarti bahwa aktivitas onchain pengguna tidak boleh dikumpulkan di satu tempat: setiap item harus disimpan secara terpisah, dan dompet pengguna harus menjadi satu-satunya hal dengan "tampilan global" yang melihat semua pengesahan Anda pada saat yang sama. Ekosistem banyak akun per pengguna asli membantu mencapai hal ini, seperti halnya protokol pengesahan offchain seperti EASdanZupass.

Ini mewakili visi pragmatis untuk privasi Ethereum dalam jangka menengah ke depan. Ini dapat diimplementasikan hari ini, meskipun ada fitur yang dapat diperkenalkan di L1 dan L2 untuk membuat transfer yang menjaga privasi lebih efisien dan dapat diandalkan. Beberapa pengagum privasi berpendapat bahwa hal yang hanya dapat diterima adalah privasi total dari segalanya: mengenkripsi seluruh EVM. Saya akan berpendapat bahwa ini mungkin ideal sebagai hasil jangka panjang, tetapi ini memerlukan pemikiran ulang yang jauh lebih mendasar tentang model pemrograman, dan saat ini belum mencapai tingkat kematangan di mana sudah siap untuk digunakan dan diterapkan di seluruh Ethereum. Kita memerlukan privasi secara default untuk mendapatkan kumpulan anonimitas yang cukup besar. Namun, fokus pertama pada membuat (i) transfer antar akun, dan (ii) identitas dan kasus penggunaan terkait identitas seperti pernyataan pribadi adalah langkah awal yang pragmatis yang jauh lebih mudah untuk diimplementasikan, dan dompet dapat memulainya hari ini.

Dompet Ethereum juga harus menjadi dompet data

Salah satu konsekuensi dari solusi privasi yang efektif, baik untuk pembayaran atau untuk identitas atau kasus penggunaan lainnya, adalah bahwa hal itu menciptakan kebutuhan bagi pengguna untuk menyimpan data offchain. Ini jelas dalam Tornado Cash, yang mengharuskan pengguna untuk menyimpan setiap "catatan" individu yang mewakili setoran 0,1-100 ETH. Protokol privasi yang lebih modern terkadang menyimpan data yang dienkripsi secara onchain, dan menggunakan satu kunci pribadi untuk mendekripsinya. Ini berisiko, karena jika kuncinya bocor, atau jika komputer kuantum menjadi layak, semua data menjadi publik. Pengesahan offchain seperti EAS dan Zupass memiliki kebutuhan yang lebih jelas untuk penyimpanan data offchain.

Dompet perlu menjadi bukan hanya perangkat lunak untuk menyimpan izin akses onchain, tetapi juga perangkat lunak untuk menyimpan data pribadi Anda. Ini adalah sesuatu yang dunia non-kripto semakin mengakui juga, misalnya lihat Tim Berners-Lee’skerja terbaru di toko data pribadi. Semua masalah yang perlu kita selesaikan seputar jaminan kontrol izin akses yang kuat, kita juga perlu selesaikan seputar jaminan aksesibilitas dan tidak bocornya data dengan kuat. Mungkin solusinya bisa digabungkan bersama: jika Anda memiliki N penjaga, gunakan pembagian rahasia M-dari-N antara para penjaga yang sama untuk menyimpan data Anda. Data secara inheren lebih sulit untuk diamankan, karena Anda tidak dapat mencabut bagian seseorang darinya, tetapi kita harus mencari solusi penyimpanan terdesentralisasi yang aman sebisa mungkin.

Akses rantai yang aman

Hari ini, wallet mempercayai penyedia RPC mereka untuk memberi tahu mereka informasi apa pun tentang suatu rantai. Ini adalah kerentanan dalam dua hal:

1. Penyedia RPC bisa mencoba mencuri uang dengan memberikan informasi palsu kepada mereka, misalnya tentang harga pasar
2. Penyedia RPC dapat mengekstrak informasi pribadi tentang aplikasi dan akun lain yang digunakan pengguna

Ideally, kita ingin menutup kedua lubang ini. Untuk menutup yang pertama, kita membutuhkan klien ringan yang terstandarisasi untuk L1 dan L2s, yang secara langsung memverifikasi konsensus blockchain.Heliossudah melakukannya untuk L1, dan telah melakukan beberapa pekerjaan awal untuk mendukung beberapa L2 tertentu. Untuk mencakup semua L2 dengan benar, yang kita butuhkan adalah standar di mana kontrak konfigurasi yang mewakili L2 (juga digunakan untuk alamat berdasarkan rantai) dapat mendeklarasikan fungsi, mungkin dengan cara yang mirip denganERC-3668, yang berisi logika untuk mendapatkan akar state terkini, dan memverifikasi bukti state dan kwitansi terhadap akar state tersebut. Dengan cara ini, kita dapat memiliki klien ringan universal, yang memungkinkan dompet untuk memverifikasi dengan aman setiap state atau peristiwa di L1 dan L2.

Untuk privasi, saat ini satu-satunya pendekatan yang realistis adalah menjalankan node lengkap sendiri. Namun, sekarang dengan masuknya L2s, menjalankan node lengkap untuk segalanya semakin sulit. Setara dengan klien ringan di sini adalah pengambilan informasi pribadi (PIR)PIR melibatkan server yang memegang salinan semua data dan klien yang mengirim permintaan terenkripsi ke server. Server melakukan komputasi atas semua data, yang mengembalikan data yang diinginkan klien, terenkripsi dengan kunci klien, tanpa mengungkapkan kepada server bagian data mana yang diakses klien.

Untuk menjaga kejujuran server, item-item database individu akan menjadi cabang-cabang Merkle sendiri, sehingga klien dapat memverifikasinya menggunakan klien ringan mereka.

PIR sangat mahal secara komputasional. Ada beberapa rute di sekitar masalah ini:

• Brute force: perbaikan dalam algoritma, atau perangkat keras khusus, dapat membuat PIR cukup cepat untuk dijalankan. Teknik-teknik ini mungkin bergantung pada pra-pemrosesan: server dapat menyimpan data yang terenkripsi dan teracak untuk setiap klien, dan klien dapat mengajukan pertanyaan pada data tersebut. Tantangan utama dalam pengaturan Ethereum adalah mengadaptasi teknik-teknik ini ke set data yang berubah dengan cepat (seperti keadaan). Hal ini membuat biaya komputasi secara real-time lebih rendah, tetapi mungkin juga membuat biaya komputasi dan penyimpanan total lebih tinggi.
• Melemahkan persyaratan privasi: misalnya, setiap pencarian hanya boleh memiliki 1 juta "campuran", jadi server akan mengetahui sejuta nilai yang mungkin diakses oleh klien, namun tidak dengan granularitas yang lebih halus
• Multi-server PIR: Algoritma PIR seringkali jauh lebih cepat jika Anda menggunakan beberapa server dengan asumsi kejujuran 1-dari-N di antara server-server tersebut.
• Anonimitas alih-alih kerahasiaan: alih-alih menyembunyikan isi permintaan, permintaan dapat dikirim melalui mixnet, menyembunyikan pengirim permintaan. Namun, melakukannya secara efektif tidak dapat dihindari meningkatkan laten, memperburuk pengalaman pengguna.

Mencari tahu kombinasi teknik yang tepat untuk memaksimalkan privasi sambil menjaga praktikalitas dalam konteks Ethereum adalah masalah penelitian terbuka, dan saya menyambut baik para ahli kriptografi yang mencoba mengatasi hal ini.

Dompet keystore ideal

Selain transfer dan akses keadaan, alur kerja penting lainnya yang perlu berjalan lancar dalam konteks lintas-L2 adalah mengubah konfigurasi validasi akun: apakah mengubah kuncinya (mis. pemulihan), atau perubahan yang lebih dalam terhadap logika keseluruhan akun. Di sini, ada tiga tingkat solusi, dari yang paling mudah hingga yang paling sulit.

1. Pemutaran ulang pembaruan: ketika seorang pengguna mengubah konfigurasi mereka, pesan yang mengotorisasi perubahan ini diputar ulang pada setiap rantai di mana dompet mendeteksi bahwa seorang pengguna memiliki aset. Secara potensial, format pesan dan aturan validasi dapat dibuat independen dari rantai, sehingga dapat diputar ulang secara otomatis pada sebanyak mungkin rantai.
2. Keystores di L1: informasi konfigurasi berada di L1, dan dompet di L2 membacanya dengan sebuahL1SLOADatauREMOTESTATICCALLDengan cara ini, pembaruan konfigurasi hanya perlu dilakukan di L1, dan konfigurasi menjadi efektif secara otomatis.
3. Keystore di L2: informasi konfigurasi berada di L2, dan dompet di L2 membacanya dengan ZK-SNARK. Ini sama dengan (2), kecuali pembaruan keystore bisa lebih murah, meskipun di sisi lain membaca lebih mahal.

Solusi (3) sangat kuat karena menumpuk dengan baik dengan privasi. Dalam "solusi privasi" normal, pengguna memiliki rahasia s , "nilai daun" L diterbitkan secara berantai, dan pengguna membuktikan bahwa L = hash (s, 1) dan N = hash (s, 2) untuk beberapa rahasia (tidak pernah terungkap) yang mereka kontrol. Nullifier N dipublikasikan, memastikan bahwa pengeluaran di masa depan dari daun yang sama gagal, tanpa pernah mengungkapkan L. Ini tergantung pada pengguna yang menjaga keamanan. Solusi privasi yang ramah pemulihan malah akan mengatakan: s adalah lokasi (misalnya alamat dan slot penyimpanan) onchain, dan pengguna harus membuktikan kueri status: L = hash (sload, 1) .

Keamanan Dapp

Link terlemah dalam keamanan pengguna seringkali terletak pada dapp. Kebanyakan waktu, pengguna berinteraksi dengan aplikasi dengan pergi ke situs web, yang secara implisit mengunduh kode antarmuka pengguna secara real-time dari server dan kemudian menjalankannya di browser. Jika server diretas, atau jika DNS diretas, pengguna akan mendapatkan salinan palsu dari antarmuka, yang dapat menipu pengguna untuk melakukan hal-hal sembarangan. Fitur dompet seperti simulasi transaksi sangat membantu dalam mengurangi risiko, tetapi jauh dari sempurna.

Idealnya, kita akan memindahkan ekosistem ke versi konten on-chain: pengguna akan mengakses dapp melalui nama ENS-nya, yang akan berisi hash IPFS antarmuka. Transaksi onchain dari multisig atau DAO diperlukan untuk memperbarui antarmuka. Dompet akan menunjukkan kepada pengguna apakah mereka berinteraksi dengan antarmuka onchain yang lebih aman, atau antarmuka web2 yang kurang aman. Dompet juga dapat menunjukkan kepada pengguna apakah mereka berinteraksi dengan rantai yang aman (misalnya tahap 1+, audit keamanan ganda).

Untuk pengguna yang peduli dengan privasi, dompet juga dapat menambahkan mode paranoid, yang membutuhkan pengguna untuk mengklik terima permintaan HTTP, dan bukan hanya operasi web3:

Mockup antarmuka yang mungkin untuk mode paranoid

Pendekatan yang lebih canggih adalah dengan bergerak di luar HTML + Javascript, dan menulis logika bisnis dapps dalam bahasa khusus, mungkin lapisan yang relatif tipis di atas Solidity atau Vyper. Browser kemudian dapat secara otomatis menghasilkan antarmuka pengguna untuk setiap fungsi yang diperlukan.OKContractsudah melakukan ini.

Satu arah lain adalah info-pertahanan kriptoekonomi: pengembang dapp, perusahaan keamanan, penyebar rantai, dan lainnya dapat menyetorkan uang jaminan yang akan dibayarkan kepada pengguna yang terkena dampak jika sebuah dapp diretas atau merugikan pengguna dengan cara yang sangat menyesatkan, seperti yang ditentukan oleh beberapa DAO adjudikasi onchain. Dompet dapat menampilkan skor pengguna yang didasarkan pada besarnya uang jaminan.

Masa depan jangka panjang

Semua di atas adalah dalam konteks antarmuka konvensional, yang melibatkan menunjuk dan mengklik pada hal-hal dan memasukkan hal-hal ke dalam bidang teks. Namun, kita juga berada di ambang paradigma yang berubah jauh lebih dalam:

• AI, yang dapat menyebabkan kita beranjak dari paradigma “klik dan ketik” ke paradigma “katakan apa yang ingin Anda lakukan, dan bot akan mencarinya”
• Antarmuka otak-komputer, baik pendekatan "ringan" seperti pelacakan mata maupun teknik yang lebih langsung dan bahkan invasif (lihat: pasien Neuralink pertama tahun ini)
• Klien yang terlibat dalam pertahanan aktif: browser Bravemelindungi pengguna secara aktif dari iklan, pelacak, dan banyak objek tidak diinginkan lainnya. Banyak browser, plugin, dan dompet kripto memiliki tim yang aktif bekerja untuk melindungi pengguna dari berbagai ancaman keamanan dan privasi. Jenis-jenis 'pengawal aktif' ini akan menjadi semakin kuat dalam dekade mendatang.

Ketiga tren ini bersama-sama akan menyebabkan pemikiran yang jauh lebih dalam tentang bagaimana antarmuka bekerja. Melalui input bahasa alami, pelacakan mata, atau pada akhirnya BCI yang lebih langsung, bersama dengan pengetahuan tentang sejarah Anda (mungkin termasuk pesan teks, selama semua data diproses secara lokal), sebuah “dompet” dapat mendapatkan ide intuitif yang jelas tentang apa yang Anda ingin lakukan. Kecerdasan buatan kemudian dapat menerjemahkan intuisi tersebut menjadi “rencana tindakan” yang konkret: serangkaian interaksi onchain dan offchain yang mencapai apa yang Anda inginkan. Ini dapat sangat mengurangi kebutuhan akan antarmuka pengguna pihak ketiga sepenuhnya. Jika pengguna berinteraksi dengan aplikasi pihak ketiga (atau pengguna lain), kecerdasan buatan harus berpikir secara adversarial atas nama pengguna, dan mengidentifikasi ancaman apa pun dan menyarankan rencana tindakan untuk menghindarinya. Idealnya, akan ada ekosistem terbuka dari kecerdasan buatan ini, yang diproduksi oleh kelompok-kelompok yang berbeda dengan bias dan struktur insentif yang berbeda.

Ide-ide yang lebih radikal ini bergantung pada teknologi yang sangat tidak matang saat ini, jadi saya tidak akan menempatkan aset saya hari ini ke dalam dompet yang bergantung pada mereka. Namun, sesuatu seperti ini tampaknya cukup jelas menjadi masa depan, sehingga layak untuk mulai lebih aktif menjelajahi arah tersebut.

Penafian:

1. Artikel ini dicetak ulang dari [ gatevitalik]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gerbang Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penyangkalan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Belajar gate. Kecuali disebutkan, menyalin, mendistribusikan, atau melakukan plagiarisme terhadap artikel yang diterjemahkan dilarang.