V God Blog: Memahami Dompet dan Kasus Aplikasi Lainnya Membaca Lapisan 2 Lintas Lapisan

Pengarang: Vitalik Buterin; Penyusun: Kata Bulu

Dalam artikel Tiga Transisi, Vitalik Buterin, pendiri Ethereum, menguraikan dengan jelas tentang "jaringan utama (selanjutnya disebut sebagai L1) + rantai silang lapisan 2 (selanjutnya disebut sebagai lintas-L2) dukungan"" "Keamanan dompet" dan "privasi" adalah nilai penting sebagai fungsi yang diperlukan dari tumpukan ekosistem. Mereka seharusnya tidak hanya menjadi beberapa komponen tambahan, dan dompet terpisah menyediakan fungsi terkait.

Dan artikel ini, kata Vitalik Buterin, akan fokus pada masalah teknis utama: cara lebih mudah membaca data L1 dari L2; atau membaca data L2 dari L1; atau cara lebih mudah membaca data L2 dari L2 Membaca data dari L2 lain . **

Vitalik Buterin mengemukakan bahwa kunci penyelesaian permasalahan di atas terletak pada bagaimana mewujudkan pemisahan aset dan keystore. Teknologi ini juga memiliki kasus penggunaan yang sangat berharga di area selain penskalaan, seperti mobilitas aset antara L1 dan L2.

** Apa tujuan melakukan ini? **

Setelah L2 menjadi arus utama, pengguna akan dapat memiliki aset di beberapa L2 dan mungkin juga L1.

Setelah dompet kontrak pintar menjadi arus utama, "kunci" yang sekarang umum tidak akan digunakan lagi.

Setelah kedua hal ini terjadi pada saat yang sama, pengguna akan memerlukan metode yang tidak memerlukan banyak transaksi untuk mengubah kunci akun yang berbeda.

Secara khusus, kami memerlukan cara untuk menangani alamat yang "kontrafaktual" (juga dikenal sebagai "alamat hipotetis"): alamat yang belum "terdaftar" di rantai dengan cara apa pun, tetapi masih perlu menerima dan menyimpan aset dengan aman .

Faktanya, kita semua mengandalkan "pengaturan kontrafaktual" alamat ini: ketika pengguna menggunakan Ethereum untuk pertama kalinya, pengguna dapat membuat alamat ETH, dan orang lain dapat membayar ke akun ini tanpa harus mendaftar di blockchain. Daftar" alamatnya (tetapi Anda harus membayar biaya transaksi, jadi Anda perlu memegang beberapa ETH).

Untuk akun eksternal (EOA), sebenarnya semua alamat dimulai dari alamat "pengaturan kontrafaktual".

Alamat "yang diatur secara kontrafaktual" masih dimungkinkan dengan dompet kontrak pintar, sebagian besar berkat CREATE2, yang memungkinkan Anda memiliki alamat ETH yang hanya dapat dibuat dengan kode kontrak pintar yang cocok dengan isian hash tertentu.

△ EIP-1014 (CREATE2) algoritma perhitungan alamat.

Namun, pengenalan dompet smart contract juga menghadirkan tantangan baru: **Kunci akses dapat berubah. ** Perubahan ini adalah alamat adalah nilai hash dari kode init, yang hanya dapat berisi kunci verifikasi awal dompet, dan kunci verifikasi saat ini akan disimpan di penyimpanan dompet, tetapi catatan penyimpanan tidak akan secara otomatis ditransfer ke L2 lainnya.

Jika pengguna memiliki alamat di banyak L2, hanya Pemisahan Aset dan Arsitektur Penyimpanan Kunci yang dapat membantu pengguna mengubah kunci mereka.

Struktur arsitektur terpisah ini adalah bahwa setiap pengguna memiliki (i) "kontrak penyimpanan kunci" (baik pada rantai L1 atau L2 tertentu) yang menyimpan kunci verifikasi untuk semua dompet dan aturan untuk mengubah kunci, dan (ii) "Kontrak dompet " pada rantai L1 dan banyak L2, yang mendapatkan kunci verifikasi melalui pembacaan lintas rantai.

