Terima kasih khusus kepada Dan Finlay, Karl Floersch, David Hoffman, dan tim Scroll dan SoulWallet atas umpan balik, tinjauan, dan sarannya.

Ketika Ethereum bertransisi dari teknologi eksperimental muda menjadi tumpukan teknologi matang yang mampu menghadirkan pengalaman yang terbuka, global, dan tanpa izin kepada pengguna pada umumnya, ada tiga transisi teknis utama yang harus dilalui oleh tumpukan tersebut, kira-kira secara bersamaan:

• Transisi penskalaan L2 - semua orang pindah ke rollup
• Transisi keamanan dompet - semua orang beralih ke dompet kontrak pintar
• Transisi privasi - memastikan transfer dana yang menjaga privasi tersedia, dan memastikan semua gadget lain yang sedang dikembangkan (pemulihan sosial, identitas, reputasi) menjaga privasi

Segitiga transisi ekosistem. Anda hanya dapat memilih 3 dari 3.

Tanpa yang pertama, Ethereum akan gagal karena setiap transaksi membutuhkan biaya $3.75 ($82.48 jika kita mengalami kenaikan lagi), dan setiap produk yang ditujukan untuk pasar massal pasti akan melupakan rantai dan mengadopsi solusi terpusat untuk semuanya.

Tanpa yang kedua, Ethereum akan gagal karena pengguna merasa tidak nyaman menyimpan dana mereka (dan aset non-keuangan), dan semua orang akan berpindah ke bursa yang tersentralisasi.

Tanpa yang ketiga, Ethereum akan gagal karena semua transaksi (dan POAP, dll) tersedia secara publik untuk dilihat oleh siapa saja adalah pengorbanan privasi yang terlalu besar bagi banyak pengguna, dan semua orang akan beralih ke solusi terpusat yang setidaknya dapat menyembunyikan data Anda.

Ketiga transisi ini sangat penting untuk alasan di atas. Namun, hal ini juga menantang karena koordinasi yang intens untuk menyelesaikannya dengan benar. Bukan hanya fitur protokol yang perlu ditingkatkan; dalam beberapa kasus, cara kita berinteraksi dengan Ethereum perlu diubah secara mendasar, membutuhkan perubahan mendalam dari aplikasi dan dompet.

Ketiga transisi tersebut akan secara radikal membentuk kembali hubungan antara pengguna dan alamat

Dalam dunia penskalaan L2, pengguna akan ada di banyak L2. Apakah Anda anggota ExampleDAO, yang hidup dengan Optimisme? Kemudian Anda memiliki akun di Optimism! Apakah Anda memegang CDP dalam sistem stablecoin di ZkSync? Kemudian Anda memiliki akun di ZkSync! Apakah Anda pernah mencoba beberapa aplikasi yang kebetulan ada di Kakarot? Maka Anda memiliki akun di Kakarot! Hari-hari di mana pengguna hanya memiliki satu alamat akan hilang.

Saya memiliki ETH di empat tempat, menurut tampilan Dompet Berani saya. Dan ya, Arbitrum dan Arbitrum Nova berbeda. Jangan khawatir, hal ini akan semakin membingungkan seiring berjalannya waktu!

Dompet kontrak pintar menambah kompleksitas, dengan membuatnya jauh lebih sulit untuk memiliki alamat yang sama di seluruh L1 dan berbagai L2. Saat ini, sebagian besar pengguna menggunakan akun yang dimiliki secara eksternal, yang alamatnya secara harfiah merupakan hash dari kunci publik yang digunakan untuk memverifikasi tanda tangan - jadi tidak ada yang berubah antara L1 dan L2. Akan tetapi, dengan dompet kontrak pintar, menyimpan satu alamat menjadi lebih sulit. Meskipun banyak usaha telah dilakukan untuk mencoba membuat alamat menjadi hash kode yang dapat setara di seluruh jaringan, terutama CREATE2 dan pabrik tunggal ERC-2470, namun sulit untuk membuat hal ini bekerja dengan sempurna. Beberapa L2 (mis. "tipe 4 ZK-EVM") tidak sepenuhnya setara dengan EVM, sering kali menggunakan Solidity atau rakitan perantara sebagai gantinya, sehingga mencegah kesetaraan hash. Dan bahkan ketika Anda dapat memiliki kesetaraan hash, kemungkinan perubahan kepemilikan dompet melalui perubahan kunci menciptakan konsekuensi lain yang tidak intuitif.

