Ketika Ethereum bertransformasi dari teknologi eksperimental muda menjadi tumpukan teknologi matang yang benar-benar dapat menghadirkan pengalaman terbuka, global, dan tanpa izin bagi pengguna biasa, tumpukan tersebut perlu melalui tiga transformasi teknologi utama, kira-kira secara bersamaan:
Pergeseran penskalaan L2 - semua orang bermigrasi ke rollup
Pergeseran keamanan dompet - semua orang bermigrasi ke dompet kontrak pintar
Pergeseran Privasi - Pastikan transfer uang yang menjaga privasi dan memastikan bahwa semua alat lain yang dikembangkan (pemulihan sosial, identitas, reputasi) juga menjaga privasi
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-898e667808-dd1a6f-62a40f)
Ini adalah segitiga transformasi ekosistem. Anda hanya dapat memilih 3 dari 3.
Tanpa yang pertama, Ethereum akan gagal karena setiap transaksi akan menelan biaya $3,75 ($82,48 jika kita memiliki bull run lagi), dan setiap produk pasar massal pada akhirnya akan melupakan rantai, dan Ambil solusi terpusat untuk semuanya.
Tanpa yang kedua, Ethereum akan gagal karena pengguna akan enggan menyimpan dana mereka (dan aset non-finansial) dan semua akan berpindah ke bursa terpusat.
Tanpa yang ketiga, Ethereum akan gagal, karena semua transaksi (dan POAP, dll.) akan menjadi publik untuk dilihat siapa saja, yang akan menjadi pengorbanan privasi yang sangat tinggi bagi banyak pengguna, dan setiap orang akan pindah untuk memiliki setidaknya beberapa data tersembunyi yang terpusat. larutan.
Untuk alasan yang disebutkan di atas, ketiga transisi ini sangat penting. Tetapi mereka juga menantang karena koordinasi yang intens diperlukan untuk menyelesaikannya. Tidak hanya fungsionalitas protokol yang perlu ditingkatkan, ada kasus di mana perubahan yang cukup mendasar perlu dilakukan pada cara kita berinteraksi dengan Ethereum, yang membutuhkan perubahan mendalam pada aplikasi dan dompet.
Ketiga pergeseran ini akan merevolusi hubungan antara pengguna dan alamat
Di dunia yang diperluas L2, pengguna akan ada di banyak L2. Apakah Anda anggota ExampleDAO, yang ada di Optimism? Maka Anda memiliki akun di Optimisme! Apakah Anda memegang CDP di sistem stablecoin ZkSync? Maka Anda memiliki akun di ZkSync! Sudahkah Anda mencoba beberapa aplikasi yang kebetulan ada di Kakarot? Maka Anda memiliki akun di Kakarot! Lewatlah sudah hari-hari ketika pengguna hanya memiliki satu alamat.
Saya memiliki ETH di empat tempat, menurut tampilan Dompet Berani saya. Ya, Arbitrum dan Arbitrum Nova berbeda. Jangan khawatir, ini akan menjadi lebih rumit dari waktu ke waktu!
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-a9bb8e17d9-dd1a6f-62a40f)
Dompet kontrak pintar menambah kerumitan, 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, mempertahankan alamat menjadi lebih sulit. Sementara banyak pekerjaan telah dilakukan mencoba membuat alamat menjadi hash kode yang setara di seluruh jaringan, terutama pabrik tunggal CREATE2 dan ERC-2470, sangat sulit untuk melakukannya dengan sempurna. Beberapa L2 (seperti "ZK-EVM tipe 4") tidak sepenuhnya setara dengan EVM, biasanya menggunakan Solidity atau rakitan perantara, mencegah kesetaraan hash. Bahkan jika Anda dapat memiliki kesetaraan hash, kemungkinan dompet mengubah kepemilikan melalui perubahan kunci memiliki konsekuensi non-intuitif lainnya.
Privasi memerlukan lebih banyak alamat per pengguna, dan bahkan dapat mengubah jenis alamat yang kami tangani. Jika proposal alamat pribadi digunakan secara luas, daripada hanya beberapa alamat per pengguna, atau satu alamat per L2, mungkin ada 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 alamat internal skema privasi itu sendiri.
Seperti yang telah kita lihat, tiga pergeseran melemahkan model mental "satu pengguna ~ = satu alamat" dengan cara yang berbeda, dan beberapa dari efek ini menyebabkan kompleksitas implementasi pergeseran. Dua komplikasi khusus adalah:
Jika Anda ingin membayar seseorang, bagaimana Anda mendapatkan informasi untuk membayar mereka?
Jika pengguna menyimpan banyak aset di tempat yang berbeda pada rantai yang berbeda, bagaimana cara mereka melakukan penggantian kunci dan pemulihan sosial?
Tiga transisi terkait dengan 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 akan menerima koin di Taiko. apa yang saya lakukan?
Pada dasarnya ada dua solusi:
Dompet penerima (bisa berupa pedagang, atau hanya individu biasa) berusaha untuk mendukung setiap L2, dengan beberapa fungsi otomatis untuk mengintegrasikan dana secara asinkron.
Penerima memberikan L2 dan alamat mereka, dan dompet pengirim secara otomatis merutekan dana ke L2 target melalui semacam 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 (jika mereka beruntung), atau melalui jalur yang dijembatani melintasi L2.
Tapi itu hanya salah satu contoh tantangan utama yang diperkenalkan oleh tiga shift: sesuatu yang sederhana seperti membayar seseorang mulai membutuhkan lebih banyak informasi daripada hanya alamat 20-byte.
Beralih ke dompet smart contract untungnya tidak terlalu membebani sistem alamat, tetapi masih ada beberapa masalah teknis yang perlu ditangani di bagian lain tumpukan aplikasi. Dompet perlu diperbarui untuk memastikan mereka tidak hanya mengirimkan 21.000 gas dalam transaksi, tetapi yang lebih penting untuk memastikan bahwa sisi penerima pembayaran dari dompet tidak hanya melacak transfer ETH dari EOA, tetapi juga ETH yang dikirim melalui kode kontrak pintar. Aplikasi yang mengandalkan asumsi kepemilikan alamat yang tidak dapat diubah (misalnya NFT yang melarang kontrak pintar untuk menegakkan royalti) harus menemukan cara lain untuk mencapai tujuan mereka. Dompet kontrak pintar juga akan membuat beberapa hal lebih mudah - khususnya, jika seseorang hanya menerima token ERC20 non-ETH, mereka akan dapat menggunakan pembayar ERC-4337 untuk membayar bensin dengan token itu.
Di sisi lain, privasi kembali menghadirkan tantangan besar yang belum benar-benar kami selesaikan. Tornado Cash asli tidak menimbulkan masalah ini karena tidak mendukung transfer internal: pengguna hanya dapat menyetor ke sistem dan menarik. Setelah Anda dapat melakukan transfer internal, pengguna harus menggunakan skema alamat internal dari sistem privasi. Dalam praktiknya, "pesan pembayaran" pengguna harus berisi (i) semacam "kunci publik pembelanjaan", janji rahasia yang dapat digunakan penerima untuk membelanjakan, dan (ii) pengirim mengirim pesan terenkripsi yang hanya penerima dapat mendekripsi cara untuk membantu penerima menemukan pembayaran.
Protokol alamat privasi bergantung pada konsep alamat meta, yang bekerja dengan cara berikut: bagian dari alamat meta adalah versi buta dari kunci pengeluaran pengirim, dan bagian lainnya adalah kunci enkripsi pengirim (walaupun implementasi minimal dapat mengatur ini Kedua kuncinya sama).
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-39bca9184c-dd1a6f-62a40f)
Pelajaran utama di sini adalah bahwa dalam ekosistem yang berfokus pada privasi, pengguna akan membelanjakan kunci publik dan kunci publik enkripsi, dan "informasi pembayaran" pengguna harus berisi kedua kunci tersebut. Selain membayar, ada alasan bagus lainnya untuk berkembang ke arah ini. Misalnya, jika kami menginginkan email terenkripsi di Ethereum, pengguna perlu memberikan beberapa bentuk kunci enkripsi secara publik. Dalam "dunia EOA" kami dapat menggunakan kembali kunci akun untuk mencapai hal ini, tetapi dalam dunia dompet kontrak pintar yang aman, kami mungkin harus memiliki fungsionalitas yang lebih eksplisit untuk mencapai hal ini. Ini juga akan membantu membuat identitas berbasis Ethereum lebih kompatibel dengan ekosistem privasi terdesentralisasi non-Ethereum, contoh paling menonjol adalah kunci PGP.
Tiga transformasi dan pemulihan kunci
Di dunia di mana pengguna mungkin memiliki banyak alamat, cara default untuk menerapkan perubahan kunci dan pemulihan sosial adalah meminta pengguna melakukan prosedur pemulihan pada setiap alamat secara individual. Ini dapat dilakukan dengan satu klik: dompet dapat berisi perangkat lunak untuk melakukan prosedur pemulihan pada semua alamat pengguna secara bersamaan. Namun, bahkan dengan penyederhanaan UX seperti itu, ada tiga masalah dengan pemulihan multi-alamat yang naif:
Tagihan gas yang tidak realistis: Yang ini berbicara sendiri.
Alamat kontrafaktual: alamat yang kontrak pintarnya belum dipublikasikan (sebenarnya, ini berarti akun tempat Anda belum mengirim dana). Sebagai pengguna, Anda memiliki jumlah alamat kontrafaktual yang berpotensi tak terbatas: satu atau lebih di setiap L2, termasuk L2 yang belum ada, dan serangkaian alamat kontrafaktual tak terbatas yang sama sekali berbeda, yang berasal dari skema alamat steganografi.
Privasi: Jika pengguna dengan sengaja memiliki banyak alamat untuk menghindari penautan, mereka tentu tidak ingin menautkan semuanya secara publik dengan memulihkannya pada atau sekitar waktu yang sama!
Memecahkan masalah ini sulit. Untungnya, ada solusi yang agak elegan yang bekerja cukup baik: sebuah arsitektur yang memisahkan logika validasi dari penyimpanan aset.
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-25b93e2117-dd1a6f-62a40f)
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 untuk setiap alamat adalah penunjuk ke kontrak keystore. Pembelanjaan dari alamat ini akan memerlukan bukti ke dalam kontrak keystore yang menunjukkan kunci publik pengeluaran saat ini (atau lebih realistis, terbaru).
Bukti dapat dicapai dengan beberapa cara:
Akses L1 hanya-baca langsung di L2. L2 dapat dimodifikasi untuk memberi mereka cara membaca keadaan L1 secara langsung. Jika kontrak keystore ada di L1, ini berarti kontrak di 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 bagian dari satu status L2 ke L2 lainnya. Kelemahan utama bukti Merkle adalah biaya gas yang tinggi karena panjang bukti: bukti mungkin memerlukan 5 kB, meskipun ini akan dikurangi menjadi kurang dari 1 kB di masa mendatang berkat pohon Verkle.
ZK-SNARK. Anda dapat mengurangi biaya data dengan menggunakan ZK-SNARKs cabang Merkle, bukan cabang itu sendiri. Teknik agregasi off-chain (misalnya, berdasarkan EIP-4337) dapat dibangun sehingga satu ZK-SNARK memverifikasi semua bukti status lintas rantai dalam satu blok.
Komitmen KZG. L2, atau skema yang dibangun di atasnya, dapat memperkenalkan sistem pengalamatan berurutan yang memungkinkan pembuktian status di dalam sistem ini hanya sepanjang 48 byte. Seperti ZK-SNARK, skema multi-bukti dapat menggabungkan semua bukti ini menjadi satu bukti untuk setiap blok.
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-a50b6aa1e3-dd1a6f-62a40f)
Jika kita ingin menghindari pembuktian untuk setiap transaksi, kita dapat menerapkan solusi yang lebih ringan, hanya perlu melakukan pembuktian silang L2 saat pemulihan. Pengeluaran dari akun akan bergantung pada kunci pengeluaran yang kunci publiknya disimpan di akun, tetapi pemulihan akan memerlukan transaksi yang menyalin kunci publik pengeluaran saat ini di keystore. Dana di alamat kontrafaktual aman bahkan jika kunci lama Anda tidak: "mengaktifkan" alamat kontrafaktual, mengubahnya menjadi kontrak kerja akan memerlukan pembuktian lintas-L2 yang mereplikasi kunci publik pengeluaran saat ini. Utas ini di forum Aman menjelaskan cara kerja arsitektur serupa.
Untuk menambahkan privasi ke skema seperti itu, kita hanya perlu mengenkripsi pointer, lalu melakukan semua pembuktian di ZK-SNARKs:
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-137a30a3c1-dd1a6f-62a40f)
Dengan lebih banyak pekerjaan (misalnya, menggunakan pekerjaan ini sebagai titik awal), kita juga dapat menghapus sebagian besar kerumitan ZK-SNARK dan membuat skema berbasis KZG yang lebih sederhana.
Skenario ini bisa menjadi rumit. Namun, ada banyak potensi sinergi antara program-program tersebut. Misalnya, konsep "kontrak keystore" mungkin juga menjadi solusi untuk tantangan "alamat" yang disebutkan di bagian sebelumnya: jika kita ingin pengguna memiliki alamat persisten yang tidak berubah saat pengguna memperbarui kuncinya, kita Ini adalah mungkin untuk memasukkan alamat meta rahasia, kunci enkripsi, dan informasi lainnya ke dalam kontrak keystore, dan menggunakan alamat kontrak keystore sebagai "alamat" pengguna.
Banyak infrastruktur sekunder perlu diperbarui
Menggunakan ENS itu mahal. Hari ini, Juni 2023, semuanya tidak terlalu buruk: biaya transaksi, meskipun tinggi, 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, pengembalian biaya gas menjadi 200 gwei akan menaikkan biaya transaksi 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 (biaya domain ENS tidak menjadi masalah karena platform ini menyediakan subdomain untuk pengguna mereka), kami memerlukan ENS Berjalan di L2 .
Untungnya, tim ENS sudah bergerak dan ENS di L2 benar-benar terjadi! ERC-3668 (juga dikenal sebagai "standar CCIP"), bersama dengan ENSIP-10, menyediakan metode untuk memvalidasi subdomain ENS secara otomatis pada L2 apa pun. Standar CCIP memerlukan pengaturan kontrak pintar yang menjelaskan metode untuk memverifikasi bukti data L2, dan nama domain (ecc.eth untuk Optinames, misalnya) dapat ditempatkan di bawah kendali kontrak semacam itu. Setelah kontrak CCIP mengontrol ecc.eth di L1, mengakses beberapa subdomain.ecc.eth akan secara otomatis melibatkan penemuan dan verifikasi status bukti L2 (misalnya, cabang Merkle) yang benar-benar menyimpan subdomain tersebut.
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-b1a43ef2c1-dd1a6f-62a40f)
Sebenarnya mendapatkan bukti melibatkan mengakses serangkaian URL yang disimpan dalam kontrak, yang memang terasa seperti sentralisasi, meskipun saya berpendapat bahwa sebenarnya tidak: ini adalah model kepercayaan 1-of-N (bukti tidak valid akan diblokir oleh CCIP Verifikasi logika dalam fungsi panggilan balik kontrak menangkap bahwa, selama ada URL yang mengembalikan bukti yang valid, tidak ada masalah). Daftar URL ini mungkin berisi lusinan URL.
Pekerjaan ENS CCIP adalah kisah sukses dan harus dilihat sebagai tanda bahwa reformasi radikal yang kita butuhkan adalah mungkin. Tetapi diperlukan lebih banyak reformasi tingkat aplikasi. Beberapa contoh termasuk:
Banyak dapp mengandalkan pengguna untuk memberikan tanda tangan off-chain. Untuk Externally Owned Accounts (EOA), caranya mudah. ERC-1271 menyediakan cara standar untuk dompet smart contract untuk melakukan ini. Namun, banyak dapp masih belum mendukung ERC-1271; mereka harus mendukungnya.
Dapp yang menggunakan "Apakah ini EOA?" untuk membedakan antara pengguna dan kontrak (misalnya, untuk mencegah transfer atau menerapkan royalti) akan dihentikan. Secara umum, saya akan menyarankan untuk tidak mencoba menemukan solusi teknis murni; pertanyaan untuk mengetahui apakah transfer tertentu dari kontrol kriptografi adalah transfer kepentingan yang menguntungkan adalah sulit yang tidak dapat diselesaikan tanpa menggunakan beberapa komunitas off-chain- mekanisme yang digerakkan. Pemecahan selanjutnya. Kemungkinan besar, aplikasi harus lebih sedikit mengandalkan pemblokiran transfer dan lebih mengandalkan teknik seperti pajak Harberger.
Bagaimana dompet berinteraksi dengan pengeluaran dan kunci enkripsi perlu ditingkatkan. Saat ini, dompet biasanya menggunakan tanda tangan deterministik untuk menghasilkan kunci khusus aplikasi: nonce standar (mis., hash nama aplikasi) ditandatangani dengan kunci privat EOA, menghasilkan nonce yang tidak dapat dibuat tanpa kunci privat. dari , jadi secara teknis aman. Namun, teknik ini "buram" ke dompet, mencegah dompet menerapkan pemeriksaan keamanan tingkat antarmuka pengguna. Dalam ekosistem yang lebih matang, penandatanganan, enkripsi, dan fungsi terkait perlu ditangani secara lebih eksplisit oleh dompet.
Klien ringan (misalnya Helios) harus memverifikasi L2, bukan hanya L1. Saat ini, klien ringan berfokus pada pemeriksaan validitas header L1 (menggunakan protokol sinkronisasi klien ringan), dan memvalidasi status L1 dan garpu Merkle dari transaksi yang berasal dari header L1. Besok, mereka juga perlu memverifikasi bukti status L2 yang berasal dari root status yang disimpan di L1 (versi yang lebih canggih ini benar-benar melihat pra-konfirmasi L2).
Dompet perlu melindungi aset dan data
Sekarang, bisnis dompet adalah melindungi aset. Semuanya on-chain, dan satu-satunya hal yang perlu dilindungi dompet adalah kunci pribadi yang saat ini melindungi aset tersebut. Jika Anda mengubah kunci, Anda dapat dengan aman menerbitkan kunci pribadi sebelumnya di Internet pada hari berikutnya. Namun, di dunia tanpa bukti pengetahuan, hal ini tidak lagi terjadi: dompet tidak hanya melindungi kredensial autentikasi, tetapi juga melindungi data Anda.
Kami melihat tanda-tanda pertama dunia seperti itu dengan Zupass, sistem identitas berbasis ZK-SNARK yang digunakan di Zuzalu. Pengguna memiliki kunci privat, yang mereka gunakan untuk mengautentikasi sistem, yang dapat digunakan untuk melakukan pembuktian dasar seperti "buktikan bahwa saya adalah penduduk Zuzalu, tetapi jangan ungkapkan yang mana". Namun, sistem Zupass juga mulai memiliki aplikasi lain yang dibuat di atasnya, terutama Stamps (POAP versi Zupass).
Salah satu dari banyak stempel Zupass saya yang membuktikan bahwa saya bangga menjadi anggota Tim Kucing.
Fitur utama yang ditawarkan perangko di atas POAP adalah perangko bersifat pribadi: Anda menyimpan data secara lokal, dan Anda hanya membuktikan perangko (atau perhitungan di atasnya) kepada mereka jika Anda ingin mereka memiliki informasi ini tentang Anda. Tapi ini meningkatkan risikonya: jika Anda kehilangan informasi ini, Anda kehilangan stempel Anda.
Tentu saja, masalah menyimpan data bermuara pada masalah memegang kunci kriptografi: 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 de-facto Zupass adalah mendorong orang untuk menyimpan kunci mereka di beberapa perangkat (misalnya, laptop dan telepon), karena kemungkinan mereka kehilangan semuanya pada saat yang bersamaan sangat kecil. Kita dapat melangkah lebih jauh dan menggunakan pembagian rahasia untuk menyimpan kunci, membagi kunci di antara banyak penjaga.
Pemulihan sosial melalui MPC ini bukanlah solusi yang memadai untuk dompet, karena ini berarti tidak hanya wali saat ini, tetapi wali sebelumnya dapat berkolusi untuk mencuri aset Anda, yang merupakan risiko tinggi yang tidak dapat diterima. Namun, pelanggaran privasi biasanya berisiko lebih kecil daripada kehilangan aset sepenuhnya, dan jika seseorang memerlukan kasus penggunaan yang sangat menjaga privasi, dia dapat menerima risiko kehilangan yang lebih tinggi dengan tidak mencadangkan kunci terkait yang memerlukan privasi- melestarikan tindakan.
Untuk menghindari pengguna yang kewalahan dengan sistem kompleks dari beberapa jalur pemulihan, dompet yang mendukung pemulihan sosial mungkin perlu mengelola pemulihan aset dan pemulihan kunci enkripsi.
Kembali ke pertanyaan identitas
Tema umum dari perubahan ini adalah bahwa konsep "alamat" yang Anda gunakan di rantai sebagai pengidentifikasi kriptografi yang mewakili "Anda" harus berubah secara radikal. "Petunjuk tentang cara berinteraksi dengan saya" tidak lagi hanya alamat ETH; mereka harus berisi beberapa kombinasi beberapa alamat di beberapa L2, alamat meta rahasia, kunci enkripsi, dan data lain dalam beberapa bentuk.
Salah satu cara untuk melakukannya adalah menjadikan ENS identitas Anda: catatan ENS Anda dapat berisi semua informasi ini, dan jika Anda mengirim seseorang bob.eth (atau bob.ecc.eth, atau...), mereka dapat mengetahui dan mempelajarinya semua hal yang membayar dan berinteraksi dengan Anda, termasuk dengan cara lintas sektoral dan menjaga privasi yang lebih kompleks.
Namun, pendekatan yang berpusat pada ENS ini memiliki dua kelemahan:
Itu mengikat terlalu banyak hal pada nama Anda. Nama Anda bukan Anda, nama Anda hanyalah salah satu dari banyak atribut Anda. Anda harus dapat mengubah nama Anda tanpa memindahkan seluruh profil identitas Anda dan memperbarui banyak catatan di banyak aplikasi.
Anda tidak dapat memiliki nama kontrafaktual yang tidak dipercaya. Fitur utama UX dari setiap blockchain adalah kemampuan untuk mengirim koin ke orang yang belum berinteraksi dengan rantai tersebut. Tanpa fungsionalitas seperti itu, ada masalah ayam-dan-telur: berinteraksi dengan rantai membutuhkan pembayaran biaya transaksi, dan membayar biaya mengharuskan... sudah memiliki koin. Alamat ETH, termasuk alamat smart contract dengan CREATE2, memiliki fitur ini. Nama ENS tidak, karena jika dua Bobs keduanya memutuskan mereka off-chain bob.ecc.eth, tidak ada cara untuk memilih mana yang mendapatkan nama.
Salah satu solusi yang mungkin adalah memasukkan lebih banyak barang ke dalam kontrak keystore yang disebutkan dalam arsitektur sebelumnya di posting ini. Kontrak keystore dapat berisi berbagai informasi tentang Anda dan cara Anda berinteraksi dengannya (melalui CCIP, beberapa di antaranya dapat bersifat off-chain), dan pengguna dapat menggunakan kontrak keystore mereka sebagai pengidentifikasi utama. Namun sebenarnya aset yang mereka terima akan disimpan di berbagai tempat berbeda. Kontrak keystore tidak terikat pada nama, mereka ramah kontrafaktual: Anda dapat membuat alamat yang hanya dapat diinisialisasi oleh kontrak keystore dengan beberapa parameter awal tetap.
Kategori solusi lainnya berkaitan dengan meninggalkan konsep alamat berorientasi pengguna, yang memiliki semangat yang sama dengan protokol pembayaran Bitcoin. Satu ide 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 Terima pembayaran sesuai keinginan mereka.
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-f7c28b44ae-dd1a6f-62a40f)
Entah itu pengirim atau penerima yang bertindak lebih dulu, lebih mengandalkan dompet untuk secara langsung menghasilkan informasi pembayaran terkini secara real-time mengurangi friksi. Karena itu, pengidentifikasi persisten nyaman (terutama dengan ENS), dan dalam praktiknya asumsi komunikasi langsung antara pengirim dan penerima adalah masalah yang sangat rumit, jadi kami mungkin melihat kombinasi teknologi yang berbeda.
Dalam semua desain ini, sangat penting untuk menjaga agar semuanya tetap terdesentralisasi dan dapat dipahami oleh pengguna. Kami perlu memastikan bahwa pengguna dapat dengan mudah mengakses tampilan terbaru dari aset mereka saat ini, serta informasi yang dipublikasikan yang ditujukan untuk mereka. Pandangan ini harus mengandalkan alat terbuka daripada solusi berpemilik. Diperlukan kerja keras untuk menjaga agar infrastruktur pembayaran yang lebih kompleks tidak menjadi "menara abstraksi" yang buram di mana pengembang kesulitan memahami apa yang sedang terjadi dan menyesuaikannya dengan lingkungan baru. Terlepas dari tantangannya, mencapai skalabilitas Ethereum, keamanan dompet, dan privasi untuk pengguna biasa adalah yang terpenting. Ini bukan hanya tentang kelayakan teknis, ini tentang aksesibilitas sebenarnya untuk pengguna rata-rata. Kita perlu menjawab tantangan ini.
Terima kasih khusus kepada Dan Finlay, Karl Floersch, David Hoffman, serta tim Scroll dan SoulWallet atas umpan balik, ulasan, dan saran mereka.
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: Untuk mencapai implementasi berskala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi
Asli: "Tiga Transisi"
Ditulis oleh: Vitalik Buterin
Kompilasi: MarsBit, MK
Ketika Ethereum bertransformasi dari teknologi eksperimental muda menjadi tumpukan teknologi matang yang benar-benar dapat menghadirkan pengalaman terbuka, global, dan tanpa izin bagi pengguna biasa, tumpukan tersebut perlu melalui tiga transformasi teknologi utama, kira-kira secara bersamaan:
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-898e667808-dd1a6f-62a40f)
Ini adalah segitiga transformasi ekosistem. Anda hanya dapat memilih 3 dari 3.
Tanpa yang pertama, Ethereum akan gagal karena setiap transaksi akan menelan biaya $3,75 ($82,48 jika kita memiliki bull run lagi), dan setiap produk pasar massal pada akhirnya akan melupakan rantai, dan Ambil solusi terpusat untuk semuanya.
Tanpa yang kedua, Ethereum akan gagal karena pengguna akan enggan menyimpan dana mereka (dan aset non-finansial) dan semua akan berpindah ke bursa terpusat.
Tanpa yang ketiga, Ethereum akan gagal, karena semua transaksi (dan POAP, dll.) akan menjadi publik untuk dilihat siapa saja, yang akan menjadi pengorbanan privasi yang sangat tinggi bagi banyak pengguna, dan setiap orang akan pindah untuk memiliki setidaknya beberapa data tersembunyi yang terpusat. larutan.
Untuk alasan yang disebutkan di atas, ketiga transisi ini sangat penting. Tetapi mereka juga menantang karena koordinasi yang intens diperlukan untuk menyelesaikannya. Tidak hanya fungsionalitas protokol yang perlu ditingkatkan, ada kasus di mana perubahan yang cukup mendasar perlu dilakukan pada cara kita berinteraksi dengan Ethereum, yang membutuhkan perubahan mendalam pada aplikasi dan dompet.
Ketiga pergeseran ini akan merevolusi hubungan antara pengguna dan alamat
Di dunia yang diperluas L2, pengguna akan ada di banyak L2. Apakah Anda anggota ExampleDAO, yang ada di Optimism? Maka Anda memiliki akun di Optimisme! Apakah Anda memegang CDP di sistem stablecoin ZkSync? Maka Anda memiliki akun di ZkSync! Sudahkah Anda mencoba beberapa aplikasi yang kebetulan ada di Kakarot? Maka Anda memiliki akun di Kakarot! Lewatlah sudah hari-hari ketika pengguna hanya memiliki satu alamat.
Saya memiliki ETH di empat tempat, menurut tampilan Dompet Berani saya. Ya, Arbitrum dan Arbitrum Nova berbeda. Jangan khawatir, ini akan menjadi lebih rumit dari waktu ke waktu!
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-a9bb8e17d9-dd1a6f-62a40f)
Dompet kontrak pintar menambah kerumitan, 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, mempertahankan alamat menjadi lebih sulit. Sementara banyak pekerjaan telah dilakukan mencoba membuat alamat menjadi hash kode yang setara di seluruh jaringan, terutama pabrik tunggal CREATE2 dan ERC-2470, sangat sulit untuk melakukannya dengan sempurna. Beberapa L2 (seperti "ZK-EVM tipe 4") tidak sepenuhnya setara dengan EVM, biasanya menggunakan Solidity atau rakitan perantara, mencegah kesetaraan hash. Bahkan jika Anda dapat memiliki kesetaraan hash, kemungkinan dompet mengubah kepemilikan melalui perubahan kunci memiliki konsekuensi non-intuitif lainnya.
Privasi memerlukan lebih banyak alamat per pengguna, dan bahkan dapat mengubah jenis alamat yang kami tangani. Jika proposal alamat pribadi digunakan secara luas, daripada hanya beberapa alamat per pengguna, atau satu alamat per L2, mungkin ada 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 alamat internal skema privasi itu sendiri.
Seperti yang telah kita lihat, tiga pergeseran melemahkan model mental "satu pengguna ~ = satu alamat" dengan cara yang berbeda, dan beberapa dari efek ini menyebabkan kompleksitas implementasi pergeseran. Dua komplikasi khusus adalah:
Jika Anda ingin membayar seseorang, bagaimana Anda mendapatkan informasi untuk membayar mereka?
Jika pengguna menyimpan banyak aset di tempat yang berbeda pada rantai yang berbeda, bagaimana cara mereka melakukan penggantian kunci dan pemulihan sosial?
Tiga transisi terkait dengan 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 akan menerima koin di Taiko. apa yang saya lakukan?
Pada dasarnya ada dua solusi:
Dompet penerima (bisa berupa pedagang, atau hanya individu biasa) berusaha untuk mendukung setiap L2, dengan beberapa fungsi otomatis untuk mengintegrasikan dana secara asinkron.
Penerima memberikan L2 dan alamat mereka, dan dompet pengirim secara otomatis merutekan dana ke L2 target melalui semacam 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 (jika mereka beruntung), atau melalui jalur yang dijembatani melintasi L2.
Tapi itu hanya salah satu contoh tantangan utama yang diperkenalkan oleh tiga shift: sesuatu yang sederhana seperti membayar seseorang mulai membutuhkan lebih banyak informasi daripada hanya alamat 20-byte.
Beralih ke dompet smart contract untungnya tidak terlalu membebani sistem alamat, tetapi masih ada beberapa masalah teknis yang perlu ditangani di bagian lain tumpukan aplikasi. Dompet perlu diperbarui untuk memastikan mereka tidak hanya mengirimkan 21.000 gas dalam transaksi, tetapi yang lebih penting untuk memastikan bahwa sisi penerima pembayaran dari dompet tidak hanya melacak transfer ETH dari EOA, tetapi juga ETH yang dikirim melalui kode kontrak pintar. Aplikasi yang mengandalkan asumsi kepemilikan alamat yang tidak dapat diubah (misalnya NFT yang melarang kontrak pintar untuk menegakkan royalti) harus menemukan cara lain untuk mencapai tujuan mereka. Dompet kontrak pintar juga akan membuat beberapa hal lebih mudah - khususnya, jika seseorang hanya menerima token ERC20 non-ETH, mereka akan dapat menggunakan pembayar ERC-4337 untuk membayar bensin dengan token itu.
Di sisi lain, privasi kembali menghadirkan tantangan besar yang belum benar-benar kami selesaikan. Tornado Cash asli tidak menimbulkan masalah ini karena tidak mendukung transfer internal: pengguna hanya dapat menyetor ke sistem dan menarik. Setelah Anda dapat melakukan transfer internal, pengguna harus menggunakan skema alamat internal dari sistem privasi. Dalam praktiknya, "pesan pembayaran" pengguna harus berisi (i) semacam "kunci publik pembelanjaan", janji rahasia yang dapat digunakan penerima untuk membelanjakan, dan (ii) pengirim mengirim pesan terenkripsi yang hanya penerima dapat mendekripsi cara untuk membantu penerima menemukan pembayaran.
Protokol alamat privasi bergantung pada konsep alamat meta, yang bekerja dengan cara berikut: bagian dari alamat meta adalah versi buta dari kunci pengeluaran pengirim, dan bagian lainnya adalah kunci enkripsi pengirim (walaupun implementasi minimal dapat mengatur ini Kedua kuncinya sama).
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-39bca9184c-dd1a6f-62a40f)
Pelajaran utama di sini adalah bahwa dalam ekosistem yang berfokus pada privasi, pengguna akan membelanjakan kunci publik dan kunci publik enkripsi, dan "informasi pembayaran" pengguna harus berisi kedua kunci tersebut. Selain membayar, ada alasan bagus lainnya untuk berkembang ke arah ini. Misalnya, jika kami menginginkan email terenkripsi di Ethereum, pengguna perlu memberikan beberapa bentuk kunci enkripsi secara publik. Dalam "dunia EOA" kami dapat menggunakan kembali kunci akun untuk mencapai hal ini, tetapi dalam dunia dompet kontrak pintar yang aman, kami mungkin harus memiliki fungsionalitas yang lebih eksplisit untuk mencapai hal ini. Ini juga akan membantu membuat identitas berbasis Ethereum lebih kompatibel dengan ekosistem privasi terdesentralisasi non-Ethereum, contoh paling menonjol adalah kunci PGP.
Tiga transformasi dan pemulihan kunci
Di dunia di mana pengguna mungkin memiliki banyak alamat, cara default untuk menerapkan perubahan kunci dan pemulihan sosial adalah meminta pengguna melakukan prosedur pemulihan pada setiap alamat secara individual. Ini dapat dilakukan dengan satu klik: dompet dapat berisi perangkat lunak untuk melakukan prosedur pemulihan pada semua alamat pengguna secara bersamaan. Namun, bahkan dengan penyederhanaan UX seperti itu, ada tiga masalah dengan pemulihan multi-alamat yang naif:
Memecahkan masalah ini sulit. Untungnya, ada solusi yang agak elegan yang bekerja cukup baik: sebuah arsitektur yang memisahkan logika validasi dari penyimpanan aset.
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-25b93e2117-dd1a6f-62a40f)
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 untuk setiap alamat adalah penunjuk ke kontrak keystore. Pembelanjaan dari alamat ini akan memerlukan bukti ke dalam kontrak keystore yang menunjukkan kunci publik pengeluaran saat ini (atau lebih realistis, terbaru).
Bukti dapat dicapai dengan beberapa cara:
Akses L1 hanya-baca langsung di L2. L2 dapat dimodifikasi untuk memberi mereka cara membaca keadaan L1 secara langsung. Jika kontrak keystore ada di L1, ini berarti kontrak di 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 bagian dari satu status L2 ke L2 lainnya. Kelemahan utama bukti Merkle adalah biaya gas yang tinggi karena panjang bukti: bukti mungkin memerlukan 5 kB, meskipun ini akan dikurangi menjadi kurang dari 1 kB di masa mendatang berkat pohon Verkle.
ZK-SNARK. Anda dapat mengurangi biaya data dengan menggunakan ZK-SNARKs cabang Merkle, bukan cabang itu sendiri. Teknik agregasi off-chain (misalnya, berdasarkan EIP-4337) dapat dibangun sehingga satu ZK-SNARK memverifikasi semua bukti status lintas rantai dalam satu blok.
Komitmen KZG. L2, atau skema yang dibangun di atasnya, dapat memperkenalkan sistem pengalamatan berurutan yang memungkinkan pembuktian status di dalam sistem ini hanya sepanjang 48 byte. Seperti ZK-SNARK, skema multi-bukti dapat menggabungkan semua bukti ini menjadi satu bukti untuk setiap blok.
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-a50b6aa1e3-dd1a6f-62a40f)
Jika kita ingin menghindari pembuktian untuk setiap transaksi, kita dapat menerapkan solusi yang lebih ringan, hanya perlu melakukan pembuktian silang L2 saat pemulihan. Pengeluaran dari akun akan bergantung pada kunci pengeluaran yang kunci publiknya disimpan di akun, tetapi pemulihan akan memerlukan transaksi yang menyalin kunci publik pengeluaran saat ini di keystore. Dana di alamat kontrafaktual aman bahkan jika kunci lama Anda tidak: "mengaktifkan" alamat kontrafaktual, mengubahnya menjadi kontrak kerja akan memerlukan pembuktian lintas-L2 yang mereplikasi kunci publik pengeluaran saat ini. Utas ini di forum Aman menjelaskan cara kerja arsitektur serupa.
Untuk menambahkan privasi ke skema seperti itu, kita hanya perlu mengenkripsi pointer, lalu melakukan semua pembuktian di ZK-SNARKs:
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-137a30a3c1-dd1a6f-62a40f)
Dengan lebih banyak pekerjaan (misalnya, menggunakan pekerjaan ini sebagai titik awal), kita juga dapat menghapus sebagian besar kerumitan ZK-SNARK dan membuat skema berbasis KZG yang lebih sederhana.
Skenario ini bisa menjadi rumit. Namun, ada banyak potensi sinergi antara program-program tersebut. Misalnya, konsep "kontrak keystore" mungkin juga menjadi solusi untuk tantangan "alamat" yang disebutkan di bagian sebelumnya: jika kita ingin pengguna memiliki alamat persisten yang tidak berubah saat pengguna memperbarui kuncinya, kita Ini adalah mungkin untuk memasukkan alamat meta rahasia, kunci enkripsi, dan informasi lainnya ke dalam kontrak keystore, dan menggunakan alamat kontrak keystore sebagai "alamat" pengguna.
Banyak infrastruktur sekunder perlu diperbarui
Menggunakan ENS itu mahal. Hari ini, Juni 2023, semuanya tidak terlalu buruk: biaya transaksi, meskipun tinggi, 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, pengembalian biaya gas menjadi 200 gwei akan menaikkan biaya transaksi 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 (biaya domain ENS tidak menjadi masalah karena platform ini menyediakan subdomain untuk pengguna mereka), kami memerlukan ENS Berjalan di L2 .
Untungnya, tim ENS sudah bergerak dan ENS di L2 benar-benar terjadi! ERC-3668 (juga dikenal sebagai "standar CCIP"), bersama dengan ENSIP-10, menyediakan metode untuk memvalidasi subdomain ENS secara otomatis pada L2 apa pun. Standar CCIP memerlukan pengaturan kontrak pintar yang menjelaskan metode untuk memverifikasi bukti data L2, dan nama domain (ecc.eth untuk Optinames, misalnya) dapat ditempatkan di bawah kendali kontrak semacam itu. Setelah kontrak CCIP mengontrol ecc.eth di L1, mengakses beberapa subdomain.ecc.eth akan secara otomatis melibatkan penemuan dan verifikasi status bukti L2 (misalnya, cabang Merkle) yang benar-benar menyimpan subdomain tersebut.
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-b1a43ef2c1-dd1a6f-62a40f)
Sebenarnya mendapatkan bukti melibatkan mengakses serangkaian URL yang disimpan dalam kontrak, yang memang terasa seperti sentralisasi, meskipun saya berpendapat bahwa sebenarnya tidak: ini adalah model kepercayaan 1-of-N (bukti tidak valid akan diblokir oleh CCIP Verifikasi logika dalam fungsi panggilan balik kontrak menangkap bahwa, selama ada URL yang mengembalikan bukti yang valid, tidak ada masalah). Daftar URL ini mungkin berisi lusinan URL.
Pekerjaan ENS CCIP adalah kisah sukses dan harus dilihat sebagai tanda bahwa reformasi radikal yang kita butuhkan adalah mungkin. Tetapi diperlukan lebih banyak reformasi tingkat aplikasi. Beberapa contoh termasuk:
Banyak dapp mengandalkan pengguna untuk memberikan tanda tangan off-chain. Untuk Externally Owned Accounts (EOA), caranya mudah. ERC-1271 menyediakan cara standar untuk dompet smart contract untuk melakukan ini. Namun, banyak dapp masih belum mendukung ERC-1271; mereka harus mendukungnya.
Dapp yang menggunakan "Apakah ini EOA?" untuk membedakan antara pengguna dan kontrak (misalnya, untuk mencegah transfer atau menerapkan royalti) akan dihentikan. Secara umum, saya akan menyarankan untuk tidak mencoba menemukan solusi teknis murni; pertanyaan untuk mengetahui apakah transfer tertentu dari kontrol kriptografi adalah transfer kepentingan yang menguntungkan adalah sulit yang tidak dapat diselesaikan tanpa menggunakan beberapa komunitas off-chain- mekanisme yang digerakkan. Pemecahan selanjutnya. Kemungkinan besar, aplikasi harus lebih sedikit mengandalkan pemblokiran transfer dan lebih mengandalkan teknik seperti pajak Harberger.
Bagaimana dompet berinteraksi dengan pengeluaran dan kunci enkripsi perlu ditingkatkan. Saat ini, dompet biasanya menggunakan tanda tangan deterministik untuk menghasilkan kunci khusus aplikasi: nonce standar (mis., hash nama aplikasi) ditandatangani dengan kunci privat EOA, menghasilkan nonce yang tidak dapat dibuat tanpa kunci privat. dari , jadi secara teknis aman. Namun, teknik ini "buram" ke dompet, mencegah dompet menerapkan pemeriksaan keamanan tingkat antarmuka pengguna. Dalam ekosistem yang lebih matang, penandatanganan, enkripsi, dan fungsi terkait perlu ditangani secara lebih eksplisit oleh dompet.
Klien ringan (misalnya Helios) harus memverifikasi L2, bukan hanya L1. Saat ini, klien ringan berfokus pada pemeriksaan validitas header L1 (menggunakan protokol sinkronisasi klien ringan), dan memvalidasi status L1 dan garpu Merkle dari transaksi yang berasal dari header L1. Besok, mereka juga perlu memverifikasi bukti status L2 yang berasal dari root status yang disimpan di L1 (versi yang lebih canggih ini benar-benar melihat pra-konfirmasi L2).
Dompet perlu melindungi aset dan data
Sekarang, bisnis dompet adalah melindungi aset. Semuanya on-chain, dan satu-satunya hal yang perlu dilindungi dompet adalah kunci pribadi yang saat ini melindungi aset tersebut. Jika Anda mengubah kunci, Anda dapat dengan aman menerbitkan kunci pribadi sebelumnya di Internet pada hari berikutnya. Namun, di dunia tanpa bukti pengetahuan, hal ini tidak lagi terjadi: dompet tidak hanya melindungi kredensial autentikasi, tetapi juga melindungi data Anda.
Kami melihat tanda-tanda pertama dunia seperti itu dengan Zupass, sistem identitas berbasis ZK-SNARK yang digunakan di Zuzalu. Pengguna memiliki kunci privat, yang mereka gunakan untuk mengautentikasi sistem, yang dapat digunakan untuk melakukan pembuktian dasar seperti "buktikan bahwa saya adalah penduduk Zuzalu, tetapi jangan ungkapkan yang mana". Namun, sistem Zupass juga mulai memiliki aplikasi lain yang dibuat di atasnya, terutama Stamps (POAP versi Zupass).
Salah satu dari banyak stempel Zupass saya yang membuktikan bahwa saya bangga menjadi anggota Tim Kucing.
Fitur utama yang ditawarkan perangko di atas POAP adalah perangko bersifat pribadi: Anda menyimpan data secara lokal, dan Anda hanya membuktikan perangko (atau perhitungan di atasnya) kepada mereka jika Anda ingin mereka memiliki informasi ini tentang Anda. Tapi ini meningkatkan risikonya: jika Anda kehilangan informasi ini, Anda kehilangan stempel Anda.
Tentu saja, masalah menyimpan data bermuara pada masalah memegang kunci kriptografi: 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 de-facto Zupass adalah mendorong orang untuk menyimpan kunci mereka di beberapa perangkat (misalnya, laptop dan telepon), karena kemungkinan mereka kehilangan semuanya pada saat yang bersamaan sangat kecil. Kita dapat melangkah lebih jauh dan menggunakan pembagian rahasia untuk menyimpan kunci, membagi kunci di antara banyak penjaga.
Pemulihan sosial melalui MPC ini bukanlah solusi yang memadai untuk dompet, karena ini berarti tidak hanya wali saat ini, tetapi wali sebelumnya dapat berkolusi untuk mencuri aset Anda, yang merupakan risiko tinggi yang tidak dapat diterima. Namun, pelanggaran privasi biasanya berisiko lebih kecil daripada kehilangan aset sepenuhnya, dan jika seseorang memerlukan kasus penggunaan yang sangat menjaga privasi, dia dapat menerima risiko kehilangan yang lebih tinggi dengan tidak mencadangkan kunci terkait yang memerlukan privasi- melestarikan tindakan.
Untuk menghindari pengguna yang kewalahan dengan sistem kompleks dari beberapa jalur pemulihan, dompet yang mendukung pemulihan sosial mungkin perlu mengelola pemulihan aset dan pemulihan kunci enkripsi.
Kembali ke pertanyaan identitas
Tema umum dari perubahan ini adalah bahwa konsep "alamat" yang Anda gunakan di rantai sebagai pengidentifikasi kriptografi yang mewakili "Anda" harus berubah secara radikal. "Petunjuk tentang cara berinteraksi dengan saya" tidak lagi hanya alamat ETH; mereka harus berisi beberapa kombinasi beberapa alamat di beberapa L2, alamat meta rahasia, kunci enkripsi, dan data lain dalam beberapa bentuk.
Salah satu cara untuk melakukannya adalah menjadikan ENS identitas Anda: catatan ENS Anda dapat berisi semua informasi ini, dan jika Anda mengirim seseorang bob.eth (atau bob.ecc.eth, atau...), mereka dapat mengetahui dan mempelajarinya semua hal yang membayar dan berinteraksi dengan Anda, termasuk dengan cara lintas sektoral dan menjaga privasi yang lebih kompleks.
Namun, pendekatan yang berpusat pada ENS ini memiliki dua kelemahan:
Salah satu solusi yang mungkin adalah memasukkan lebih banyak barang ke dalam kontrak keystore yang disebutkan dalam arsitektur sebelumnya di posting ini. Kontrak keystore dapat berisi berbagai informasi tentang Anda dan cara Anda berinteraksi dengannya (melalui CCIP, beberapa di antaranya dapat bersifat off-chain), dan pengguna dapat menggunakan kontrak keystore mereka sebagai pengidentifikasi utama. Namun sebenarnya aset yang mereka terima akan disimpan di berbagai tempat berbeda. Kontrak keystore tidak terikat pada nama, mereka ramah kontrafaktual: Anda dapat membuat alamat yang hanya dapat diinisialisasi oleh kontrak keystore dengan beberapa parameter awal tetap.
Kategori solusi lainnya berkaitan dengan meninggalkan konsep alamat berorientasi pengguna, yang memiliki semangat yang sama dengan protokol pembayaran Bitcoin. Satu ide 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 Terima pembayaran sesuai keinginan mereka.
![Vitalik: Untuk mencapai implementasi skala besar, Ethereum harus menjalani tiga transformasi: L2, dompet, dan privasi] (https://img.gateio.im/social/moments-69a80767fe-f7c28b44ae-dd1a6f-62a40f)
Entah itu pengirim atau penerima yang bertindak lebih dulu, lebih mengandalkan dompet untuk secara langsung menghasilkan informasi pembayaran terkini secara real-time mengurangi friksi. Karena itu, pengidentifikasi persisten nyaman (terutama dengan ENS), dan dalam praktiknya asumsi komunikasi langsung antara pengirim dan penerima adalah masalah yang sangat rumit, jadi kami mungkin melihat kombinasi teknologi yang berbeda.
Dalam semua desain ini, sangat penting untuk menjaga agar semuanya tetap terdesentralisasi dan dapat dipahami oleh pengguna. Kami perlu memastikan bahwa pengguna dapat dengan mudah mengakses tampilan terbaru dari aset mereka saat ini, serta informasi yang dipublikasikan yang ditujukan untuk mereka. Pandangan ini harus mengandalkan alat terbuka daripada solusi berpemilik. Diperlukan kerja keras untuk menjaga agar infrastruktur pembayaran yang lebih kompleks tidak menjadi "menara abstraksi" yang buram di mana pengembang kesulitan memahami apa yang sedang terjadi dan menyesuaikannya dengan lingkungan baru. Terlepas dari tantangannya, mencapai skalabilitas Ethereum, keamanan dompet, dan privasi untuk pengguna biasa adalah yang terpenting. Ini bukan hanya tentang kelayakan teknis, ini tentang aksesibilitas sebenarnya untuk pengguna rata-rata. Kita perlu menjawab tantangan ini.
Terima kasih khusus kepada Dan Finlay, Karl Floersch, David Hoffman, serta tim Scroll dan SoulWallet atas umpan balik, ulasan, dan saran mereka.