Ada dua cara untuk menerapkan arsitektur pemisahan penyimpanan aset dan kunci:

Versi ringan (yaitu hanya memeriksa kunci yang diperbarui): Setiap dompet menyimpan kunci verifikasi secara lokal, dan berisi fungsi yang dapat dipanggil untuk memeriksa bukti rantai silang dari status keystore saat ini, dan memperbarui penyimpanan lokal kunci untuk mencocokkan. Memanggil fungsi ini untuk mendapatkan kunci autentikasi saat ini dari keystore diperlukan saat menggunakan dompet untuk pertama kali di L2.

• **Keuntungan: **Penggunaan bukti lintas rantai lebih bijaksana, dan tidak akan ada biaya operasi jaringan yang terlalu mahal. Semua aset hanya dapat digunakan dengan kunci saat ini, sehingga keamanannya tetap terjamin.
• **Kekurangan: **Perlu mengubah kunci verifikasi, perubahan kunci on-chain harus dilakukan pada keystore dan setiap dompet yang telah diinisialisasi, dan dapat menghabiskan banyak Biaya Gas.

Versi lengkap (yakni setiap transaksi diperiksa): Setiap transaksi memerlukan bukti rantai silang yang menunjukkan kunci saat ini di keystore.

• Keuntungan: Kompleksitas sistem rendah, dan keystore diperbarui dengan cepat.
• **Kerugian: **Biaya operasi jaringan dari satu transaksi tinggi, dan tidak mudah untuk kompatibel dengan ERC-4337. ERC-4337 saat ini tidak mendukung pembacaan objek yang dapat diubah di seluruh kontrak selama verifikasi.

** Apa itu bukti lintas rantai? **

Untuk mendemonstrasikan kompleksitas bukti lintas rantai, kami memilih salah satu skenario aplikasi paling kompleks untuk mendemonstrasikan dan menjelaskan prinsip teknis ini.Skenario aplikasi kompleks ini adalah sebagai berikut: kunci disimpan di satu L2, dan dompet aktif L2 lainnya. Jika keystore di dompet ada di L1, hanya setengah dari desain ini yang dibutuhkan.

Asumsikan keystore ada di Linea dan dompet ada di Kakarot. Proses sertifikasi lengkap dari kunci dompet harus mencakup:

• Bukti root status Linea saat ini, mengingat root status Ethereum saat ini yang diketahui oleh Kakarot.
• Bukti kunci saat ini di keystore, mengingat root status Linea saat ini.

Ada dua pertanyaan implementasi pelik utama di sini: "Bukti seperti apa yang perlu digunakan? (Apakah ini bukti Merkle? Atau yang lainnya?)" dan "Bagaimana L2 mempelajari akar status L1 terdekat?" Atau, "L1 Bagaimana mempelajari akar status L2?"

Jadi, dalam kedua kasus tersebut, berapa lama jeda antara saat suatu peristiwa terjadi di satu pihak dan saat pihak lain dapat memberikan bukti?

**Skema bukti apa yang tersedia untuk kami? **

Ada lima metode utama untuk dipilih:

• Bukti Merkle
• Umum ZK-SNARK
• Sertifikat untuk tujuan khusus (misalnya menggunakan KZG)
• Verkle proof, antara KZG dan ZK-SNARK, dengan mempertimbangkan upaya dan biaya infrastruktur
• tidak ada bukti, bergantung pada pembacaan keadaan langsung

Dalam hal pekerjaan infrastruktur yang diperlukan dan biaya pengguna, secara kasar dapat diurutkan sebagai berikut:

"Agregasi" mengacu pada menggabungkan semua bukti yang diberikan oleh pengguna di setiap blok menjadi satu bukti meta besar, menggabungkannya menjadi satu. Ini berfungsi untuk SNARK dan KZG, tetapi tidak untuk garpu Merkle.

Nyatanya, "agregasi" hanya berharga jika solusi tersebut memiliki banyak pengguna. ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

**Bagaimana cara kerja bukti Merkle? **