Privasi mengharuskan setiap pengguna memiliki lebih banyak alamat, dan bahkan dapat mengubah jenis alamat yang kita gunakan. Jika proposal alamat siluman digunakan secara luas, alih-alih setiap pengguna hanya memiliki beberapa alamat, atau satu alamat per L2, pengguna dapat memiliki satu alamat per transaksi. Skema privasi lainnya, bahkan yang sudah ada seperti Tornado Cash, mengubah cara penyimpanan aset dengan cara yang berbeda: banyak dana pengguna disimpan dalam smart contract yang sama (dan karenanya di alamat yang sama). Untuk mengirim dana ke pengguna tertentu, pengguna harus mengandalkan sistem pengalamatan internal skema privasi itu sendiri.

Seperti yang telah kita lihat, masing-masing dari ketiga transisi tersebut melemahkan model mental "satu pengguna ~= satu alamat" dengan cara yang berbeda, dan beberapa dari efek ini memberi umpan balik ke dalam kerumitan dalam mengeksekusi transisi. Ada dua hal khusus yang menjadi titik kerumitan:

1. Jika Anda ingin membayar seseorang, bagaimana Anda akan mendapatkan informasi tentang cara membayarnya?
2. Jika pengguna memiliki banyak aset yang disimpan di berbagai tempat di berbagai rantai yang berbeda, bagaimana mereka melakukan perubahan penting dan pemulihan sosial?

Tiga transisi dan pembayaran on-chain (dan identitas)

Saya memiliki koin di Scroll, dan saya ingin membayar kopi (jika "saya" secara harfiah adalah saya, penulis artikel ini, maka "kopi" tentu saja merupakan metonimi untuk "teh hijau"). Anda menjual kopi kepada saya, tetapi Anda hanya disiapkan untuk menerima koin di Taiko. Apa yang harus dilakukan?

Pada dasarnya ada dua solusi:

1. Dompet penerima (yang bisa berupa pedagang, tetapi juga bisa berupa individu biasa) berusaha keras untuk mendukung setiap L2, dan memiliki beberapa fungsionalitas otomatis untuk mengkonsolidasikan dana secara asinkron.
2. Penerima memberikan L2 mereka bersama dengan alamat mereka, dan dompet pengirim secara otomatis merutekan dana ke L2 tujuan melalui beberapa sistem penghubung lintas-L2.

Tentu saja, solusi-solusi ini dapat dikombinasikan: penerima menyediakan daftar L2 yang bersedia mereka terima, dan dompet pengirim menentukan pembayaran, yang dapat melibatkan pengiriman langsung jika mereka beruntung, atau jalur penghubung lintas-L2.

Namun ini hanya satu contoh dari tantangan utama yang diperkenalkan oleh ketiga transisi tersebut: tindakan sederhana seperti membayar seseorang mulai membutuhkan lebih banyak informasi daripada sekadar alamat 20-byte.

Transisi ke dompet kontrak pintar untungnya tidak membebani sistem pengalamatan, tetapi masih ada beberapa masalah teknis di bagian lain dari tumpukan aplikasi yang perlu diselesaikan. Dompet perlu diperbarui untuk memastikan bahwa mereka tidak hanya mengirim 21000 gas bersama dengan transaksi, dan akan lebih penting lagi untuk memastikan bahwa sisi penerima pembayaran dompet tidak hanya melacak transfer ETH dari EOA, tetapi juga ETH yang dikirim oleh kode kontrak pintar. Aplikasi yang mengandalkan asumsi bahwa kepemilikan alamat tidak dapat diubah (mis. NFT yang melarang smart contract untuk menegakkan royalti) harus mencari cara lain untuk mencapai tujuannya. Dompet kontrak pintar juga akan membuat beberapa hal menjadi lebih mudah - terutama, jika seseorang hanya menerima token ERC20 non-ETH, mereka akan dapat menggunakan paymaster ERC-4337 untuk membayar gas dengan token tersebut.

Di sisi lain, privasi, sekali lagi menjadi tantangan besar yang belum benar-benar kami tangani. Tornado Cash yang asli tidak memperkenalkan masalah ini, karena tidak mendukung transfer internal: pengguna hanya dapat menyetor ke dalam sistem dan menarik keluar. Namun, setelah Anda dapat melakukan transfer internal, pengguna harus menggunakan skema pengalamatan internal sistem privasi. Dalam praktiknya, "informasi pembayaran" pengguna harus berisi (i) semacam "spending pubkey", sebuah komitmen rahasia yang dapat digunakan oleh penerima untuk membelanjakan uangnya, dan (ii) sebuah cara bagi pengirim untuk mengirimkan informasi terenkripsi yang hanya dapat didekripsi oleh penerima, untuk membantu penerima mengetahui pembayaran.

