Saat Ethereum berevolusi dari teknologi eksperimental muda menjadi kumpulan teknologi matang yang mampu memberikan pengalaman terbuka, global, dan tanpa izin kepada pengguna biasa, ada tiga transisi teknologi utama yang perlu terjadi secara bersamaan:
Yang pertama adalah transformasi perluasan kapasitas L2 - semua orang beralih ke teknologi Rollup;
Kedua adalah Transformasi Keamanan Dompet - Semua orang mulai menggunakan dompet kontrak pintar;
Yang ketiga adalah transformasi privasi - memastikan tersedianya fungsi transfer dana yang melindungi privasi, dan memastikan bahwa semua alat lain yang sedang dikembangkan (pemulihan sosial, verifikasi identitas, reputasi, dll.) memiliki fitur yang menjaga privasi.
Segitiga Transformasi Ekosistem Ethereum. Anda hanya bisa memilih ketiganya. *
Tanpa item pertama, Ethereum akan gagal karena setiap transaksi berharga $3,75 ($82,48 jika kita mengalami bull run lagi), dan setiap produk pasar massal pasti akan membatalkan Perdagangan on-chain dan mengadopsi solusi terpusat.
Tanpa item kedua, Ethereum akan gagal karena pengguna tidak mau menyimpan dana mereka (dan aset non-finansial) dan semua orang akan beralih ke pertukaran terpusat.
Tanpa item ketiga, Ethereum akan gagal karena bagi banyak pengguna, semua transaksi (dan POAP dll) akan terlihat secara publik, pengorbanan privasi akan terlalu besar dan semua orang akan beralih ke setidaknya beberapa level data tersembunyi Solusi terpusat.
Untuk alasan yang diuraikan di atas, ketiga transisi ini sangat penting. Tetapi mereka juga menantang karena rumitnya koordinasi yang terlibat. Bukan hanya fungsionalitas protokol yang perlu ditingkatkan; dalam beberapa kasus, cara kita berinteraksi dengan Ethereum perlu berubah secara mendasar dan mendalam, membutuhkan perubahan besar dalam aplikasi dan dompet.
Ketiga transformasi ini pada dasarnya akan membentuk kembali hubungan antara pengguna dan alamat
Dalam dunia penskalaan L2, pengguna akan ada di beberapa jaringan L2. Apakah Anda anggota dari ExampleDAO? ContohDAO ada di Optimisme. Maka Anda memiliki akun dengan Optimisme! Apakah Anda memegang CDP sistem stablecoin di ZkSync? Maka Anda memiliki akun di ZkSync! Apakah Anda pernah mencoba beberapa aplikasi yang ada di Kakarot? Maka Anda memiliki akun di Kakarot! Lewatlah sudah hari-hari ketika pengguna hanya memiliki satu alamat.
*Tampilan dompet Brave saya, saya memegang Ethereum di empat tempat. Ya, Arbitrum dan Arbitrum Nova berbeda. Jangan khawatir, hal-hal akan menjadi lebih rumit dari waktu ke waktu! *
**Dompet kontrak pintar menambah kerumitan karena membuatnya lebih sulit untuk memiliki alamat yang sama di jaringan L1 dan berbagai jaringan L2. **Sebagian besar pengguna saat ini 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, mempertahankan alamat menjadi lebih sulit saat menggunakan dompet smart contract. Sementara banyak pekerjaan telah dilakukan untuk mencoba dan membuat alamat hash kode yang setara di seluruh jaringan yang berbeda, yang paling penting adalah CREATE2 dan pabrik singleton ERC-2470, sulit untuk mencapainya dengan sempurna. Beberapa jaringan L2 (mis., "ZK-EVM tipe keempat") tidak persis sama dengan EVM, seringkali menggunakan Solidity atau bahasa rakitan menengah daripada setara hash. Bahkan jika kesetaraan hash dapat dicapai, kemungkinan dompet mengubah kepemilikan melalui perubahan kunci menyebabkan konsekuensi lain yang kurang dapat diprediksi.
**Privasi memerlukan lebih banyak alamat per pengguna dan bahkan dapat mengubah jenis alamat yang kami tangani. **Jika proposal alamat tersembunyi digunakan secara luas, pengguna mungkin memiliki satu alamat per transaksi, bukan hanya beberapa alamat per pengguna atau satu alamat per jaringan L2. Skema privasi lainnya, bahkan yang sudah ada seperti Tornado Cash, mengubah cara aset disimpan dengan cara yang 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, ketiga transformasi ini melemahkan model mental "satu pengguna ≈ satu alamat" dengan cara yang berbeda, beberapa di antaranya pada gilirannya meningkatkan kompleksitas pelaksanaan transformasi ini. Dua dari masalah yang sangat kompleks adalah:
**1. Jika Anda ingin membayar seseorang, bagaimana cara Anda mendapatkan informasi pembayaran? **
**2. Jika pengguna menyimpan aset di lokasi yang berbeda pada rantai yang berbeda, bagaimana mereka melakukan perubahan kunci dan pemulihan sosial? **
Ketiga transisi dan pembayaran on-chain (dan identitas) ini
Saya memegang token di Scroll, dan saya ingin menggunakannya untuk membeli kopi (jika "saya" secara literal mengacu pada Vitalik, penulis artikel ini, maka "kopi" tentu saja berarti "teh hijau"). Anda menjual kopi di Taiko, tetapi Anda hanya menerima token di Taiko. apa yang harus dilakukan?
Pada dasarnya ada dua solusi:
Dompet penerima (yang dapat berupa pedagang atau individu biasa) berusaha untuk mendukung setiap L2 dan memiliki beberapa fungsi penggabungan dana asinkron.
Penerima pembayaran memberikan informasi L2 mereka di sebelah alamat, dan dompet pengirim secara otomatis merutekan dana ke L2 target melalui semacam sistem penghubung lintas-L2.
Tentu saja, solusi ini dapat digunakan dalam kombinasi: penerima pembayaran memberikan daftar L2 yang bersedia mereka terima, dan dompet pengirim menentukan metode pembayaran, yang dapat dikirim secara langsung (dengan keberuntungan), atau dibayar melalui jalur yang dijembatani melintasi L2.
Tapi ini hanyalah salah satu contoh dari tantangan utama yang diperkenalkan oleh tiga transformasi: Perilaku pembayaran sederhana mulai membutuhkan lebih banyak informasi daripada hanya alamat 20-byte.
Untungnya, pindah ke dompet smart contract bukanlah beban besar pada sistem alamat, tetapi masih ada beberapa masalah teknis yang perlu diselesaikan di bagian lain tumpukan aplikasi. Dompet perlu diperbarui untuk memastikan bahwa mereka tidak hanya mengirim 21000 gas saat mengirim transaksi, tetapi lebih banyak perhatian harus diberikan untuk memastikan bahwa ujung penerima dompet melacak tidak hanya transfer ETH dari EOA, tetapi juga transfer ETH dari kode kontrak pintar. Aplikasi yang mengandalkan kepemilikan alamat yang tidak dapat diubah (mis. NFT yang melarang kontrak pintar untuk menegakkan royalti) harus menemukan cara lain untuk mencapai tujuan mereka. Dompet kontrak pintar juga akan mempermudah beberapa hal, terutama jika seseorang hanya menerima token ERC20 non-ETH, mereka akan dapat menggunakan paymaster ERC-4337 untuk membayar bensin menggunakan token itu.
Di sisi lain, masalah privasi kembali menjadi tantangan besar yang belum benar-benar kami selesaikan. Tornado Cash asli tidak menimbulkan masalah ini karena tidak mendukung transfer internal: pengguna hanya dapat menyetor dan menarik uang ke dalam sistem. 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", komitmen rahasia yang dapat digunakan penerima untuk membelanjakan, dan (ii) pengirim dapat mengirim pesan terenkripsi yang hanya penerima dapat mendekripsi Penerima bantuan menemukan metode pembayaran.
Protokol alamat Stealth bergantung pada konsep alamat-meta, yang berfungsi sebagai berikut: bagian dari alamat-meta adalah kunci pengeluaran yang ditipu pengirim, dan bagian lainnya adalah kunci terenkripsi pengirim (walaupun implementasi minimal dapat mengatur kedua kunci menjadi sama).
Tinjauan skema alamat siluman abstrak berdasarkan enkripsi dan ZK-SNARKs
Pelajaran utama di sini adalah bahwa **dalam ekosistem yang ramah privasi, pengguna akan membelanjakan kunci publik dan kunci publik enkripsi, dan "informasi pembayaran" pengguna harus menyertakan kedua kunci tersebut. **Selain membayar, ada alasan bagus lainnya untuk memperluas 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, tetapi di dunia dompet kontrak pintar yang aman, kami mungkin harus menyediakan fungsionalitas yang lebih eksplisit untuk ini. Ini juga membantu membuat identitas berbasis Ethereum lebih kompatibel dengan ekosistem privasi terdesentralisasi non-Ethereum, terutama kunci PGP.
Ketiga transisi dan pemulihan kunci ini
Di dunia di mana setiap pengguna memiliki banyak alamat, cara default untuk menerapkan perubahan kunci dan pemulihan sosial adalah meminta pengguna menjalankan proses pemulihan di setiap alamat satu per satu. Ini dapat dilakukan dengan satu klik: dompet dapat menyediakan fungsi perangkat lunak untuk melakukan proses pemulihan secara bersamaan di semua alamat pengguna. Namun, bahkan dengan penyederhanaan pengalaman pengguna ini, ada tiga masalah dengan pemulihan multi-alamat:
1. Biaya bahan bakar tidak realistis: Ini terbukti dengan sendirinya.
2. Alamat kontrafaktual: alamat yang belum mengeluarkan kontrak cerdas (sebenarnya, ini berarti akun yang dananya belum Anda kirimkan). Sebagai pengguna, Anda mungkin memiliki alamat virtual dalam jumlah tak terbatas: satu atau lebih di setiap L2, termasuk L2 yang belum ada, dan satu set alamat virtual tak terbatas yang muncul dari skema alamat tersembunyi.
3. Privasi: Jika pengguna dengan sengaja menggunakan beberapa alamat untuk menghindari pengaitan satu sama lain, mereka pasti tidak ingin mengaitkan semuanya secara publik dengan memulihkannya pada atau mendekati waktu yang sama!
Memecahkan masalah ini sulit. Untungnya, ada solusi yang cukup elegan yang bekerja cukup baik: Arsitektur ini memisahkan logika validasi dari kepemilikan aset.
Setiap pengguna memiliki kontrak keystore yang ada di satu lokasi (bisa berupa mainnet atau L2 tertentu). Kemudian, pengguna memiliki alamat pada L2 yang berbeda, dan logika verifikasi untuk setiap alamat adalah penunjuk ke kontrak keystore. Menghabiskan dana dari alamat-alamat ini akan memerlukan bukti kunci publik pengeluaran saat ini (atau lebih realistis, sangat baru) untuk dana tersebut.
Bukti ini dapat dicapai dengan beberapa cara:
** Akses hanya baca ke L1 langsung di dalam L2. ** L2 dapat dimodifikasi untuk memungkinkannya membaca status L1 secara langsung. Jika kontrak keystore ada di L1, itu berarti kontrak di L2 memiliki akses "gratis" ke keystore.
**Cabang Merkle. ** Cabang Merkle dapat membuktikan status L1 ke L2, atau status L2 ke L1, atau kombinasi keduanya dapat membuktikan status parsial dari satu L2 ke L2 lainnya. Kelemahan utama bukti Merkle adalah biaya gas yang tinggi karena panjang bukti, yang mungkin memerlukan panjang bukti 5 kB, namun karena penggunaan pohon Verkle, ini akan dikurangi menjadi <1 kB di masa mendatang.
**ZK-SNARK. **Anda dapat mengurangi biaya data dengan menggunakan ZK-SNARKs cabang Merkle alih-alih menggunakan cabang itu sendiri. Teknik agregasi off-chain (misalnya di atas EIP-4337) dapat dibangun untuk mengaktifkan ZK-SNARK tunggal untuk memverifikasi semua bukti status lintas rantai dalam sebuah blok.
**Janji KZG. **Baik itu L2 atau skema yang dibangun di atasnya, sistem pengalamatan sekuensial dapat diperkenalkan, memungkinkan pembuktian keadaan di dalam sistem menjadi hanya 48 byte. Seperti ZK-SNARK, skema multi-bukti dapat menggabungkan semua bukti ini menjadi satu bukti untuk setiap blok.
Jika kita ingin menghindari bukti untuk setiap transaksi, kita dapat menerapkan skema yang lebih ringan yang hanya memerlukan pemulihan di seluruh bukti L2. Pembelanjaan dari akun akan bergantung pada kunci pembelanjaan dengan kunci publik terkait yang disimpan di dalam akun, tetapi pemulihan akan memerlukan transaksi untuk menyalin kunci publik pembelanjaan saat ini ke dalam keystore. Bahkan jika kunci lama Anda tidak aman, dana di alamat virtual tetap aman: "mengaktifkan" alamat virtual untuk mengubahnya menjadi kontrak yang dapat digunakan akan memerlukan bukti lintas-L2 untuk mereplikasi kunci publik pembelanjaan saat ini. Ada utas di forum Aman yang menjelaskan cara kerja arsitektur serupa.
Untuk menambah privasi pada skema tersebut, kita hanya perlu mengenkripsi pointer dan melakukan semua pembuktian di dalam ZK-SNARKs:
Dengan pekerjaan lebih lanjut (mis. menggunakan pekerjaan ini sebagai titik awal), kita juga dapat menghapus ZK -Sebagian besar kompleksitas SNARK, membangun skema berbasis KZG yang lebih disederhanakan.
Skenario ini bisa menjadi rumit. Keuntungannya adalah ada banyak potensi sinergi di antara mereka. Misalnya, konsep "kontrak keystore" juga bisa menjadi solusi untuk "alamat" yang disebutkan di bagian sebelumnya: jika kita ingin pengguna memiliki alamat tetap yang tidak berubah setiap kali mereka memperbarui kuncinya, kita dapat memasukkan the stealth Alamat meta, kunci enkripsi, dan informasi lainnya dimasukkan ke dalam kontrak keystore, dan alamat kontrak keystore digunakan sebagai "alamat" pengguna.
Banyak infrastruktur sekunder perlu diperbarui
Menggunakan ENS itu mahal. Meski tidak semahal sebelumnya pada Juni 2023, biaya transaksi pendaftaran nama domain masih relatif tinggi, sebanding dengan biaya nama domain ENS. Misalnya, biayanya sekitar $27 untuk mendaftar di zuzalu.eth, $11 di antaranya adalah biaya transaksi. Tetapi jika pasar berubah menjadi bullish lagi, biaya akan melonjak. Bahkan jika harga ETH tidak naik, jika biaya gas kembali menjadi 200 gwei, biaya transaksi untuk pendaftaran nama domain akan mencapai $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 dapat menyediakan subdomain kepada pengguna), kami memerlukan ENS digunakan di Lapisan 2.
Untungnya, tim ENS telah meningkat dan ENS diimplementasikan pada Layer 2! ERC-3668 (juga dikenal sebagai "standar CCIP") dan ENSIP-10 menyediakan cara untuk memverifikasi subdomain ENS secara otomatis pada Layer 2 apa pun. Standar CCIP memerlukan pengaturan smart contract yang menjelaskan metode untuk memverifikasi bukti data pada Layer 2, dan nama domain (misalnya, ecc.eth untuk Optinames) dapat ditempatkan di bawah kendali kontrak tersebut. Setelah kontrak CCIP mengontrol ecc.eth di L1, mengakses subdomain.ecc.eth tertentu akan secara otomatis menemukan dan memverifikasi bukti yang menyimpan status Layer 2 dari subdomain spesifik tersebut (misalnya, cabang Merkle).
sebenarnya mendapatkan bukti ini melibatkan mengakses daftar URL yang disimpan dalam kontrak, meskipun ini entah bagaimana itu mungkin terlihat seperti sentralisasi, tapi menurut saya sebenarnya tidak: ini adalah model kepercayaan 1-ke-N (bukti tidak valid ditangkap oleh logika validasi dalam fungsi panggilan balik kontrak CCIP, selama salah satu URL A yang mengembalikan bukti yang valid baik-baik saja). Daftar URL mungkin berisi lusinan URL.
**Upaya CCIP ENS adalah kisah sukses dan harus dilihat sebagai tanda bahwa reformasi radikal yang kita butuhkan benar-benar mungkin dilakukan. ** Namun masih banyak reformasi tingkat aplikasi yang perlu dilakukan. Berikut beberapa contohnya:
**Banyak DApps mengandalkan pengguna untuk memberikan tanda tangan off-chain. **Untuk Akun Eksternal (EOA) caranya mudah. ERC-1271 menyediakan cara standar untuk melakukan ini untuk dompet smart contract. Namun, banyak DApps yang masih belum mendukung ERC-1271 dan perlu diadaptasi.
** DApps yang menggunakan "apakah ini EOA?" untuk membedakan antara pengguna dan kontrak (misalnya untuk mencegah transfer atau menerapkan royalti) akan mengalami masalah. ** Secara umum, saya akan menyarankan untuk tidak mencoba menemukan solusi teknis murni di sini; menentukan apakah transfer tertentu dari kontrol kriptografi adalah transfer kepemilikan yang menguntungkan adalah masalah sulit yang mungkin tidak dapat diselesaikan tanpa menggunakan beberapa komunitas yang digerakkan oleh komunitas off-chain mekanisme memecahkan. Kemungkinan besar, aplikasi akan lebih sedikit mengandalkan sarana teknis untuk memblokir transfer dan lebih mengandalkan teknik seperti pajak Harberger.
**Interaksi dompet dengan pembayaran dan kunci enkripsi perlu ditingkatkan. **Saat ini, dompet biasanya menggunakan tanda tangan deterministik untuk menghasilkan kunci khusus aplikasi: menandatangani nonce standar (mis. hash nama aplikasi) dengan kunci privat EOA akan menghasilkan nilai deterministik kecuali jika kunci privat dimiliki, jika tidak nilainya tidak dapat dihasilkan dan oleh karena itu murni 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 (seperti Helios) perlu mengautentikasi Layer 2, bukan hanya Layer 1**. **Saat ini, klien ringan difokuskan untuk memeriksa validitas informasi header blok L1 (menggunakan protokol sinkronisasi klien ringan), dan memverifikasi cabang Merkle dari status dan transaksi L1 berdasarkan informasi header blok L1. Di masa mendatang, mereka juga perlu memverifikasi bukti status L2 yang di-root di root status yang disimpan di L1 (versi yang lebih canggih akan benar-benar melihat pra-konfirmasi L2).
Dompet perlu melindungi aset dan data
Saat ini, misi dompet adalah untuk melindungi aset. Semuanya disimpan dalam rantai, semua yang perlu dilindungi dompet adalah kunci pribadi yang saat ini mengamankan aset ini. Jika Anda mengubah kunci, Anda dapat memposting kunci pribadi sebelumnya secara publik dengan aman di Internet pada hari berikutnya. Namun, di dunia tanpa pengetahuan, hal ini tidak lagi terjadi: dompet tidak hanya melindungi kredensial autentikasi, tetapi juga menyimpan data Anda.
Kami melihat tanda-tanda pertama dunia seperti itu di Zuzalu dengan Zupass, sistem identitas berbasis ZK-SNARK. Pengguna memiliki kunci pribadi yang digunakan untuk mengautentikasi ke dalam sistem, yang dapat digunakan untuk menghasilkan bukti dasar seperti "buktikan bahwa saya adalah penduduk Zuzalu tanpa mengungkapkan penduduk mana saya". 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 adalah anggota Tim Kucing. *
Fitur utama stempel relatif terhadap POAP adalah sifatnya pribadi: Anda menyimpan data secara lokal, dan hanya membuktikan stempel ke ZK mereka (atau melakukan perhitungan pada stempel) jika Anda ingin memberikan informasi itu kepada seseorang. Tetapi ini juga disertai dengan risiko tambahan: jika Anda kehilangan informasi itu, Anda akan kehilangan stempel Anda.
Tentu saja, masalah menyimpan data dapat direduksi menjadi masalah memegang kunci enkripsi tunggal: pihak ketiga (bahkan on-chain) 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 memegang kunci enkripsi. Namun demikian, jika Anda kehilangan kunci enkripsi, Anda kehilangan semua data Anda. Dan, sebaliknya, jika seseorang melihat kunci enkripsi Anda, mereka akan 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. Kami dapat melangkah lebih jauh dengan menggunakan berbagi kunci untuk membagi penyimpanan kunci di antara beberapa pelindung.
Pemulihan sosial melalui MPC bukanlah solusi yang memadai untuk dompet, karena itu berarti tidak hanya pelindung saat ini, tetapi juga pelindung sebelumnya dapat berkolusi untuk mencuri aset Anda, yang merupakan risiko yang sangat tinggi. Sementara pelanggaran privasi biasanya kurang berisiko daripada kehilangan aset sepenuhnya, untuk kasus penggunaan dengan kebutuhan privasi yang tinggi, risiko kehilangan yang lebih tinggi dapat diterima dengan tidak mencadangkan kunci yang terkait dengan kebutuhan privasi tersebut.
Untuk menghindari macetnya pengguna dalam sistem rumit dengan beberapa jalur pemulihan, dompet yang mendukung pemulihan sosial mungkin perlu mengelola kedua aspek pemulihan aset dan pemulihan kunci enkripsi.
Kembali ke identitas
Tema umum di antara perubahan ini adalah bahwa konsep "alamat" sebagai representasi identitas pada blockchain perlu diubah secara fundamental. ** "Petunjuk tentang cara berinteraksi dengan saya" tidak lagi hanya berupa alamat ETH; ekspres. **
Salah satu cara ini adalah dengan menggunakan ENS sebagai identitas Anda: catatan ENS Anda dapat berisi semua informasi tentang cara membayar dan berinteraksi dengan Anda, jika Anda mengirim seseorang bob.eth (atau bob.ecc.eth dll.), mereka dapat Menanyakan dan pelajari semua yang berinteraksi dengan Anda, termasuk dengan cara yang lebih kompleks di seluruh domain dan dengan perlindungan privasi.
Namun, pendekatan yang berpusat pada ENS ini memiliki dua kelemahan:
** Ini mengasosiasikan terlalu banyak konten dengan nama Anda. **Nama Anda tidak berarti segalanya tentang Anda, itu hanyalah salah satu dari banyak atribut tentang Anda. Seharusnya dimungkinkan untuk mengubah nama Anda tanpa memigrasikan seluruh profil identitas Anda dan memperbarui catatan di banyak aplikasi.
** Anda tidak dapat memiliki nama kontrafaktual yang tidak memerlukan kepercayaan. ** Fitur pengalaman pengguna utama dari setiap blockchain adalah kemampuan untuk mengirim token ke orang yang belum berinteraksi dengan rantai. Tanpa fungsi seperti itu, ada dilema: berinteraksi dengan rantai memerlukan pembayaran biaya transaksi, dan membayar biaya transaksi memerlukan... sudah memiliki token. Alamat ETH, termasuk alamat smart contract dengan CREATE2, memiliki fungsi ini. Nama ENS tidak, karena jika kedua Bob memutuskan off-chain bahwa mereka adalah bob.ecc.eth, tidak ada cara untuk memilih Bob mana yang mendapatkan nama tersebut.
Salah satu solusi yang mungkin adalah memasukkan lebih banyak konten ke dalam kontrak keystore yang disebutkan sebelumnya dalam arsitektur artikel ini. Kontrak keystore dapat berisi berbagai informasi tentang Anda dan interaksi dengan Anda (dan dengan CCIP, beberapa informasi ini dapat bersifat off-chain), pengguna akan menggunakan kontrak keystore mereka sebagai pengidentifikasi utama mereka. Namun, aset yang sebenarnya mereka terima akan disimpan di berbagai tempat berbeda. Kontrak keystore bersifat name-agnostic dan virtual-name-friendly: Anda dapat menghasilkan alamat yang hanya dapat diinisialisasi oleh kontrak keystore dengan parameter awal tetap tertentu.
Kelas solusi lain melibatkan pengabaian gagasan alamat yang menghadap pengguna sepenuhnya, mirip dengan protokol pembayaran Bitcoin. Satu ide adalah lebih mengandalkan saluran komunikasi langsung antara pengirim dan penerima; misalnya, pengirim dapat mengirim tautan permintaan (sebagai URL eksplisit atau kode QR), yang dapat digunakan penerima untuk mengirim permintaan apa pun yang ingin mereka terima pembayaran.
Entah itu pengirim atau penerima yang bertindak lebih dulu, lebih mengandalkan dompet untuk menghasilkan informasi pembayaran terkini secara real-time mengurangi friksi. Namun, pengidentifikasi persisten nyaman (terutama dengan ENS), sedangkan dalam praktiknya mengandalkan komunikasi langsung antara pengirim dan penerima adalah masalah yang sangat rumit, sehingga kombinasi teknik yang berbeda dapat terlihat.
Dalam semua desain ini, sangat penting untuk tetap terdesentralisasi dan dapat dipahami oleh pengguna. Kami perlu memastikan bahwa pengguna dapat dengan mudah mengakses tampilan terbaru dari aset mereka saat ini dan pesan yang ditargetkan untuk mereka. Pandangan ini harus mengandalkan alat terbuka daripada solusi berpemilik. Dibutuhkan kerja keras untuk menjaga kompleksitas infrastruktur pembayaran yang lebih besar agar tidak menjadi "menara abstraksi" buram yang sulit dipahami dan diadaptasi ke 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 aktual bagi pengguna rata-rata. Kita perlu menjawab 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: Ekosistem Ethereum membutuhkan tiga transformasi teknologi
Penulis: Vitalik, pendiri Ethereum; Terjemahan: Jinse Finance cryptonaitive
Saat Ethereum berevolusi dari teknologi eksperimental muda menjadi kumpulan teknologi matang yang mampu memberikan pengalaman terbuka, global, dan tanpa izin kepada pengguna biasa, ada tiga transisi teknologi utama yang perlu terjadi secara bersamaan:
Tanpa item pertama, Ethereum akan gagal karena setiap transaksi berharga $3,75 ($82,48 jika kita mengalami bull run lagi), dan setiap produk pasar massal pasti akan membatalkan Perdagangan on-chain dan mengadopsi solusi terpusat.
Tanpa item kedua, Ethereum akan gagal karena pengguna tidak mau menyimpan dana mereka (dan aset non-finansial) dan semua orang akan beralih ke pertukaran terpusat.
Tanpa item ketiga, Ethereum akan gagal karena bagi banyak pengguna, semua transaksi (dan POAP dll) akan terlihat secara publik, pengorbanan privasi akan terlalu besar dan semua orang akan beralih ke setidaknya beberapa level data tersembunyi Solusi terpusat.
Untuk alasan yang diuraikan di atas, ketiga transisi ini sangat penting. Tetapi mereka juga menantang karena rumitnya koordinasi yang terlibat. Bukan hanya fungsionalitas protokol yang perlu ditingkatkan; dalam beberapa kasus, cara kita berinteraksi dengan Ethereum perlu berubah secara mendasar dan mendalam, membutuhkan perubahan besar dalam aplikasi dan dompet.
Ketiga transformasi ini pada dasarnya akan membentuk kembali hubungan antara pengguna dan alamat
Dalam dunia penskalaan L2, pengguna akan ada di beberapa jaringan L2. Apakah Anda anggota dari ExampleDAO? ContohDAO ada di Optimisme. Maka Anda memiliki akun dengan Optimisme! Apakah Anda memegang CDP sistem stablecoin di ZkSync? Maka Anda memiliki akun di ZkSync! Apakah Anda pernah mencoba beberapa aplikasi yang ada di Kakarot? Maka Anda memiliki akun di Kakarot! Lewatlah sudah hari-hari ketika pengguna hanya memiliki satu alamat.
**Dompet kontrak pintar menambah kerumitan karena membuatnya lebih sulit untuk memiliki alamat yang sama di jaringan L1 dan berbagai jaringan L2. **Sebagian besar pengguna saat ini 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, mempertahankan alamat menjadi lebih sulit saat menggunakan dompet smart contract. Sementara banyak pekerjaan telah dilakukan untuk mencoba dan membuat alamat hash kode yang setara di seluruh jaringan yang berbeda, yang paling penting adalah CREATE2 dan pabrik singleton ERC-2470, sulit untuk mencapainya dengan sempurna. Beberapa jaringan L2 (mis., "ZK-EVM tipe keempat") tidak persis sama dengan EVM, seringkali menggunakan Solidity atau bahasa rakitan menengah daripada setara hash. Bahkan jika kesetaraan hash dapat dicapai, kemungkinan dompet mengubah kepemilikan melalui perubahan kunci menyebabkan konsekuensi lain yang kurang dapat diprediksi.
**Privasi memerlukan lebih banyak alamat per pengguna dan bahkan dapat mengubah jenis alamat yang kami tangani. **Jika proposal alamat tersembunyi digunakan secara luas, pengguna mungkin memiliki satu alamat per transaksi, bukan hanya beberapa alamat per pengguna atau satu alamat per jaringan L2. Skema privasi lainnya, bahkan yang sudah ada seperti Tornado Cash, mengubah cara aset disimpan dengan cara yang 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, ketiga transformasi ini melemahkan model mental "satu pengguna ≈ satu alamat" dengan cara yang berbeda, beberapa di antaranya pada gilirannya meningkatkan kompleksitas pelaksanaan transformasi ini. Dua dari masalah yang sangat kompleks adalah:
**1. Jika Anda ingin membayar seseorang, bagaimana cara Anda mendapatkan informasi pembayaran? **
**2. Jika pengguna menyimpan aset di lokasi yang berbeda pada rantai yang berbeda, bagaimana mereka melakukan perubahan kunci dan pemulihan sosial? **
Ketiga transisi dan pembayaran on-chain (dan identitas) ini
Saya memegang token di Scroll, dan saya ingin menggunakannya untuk membeli kopi (jika "saya" secara literal mengacu pada Vitalik, penulis artikel ini, maka "kopi" tentu saja berarti "teh hijau"). Anda menjual kopi di Taiko, tetapi Anda hanya menerima token di Taiko. apa yang harus dilakukan?
Pada dasarnya ada dua solusi:
Dompet penerima (yang dapat berupa pedagang atau individu biasa) berusaha untuk mendukung setiap L2 dan memiliki beberapa fungsi penggabungan dana asinkron.
Penerima pembayaran memberikan informasi L2 mereka di sebelah alamat, dan dompet pengirim secara otomatis merutekan dana ke L2 target melalui semacam sistem penghubung lintas-L2.
Tentu saja, solusi ini dapat digunakan dalam kombinasi: penerima pembayaran memberikan daftar L2 yang bersedia mereka terima, dan dompet pengirim menentukan metode pembayaran, yang dapat dikirim secara langsung (dengan keberuntungan), atau dibayar melalui jalur yang dijembatani melintasi L2.
Tapi ini hanyalah salah satu contoh dari tantangan utama yang diperkenalkan oleh tiga transformasi: Perilaku pembayaran sederhana mulai membutuhkan lebih banyak informasi daripada hanya alamat 20-byte.
Untungnya, pindah ke dompet smart contract bukanlah beban besar pada sistem alamat, tetapi masih ada beberapa masalah teknis yang perlu diselesaikan di bagian lain tumpukan aplikasi. Dompet perlu diperbarui untuk memastikan bahwa mereka tidak hanya mengirim 21000 gas saat mengirim transaksi, tetapi lebih banyak perhatian harus diberikan untuk memastikan bahwa ujung penerima dompet melacak tidak hanya transfer ETH dari EOA, tetapi juga transfer ETH dari kode kontrak pintar. Aplikasi yang mengandalkan kepemilikan alamat yang tidak dapat diubah (mis. NFT yang melarang kontrak pintar untuk menegakkan royalti) harus menemukan cara lain untuk mencapai tujuan mereka. Dompet kontrak pintar juga akan mempermudah beberapa hal, terutama jika seseorang hanya menerima token ERC20 non-ETH, mereka akan dapat menggunakan paymaster ERC-4337 untuk membayar bensin menggunakan token itu.
Di sisi lain, masalah privasi kembali menjadi tantangan besar yang belum benar-benar kami selesaikan. Tornado Cash asli tidak menimbulkan masalah ini karena tidak mendukung transfer internal: pengguna hanya dapat menyetor dan menarik uang ke dalam sistem. 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", komitmen rahasia yang dapat digunakan penerima untuk membelanjakan, dan (ii) pengirim dapat mengirim pesan terenkripsi yang hanya penerima dapat mendekripsi Penerima bantuan menemukan metode pembayaran.
Protokol alamat Stealth bergantung pada konsep alamat-meta, yang berfungsi sebagai berikut: bagian dari alamat-meta adalah kunci pengeluaran yang ditipu pengirim, dan bagian lainnya adalah kunci terenkripsi pengirim (walaupun implementasi minimal dapat mengatur kedua kunci menjadi sama).
Tinjauan skema alamat siluman abstrak berdasarkan enkripsi dan ZK-SNARKs
Pelajaran utama di sini adalah bahwa **dalam ekosistem yang ramah privasi, pengguna akan membelanjakan kunci publik dan kunci publik enkripsi, dan "informasi pembayaran" pengguna harus menyertakan kedua kunci tersebut. **Selain membayar, ada alasan bagus lainnya untuk memperluas 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, tetapi di dunia dompet kontrak pintar yang aman, kami mungkin harus menyediakan fungsionalitas yang lebih eksplisit untuk ini. Ini juga membantu membuat identitas berbasis Ethereum lebih kompatibel dengan ekosistem privasi terdesentralisasi non-Ethereum, terutama kunci PGP.
Ketiga transisi dan pemulihan kunci ini
Di dunia di mana setiap pengguna memiliki banyak alamat, cara default untuk menerapkan perubahan kunci dan pemulihan sosial adalah meminta pengguna menjalankan proses pemulihan di setiap alamat satu per satu. Ini dapat dilakukan dengan satu klik: dompet dapat menyediakan fungsi perangkat lunak untuk melakukan proses pemulihan secara bersamaan di semua alamat pengguna. Namun, bahkan dengan penyederhanaan pengalaman pengguna ini, ada tiga masalah dengan pemulihan multi-alamat:
1. Biaya bahan bakar tidak realistis: Ini terbukti dengan sendirinya.
2. Alamat kontrafaktual: alamat yang belum mengeluarkan kontrak cerdas (sebenarnya, ini berarti akun yang dananya belum Anda kirimkan). Sebagai pengguna, Anda mungkin memiliki alamat virtual dalam jumlah tak terbatas: satu atau lebih di setiap L2, termasuk L2 yang belum ada, dan satu set alamat virtual tak terbatas yang muncul dari skema alamat tersembunyi.
3. Privasi: Jika pengguna dengan sengaja menggunakan beberapa alamat untuk menghindari pengaitan satu sama lain, mereka pasti tidak ingin mengaitkan semuanya secara publik dengan memulihkannya pada atau mendekati waktu yang sama!
Memecahkan masalah ini sulit. Untungnya, ada solusi yang cukup elegan yang bekerja cukup baik: Arsitektur ini memisahkan logika validasi dari kepemilikan aset.
Setiap pengguna memiliki kontrak keystore yang ada di satu lokasi (bisa berupa mainnet atau L2 tertentu). Kemudian, pengguna memiliki alamat pada L2 yang berbeda, dan logika verifikasi untuk setiap alamat adalah penunjuk ke kontrak keystore. Menghabiskan dana dari alamat-alamat ini akan memerlukan bukti kunci publik pengeluaran saat ini (atau lebih realistis, sangat baru) untuk dana tersebut.
Bukti ini dapat dicapai dengan beberapa cara:
Jika kita ingin menghindari bukti untuk setiap transaksi, kita dapat menerapkan skema yang lebih ringan yang hanya memerlukan pemulihan di seluruh bukti L2. Pembelanjaan dari akun akan bergantung pada kunci pembelanjaan dengan kunci publik terkait yang disimpan di dalam akun, tetapi pemulihan akan memerlukan transaksi untuk menyalin kunci publik pembelanjaan saat ini ke dalam keystore. Bahkan jika kunci lama Anda tidak aman, dana di alamat virtual tetap aman: "mengaktifkan" alamat virtual untuk mengubahnya menjadi kontrak yang dapat digunakan akan memerlukan bukti lintas-L2 untuk mereplikasi kunci publik pembelanjaan saat ini. Ada utas di forum Aman yang menjelaskan cara kerja arsitektur serupa.
Untuk menambah privasi pada skema tersebut, kita hanya perlu mengenkripsi pointer dan melakukan semua pembuktian di dalam ZK-SNARKs:
Skenario ini bisa menjadi rumit. Keuntungannya adalah ada banyak potensi sinergi di antara mereka. Misalnya, konsep "kontrak keystore" juga bisa menjadi solusi untuk "alamat" yang disebutkan di bagian sebelumnya: jika kita ingin pengguna memiliki alamat tetap yang tidak berubah setiap kali mereka memperbarui kuncinya, kita dapat memasukkan the stealth Alamat meta, kunci enkripsi, dan informasi lainnya dimasukkan ke dalam kontrak keystore, dan alamat kontrak keystore digunakan sebagai "alamat" pengguna.
Banyak infrastruktur sekunder perlu diperbarui
Menggunakan ENS itu mahal. Meski tidak semahal sebelumnya pada Juni 2023, biaya transaksi pendaftaran nama domain masih relatif tinggi, sebanding dengan biaya nama domain ENS. Misalnya, biayanya sekitar $27 untuk mendaftar di zuzalu.eth, $11 di antaranya adalah biaya transaksi. Tetapi jika pasar berubah menjadi bullish lagi, biaya akan melonjak. Bahkan jika harga ETH tidak naik, jika biaya gas kembali menjadi 200 gwei, biaya transaksi untuk pendaftaran nama domain akan mencapai $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 dapat menyediakan subdomain kepada pengguna), kami memerlukan ENS digunakan di Lapisan 2.
Untungnya, tim ENS telah meningkat dan ENS diimplementasikan pada Layer 2! ERC-3668 (juga dikenal sebagai "standar CCIP") dan ENSIP-10 menyediakan cara untuk memverifikasi subdomain ENS secara otomatis pada Layer 2 apa pun. Standar CCIP memerlukan pengaturan smart contract yang menjelaskan metode untuk memverifikasi bukti data pada Layer 2, dan nama domain (misalnya, ecc.eth untuk Optinames) dapat ditempatkan di bawah kendali kontrak tersebut. Setelah kontrak CCIP mengontrol ecc.eth di L1, mengakses subdomain.ecc.eth tertentu akan secara otomatis menemukan dan memverifikasi bukti yang menyimpan status Layer 2 dari subdomain spesifik tersebut (misalnya, cabang Merkle).
**Upaya CCIP ENS adalah kisah sukses dan harus dilihat sebagai tanda bahwa reformasi radikal yang kita butuhkan benar-benar mungkin dilakukan. ** Namun masih banyak reformasi tingkat aplikasi yang perlu dilakukan. Berikut beberapa contohnya:
Dompet perlu melindungi aset dan data
Saat ini, misi dompet adalah untuk melindungi aset. Semuanya disimpan dalam rantai, semua yang perlu dilindungi dompet adalah kunci pribadi yang saat ini mengamankan aset ini. Jika Anda mengubah kunci, Anda dapat memposting kunci pribadi sebelumnya secara publik dengan aman di Internet pada hari berikutnya. Namun, di dunia tanpa pengetahuan, hal ini tidak lagi terjadi: dompet tidak hanya melindungi kredensial autentikasi, tetapi juga menyimpan data Anda.
Kami melihat tanda-tanda pertama dunia seperti itu di Zuzalu dengan Zupass, sistem identitas berbasis ZK-SNARK. Pengguna memiliki kunci pribadi yang digunakan untuk mengautentikasi ke dalam sistem, yang dapat digunakan untuk menghasilkan bukti dasar seperti "buktikan bahwa saya adalah penduduk Zuzalu tanpa mengungkapkan penduduk mana saya". 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 adalah anggota Tim Kucing. *
Fitur utama stempel relatif terhadap POAP adalah sifatnya pribadi: Anda menyimpan data secara lokal, dan hanya membuktikan stempel ke ZK mereka (atau melakukan perhitungan pada stempel) jika Anda ingin memberikan informasi itu kepada seseorang. Tetapi ini juga disertai dengan risiko tambahan: jika Anda kehilangan informasi itu, Anda akan kehilangan stempel Anda.
Tentu saja, masalah menyimpan data dapat direduksi menjadi masalah memegang kunci enkripsi tunggal: pihak ketiga (bahkan on-chain) 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 memegang kunci enkripsi. Namun demikian, jika Anda kehilangan kunci enkripsi, Anda kehilangan semua data Anda. Dan, sebaliknya, jika seseorang melihat kunci enkripsi Anda, mereka akan 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. Kami dapat melangkah lebih jauh dengan menggunakan berbagi kunci untuk membagi penyimpanan kunci di antara beberapa pelindung.
Pemulihan sosial melalui MPC bukanlah solusi yang memadai untuk dompet, karena itu berarti tidak hanya pelindung saat ini, tetapi juga pelindung sebelumnya dapat berkolusi untuk mencuri aset Anda, yang merupakan risiko yang sangat tinggi. Sementara pelanggaran privasi biasanya kurang berisiko daripada kehilangan aset sepenuhnya, untuk kasus penggunaan dengan kebutuhan privasi yang tinggi, risiko kehilangan yang lebih tinggi dapat diterima dengan tidak mencadangkan kunci yang terkait dengan kebutuhan privasi tersebut.
Untuk menghindari macetnya pengguna dalam sistem rumit dengan beberapa jalur pemulihan, dompet yang mendukung pemulihan sosial mungkin perlu mengelola kedua aspek pemulihan aset dan pemulihan kunci enkripsi.
Kembali ke identitas
Tema umum di antara perubahan ini adalah bahwa konsep "alamat" sebagai representasi identitas pada blockchain perlu diubah secara fundamental. ** "Petunjuk tentang cara berinteraksi dengan saya" tidak lagi hanya berupa alamat ETH; ekspres. **
Salah satu cara ini adalah dengan menggunakan ENS sebagai identitas Anda: catatan ENS Anda dapat berisi semua informasi tentang cara membayar dan berinteraksi dengan Anda, jika Anda mengirim seseorang bob.eth (atau bob.ecc.eth dll.), mereka dapat Menanyakan dan pelajari semua yang berinteraksi dengan Anda, termasuk dengan cara yang lebih kompleks di seluruh domain dan dengan perlindungan privasi.
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 sebelumnya dalam arsitektur artikel ini. Kontrak keystore dapat berisi berbagai informasi tentang Anda dan interaksi dengan Anda (dan dengan CCIP, beberapa informasi ini dapat bersifat off-chain), pengguna akan menggunakan kontrak keystore mereka sebagai pengidentifikasi utama mereka. Namun, aset yang sebenarnya mereka terima akan disimpan di berbagai tempat berbeda. Kontrak keystore bersifat name-agnostic dan virtual-name-friendly: Anda dapat menghasilkan alamat yang hanya dapat diinisialisasi oleh kontrak keystore dengan parameter awal tetap tertentu.
Kelas solusi lain melibatkan pengabaian gagasan alamat yang menghadap pengguna sepenuhnya, mirip dengan protokol pembayaran Bitcoin. Satu ide adalah lebih mengandalkan saluran komunikasi langsung antara pengirim dan penerima; misalnya, pengirim dapat mengirim tautan permintaan (sebagai URL eksplisit atau kode QR), yang dapat digunakan penerima untuk mengirim permintaan apa pun yang ingin mereka terima pembayaran.
Entah itu pengirim atau penerima yang bertindak lebih dulu, lebih mengandalkan dompet untuk menghasilkan informasi pembayaran terkini secara real-time mengurangi friksi. Namun, pengidentifikasi persisten nyaman (terutama dengan ENS), sedangkan dalam praktiknya mengandalkan komunikasi langsung antara pengirim dan penerima adalah masalah yang sangat rumit, sehingga kombinasi teknik yang berbeda dapat terlihat.
Dalam semua desain ini, sangat penting untuk tetap terdesentralisasi dan dapat dipahami oleh pengguna. Kami perlu memastikan bahwa pengguna dapat dengan mudah mengakses tampilan terbaru dari aset mereka saat ini dan pesan yang ditargetkan untuk mereka. Pandangan ini harus mengandalkan alat terbuka daripada solusi berpemilik. Dibutuhkan kerja keras untuk menjaga kompleksitas infrastruktur pembayaran yang lebih besar agar tidak menjadi "menara abstraksi" buram yang sulit dipahami dan diadaptasi ke 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 aktual bagi pengguna rata-rata. Kita perlu menjawab tantangan ini.