Soal ini sangat sederhana dan bisa langsung diikuti dengan diagram pada bagian sebelumnya. Setiap "bukti" (dengan asumsi bahwa satu L2 terbukti menjadi L2 lainnya, yang merupakan skenario aplikasi yang paling sulit) akan mencakup:

Garpu Merkle yang membuktikan memegang root status dari keystore L2, root status terbaru dari Ethereum yang dikenal dengan L2. Akar status yang memegang keystore L2 disimpan dalam slot penyimpanan yang diketahui di alamat yang diketahui (kontrak L1 mewakili L2), sehingga jalur dapat di-hardcode.

Cabang Merkle yang membuktikan kunci verifikasi saat ini, menurut root negara bagian yang memegang keystore L2. Selain itu, kunci autentikasi disimpan dalam slot yang diketahui di alamat yang diketahui, sehingga jalur dapat di-hardcode.

Namun, bukti keadaan di Ethereum rumit, tetapi ada perpustakaan yang dapat digunakan untuk memverifikasinya, dan jika menggunakan perpustakaan ini, mekanismenya tidak terlalu rumit.

Namun, tantangan yang lebih besar adalah biaya. **Merkle terbukti sangat panjang, dan pohon Patricia 3,9 kali lebih panjang dari yang diperlukan - jauh lebih tinggi dari harga dasar saat ini sebesar 21.000 Biaya Gas per transaksi.

Namun, jika buktinya diverifikasi pada L2, perbedaannya semakin parah. Komputasi di dalam L2 murah karena komputasi dilakukan secara off-chain dan dalam ekosistem dengan jumlah node yang lebih sedikit daripada L1.

Kita dapat menghitung artinya dengan melihat perbandingan antara biaya Biaya Gas L1 dan biaya Biaya Gas L2:

Saat ini, jika ini adalah operasi pengiriman yang relatif sederhana, biaya pada jaringan L1 sekitar 15~25 kali lipat dari L2, dan biaya pertukaran Token sekitar 20~50 kali lipat dari L2.

Operasi pengiriman sederhana memiliki jumlah data yang besar; dan operasi pertukaran membutuhkan daya komputasi yang lebih tinggi, sehingga operasi pertukaran adalah tolok ukur yang lebih baik untuk memperkirakan biaya perhitungan L1 dan perhitungan L2.

Menyatukan hal di atas, jika kita mengasumsikan rasio biaya 30x antara biaya komputasi L1 dan biaya komputasi L2, ini tampaknya menyiratkan bahwa biaya menempatkan bukti Merkle pada L2 bisa setara dengan sekitar lima puluh transaksi reguler.

Tentu saja, menggunakan pohon Merkle biner akan mengurangi biaya dengan faktor sekitar 4, tetapi meskipun demikian biayanya masih akan menjadi penghalang dalam banyak kasus, dan jika kami bersedia melepaskan kompatibilitas dengan pohon status hexa Ethereum saat ini, itu mungkin Akan mencari opsi yang lebih baik.

**Bagaimana cara kerja bukti ZK-SNARK? **

Penggunaan ZK-SNARK juga secara konseptual mudah dipahami: Anda cukup mengganti bukti Merkle pada diagram di atas dengan ZK-SNARK yang membuktikan keberadaan bukti Merkle tersebut. Jumlah perhitungan ZK-SNARK adalah sekitar 400.000 Biaya Gas, sekitar 400 byte; transaksi dasar membutuhkan 21.000 Biaya Gas dan 100 byte.

Oleh karena itu, dari sudut pandang perhitungan, biaya ZK-SNARK adalah 19 kali biaya transaksi dasar saat ini; dari sudut pandang data, biaya ZK-SNARK adalah 4 kali biaya transaksi dasar saat ini dan 16 kali biaya masa depan. biaya transaksi dasar.

Angka-angka ini merupakan peningkatan besar atas bukti Merkle, tetapi masih cukup mahal. Ada dua cara untuk memperbaiki situasi ini: (i) bukti KZG tujuan khusus, atau (ii) agregasi, serupa dengan agregasi ERC-4337.

**Bagaimana cara kerja bukti KZG tujuan khusus? **