Protokol alamat siluman bergantung pada konsep meta-address, yang bekerja dengan cara ini: satu bagian dari meta-address adalah versi buta dari kunci pengeluaran pengirim, dan bagian lainnya adalah kunci enkripsi pengirim (meskipun implementasi minimal dapat mengatur kedua kunci tersebut menjadi sama).

Gambaran skematik dari skema alamat siluman abstrak berdasarkan enkripsi dan ZK-SNARK.

Pelajaran utama di sini adalah bahwa dalam ekosistem yang ramah privasi, seorang pengguna akan memiliki pubkey pengeluaran dan pubkey enkripsi, dan "informasi pembayaran" pengguna harus menyertakan kedua kunci tersebut. Ada juga alasan bagus selain pembayaran untuk memperluas ke arah ini. Sebagai contoh, jika kita menginginkan email terenkripsi berbasis Ethereum, pengguna harus memberikan semacam kunci enkripsi secara publik. Dalam "dunia EOA", kita dapat menggunakan kembali kunci akun untuk hal ini, tetapi dalam dunia smart-contract-wallet yang aman, kita mungkin harus memiliki fungsionalitas yang lebih eksplisit untuk hal ini. Hal ini juga akan membantu membuat identitas berbasis Ethereum lebih kompatibel dengan ekosistem privasi terdesentralisasi non-Ethereum, terutama kunci PGP.

Tiga transisi dan pemulihan kunci

Cara standar untuk mengimplementasikan perubahan penting dan pemulihan sosial di dunia dengan banyak alamat-per-pengguna adalah dengan meminta pengguna menjalankan prosedur pemulihan pada setiap alamat secara terpisah. Hal ini dapat dilakukan dengan satu klik: dompet dapat menyertakan perangkat lunak untuk menjalankan prosedur pemulihan di seluruh alamat pengguna secara bersamaan. Namun, bahkan dengan penyederhanaan UX seperti itu, pemulihan multi-alamat yang naif memiliki tiga masalah:

1. Ketidakpraktisan biaya gas: yang satu ini cukup jelas.
2. Alamat kontrafaktual: alamat yang belum diterbitkan smart contract-nya (dalam praktiknya, ini berarti akun yang belum pernah Anda kirimkan dana). Anda sebagai pengguna memiliki jumlah alamat fiktif yang berpotensi tidak terbatas: satu atau lebih pada setiap L2, termasuk L2 yang belum ada, dan serangkaian alamat fiktif lain yang tak terbatas yang timbul dari skema alamat siluman.
3. Privasi: jika pengguna dengan sengaja memiliki banyak alamat untuk menghindari tautan satu sama lain, mereka tentu tidak ingin menautkan semuanya secara publik dengan memulihkannya pada waktu yang sama!

Memecahkan masalah ini memang sulit. Untungnya, ada solusi yang cukup elegan yang berkinerja cukup baik: arsitektur yang memisahkan logika verifikasi dan kepemilikan aset.

Setiap pengguna memiliki kontrak keystore, yang ada di satu lokasi (bisa berupa mainnet atau L2 tertentu). Pengguna kemudian memiliki alamat pada L2 yang berbeda, di mana logika verifikasi dari setiap alamat tersebut adalah penunjuk ke kontrak keystore. Pembelanjaan dari alamat tersebut akan membutuhkan bukti yang masuk ke dalam kontrak keystore yang menunjukkan kunci publik pembelanjaan saat ini (atau, lebih realistisnya, sangat baru).

Buktinya dapat diimplementasikan dalam beberapa cara:

• Akses L1 hanya-baca langsung di dalam L2. Dimungkinkan untuk memodifikasi L2 agar dapat membaca status L1 secara langsung. Jika kontrak keystore berada di L1, ini berarti kontrak di dalam L2 dapat mengakses keystore "secara gratis"
• Cabang Merkle. Cabang-cabang Merkle dapat membuktikan status L1 ke L2, atau status L2 ke L1, atau Anda dapat menggabungkan keduanya untuk membuktikan bagian dari status satu L2 ke L2 lainnya. Kelemahan utama dari bukti Merkle adalah biaya gas yang tinggi karena panjangnya bukti: berpotensi 5 kB untuk sebuah bukti, meskipun ini akan berkurang menjadi < 1 kB di masa depan karena adanya pohon Verkle.
• ZK-SNARKS. Anda dapat mengurangi biaya data dengan menggunakan ZK-SNARK dari cabang Merkle dan bukan cabang itu sendiri. Dimungkinkan untuk membangun teknik agregasi off-chain (contohnya di atas EIP-4337) untuk membuat satu ZK-SNARK memverifikasi semua bukti status cross-chain dalam sebuah blok.
• Komitmen KZG. Baik L2, atau skema yang dibangun di atasnya, dapat memperkenalkan sistem pengalamatan berurutan, yang memungkinkan bukti status di dalam sistem ini hanya sepanjang 48 byte. Seperti halnya dengan ZK-SNARK, skema multiproof dapat menggabungkan semua bukti ini menjadi satu bukti per blok.

Jika kita ingin menghindari membuat satu bukti per transaksi, kita dapat menerapkan skema yang lebih ringan yang hanya membutuhkan bukti lintas-L2 untuk pemulihan. Pengeluaran dari sebuah akun akan bergantung pada kunci pengeluaran yang pubkey-nya disimpan di dalam akun tersebut, tetapi pemulihan akan membutuhkan transaksi yang menyalin pengeluaran_pubkey saat ini di dalam keystore. Dana di alamat kontrafaktual tetap aman meskipun kunci lama Anda tidak aman: "mengaktifkan" alamat kontrafaktual untuk mengubahnya menjadi kontrak kerja akan membutuhkan pembuatan bukti lintas-L2 untuk menyalin pengeluaran_pubkey saat ini. Utas di forum Safe ini menjelaskan bagaimana arsitektur serupa dapat bekerja.

Untuk menambahkan privasi pada skema seperti itu, maka kita hanya mengenkripsi pointer, dan kita melakukan semua pembuktian di dalam ZK-SNARK:

Dengan pekerjaan yang lebih banyak (mis. menggunakan <a href="https://notes.ethereum.org/@vbuterin/non_index_revealing_proof"> ini karya sebagai titik awal), kita juga dapat menghilangkan sebagian besar kerumitan ZK-SNARK dan membuat skema berbasis KZG yang lebih sederhana.

Skema ini bisa menjadi rumit. Sisi positifnya, ada banyak potensi sinergi di antara keduanya. Sebagai contoh, konsep "kontrak keystore" juga dapat menjadi solusi untuk tantangan "alamat" yang disebutkan pada bagian sebelumnya: jika kita ingin pengguna memiliki alamat yang tetap, yang tidak berubah setiap kali pengguna memperbarui kunci, kita dapat meletakkan meta-alamat siluman, kunci enkripsi, dan informasi lainnya ke dalam kontrak keystore, dan menggunakan alamat kontrak keystore sebagai "alamat" pengguna.

Banyak infrastruktur sekunder yang perlu diperbarui

Menggunakan ENS itu mahal. Saat ini, di bulan Juni 2023, situasinya tidak terlalu buruk: biaya transaksinya cukup besar, tetapi masih sebanding dengan biaya domain ENS. Mendaftarkan zuzalu.eth menghabiskan biaya sekitar $27, di mana $11 di antaranya adalah biaya transaksi. Tetapi jika kita mengalami pasar bullish lagi, biaya akan meroket. Bahkan tanpa kenaikan harga ETH, biaya gas yang kembali ke 200 gwei akan menaikkan biaya pendaftaran domain menjadi $104. Jadi, jika kita ingin orang-orang benar-benar menggunakan ENS, terutama untuk kasus penggunaan seperti media sosial yang terdesentralisasi di mana pengguna menuntut pendaftaran yang hampir gratis (dan biaya domain ENS tidak menjadi masalah karena platform ini menawarkan sub-domain kepada penggunanya), kita membutuhkan ENS untuk bekerja pada L2.

