Terima kasih khusus kepada Dan Finlay, Karl Floersch, David Hoffman, serta tim Scroll dan SoulWallet atas umpan balik, ulasan, dan saran mereka.
Saat Ethereum bertransisi dari teknologi eksperimental muda ke tumpukan teknologi yang matang yang mampu benar-benar memberikan pengalaman terbuka, global, dan tanpa izin kepada pengguna biasa, tumpukan tersebut harus melalui tiga transisi teknologi utama secara bersamaan:
Transisi ekspansi L2 - semua orang beralih ke rollup
Transisi keamanan dompet - semua orang pindah ke dompet kontrak pintar
Transisi Privasi - Pastikan transfer dana yang menjaga privasi tersedia, dan pastikan semua gadget lain dalam pengembangan (pemulihan sosial, identitas, reputasi) menjaga privasi
Segitiga transisi ekosistem.
Tanpa yang pertama, Ethereum akan gagal karena setiap transaksi berharga $3,75 ($82,48 jika kita memiliki bull run lainnya) 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 enggan menyimpan dana mereka (dan aset non-finansial) dan semua orang beralih ke pertukaran terpusat.
Tanpa yang ketiga, Ethereum akan gagal karena semua transaksi (dan POAP dll.) Solusi terpusat yang menyembunyikan data Anda secara maksimal.
Ketiga transisi ini sangat penting karena alasan yang diuraikan di atas. Tapi mereka juga menantang, karena menanganinya dengan benar membutuhkan koordinasi yang erat. Bukan hanya fungsionalitas protokol yang perlu ditingkatkan; dalam beberapa kasus, cara kita berinteraksi dengan Ethereum perlu berubah secara mendasar, membutuhkan perubahan besar pada aplikasi dan dompet.
Tiga transisi ini pada dasarnya akan membentuk ulang hubungan antara pengguna dan alamat
Di dunia yang diperluas L2, pengguna akan ada di banyak L2. Apakah Anda anggota ExampleDAO yang mengandalkan Optimisme? Maka Anda memiliki akun Optimisme! Apakah Anda memegang CDP di sistem stablecoin di ZkSync? Maka Anda memiliki akun di ZkSync! Sudahkah Anda mencoba beberapa aplikasi di kakarot? Maka Anda memiliki akun di Kakarot! Lewatlah sudah hari-hari ketika pengguna hanya memiliki satu alamat.
*Menurut tampilan Dompet Berani saya, saya memiliki ETH di empat tempat. Ya, Arbitrum dan Arbitrum Nova berbeda. Jangan khawatir, itu akan menjadi lebih berantakan dari waktu ke waktu! *
Dompet kontrak pintar menambah kerumitan dan membuatnya lebih sulit untuk memiliki alamat yang sama di L1 dan berbagai L2. Saat ini, sebagian besar pengguna menggunakan akun yang dimiliki secara eksternal yang alamatnya sebenarnya adalah hash dari kunci publik yang digunakan untuk memverifikasi tanda tangan - jadi tidak ada yang berubah antara L1 dan L2. Namun, dengan dompet smart contract, menjadi lebih sulit untuk memesan alamat. Sementara banyak pekerjaan telah dilakukan untuk mencoba dan membuat alamat menjadi hash kode yang setara di seluruh jaringan, terutama pabrik tunggal CREATE2 dan ERC-2470, sulit untuk membuat ini bekerja dengan sempurna. Beberapa L2 (seperti "Tipe 4 ZK-EVM") tidak persis sama dengan EVM, biasanya Soliditas atau rakitan perantara digunakan sebagai gantinya untuk mencegah kesetaraan hash. Bahkan jika Anda dapat memiliki kesetaraan hash, kemungkinan dompet mengubah kepemilikan melalui perubahan kunci memiliki konsekuensi tidak intuitif lainnya.
Privasi membutuhkan lebih banyak alamat per pengguna dan bahkan dapat mengubah jenis alamat yang kami tangani. Jika proposal alamat tersembunyi digunakan secara luas, bukan hanya beberapa alamat per pengguna, atau satu alamat per L2, pengguna mungkin memiliki satu alamat per transaksi. Skema privasi lainnya, bahkan yang sudah ada seperti Tornado Cash, mengubah cara aset disimpan secara berbeda: banyak dana pengguna disimpan dalam kontrak pintar yang sama (dan dengan demikian di alamat yang sama). Untuk mengirim dana ke pengguna tertentu, pengguna harus bergantung pada sistem pengalamatan internal skema privasi itu sendiri.
Seperti yang telah kita lihat, masing-masing dari ketiga transisi ini melemahkan model mental "satu pengguna ~= satu alamat" dengan cara yang berbeda, dengan beberapa efek ini menambah kompleksitas implementasi transisi. Dua poin komplikasi khusus adalah:
Jika Anda ingin membayar seseorang, bagaimana Anda mendapatkan informasi tentang cara membayar mereka?
Jika pengguna memiliki banyak aset lintas rantai yang disimpan di tempat berbeda, bagaimana cara mereka melakukan perubahan kunci dan pemulihan sosial?
Tiga transisi dan pembayaran on-chain (dan identitas)
Saya memiliki koin di Gulir dan saya ingin membayar kopi (jika "Saya" secara harfiah menyebut saya sebagai penulis artikel ini, maka "kopi" tentu saja merupakan metonim untuk "teh hijau"). Anda menjual kopi kepada saya, tetapi Anda hanya dapat menerima koin di Taiko. apa yang harus dilakukan
Pada dasarnya ada dua solusi:
Dompet penerima (yang dapat berupa pedagang atau individu biasa) bekerja sangat keras untuk mendukung setiap L2, dengan beberapa otomatisasi untuk mengintegrasikan dana secara asinkron.
Penerima pembayaran memberikan L2 dan alamat mereka, dan dompet pengirim secara otomatis merutekan dana ke L2 tujuan melalui beberapa sistem penghubung antar-L2.
Tentu saja, solusi ini dapat digabungkan: penerima memberikan daftar L2 yang bersedia mereka terima, dan dompet pengirim menghitung pembayaran, yang mungkin melibatkan pengiriman langsung, atau jalur penghubung melintasi L2 jika mereka beruntung.
Tapi ini hanyalah salah satu contoh tantangan utama yang dihadirkan oleh ketiga transisi ini: operasi sederhana seperti membayar seseorang mulai membutuhkan lebih banyak informasi daripada hanya alamat 20-byte.
Untungnya, transisi ke dompet smart contract tidak akan membebani sistem pengalamatan, tetapi masih ada beberapa masalah teknis yang harus diselesaikan di bagian lain tumpukan aplikasi. Dompet perlu diperbarui untuk memastikan mereka tidak hanya mengirim 21.000 gas dengan transaksi, dan lebih penting untuk memastikan pembayaran menerima akhir dompet tidak hanya melacak transfer ETH dari EOA, tetapi juga melacak ETH dikirim oleh kode kontrak pintar. Aplikasi yang bergantung pada asumsi kepemilikan alamat yang tidak dapat diubah (misalnya NFT yang melarang kontrak pintar untuk menerapkan biaya royalti) harus mencari cara lain untuk mencapai tujuannya. Dompet kontrak pintar juga akan membuat segalanya lebih mudah - terutama, jika seseorang hanya menerima token ERC20 non-ETH, mereka akan dapat menggunakan token itu untuk membayar bensin menggunakan paymaster ERC-4337.
Privasi, di sisi lain, sekali lagi menimbulkan tantangan besar yang belum benar-benar kami atasi. Tornado Cash asli tidak menimbulkan masalah ini karena tidak mendukung transfer internal: pengguna hanya dapat menyetor ke sistem dan menarik diri darinya. Namun, setelah transfer internal dimungkinkan, pengguna perlu menggunakan skema pengalamatan internal sistem privasi. Dalam praktiknya, "pesan pembayaran" pengguna harus berisi (i) semacam "kunci publik pembelanjaan", janji rahasia yang dapat digunakan penerima untuk membelanjakan, dan (ii) cara bagi pengirim untuk mengirim mata uang kripto hanya Informasi yang dapat diuraikan oleh penerima pembayaran untuk membantu penerima pembayaran menemukan pembayaran.
Protokol alamat siluman bergantung pada konsep alamat meta, yang bekerja dengan cara ini: bagian dari alamat meta adalah versi buta dari kunci pengeluaran pengirim, dan bagian lainnya adalah kunci enkripsi pengirim (walaupun implementasi minimal dapat mengatur keduanya tombolnya sama).
Diagram skematis dari skema alamat siluman abstrak berdasarkan enkripsi dan ZK-SNARKs.
Pelajaran utama di sini adalah bahwa dalam ekosistem ramah privasi, pengguna akan memiliki kunci publik konsumsi dan kunci publik enkripsi, dan "informasi pembayaran" pengguna harus menyertakan kedua kunci tersebut. Di luar pembayaran, ada alasan bagus untuk memperluas ke arah ini. Misalnya, jika kami ingin email terenkripsi berdasarkan Ethereum, pengguna perlu memberikan semacam kunci enkripsi secara publik. Di "dunia EOA" kami dapat menggunakan kembali kunci akun untuk ini, tetapi di dunia dompet kontrak pintar yang aman, kami mungkin harus menyediakan fungsi yang lebih eksplisit untuk ini. Ini juga membantu membuat identitas berbasis Ethereum lebih kompatibel dengan ekosistem privasi terdesentralisasi non-Ethereum, terutama kunci PGP.
Tiga transisi dan pemulihan kunci
Cara default untuk menerapkan perubahan kritis dan pemulihan sosial di dunia di mana setiap pengguna memiliki banyak alamat adalah dengan meminta pengguna menjalankan proses pemulihan di setiap alamat secara terpisah. Ini dapat dilakukan dengan satu klik: dompet dapat berisi perangkat lunak yang dapat melakukan prosedur pemulihan pada semua alamat pengguna secara bersamaan. Namun, bahkan dengan penyederhanaan pengalaman pengguna ini, ada tiga masalah dengan pemulihan multi-alamat sederhana:
Biaya gas tidak praktis: Yang ini cukup jelas.
Alamat kontrafaktual: Alamat yang belum dikeluarkan oleh kontrak pintar (sebenarnya, ini berarti akun yang dananya belum Anda kirimkan). Sebagai pengguna, Anda mungkin memiliki alamat kontrafaktual dalam jumlah tak terbatas: satu atau lebih alamat di setiap L2, termasuk L2 yang belum ada, dan rangkaian alamat kontrafaktual tak terbatas lainnya yang dihasilkan dari skema alamat siluman.
Privasi: Jika pengguna dengan sengaja memiliki beberapa alamat untuk menghindari penautan satu sama lain, mereka tentu tidak ingin menautkan semuanya secara publik dengan memulihkannya pada atau sekitar waktu yang sama!
Memecahkan masalah ini sulit. Untungnya, ada solusi elegan yang bekerja cukup baik: arsitektur yang memisahkan logika validasi dari penyimpanan 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 validasi untuk setiap alamat adalah penunjuk ke kontrak keystore. Pembelanjaan dari alamat ini memerlukan bukti masuk ke dalam kontrak keystore yang menunjukkan kunci publik pembelanjaan saat ini (atau, lebih realistis, terbaru).
Bukti dapat dicapai dengan beberapa cara:
Akses L1 hanya baca langsung di L2. L2 dapat dimodifikasi untuk membaca status L1 secara langsung. Jika kontrak keystore ada di L1, ini berarti kontrak di dalam L2 memiliki akses "gratis" ke keystore
Cabang Merkel. Cabang Merkle dapat membuktikan status L1 ke L2, atau status L2 ke L1, atau Anda dapat menggabungkan keduanya untuk membuktikan status parsial dari satu L2 ke L2 lainnya. Kelemahan utama bukti Merkle adalah biaya gas yang tinggi karena panjang bukti: bukti mungkin memerlukan 5 kB, tetapi ini akan dikurangi menjadi <1 kB di masa mendatang berkat pohon Verkle.
ZK-SNARK. Anda dapat mengurangi biaya data dengan menggunakan garpu Merkle ZK-SNARK, bukan garpu itu sendiri. Teknik agregasi off-chain dapat dibangun (misalnya, di atas EIP-4337) agar ZK-SNARK memverifikasi semua bukti status lintas rantai dalam sebuah blok.
KZG Janji. L2, atau skema yang dibangun di atasnya, dapat memperkenalkan sistem pengalamatan sekuensial, yang memungkinkan pembuktian keadaan dalam sistem itu hanya sepanjang 48 byte. Seperti ZK-SNARK, beberapa skema bukti dapat menggabungkan semua bukti ini menjadi satu bukti untuk setiap blok.
Jika kita ingin menghindari pembuatan bukti untuk setiap transaksi, kita dapat mengimplementasikan skema yang lebih ringan yang hanya memerlukan satu bukti lintas-L2 untuk dipulihkan. Pengeluaran dari akun akan bergantung pada kunci pengeluaran yang kunci publiknya disimpan di akun, tetapi pemulihan akan memerlukan transaksi untuk menyalin kunci publik pengeluaran saat ini di keystore. Dana di alamat kontrafaktual tetap aman meskipun kunci lama Anda tidak: "mengaktifkan" alamat kontrafaktual untuk mengubahnya menjadi kontrak kerja memerlukan bukti L2 silang untuk menduplikasi kunci_pub pengeluaran saat ini. Utas ini di forum Aman menjelaskan cara kerja arsitektur serupa.
Untuk menambahkan privasi ke skema seperti itu, kami cukup mengenkripsi pointer ini, dan kemudian kami melakukan semua bukti di ZK-SNARKs:
Dengan lebih banyak pekerjaan (misalnya, menggunakan pekerjaan ini sebagai titik awal), kita juga dapat menghilangkan sebagian besar kerumitan ZK-SNARK dan membuat skema berbasis KZG yang lebih sederhana.
Skenario ini bisa menjadi rumit. Di sisi positifnya, ada banyak potensi sinergi di antara keduanya. Misalnya, konsep "kontrak keystore" juga dapat menyelesaikan tantangan "alamat" yang disebutkan di bagian sebelumnya: jika kita ingin pengguna memiliki alamat permanen yang tidak berubah setiap kali pengguna memasukkan ulang, kita dapat menempatkan Alamat meta tersembunyi , kunci enkripsi dan informasi lainnya dimasukkan ke dalam kontrak keystore, dan alamat kontrak keystore digunakan sebagai "alamat" pengguna.
Banyak infrastruktur sekunder perlu ditingkatkan
Menggunakan ENS itu mahal. Hari ini, di bulan Juni 2023, semuanya tidak terlalu buruk: biaya transaksi tinggi, tetapi masih sebanding dengan biaya domain ENS. Mendaftar dengan zuzalu.eth menghabiskan biaya sekitar $27, di mana $11 adalah biaya transaksi. Tetapi jika kita memiliki bull market lain, biaya akan meroket. Bahkan tanpa kenaikan harga ETH, memindahkan biaya gas kembali ke 200 gwei akan menaikkan biaya tx untuk pendaftaran domain menjadi $104. Jadi jika kami ingin orang benar-benar menggunakan ENS, terutama untuk kasus penggunaan seperti media sosial terdesentralisasi di mana pengguna meminta pendaftaran hampir gratis (dan biaya domain ENS tidak menjadi masalah karena platform ini menyediakan subdomain kepada penggunanya), kami memerlukan ENS di L2 untuk berfungsi .
Untungnya, tim ENS meningkat dan ENS di L2 terjadi! ERC-3668 (alias "standar CCIP"), bersama dengan ENSIP-10, menyediakan cara untuk membuat subdomain ENS pada L2 apa pun dapat diverifikasi secara otomatis. Standar CCIP mensyaratkan pembuatan kontrak cerdas yang menjelaskan metode verifikasi bukti data L2, dan bahwa domain (mis. Optinames menggunakan ecc.eth) dapat dikendalikan oleh kontrak semacam itu. Setelah kontrak CCIP mengambil kendali ecc.eth di L1, mengakses beberapa subdomain.ecc.eth akan secara otomatis melibatkan pencarian dan verifikasi bukti status (misalnya cabang Merkle) di L2 tempat subdomain tertentu sebenarnya disimpan.
Sebenarnya mendapatkan bukti melibatkan daftar URL yang disimpan dalam kontrak, yang tentunya terasa seperti terpusat, tapi menurut saya sebenarnya tidak: ini adalah model kepercayaan 1-dari-N (bukti tidak valid ditangkap oleh logika verifikasi dalam fungsi panggilan balik kontrak CCIP, selama salah satu URL mengembalikan bukti yang valid, tidak apa-apa). Daftar URL mungkin berisi lusinan.
Upaya ENS CCIP adalah kisah sukses, dan itu harus dilihat sebagai tanda bahwa reformasi radikal yang kita butuhkan sebenarnya mungkin terjadi. Namun masih banyak pembenahan layer aplikasi yang perlu dilakukan. Beberapa contoh:
Banyak dapp mengandalkan pengguna untuk memberikan tanda tangan off-chain. Dengan Akun Milik Eksternal (EOA), itu mudah. ERC-1271 menyediakan cara standar untuk dompet smart contract untuk melakukan ini. Namun, banyak dapp masih belum mendukung ERC-1271; mereka perlu mendukungnya.
Dapp yang menggunakan "Apakah ini EOA?" untuk membedakan pengguna dan kontrak (misalnya, mencegah transfer atau menerapkan biaya royalti) akan dihentikan. Secara umum, saya menyarankan untuk tidak mencari solusi teknis murni di sini; mencari tahu apakah transfer tertentu dari kontrol kriptografi adalah transfer kepemilikan manfaat adalah masalah sulit yang mungkin tidak dapat diselesaikan tanpa mengatasi beberapa mekanisme berbasis komunitas off-chain. Kemungkinan besar, aplikasi harus lebih sedikit mengandalkan pencegahan pengalihan dan lebih mengandalkan teknik seperti pajak Harberger.
Harus meningkatkan cara dompet berinteraksi dengan pembelanjaan dan kunci enkripsi. Saat ini, dompet biasanya menggunakan tanda tangan deterministik untuk menghasilkan kunci khusus aplikasi: menandatangani nonce standar (seperti hash nama aplikasi) dengan kunci privat EOA menghasilkan nilai deterministik yang tidak dapat dihasilkan tanpa kunci privat, Jadi aman dalam arti murni teknis. Namun, teknik ini "buram" untuk dompet, mencegah dompet menerapkan pemeriksaan keamanan tingkat antarmuka pengguna. Dalam ekosistem yang lebih matang, penandatanganan, enkripsi, dan fungsi terkait harus ditangani secara lebih eksplisit oleh dompet.
Klien ringan (seperti Helios) harus mengotentikasi L2 dan bukan hanya L1. Saat ini, klien ringan fokus pada pemeriksaan validitas header L1 (menggunakan protokol sinkronisasi klien ringan), dan memverifikasi garpu Merkle dari status L1 dan transaksi yang berakar di header L1. Besok, mereka juga perlu memverifikasi bukti status L2, yang di-root di root status yang disimpan di L1 (versi yang lebih canggih sebenarnya melihat pra-konfirmasi L2).
Dompet perlu melindungi aset dan data
Hari ini, dompet dalam bisnis melindungi aset. Semuanya on-chain, dan satu-satunya hal yang perlu dilindungi dompet adalah kunci pribadi yang saat ini mengamankan aset ini. Jika Anda mengubah kunci Anda, Anda dapat dengan aman menerbitkan kunci pribadi Anda sebelumnya di Internet pada hari berikutnya. Namun, di dunia ZK, ini tidak lagi benar: dompet tidak hanya melindungi kredensial autentikasi, tetapi juga menyimpan data Anda.
Kami melihat tanda-tanda pertama dunia seperti itu dengan Zupass, sistem identitas berbasis ZK-SNARK yang digunakan oleh Zuzalu. Pengguna memiliki kunci pribadi untuk mengotentikasi sistem, yang dapat digunakan untuk membuat bukti dasar seperti "membuktikan bahwa saya adalah penduduk Zuzalu tanpa mengungkapkan yang mana". Tetapi sistem Zupass juga mulai membangun aplikasi lain di atasnya, terutama stempel (POAP versi Zupass).
Salah satu dari banyak stempel Zupass saya yang mengonfirmasi bahwa saya bangga menjadi anggota Tim Kucing.
Fitur utama yang ditawarkan stempel dibandingkan dengan POAP adalah stempel bersifat pribadi: Anda menyimpan data secara lokal, dan jika Anda ingin seseorang memiliki informasi tentang Anda, Anda hanya perlu membuktikan stempel (atau perhitungan pada stempel) kepada seseorang . Tapi itu menambah risiko: jika Anda kehilangan informasi itu, Anda kehilangan stempelnya.
Tentu saja, masalah menyimpan data dapat direduksi menjadi masalah memegang kunci enkripsi tunggal: beberapa pihak ketiga (atau bahkan rantai) dapat menyimpan salinan data terenkripsi. Ini memiliki keuntungan nyaman bahwa tindakan yang Anda lakukan tidak mengubah kunci enkripsi, jadi tidak diperlukan interaksi dengan sistem yang menjaga keamanan kunci enkripsi Anda. Namun demikian, jika Anda kehilangan kunci enkripsi, Anda kehilangan segalanya. Sebaliknya, jika seseorang melihat kunci enkripsi Anda, mereka dapat melihat semua yang dienkripsi dengan kunci tersebut.
Solusi praktis Zupass adalah mendorong orang untuk menyimpan kunci mereka di beberapa perangkat (seperti laptop dan telepon), karena kemungkinan mereka kehilangan akses ke semuanya sekaligus sangat kecil. Kita bisa melangkah lebih jauh dan menggunakan pembagian rahasia untuk menyimpan kunci, didistribusikan di antara banyak penjaga.
Pemulihan sosial melalui MPC ini bukanlah solusi yang memadai untuk dompet, karena ini berarti bahwa tidak hanya wali saat ini tetapi juga wali sebelumnya dapat berkolusi untuk mencuri aset Anda, yang merupakan risiko tinggi yang tidak dapat diterima. Namun risiko pelanggaran privasi biasanya lebih rendah daripada risiko kehilangan aset total, dan orang dengan kasus penggunaan privasi tinggi selalu dapat menerima risiko kehilangan yang lebih tinggi dengan tidak mencadangkan kunci yang terkait dengan operasi yang menuntut privasi ini.
Untuk menghindari pengguna kewalahan oleh sistem Bizantium dengan beberapa jalur pemulihan, dompet yang mendukung pemulihan sosial mungkin perlu mengelola pemulihan aset dan pemulihan kunci enkripsi.
Kembali ke identitas
Salah satu kesamaan dari perubahan ini adalah bahwa konsep "alamat", pengidentifikasi kriptografi yang Anda gunakan untuk mewakili "Anda" di rantai, harus berubah secara mendasar. "Petunjuk untuk cara berinteraksi dengan saya" tidak lagi hanya berupa alamat ETH; mereka harus berupa kombinasi beberapa alamat pada beberapa L2, alamat meta tersembunyi, kunci enkripsi, dan data lain dalam beberapa bentuk.
Salah satu caranya adalah menjadikan ENS identitas Anda: catatan ENS Anda hanya dapat berisi semua informasi ini, dan jika Anda mengirim seseorang bob.eth (atau bob.ecc.eth, atau...), mereka dapat mencari Dan melihat segala sesuatu tentang caranya itu membayar dan berinteraksi dengan Anda, termasuk metode lintas-domain dan perlindungan privasi yang lebih kompleks.
Namun pendekatan yang berpusat pada ENS ini memiliki dua kelemahan:
Ini mengaitkan terlalu banyak hal dengan nama domain Anda. Nama domain Anda bukan Anda, nama domain Anda adalah salah satu dari banyak atribut Anda. Seharusnya dimungkinkan untuk mengubah nama domain Anda tanpa memindahkan seluruh profil identitas Anda dan memperbarui banyak catatan di banyak aplikasi.
Anda tidak dapat memiliki jagung kontrafaktual yang tidak dapat dipercaya. Fitur utama UX dari setiap blockchain adalah kemampuan untuk mengirim koin ke orang yang belum berinteraksi dengan rantai tersebut. Tanpa fungsi seperti itu, ada tangkapan- 22: berinteraksi dengan rantai memerlukan pembayaran biaya transaksi, yang mengharuskan... sudah memiliki koin. Alamat ETH, termasuk alamat smart contract dengan CREATE2, memiliki fungsi ini. Nama ENS tidak akan, karena jika dua Bob sama-sama memutuskan mereka off-chain bob.ecc.eth, tidak ada cara untuk memilih siapa di antara mereka yang mendapatkan nama tersebut.
Salah satu solusi yang mungkin adalah memasukkan lebih banyak konten ke dalam kontrak keystore yang disebutkan dalam arsitektur sebelumnya di artikel ini. Kontrak keystore dapat berisi semua jenis informasi tentang Anda dan bagaimana Anda berinteraksi dengannya (untuk CCIP, beberapa informasi ini mungkin off-chain), dan pengguna akan menggunakan kontrak keystore mereka sebagai pengidentifikasi utama mereka. Namun sebenarnya aset yang mereka terima akan disimpan di berbagai tempat berbeda. Kontrak keystore adalah nama-agnostik, dan kontrafaktual ramah: Anda dapat menghasilkan alamat yang dapat dibuktikan hanya diinisialisasi oleh kontrak keystore dengan beberapa parameter awal tetap.
Jenis solusi lain mirip dengan protokol pembayaran Bitcoin, sepenuhnya meninggalkan konsep alamat berorientasi pengguna. Salah satu idenya adalah lebih mengandalkan saluran komunikasi langsung antara pengirim dan penerima; misalnya, pengirim dapat mengirim tautan klaim (sebagai URL eksplisit atau kode QR) yang dapat digunakan penerima untuk mengikuti kesediaan mereka menerima pembayaran.
Terlepas dari apakah pengirim atau penerima bergerak lebih dulu, lebih mengandalkan dompet untuk secara langsung menghasilkan informasi pembayaran terkini secara real-time mengurangi friksi. Yang mengatakan, pengidentifikasi persisten itu nyaman (terutama dengan ENS), sedangkan asumsi komunikasi langsung antara pengirim dan penerima dalam praktiknya sangat rumit, jadi kita mungkin akan melihat kombinasi teknologi yang berbeda.
Dalam semua desain ini, membuat hal-hal terpisah dan mudah dipahami pengguna adalah yang paling penting. Kami perlu memastikan pengguna memiliki akses mudah ke tampilan terbaru tentang aset mereka saat ini dan berita apa yang dipublikasikan untuk mereka. Perspektif ini harus mengandalkan alat terbuka, bukan solusi berpemilik. Menjaga infrastruktur pembayaran yang lebih kompleks agar tidak menjadi "menara abstraksi" buram di mana pengembang kesulitan memahami apa yang terjadi dan menyesuaikannya dengan lingkungan baru akan membutuhkan kerja keras. Terlepas dari tantangannya, mencapai skalabilitas, keamanan dompet, dan privasi untuk pengguna biasa sangat penting untuk masa depan Ethereum. Ini bukan hanya tentang kelayakan teknis, ini tentang aksesibilitas sebenarnya untuk pengguna rata-rata. Kita harus bangkit menghadapi tantangan ini.
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Vitalik Buterin: Tiga Transisi Teknis Ethereum
Penulis asli: pendiri Ethereum Vitalik Buterin
Terima kasih khusus kepada Dan Finlay, Karl Floersch, David Hoffman, serta tim Scroll dan SoulWallet atas umpan balik, ulasan, dan saran mereka.
Saat Ethereum bertransisi dari teknologi eksperimental muda ke tumpukan teknologi yang matang yang mampu benar-benar memberikan pengalaman terbuka, global, dan tanpa izin kepada pengguna biasa, tumpukan tersebut harus melalui tiga transisi teknologi utama secara bersamaan:
Tanpa yang pertama, Ethereum akan gagal karena setiap transaksi berharga $3,75 ($82,48 jika kita memiliki bull run lainnya) 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 enggan menyimpan dana mereka (dan aset non-finansial) dan semua orang beralih ke pertukaran terpusat.
Tanpa yang ketiga, Ethereum akan gagal karena semua transaksi (dan POAP dll.) Solusi terpusat yang menyembunyikan data Anda secara maksimal.
Ketiga transisi ini sangat penting karena alasan yang diuraikan di atas. Tapi mereka juga menantang, karena menanganinya dengan benar membutuhkan koordinasi yang erat. Bukan hanya fungsionalitas protokol yang perlu ditingkatkan; dalam beberapa kasus, cara kita berinteraksi dengan Ethereum perlu berubah secara mendasar, membutuhkan perubahan besar pada aplikasi dan dompet.
Tiga transisi ini pada dasarnya akan membentuk ulang hubungan antara pengguna dan alamat
Di dunia yang diperluas L2, pengguna akan ada di banyak L2. Apakah Anda anggota ExampleDAO yang mengandalkan Optimisme? Maka Anda memiliki akun Optimisme! Apakah Anda memegang CDP di sistem stablecoin di ZkSync? Maka Anda memiliki akun di ZkSync! Sudahkah Anda mencoba beberapa aplikasi di kakarot? Maka Anda memiliki akun di Kakarot! Lewatlah sudah hari-hari ketika pengguna hanya memiliki satu alamat.
Dompet kontrak pintar menambah kerumitan dan membuatnya lebih sulit untuk memiliki alamat yang sama di L1 dan berbagai L2. Saat ini, sebagian besar pengguna menggunakan akun yang dimiliki secara eksternal yang alamatnya sebenarnya adalah hash dari kunci publik yang digunakan untuk memverifikasi tanda tangan - jadi tidak ada yang berubah antara L1 dan L2. Namun, dengan dompet smart contract, menjadi lebih sulit untuk memesan alamat. Sementara banyak pekerjaan telah dilakukan untuk mencoba dan membuat alamat menjadi hash kode yang setara di seluruh jaringan, terutama pabrik tunggal CREATE2 dan ERC-2470, sulit untuk membuat ini bekerja dengan sempurna. Beberapa L2 (seperti "Tipe 4 ZK-EVM") tidak persis sama dengan EVM, biasanya Soliditas atau rakitan perantara digunakan sebagai gantinya untuk mencegah kesetaraan hash. Bahkan jika Anda dapat memiliki kesetaraan hash, kemungkinan dompet mengubah kepemilikan melalui perubahan kunci memiliki konsekuensi tidak intuitif lainnya.
Privasi membutuhkan lebih banyak alamat per pengguna dan bahkan dapat mengubah jenis alamat yang kami tangani. Jika proposal alamat tersembunyi digunakan secara luas, bukan hanya beberapa alamat per pengguna, atau satu alamat per L2, pengguna mungkin memiliki satu alamat per transaksi. Skema privasi lainnya, bahkan yang sudah ada seperti Tornado Cash, mengubah cara aset disimpan secara berbeda: banyak dana pengguna disimpan dalam kontrak pintar yang sama (dan dengan demikian di alamat yang sama). Untuk mengirim dana ke pengguna tertentu, pengguna harus bergantung pada sistem pengalamatan internal skema privasi itu sendiri.
Seperti yang telah kita lihat, masing-masing dari ketiga transisi ini melemahkan model mental "satu pengguna ~= satu alamat" dengan cara yang berbeda, dengan beberapa efek ini menambah kompleksitas implementasi transisi. Dua poin komplikasi khusus adalah:
Jika Anda ingin membayar seseorang, bagaimana Anda mendapatkan informasi tentang cara membayar mereka?
Jika pengguna memiliki banyak aset lintas rantai yang disimpan di tempat berbeda, bagaimana cara mereka melakukan perubahan kunci dan pemulihan sosial?
Tiga transisi dan pembayaran on-chain (dan identitas)
Saya memiliki koin di Gulir dan saya ingin membayar kopi (jika "Saya" secara harfiah menyebut saya sebagai penulis artikel ini, maka "kopi" tentu saja merupakan metonim untuk "teh hijau"). Anda menjual kopi kepada saya, tetapi Anda hanya dapat menerima koin di Taiko. apa yang harus dilakukan
Pada dasarnya ada dua solusi:
Tentu saja, solusi ini dapat digabungkan: penerima memberikan daftar L2 yang bersedia mereka terima, dan dompet pengirim menghitung pembayaran, yang mungkin melibatkan pengiriman langsung, atau jalur penghubung melintasi L2 jika mereka beruntung.
Tapi ini hanyalah salah satu contoh tantangan utama yang dihadirkan oleh ketiga transisi ini: operasi sederhana seperti membayar seseorang mulai membutuhkan lebih banyak informasi daripada hanya alamat 20-byte.
Untungnya, transisi ke dompet smart contract tidak akan membebani sistem pengalamatan, tetapi masih ada beberapa masalah teknis yang harus diselesaikan di bagian lain tumpukan aplikasi. Dompet perlu diperbarui untuk memastikan mereka tidak hanya mengirim 21.000 gas dengan transaksi, dan lebih penting untuk memastikan pembayaran menerima akhir dompet tidak hanya melacak transfer ETH dari EOA, tetapi juga melacak ETH dikirim oleh kode kontrak pintar. Aplikasi yang bergantung pada asumsi kepemilikan alamat yang tidak dapat diubah (misalnya NFT yang melarang kontrak pintar untuk menerapkan biaya royalti) harus mencari cara lain untuk mencapai tujuannya. Dompet kontrak pintar juga akan membuat segalanya lebih mudah - terutama, jika seseorang hanya menerima token ERC20 non-ETH, mereka akan dapat menggunakan token itu untuk membayar bensin menggunakan paymaster ERC-4337.
Privasi, di sisi lain, sekali lagi menimbulkan tantangan besar yang belum benar-benar kami atasi. Tornado Cash asli tidak menimbulkan masalah ini karena tidak mendukung transfer internal: pengguna hanya dapat menyetor ke sistem dan menarik diri darinya. Namun, setelah transfer internal dimungkinkan, pengguna perlu menggunakan skema pengalamatan internal sistem privasi. Dalam praktiknya, "pesan pembayaran" pengguna harus berisi (i) semacam "kunci publik pembelanjaan", janji rahasia yang dapat digunakan penerima untuk membelanjakan, dan (ii) cara bagi pengirim untuk mengirim mata uang kripto hanya Informasi yang dapat diuraikan oleh penerima pembayaran untuk membantu penerima pembayaran menemukan pembayaran.
Protokol alamat siluman bergantung pada konsep alamat meta, yang bekerja dengan cara ini: bagian dari alamat meta adalah versi buta dari kunci pengeluaran pengirim, dan bagian lainnya adalah kunci enkripsi pengirim (walaupun implementasi minimal dapat mengatur keduanya tombolnya sama).
Pelajaran utama di sini adalah bahwa dalam ekosistem ramah privasi, pengguna akan memiliki kunci publik konsumsi dan kunci publik enkripsi, dan "informasi pembayaran" pengguna harus menyertakan kedua kunci tersebut. Di luar pembayaran, ada alasan bagus untuk memperluas ke arah ini. Misalnya, jika kami ingin email terenkripsi berdasarkan Ethereum, pengguna perlu memberikan semacam kunci enkripsi secara publik. Di "dunia EOA" kami dapat menggunakan kembali kunci akun untuk ini, tetapi di dunia dompet kontrak pintar yang aman, kami mungkin harus menyediakan fungsi yang lebih eksplisit untuk ini. Ini juga membantu membuat identitas berbasis Ethereum lebih kompatibel dengan ekosistem privasi terdesentralisasi non-Ethereum, terutama kunci PGP.
Tiga transisi dan pemulihan kunci
Cara default untuk menerapkan perubahan kritis dan pemulihan sosial di dunia di mana setiap pengguna memiliki banyak alamat adalah dengan meminta pengguna menjalankan proses pemulihan di setiap alamat secara terpisah. Ini dapat dilakukan dengan satu klik: dompet dapat berisi perangkat lunak yang dapat melakukan prosedur pemulihan pada semua alamat pengguna secara bersamaan. Namun, bahkan dengan penyederhanaan pengalaman pengguna ini, ada tiga masalah dengan pemulihan multi-alamat sederhana:
Memecahkan masalah ini sulit. Untungnya, ada solusi elegan yang bekerja cukup baik: arsitektur yang memisahkan logika validasi dari penyimpanan aset.
Bukti dapat dicapai dengan beberapa cara:
Untuk menambahkan privasi ke skema seperti itu, kami cukup mengenkripsi pointer ini, dan kemudian kami melakukan semua bukti di ZK-SNARKs:
Skenario ini bisa menjadi rumit. Di sisi positifnya, ada banyak potensi sinergi di antara keduanya. Misalnya, konsep "kontrak keystore" juga dapat menyelesaikan tantangan "alamat" yang disebutkan di bagian sebelumnya: jika kita ingin pengguna memiliki alamat permanen yang tidak berubah setiap kali pengguna memasukkan ulang, kita dapat menempatkan Alamat meta tersembunyi , kunci enkripsi dan informasi lainnya dimasukkan ke dalam kontrak keystore, dan alamat kontrak keystore digunakan sebagai "alamat" pengguna.
Banyak infrastruktur sekunder perlu ditingkatkan
Menggunakan ENS itu mahal. Hari ini, di bulan Juni 2023, semuanya tidak terlalu buruk: biaya transaksi tinggi, tetapi masih sebanding dengan biaya domain ENS. Mendaftar dengan zuzalu.eth menghabiskan biaya sekitar $27, di mana $11 adalah biaya transaksi. Tetapi jika kita memiliki bull market lain, biaya akan meroket. Bahkan tanpa kenaikan harga ETH, memindahkan biaya gas kembali ke 200 gwei akan menaikkan biaya tx untuk pendaftaran domain menjadi $104. Jadi jika kami ingin orang benar-benar menggunakan ENS, terutama untuk kasus penggunaan seperti media sosial terdesentralisasi di mana pengguna meminta pendaftaran hampir gratis (dan biaya domain ENS tidak menjadi masalah karena platform ini menyediakan subdomain kepada penggunanya), kami memerlukan ENS di L2 untuk berfungsi .
Untungnya, tim ENS meningkat dan ENS di L2 terjadi! ERC-3668 (alias "standar CCIP"), bersama dengan ENSIP-10, menyediakan cara untuk membuat subdomain ENS pada L2 apa pun dapat diverifikasi secara otomatis. Standar CCIP mensyaratkan pembuatan kontrak cerdas yang menjelaskan metode verifikasi bukti data L2, dan bahwa domain (mis. Optinames menggunakan ecc.eth) dapat dikendalikan oleh kontrak semacam itu. Setelah kontrak CCIP mengambil kendali ecc.eth di L1, mengakses beberapa subdomain.ecc.eth akan secara otomatis melibatkan pencarian dan verifikasi bukti status (misalnya cabang Merkle) di L2 tempat subdomain tertentu sebenarnya disimpan.
Upaya ENS CCIP adalah kisah sukses, dan itu harus dilihat sebagai tanda bahwa reformasi radikal yang kita butuhkan sebenarnya mungkin terjadi. Namun masih banyak pembenahan layer aplikasi yang perlu dilakukan. Beberapa contoh:
Dompet perlu melindungi aset dan data
Hari ini, dompet dalam bisnis melindungi aset. Semuanya on-chain, dan satu-satunya hal yang perlu dilindungi dompet adalah kunci pribadi yang saat ini mengamankan aset ini. Jika Anda mengubah kunci Anda, Anda dapat dengan aman menerbitkan kunci pribadi Anda sebelumnya di Internet pada hari berikutnya. Namun, di dunia ZK, ini tidak lagi benar: dompet tidak hanya melindungi kredensial autentikasi, tetapi juga menyimpan data Anda.
Kami melihat tanda-tanda pertama dunia seperti itu dengan Zupass, sistem identitas berbasis ZK-SNARK yang digunakan oleh Zuzalu. Pengguna memiliki kunci pribadi untuk mengotentikasi sistem, yang dapat digunakan untuk membuat bukti dasar seperti "membuktikan bahwa saya adalah penduduk Zuzalu tanpa mengungkapkan yang mana". Tetapi sistem Zupass juga mulai membangun aplikasi lain di atasnya, terutama stempel (POAP versi Zupass).
Fitur utama yang ditawarkan stempel dibandingkan dengan POAP adalah stempel bersifat pribadi: Anda menyimpan data secara lokal, dan jika Anda ingin seseorang memiliki informasi tentang Anda, Anda hanya perlu membuktikan stempel (atau perhitungan pada stempel) kepada seseorang . Tapi itu menambah risiko: jika Anda kehilangan informasi itu, Anda kehilangan stempelnya.
Tentu saja, masalah menyimpan data dapat direduksi menjadi masalah memegang kunci enkripsi tunggal: beberapa pihak ketiga (atau bahkan rantai) dapat menyimpan salinan data terenkripsi. Ini memiliki keuntungan nyaman bahwa tindakan yang Anda lakukan tidak mengubah kunci enkripsi, jadi tidak diperlukan interaksi dengan sistem yang menjaga keamanan kunci enkripsi Anda. Namun demikian, jika Anda kehilangan kunci enkripsi, Anda kehilangan segalanya. Sebaliknya, jika seseorang melihat kunci enkripsi Anda, mereka dapat melihat semua yang dienkripsi dengan kunci tersebut.
Solusi praktis Zupass adalah mendorong orang untuk menyimpan kunci mereka di beberapa perangkat (seperti laptop dan telepon), karena kemungkinan mereka kehilangan akses ke semuanya sekaligus sangat kecil. Kita bisa melangkah lebih jauh dan menggunakan pembagian rahasia untuk menyimpan kunci, didistribusikan di antara banyak penjaga.
Pemulihan sosial melalui MPC ini bukanlah solusi yang memadai untuk dompet, karena ini berarti bahwa tidak hanya wali saat ini tetapi juga wali sebelumnya dapat berkolusi untuk mencuri aset Anda, yang merupakan risiko tinggi yang tidak dapat diterima. Namun risiko pelanggaran privasi biasanya lebih rendah daripada risiko kehilangan aset total, dan orang dengan kasus penggunaan privasi tinggi selalu dapat menerima risiko kehilangan yang lebih tinggi dengan tidak mencadangkan kunci yang terkait dengan operasi yang menuntut privasi ini.
Untuk menghindari pengguna kewalahan oleh sistem Bizantium dengan beberapa jalur pemulihan, dompet yang mendukung pemulihan sosial mungkin perlu mengelola pemulihan aset dan pemulihan kunci enkripsi.
Kembali ke identitas
Salah satu kesamaan dari perubahan ini adalah bahwa konsep "alamat", pengidentifikasi kriptografi yang Anda gunakan untuk mewakili "Anda" di rantai, harus berubah secara mendasar. "Petunjuk untuk cara berinteraksi dengan saya" tidak lagi hanya berupa alamat ETH; mereka harus berupa kombinasi beberapa alamat pada beberapa L2, alamat meta tersembunyi, kunci enkripsi, dan data lain dalam beberapa bentuk.
Salah satu caranya adalah menjadikan ENS identitas Anda: catatan ENS Anda hanya dapat berisi semua informasi ini, dan jika Anda mengirim seseorang bob.eth (atau bob.ecc.eth, atau...), mereka dapat mencari Dan melihat segala sesuatu tentang caranya itu membayar dan berinteraksi dengan Anda, termasuk metode lintas-domain dan perlindungan privasi yang lebih kompleks.
Namun pendekatan yang berpusat pada ENS ini memiliki dua kelemahan:
Salah satu solusi yang mungkin adalah memasukkan lebih banyak konten ke dalam kontrak keystore yang disebutkan dalam arsitektur sebelumnya di artikel ini. Kontrak keystore dapat berisi semua jenis informasi tentang Anda dan bagaimana Anda berinteraksi dengannya (untuk CCIP, beberapa informasi ini mungkin off-chain), dan pengguna akan menggunakan kontrak keystore mereka sebagai pengidentifikasi utama mereka. Namun sebenarnya aset yang mereka terima akan disimpan di berbagai tempat berbeda. Kontrak keystore adalah nama-agnostik, dan kontrafaktual ramah: Anda dapat menghasilkan alamat yang dapat dibuktikan hanya diinisialisasi oleh kontrak keystore dengan beberapa parameter awal tetap.
Jenis solusi lain mirip dengan protokol pembayaran Bitcoin, sepenuhnya meninggalkan konsep alamat berorientasi pengguna. Salah satu idenya adalah lebih mengandalkan saluran komunikasi langsung antara pengirim dan penerima; misalnya, pengirim dapat mengirim tautan klaim (sebagai URL eksplisit atau kode QR) yang dapat digunakan penerima untuk mengikuti kesediaan mereka menerima pembayaran.
Dalam semua desain ini, membuat hal-hal terpisah dan mudah dipahami pengguna adalah yang paling penting. Kami perlu memastikan pengguna memiliki akses mudah ke tampilan terbaru tentang aset mereka saat ini dan berita apa yang dipublikasikan untuk mereka. Perspektif ini harus mengandalkan alat terbuka, bukan solusi berpemilik. Menjaga infrastruktur pembayaran yang lebih kompleks agar tidak menjadi "menara abstraksi" buram di mana pengembang kesulitan memahami apa yang terjadi dan menyesuaikannya dengan lingkungan baru akan membutuhkan kerja keras. Terlepas dari tantangannya, mencapai skalabilitas, keamanan dompet, dan privasi untuk pengguna biasa sangat penting untuk masa depan Ethereum. Ini bukan hanya tentang kelayakan teknis, ini tentang aksesibilitas sebenarnya untuk pengguna rata-rata. Kita harus bangkit menghadapi tantangan ini.