Pertama, rekap tentang cara kerja janji KZG:

*[D_1 ...D_n] mewakili sekumpulan data yang menjadi sumber bukti KZG polinomial. *

*Khususnya, polinomial P, di mana P(w) = D_1, P(w²) = D_2 ... P(wⁿ) = D_n.w di sini adalah "akar seragam", untuk beberapa bidang evaluasi ukuran N, nilai wN = 1 (ini semua dilakukan dalam bidang terbatas). *

• Untuk "berkomitmen" ke P, kita membuat titik kurva eliptik com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk. Di Sini:*

G adalah titik pembangkit kurva

Pi adalah koefisien ke-i dari polinomial P

Si adalah titik ke-i pada pengaturan tepercaya

*Dan untuk membuktikan bahwa P(z) = a, kita buat polinomial hasil bagi Q = (P - a) / (X - z), dan buat komitmen com(Q). Polinomial semacam itu hanya mungkin dibuat jika P(z) sebenarnya sama dengan a. *

• Untuk memverifikasi bukti, kami memeriksa persamaan Q * (X - z) = P - a dengan melakukan pemeriksaan kurva eliptik pada bukti com(Q) dan komitmen polinomial com(P): kami memeriksa e(com( T), com (X - z)) ? = e(com(P) - com(a), com(1))*

Beberapa properti utama yang juga perlu diketahui meliputi:

Bukti hanyalah nilai com(Q), yaitu 48 byte

com（P₁） + com（P₂） = com（P₁ + P₂）

*Ini juga berarti bahwa Anda dapat "mengedit" nilai ke dalam kontrak yang sudah ada. *

• Misalkan kita tahu bahwa D_i saat ini adalah a, kita ingin mengaturnya menjadi b, dan komitmen yang ada untuk D adalah com(P). janji "P, tapi P(wⁱ) = b, dan tidak ada perubahan evaluasi lainnya", lalu kita atur com(new_P) = com(P) + (ba)*com(Li), di mana Li adalah "lag Langerian polinomial", sama dengan 1 pada wⁱ dan 0 pada titik wj lainnya. *

• Untuk melakukan pembaruan ini secara efisien, setiap klien dapat menghitung sebelumnya dan menyimpan semua komitmen N ke polinomial Lagrangian (com(Li)). Dalam kontrak on-chain, mungkin terlalu banyak untuk menyimpan semua N komitmen, sehingga Anda dapat membuat komitmen KZG ke kumpulan nilai com(L_i), jadi kapan pun seseorang perlu memperbarui pohon on-chain, mereka dapat cukup kirimkan ke Proper com(L_i) memberikan bukti kebenarannya. *

Jadi, miliki struktur yang terus menambahkan nilai di akhir daftar yang terus bertambah, tetapi dengan batas ukuran tertentu. Kemudian, gunakan struktur ini sebagai struktur data untuk (i) komitmen pada daftar kunci di setiap L2, disimpan di L2 tersebut dan dicerminkan ke L1, dan (ii) komitmen pada daftar komitmen pada kunci L2, disimpan di Ethereum pada L1 dan dicerminkan ke setiap L2.

Menjaga komitmen tetap diperbarui dapat menjadi bagian dari logika inti L2, atau diimplementasikan melalui jembatan penyetoran dan penarikan tanpa mengubah protokol inti L2.

Bukti lengkap membutuhkan hal-hal berikut:

1. Simpan com (daftar kunci) terbaru dari keystore di L2.
2. Bukti KZG dengan com(keylist) sebagai nilai dalam com(mirror list), yang merupakan daftar semua komitmen keylist.
3. Buat sertifikat KZG dari kunci pengguna di com (daftar kunci).

Bahkan, dua bukti KZG di atas dapat digabungkan menjadi satu dengan ukuran total hanya 100 byte.