Untungnya, tim ENS telah melangkah maju, dan ENS pada L2 benar-benar terjadi! ERC-3668 (alias "standar CCIP"), bersama dengan ENSIP-10, menyediakan cara agar subdomain ENS di L2 mana pun dapat diverifikasi secara otomatis. Standar CCIP mengharuskan pengaturan kontrak pintar yang menjelaskan metode untuk memverifikasi bukti data pada L2, dan domain (misalnya. Optinames menggunakan ecc.eth) dapat diletakkan di bawah kendali kontrak semacam itu. Setelah kontrak CCIP mengontrol ecc.eth di L1, mengakses beberapa subdomain.ecc.eth secara otomatis akan melibatkan pencarian dan verifikasi bukti (mis. Cabang Merkle) dari state di L2 yang sebenarnya menyimpan subdomain tertentu.

Sebenarnya, mengambil bukti melibatkan membuka daftar URL yang disimpan dalam kontrak, yang memang terasa seperti sentralisasi, meskipun menurut saya sebenarnya tidak: ini adalah model kepercayaan 1-of-N (bukti yang tidak valid akan tertangkap oleh logika verifikasi dalam fungsi callback kontrak CCIP, dan selama salah satu dari URL tersebut mengembalikan bukti yang valid, maka Anda tidak perlu khawatir). Daftar URL bisa berisi lusinan URL.

Upaya ENS CCIP adalah kisah sukses, dan harus dilihat sebagai tanda bahwa reformasi radikal seperti yang kita butuhkan sebenarnya mungkin dilakukan. Namun, masih banyak lagi reformasi lapisan aplikasi yang perlu dilakukan. Beberapa contoh:

• Banyak sekali dapps yang bergantung pada pengguna yang memberikan tanda tangan off-chain. Dengan akun yang dimiliki secara eksternal (EOA), hal ini mudah dilakukan. ERC-1271 menyediakan cara standar untuk melakukan hal ini untuk dompet kontrak pintar. Namun, masih banyak dapps yang belum mendukung ERC-1271; mereka harus mendukungnya.
• Dapps yang menggunakan "apakah ini EOA?" untuk mendiskriminasi pengguna dan kontrak (misalnya untuk mencegah transfer atau memberlakukan royalti) akan diputus. Secara umum, saya menyarankan untuk tidak mencoba mencari solusi teknis murni di sini; mencari tahu apakah transfer kontrol kriptografi tertentu merupakan transfer kepemilikan manfaat adalah masalah yang sulit dan mungkin tidak dapat dipecahkan tanpa menyelesaikannya dengan mekanisme yang digerakkan oleh komunitas di luar rantai. Kemungkinan besar, aplikasi harus lebih sedikit mengandalkan pencegahan transfer dan lebih banyak pada teknik seperti pajak Harberger.
• Bagaimana dompet berinteraksi dengan pembelanjaan dan kunci enkripsi harus ditingkatkan. Saat ini, dompet sering kali menggunakan tanda tangan deterministik untuk menghasilkan kunci khusus aplikasi: menandatangani nonce standar (contoh: hash dari nama aplikasi) dengan kunci pribadi EOA menghasilkan nilai deterministik yang tidak dapat dihasilkan tanpa kunci pribadi, sehingga aman dalam arti teknis murni. Akan tetapi, teknik-teknik ini bersifat "buram" untuk wallet, mencegah wallet untuk mengimplementasikan pemeriksaan keamanan pada tingkat antarmuka pengguna. Dalam ekosistem yang lebih matang, penandatanganan, enkripsi, dan fungsi-fungsi terkait harus ditangani oleh dompet secara lebih eksplisit.
• Klien yang ringan (mis. Helios) harus memverifikasi L2 dan bukan hanya L1. Saat ini, light client berfokus pada pemeriksaan validitas header L1 (menggunakan protokol sinkronisasi light client), dan memverifikasi cabang-cabang Merkle dari status L1 dan transaksi yang berakar pada header L1. Besok, mereka juga perlu memverifikasi bukti status L2 yang berakar pada akar status yang tersimpan di L1 (versi yang lebih canggih dari ini sebenarnya akan melihat pra-konfirmasi L2).

Dompet perlu mengamankan aset dan data

Saat ini, dompet adalah bisnis untuk mengamankan aset. Semuanya berjalan secara on-chain, dan satu-satunya hal yang perlu dilindungi oleh wallet adalah private key yang saat ini menjaga aset-aset tersebut. Jika Anda mengubah kunci, Anda dapat dengan aman mempublikasikan kunci pribadi Anda yang sebelumnya di internet keesokan harinya. Akan tetapi, dalam dunia ZK, hal ini tidak lagi benar: dompet tidak hanya melindungi kredensial otentikasi, tetapi juga menyimpan data Anda.