Perhatikan satu detail: Karena daftar kunci adalah daftar, bukan peta kunci/nilai seperti status, daftar kunci harus diberi posisi secara berurutan. Kontrak janji kunci akan berisi registri internalnya sendiri, memetakan setiap keystore ke ID, dan untuk setiap kunci, ia akan menyimpan hash (kunci, alamat keystore) alih-alih hanya kuncinya, untuk secara eksplisit memberi tahu L2 lain tentang yang mana keystore yang dirujuk oleh entri tertentu.

Keuntungan dari teknik ini adalah performanya sangat baik di L2. Sekitar 4 kali lebih pendek dari ZK-SNARK, jauh lebih pendek dari bukti Merkle. Perhitungan biaya sekitar 119.000 Gas Fee.

Di L1, daya komputasi lebih penting daripada data, jadi KZG sedikit lebih mahal daripada bukti Merkle.

**Bagaimana cara kerja pohon Verkle? **

Pohon Verkle pada dasarnya melibatkan penumpukan komitmen KZG bersama-sama: untuk menyimpan 2⁴⁸ nilai, komitmen KZG dapat dibuat ke daftar nilai 2²⁴, yang masing-masing merupakan komitmen KZG terhadap nilai 2²⁴.

Pohon Verkle dipertimbangkan untuk pohon status Ethereum karena pohon Verkle dapat digunakan untuk menyimpan peta nilai kunci.

Bukti dalam pohon Verkle lebih panjang dari bukti KZG, panjangnya bisa ratusan byte.

Faktanya, pohon Verkle harus dianggap seperti pohon Merkle, tetapi lebih layak tanpa SNARKing, tetapi SNARKing telah terbukti memiliki biaya bukti yang lebih rendah.

Keuntungan besar dari pohon Verkle adalah mereka dapat mengoordinasikan struktur data: sehingga dapat digunakan langsung untuk L1 atau L2, tidak ada struktur superposisi, dan mekanisme yang sama persis digunakan untuk L1 dan L2.

Begitu komputer kuantum menjadi masalah, atau begitu cabang Merkle terbukti cukup efisien, pohon Verkle memiliki lebih banyak kegunaan.

polimerisasi

Jika N pengguna melakukan N transaksi dan perlu membuktikan N klaim lintas rantai, kami dapat menghemat banyak Biaya Gas dengan menggabungkan bukti ini, yang dapat berarti:

• Bukti ZK-SNARK dari cabang N Merkle
• Beberapa sertifikat KZG
• Verkle multi-bukti (atau ZK-SNARK multi-bukti)

Dalam ketiga kasus tersebut, setiap bukti hanya berharga beberapa ratus ribu Gas Fee.

Pengembang perlu membuat satu bukti seperti itu pada setiap L2 untuk pengguna L2 itu; dengan demikian, agar bukti ini bermanfaat, seluruh skema harus memiliki penggunaan yang cukup sehingga sering terdapat setidaknya beberapa transaksi.

Jika ZK-SNARK digunakan, setiap pengguna mungkin perlu menghabiskan ribuan Biaya Gas L2. Jika multi-bukti KZG digunakan, pemverifikasi perlu menambahkan 48 Biaya Gas ke L2 dari setiap keystore yang digunakan di blok.

Namun, biaya ini jauh lebih rendah daripada tanpa agregasi, yang pasti melibatkan biaya gas lebih dari 10.000 L1 dan ratusan ribu biaya gas L2 per pengguna.

Untuk pohon Verkle, pengguna dapat langsung menggunakan Verkle multi-bukti, setiap pengguna menambahkan sekitar 100 ~ 200 byte, atau Anda dapat melakukan ZK-SNARK multi-bukti Verkle, biayanya mirip dengan ZK-SNARK cabang Merkle, tapi buktinya Kelihatannya jelas murah.

Dari sudut pandang implementasi, mungkin yang terbaik adalah membiarkan bundler mengumpulkan bukti lintas rantai melalui standar abstraksi akun ERC-4337. ERC-4337 sudah memiliki mekanisme bagi pembuat untuk menggabungkan bagian Operasi Pengguna dengan cara khusus. Bahkan ada implementasi untuk agregasi tanda tangan BLS, yang dapat mengurangi Biaya Gas L2 sebesar 1,5x hingga 3x.

Baca status secara langsung

Kemungkinan terakhir, dan yang hanya berlaku untuk L2 yang membaca L1 (bukan L1 yang membaca L2), adalah memodifikasi L2 sehingga mereka langsung melakukan panggilan statis ke kontrak L1.

Ini dapat dilakukan dengan opcode atau precompile yang memungkinkan panggilan ke L1 di mana Anda memberikan alamat target, gas dan calldata dan mengembalikan output, meskipun karena panggilan ini statis mereka tidak dapat benar-benar mengubah status L1 apa pun. L2 harus tahu apa yang terjadi dengan L1 untuk memproses deposit, jadi tidak ada hal mendasar yang mencegah hal ini terjadi; sebagian besar merupakan tantangan implementasi teknis.

Perhatikan bahwa jika keystore ada di L1, dan L2 menggabungkan fungsionalitas panggilan statis L1, maka pengesahan sama sekali tidak diperlukan.

Namun, jika L2 tidak memasukkan panggilan statis L1, atau jika keystore ada di L2, maka bukti diperlukan.

**Bagaimana L2 mempelajari root status Ethereum terbaru? **

Semua skema di atas memerlukan L2 untuk mengakses akar status L1 terdekat atau seluruh status L1 terdekat.

Faktanya, jika L2 memiliki fungsi deposit, maka Anda dapat menggunakan L2 itu untuk memindahkan root status L1 ke dalam kontrak di L2: cukup minta kontrak di L1 memanggil opcode BLOCKHASH dan menyimpannya sebagai aset Pesan diteruskan ke L2. Header blok lengkap dapat diterima di sisi L2 dan akar statusnya diekstrak.

Namun, setiap L2 lebih disukai memiliki cara eksplisit untuk langsung mengakses status L1 terbaru penuh atau root status L1 terdekat.

Tantangan utama dalam mengoptimalkan cara L2 menerima root status L1 terbaru adalah untuk mencapai keamanan dan latensi rendah pada saat yang bersamaan:

• Jika L2 lambat untuk mengimplementasikan fungsionalitas baca langsung L1, hanya membaca root status L1 terakhir, maka penundaan biasanya 15 menit, tetapi dalam beberapa kasus ekstrim penundaan bisa berminggu-minggu.
• L2 pasti dapat dirancang untuk membaca akar status L1 yang diperbarui, tetapi karena L1 dapat pulih (yang terjadi selama kebocoran tidak aktif bahkan dengan finalitas soket tunggal), L2 juga harus dapat pulih. Dari perspektif rekayasa perangkat lunak, ini secara teknis menantang.
• Jika jembatan digunakan untuk membawa akar status L1 ke L2, maka pembaruan aset membutuhkan waktu yang sangat lama, dalam kasus terbaik ada pengguna konstan yang membayar untuk pembaruan dan memperbarui sistem untuk semua orang.
• Oracles bukanlah solusi yang dapat diterima di sini: manajemen kunci dompet adalah fungsi tingkat rendah yang sangat kritis terhadap keamanan, sehingga paling banyak bergantung pada beberapa infrastruktur tingkat rendah yang sangat sederhana dan tidak dapat dipercaya secara kriptografis.

Juga, dalam arah yang berlawanan (L1 dibaca L2):

• Dalam Optimistic Rollup, root negara membutuhkan waktu seminggu untuk mencapai L1 karena penundaan bukti penipuan. Dalam pembatalan ZK, sekarang dibutuhkan berjam-jam karena kombinasi waktu verifikasi dan kendala ekonomi, meskipun teknologi masa depan akan menguranginya.
• Pra-konfirmasi (dari sequencer, certifier, dll.) bukan solusi yang dapat diterima untuk L1 membaca L2. Manajemen dompet adalah fungsi tingkat rendah yang sangat kritis terhadap keamanan, sehingga tingkat keamanan komunikasi L2 ke L1 harus benar-benar tinggi. Satu-satunya akar status yang harus dipercaya oleh L1 adalah yang telah diterima sebagai akar status terakhir oleh kontrak kepemilikan akar negara L2 di L1.