Kami melihat tanda-tanda pertama dari dunia seperti itu dengan Zupass, sistem identitas berbasis ZK-SNARK yang digunakan di Zuzalu. Pengguna memiliki kunci pribadi yang mereka gunakan untuk mengautentikasi ke sistem, yang dapat digunakan untuk membuat bukti dasar seperti "buktikan bahwa saya adalah penduduk Zuzalu, tanpa mengungkapkan yang mana". Tetapi sistem Zupass juga mulai memiliki aplikasi lain yang dibangun di atasnya, terutama perangko (POAP versi Zupass).

Salah satu dari sekian banyak perangko Zupass saya, yang menegaskan bahwa saya adalah anggota Tim Kucing yang bangga.

Fitur utama yang ditawarkan stempel dibandingkan POAP adalah stempel bersifat pribadi: Anda menyimpan data secara lokal, dan Anda hanya membuktikan stempel (atau beberapa perhitungan atas stempel) kepada seseorang jika Anda ingin mereka memiliki informasi tentang Anda. Tetapi hal ini menciptakan risiko tambahan: jika Anda kehilangan informasi tersebut, Anda akan kehilangan prangko Anda.

Tentu saja, masalah penyimpanan data dapat direduksi menjadi masalah penyimpanan satu kunci enkripsi: beberapa pihak ketiga (atau bahkan rantai) dapat menyimpan salinan data terenkripsi. Hal ini memiliki keuntungan yang nyaman karena tindakan yang Anda lakukan tidak mengubah kunci enkripsi, sehingga tidak memerlukan interaksi apa pun dengan sistem yang menyimpan kunci enkripsi Anda. Tetapi tetap saja, jika Anda kehilangan kunci enkripsi, Anda kehilangan segalanya. Dan di sisi lain, jika seseorang melihat kunci enkripsi Anda, mereka akan melihat semua yang dienkripsi dengan kunci tersebut.

Solusi de-facto dari Zupass adalah mendorong orang-orang untuk menyimpan kunci mereka di beberapa perangkat (misalnya. laptop dan ponsel), karena kemungkinan mereka akan kehilangan akses ke semua perangkat secara bersamaan sangat kecil. Kita bisa melangkah lebih jauh, dan menggunakan berbagi rahasia untuk menyimpan kunci, dibagi di antara beberapa wali.

Pemulihan sosial melalui MPC bukanlah solusi yang cukup untuk dompet, karena ini berarti tidak hanya wali saat ini tetapi juga wali sebelumnya dapat berkolusi untuk mencuri aset Anda, yang memiliki risiko yang sangat tinggi. Tetapi kebocoran privasi umumnya memiliki risiko yang lebih rendah daripada total kehilangan aset, dan seseorang dengan kasus penggunaan yang menuntut privasi tinggi selalu dapat menerima risiko kehilangan yang lebih tinggi dengan tidak mencadangkan kunci yang terkait dengan tindakan yang menuntut privasi tersebut.

Untuk menghindari membanjiri pengguna dengan sistem bizantium dengan banyak jalur pemulihan, dompet yang mendukung pemulihan sosial kemungkinan besar perlu mengelola pemulihan aset dan pemulihan kunci enkripsi.

Kembali ke identitas

Salah satu benang merah dari perubahan ini adalah bahwa konsep "alamat", sebuah pengenal kriptografi yang Anda gunakan untuk mewakili "Anda" di dalam rantai, harus berubah secara radikal. "Petunjuk cara berinteraksi dengan saya" tidak lagi hanya berupa alamat ETH; petunjuk tersebut haruslah, dalam beberapa bentuk, beberapa kombinasi dari beberapa alamat pada beberapa L2, alamat meta siluman, kunci enkripsi, dan data lainnya.

Salah satu cara untuk melakukannya adalah dengan menjadikan ENS sebagai identitas Anda: catatan ENS Anda dapat berisi semua informasi ini, dan jika Anda mengirim seseorang dengan nama bob.eth (atau bob.ecc.eth, atau...), mereka dapat mencari dan melihat segala sesuatu tentang cara membayar dan berinteraksi dengan Anda, termasuk dengan cara-cara lintas domain yang lebih rumit dan cara-cara yang menjaga privasi.

Namun, pendekatan yang berpusat pada ENS ini memiliki dua kelemahan:

• Hal ini mengikat terlalu banyak hal dengan nama Anda. Nama Anda bukanlah Anda, nama Anda adalah salah satu dari sekian banyak atribut Anda. Seharusnya Anda dapat mengubah nama Anda tanpa memindahkan seluruh profil identitas Anda dan memperbarui sejumlah besar catatan di banyak aplikasi.
• Anda tidak dapat memiliki nama-nama kontrafaktual yang tidak dapat dipercaya. Salah satu fitur UX utama dari setiap blockchain adalah kemampuan untuk mengirim koin kepada orang-orang yang belum berinteraksi dengan chain. Tanpa fungsi seperti itu, ada masalah yang muncul: berinteraksi dengan chain membutuhkan pembayaran biaya transaksi, yang mengharuskan Anda untuk... memiliki koin. Alamat ETH, termasuk alamat kontrak pintar dengan CREATE2, memiliki fitur ini. Nama ENS tidak, karena jika dua buah Bobs sama-sama memutuskan secara off-chain bahwa mereka adalah bob.ecc.eth, tidak ada cara untuk memilih salah satu dari mereka yang akan mendapatkan nama.

Salah satu solusi yang mungkin adalah memasukkan lebih banyak hal ke dalam kontrak keystore yang disebutkan dalam arsitektur di awal tulisan ini. Kontrak keystore dapat berisi berbagai informasi tentang Anda dan cara berinteraksi dengan Anda (dan dengan CCIP, beberapa informasi tersebut dapat bersifat off-chain), dan pengguna akan menggunakan kontrak keystore mereka sebagai pengenal utama mereka. Tetapi aset sebenarnya yang mereka terima akan disimpan di berbagai tempat yang berbeda. Kontrak keystore tidak terikat pada nama, dan mereka ramah terhadap kontrafaktual: Anda dapat membuat alamat yang dapat dibuktikan hanya dapat diinisialisasi oleh kontrak keystore yang memiliki parameter awal yang tetap.

Kategori solusi lainnya adalah dengan meninggalkan konsep alamat yang berhadapan dengan pengguna, dengan semangat yang sama dengan protokol pembayaran Bitcoin. Salah satu idenya adalah untuk lebih mengandalkan saluran komunikasi langsung antara pengirim dan penerima; misalnya, pengirim dapat mengirimkan tautan klaim (baik sebagai URL eksplisit atau kode QR) yang dapat digunakan oleh penerima untuk menerima pembayaran sesuai dengan keinginan mereka.

Terlepas dari apakah pengirim atau penerima bertindak lebih dulu, ketergantungan yang lebih besar pada dompet yang secara langsung menghasilkan informasi pembayaran terkini secara real time dapat mengurangi gesekan. Meskipun demikian, pengidentifikasi yang persisten memang nyaman (terutama dengan ENS), dan asumsi komunikasi langsung antara pengirim dan penerima merupakan hal yang sangat rumit dalam praktiknya, sehingga kita mungkin akan melihat kombinasi dari teknik yang berbeda.

Dalam semua desain ini, menjaga segala sesuatunya tetap terdesentralisasi dan dapat dimengerti oleh pengguna adalah hal yang terpenting. Kita perlu memastikan bahwa pengguna memiliki akses mudah ke tampilan terkini mengenai aset mereka saat ini dan pesan apa saja yang telah diterbitkan yang ditujukan untuk mereka. Pandangan ini harus bergantung pada alat bantu terbuka, bukan solusi berpemilik. Dibutuhkan kerja keras untuk menghindari kompleksitas infrastruktur pembayaran yang lebih besar agar tidak berubah menjadi "menara abstraksi" yang tidak jelas, di mana para pengembang mengalami kesulitan untuk memahami apa yang sedang terjadi dan mengadaptasinya ke dalam konteks yang baru. Terlepas dari tantangan yang ada, mencapai skalabilitas, keamanan dompet, dan privasi untuk pengguna biasa sangat penting untuk masa depan Ethereum. Ini bukan hanya tentang kelayakan teknis, tetapi juga tentang aksesibilitas yang sebenarnya bagi pengguna biasa. Kita harus bangkit untuk menghadapi tantangan ini.

Penafian: Penafian

1. Artikel ini dicetak ulang dari[vitalik], Semua hak cipta adalah milik penulis asli[Vitalik Buterin]. Jika ada keberatan dengan pencetakan ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata merupakan pandangan dan pendapat penulis dan bukan merupakan saran investasi.
3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.