Beberapa di antaranya sangat lambat untuk operasi lintas rantai yang tidak dapat dipercaya untuk banyak kasus penggunaan DeFi. Namun, untuk kasus penggunaan pembaruan kunci dompet, penundaan yang lebih lama lebih dapat diterima - karena alih-alih menunda transaksi, itu menunda perubahan kunci.

Pengguna hanya perlu menyimpan kunci lama untuk jangka waktu yang lebih lama. Jika pengguna mengubah kunci karena dicuri, maka memang ada kerentanan yang lama, tetapi dapat dikurangi, misalnya. Melalui dompet dengan fungsi pembekuan.

Pada akhirnya, solusi meminimalkan latensi terbaik adalah membuat L2 secara optimal mengimplementasikan pembacaan langsung dari root status L1, di mana setiap blok L2 (atau log komputasi root status) berisi penunjuk ke blok L1 terbaru, jadi jika L1 pulih, dan L2 bisa sembuh juga. Kontrak keystore harus ditempatkan di mainnet atau di L2 dari ZK-rollup sehingga dapat dengan cepat dikomit ke L1.

**Berapa banyak koneksi ke Ethereum yang dibutuhkan rantai lain untuk menyimpan keystore yang disimpan di dompet Ethereum atau L2? **

Anehnya, tidak banyak. Bahkan, itu tidak perlu berupa Rollup.

Jika itu L3, atau validium, tidak apa-apa untuk menyimpan dompet di sana, selama pengguna menyimpan penyimpanan kunci di L1 atau ZK-rollup, mereka benar-benar perlu memiliki akses langsung ke root status Ethereum, dan bersedia menyimpan dompet mereka di Ethereum Saat refactoring, hard fork saat Ethereum hard fork.

Skema berbasis jembatan ZK memiliki sifat teknis yang menarik, tetapi memiliki kelemahan utama karena tidak kuat terhadap 51% serangan atau hard fork.

perlindungan privasi

Idealnya, pengguna juga menginginkan privasi. Jika pengguna memiliki banyak dompet yang dikelola oleh keystore yang sama, maka mereka ingin memastikan bahwa:

• Jauhkan publik dari mengetahui bahwa semua dompet ini terhubung satu sama lain.
• Wali pemulihan sosial tidak akan tahu di mana alamat perwalian mereka.

Tapi ini menimbulkan masalah:

• Kami tidak dapat menggunakan bukti Merkle secara langsung karena tidak menjaga privasi.
• Jika kita menggunakan KZG atau SNARKs, maka buktinya perlu memberikan versi kunci verifikasi yang dibutakan tanpa mengungkapkan lokasi kunci verifikasi.
• Jika kita menggunakan agregasi, maka agregator seharusnya tidak mengetahui lokasi secara jelas; sebaliknya, agregator harus menerima bukti buta dan memiliki cara untuk menggabungkan bukti tersebut.
• Kami tidak dapat menggunakan "versi ringan" (pengesahan lintas rantai hanya saat kunci kunci), karena ini akan membuat kebocoran privasi: jika banyak dompet diperbarui pada waktu yang sama karena pembaru, maka waktu dompet ini mungkin terkait Informasi. Oleh karena itu, kita harus menggunakan "versi lengkap" (bukti lintas rantai dari setiap transaksi).

Untuk SNARK, solusinya sederhana secara konseptual: bukti secara default menyembunyikan informasi, dan agregator perlu membuat SNARK rekursif untuk membuktikan SNARK.

Tantangan utama saat ini dengan pendekatan ini adalah agregasi membutuhkan agregator untuk membuat SNARK rekursif, yang agak lambat.

Untuk KZG, kita dapat menggunakan non-pengindeksan untuk mengungkap pekerjaan bukti KZG. Namun, agregasi buta adalah masalah terbuka yang membutuhkan lebih banyak perhatian.

Namun, saat membaca L1 langsung dari dalam L2 tidak melindungi privasi, penerapan kemampuan baca langsung ini masih akan sangat berguna - tidak hanya untuk meminimalkan latensi, tetapi untuk lebih banyak kasus penggunaan.