Dalam artikel saya sebelumnya tentang tiga shift, saya menguraikan beberapa alasan utama mengapa sangat berharga untuk mulai memikirkan secara eksplisit tentang dukungan L1 + lintas-L2, keamanan dompet, dan privasi sebagai fitur dasar yang diperlukan dari tumpukan ekosistem Hal-hal dibuat sebagai plugin yang dapat dirancang secara individual oleh satu dompet.
Posting ini akan lebih fokus langsung pada aspek teknis dari submasalah tertentu, seperti: cara lebih mudah membaca L1 dari L2, L2 dari L1, atau L2 dari L2 yang lain. Mengatasi masalah ini sangat penting untuk mengaktifkan arsitektur pemisahan aset/keystore, tetapi juga memiliki kasus penggunaan yang berharga di area lain, terutama mengoptimalkan rantai panggilan lintas-L2 yang andal, termasuk kasus penggunaan seperti memindahkan aset antara L1 dan L2 .
Katalog artikel ini
Apa tujuannya?
Seperti apa bukti lintas rantai itu?
Skema bukti seperti apa yang bisa kita gunakan?
Bukti Merkel
ZK SNARK
Sertifikat KZG khusus
Bukti pohon Verkle
polimerisasi
status langsung terbaca
Bagaimana L2 mempelajari root status Ethereum terbaru?
Dompet pada rantai non-L2
perlindungan privasi
Meringkaskan
1. Apa tujuannya?
Setelah L2 menjadi arus utama, pengguna akan memiliki aset di beberapa L2, dan mungkin juga L1. Setelah dompet kontrak pintar (multisig, pemulihan sosial, atau lainnya) menjadi arus utama, kunci yang diperlukan untuk mengakses akun tertentu akan berubah seiring waktu, dan kunci lama tidak perlu lagi valid. Setelah kedua hal itu terjadi, pengguna akan memerlukan cara untuk mengubah kunci yang memiliki akses ke banyak akun yang terletak di banyak tempat berbeda tanpa melakukan transaksi dalam jumlah yang sangat besar.
Secara khusus, kami memerlukan cara untuk menangani alamat kontrafaktual: alamat yang belum "terdaftar" di rantai dengan cara apa pun, tetapi masih perlu menerima dan menyimpan dana dengan aman. Kita semua mengandalkan alamat kontrafaktual: ketika Anda pertama kali menggunakan Ethereum, Anda dapat menghasilkan alamat ETH yang dapat digunakan seseorang untuk membayar Anda tanpa "mendaftarkan" alamat on-chain (ini memerlukan pembayaran txfee, Jadi sudah memegang beberapa ETH).
Untuk EOA, semua alamat dimulai dengan alamat kontrafaktual. Dengan dompet kontrak pintar, alamat kontrafaktual masih dimungkinkan sebagian besar berkat CREATE2, yang memungkinkan Anda memiliki alamat ETH yang hanya dapat diisi oleh kontrak pintar dengan kode yang cocok dengan hash tertentu.
EIP-1014 (CREATE2) Algoritma Perhitungan Alamat
Namun, dompet kontrak pintar memperkenalkan tantangan baru: kemungkinan perubahan kunci akses. Alamat ini adalah hash dari kode init dan hanya dapat berisi kunci verifikasi awal dompet. Kunci verifikasi saat ini akan disimpan di penyimpanan dompet, tetapi catatan penyimpanan itu tidak akan disebarkan secara ajaib ke L2 lainnya.
Jika pengguna memiliki banyak alamat di banyak L2, termasuk alamat yang tidak diketahui oleh L2 tempat mereka berada (karena kontrafaktual), maka tampaknya hanya ada satu cara untuk memungkinkan pengguna mengubah kunci mereka: arsitektur pemisahan aset/keystore. Setiap pengguna memiliki (i) "kontrak keystore" (baik di L1 atau satu L2 tertentu) yang menyimpan kunci verifikasi untuk semua dompet dan aturan untuk mengubah kunci, dan (ii) "kontrak dompet" yang membaca seluruh rantai untuk kunci verifikasi.
Ada dua cara untuk mencapai ini:
Versi ringan (hanya memeriksa kunci yang diperbarui): Setiap dompet menyimpan kunci verifikasi secara lokal dan berisi fungsi yang dapat dipanggil untuk memeriksa bukti lintas rantai dari status keystore saat ini dan memperbarui kunci kunci verifikasi yang disimpan secara lokal agar cocok. Saat dompet pertama kali digunakan pada L2 tertentu, fungsi ini harus dipanggil untuk mendapatkan kunci autentikasi saat ini dari keystore.
-Pro: Bukti lintas rantai digunakan dengan hemat, jadi tidak masalah jika bukti lintas rantai mahal. Semua dana hanya dapat digunakan dengan kunci saat ini, sehingga tetap aman.
Kerugian: Untuk mengubah kunci verifikasi, Anda harus melakukan perubahan kunci on-chain di keystore dan di setiap dompet yang diinisialisasi (meskipun bukan dompet kontrafaktual). Ini bisa menghabiskan banyak bahan bakar.
Versi berat (periksa setiap tx): Setiap transaksi memerlukan bukti rantai silang yang menunjukkan kunci saat ini di keystore.
Pro: kompleksitas sistem lebih sedikit, pembaruan keystore murah.
Kontra: Single tx mahal, jadi diperlukan lebih banyak teknik untuk membuat bukti lintas rantai jauh lebih murah. Juga tidak mudah kompatibel dengan ERC-4337, yang saat ini tidak mendukung pembacaan objek yang dapat diubah di seluruh kontrak selama verifikasi.
2. Seperti apakah bukti rantai silang itu?
Untuk mendemonstrasikan kompleksitas penuh, kami akan mengeksplorasi kasus yang paling sulit: keystore di satu L2, dompet di L2 yang berbeda. Hanya setengah dari desain ini yang diperlukan jika keystore di dompet ada di L1.
Asumsikan keystore ada di Linea dan dompet ada di Kakarot. Bukti lengkap dari kunci dompet meliputi:
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 masalah implementasi utama yang rumit di sini:
Bukti apa yang kita gunakan? (Apakah ini bukti Merkel? Sesuatu yang lain?
Bagaimana L2 pertama kali mempelajari root status L1 (Ethereum) terdekat (atau, seperti yang akan kita lihat, kemungkinan status L1 penuh)? Atau, bagaimana L1 mempelajari akar status L2?
Dalam kedua kasus tersebut, berapa lama penundaan antara apa yang terjadi di satu sisi dan apa yang dapat dibuktikan di sisi lain?
3. Jenis skema pembuktian apa yang dapat kita gunakan?
Ada lima opsi utama:
Bukti Merkle
-Jenderal ZK-SNARK
Bukti khusus (misalnya menggunakan KZG)
-Verkle menunjukkan bahwa mereka berada di antara KZG dan ZK-SNARK dalam hal beban kerja dan biaya infrastruktur.
Tidak diperlukan bukti, bergantung pada pembacaan keadaan langsung
Dalam hal pekerjaan infrastruktur yang diperlukan dan biaya pengguna, secara kasar saya akan memeringkatnya sebagai berikut:
"Agregasi" mengacu pada agregasi semua bukti yang diberikan oleh pengguna dalam setiap blok menjadi satu bukti meta besar yang menggabungkan semua bukti. Ini dimungkinkan dengan SNARK dan KZG, tetapi tidak dengan garpu Merkle (Anda dapat menggabungkan garpu Merkle sedikit, tetapi itu hanya menghemat log (txs per blok) / log (jumlah total keystores), dalam praktiknya Mungkin 15-30% di tengah, jadi mungkin tidak sepadan dengan harganya).
Agregasi hanya bermanfaat jika skenario memiliki banyak pengguna, sehingga dalam praktiknya implementasi versi 1 dapat menghilangkan agregasi dan menerapkannya dalam versi 2.
4. Bagaimana bukti Merkle bekerja?
Yang ini mudah: cukup ikuti diagram di bagian sebelumnya. Lebih tepatnya, setiap "bukti" (dengan asumsi kasus pembuktian kesulitan maksimum dari satu L2 ke L2 lainnya) akan berisi:
Cabang Merkle yang membuktikan root status L2 yang memegang keystore, mengingat root status Ethereum terbaru yang diketahui L2. Keystore menyimpan root status L2 yang disimpan dalam slot penyimpanan yang diketahui di alamat yang diketahui (kontrak pada L1 mewakili L2), sehingga jalur melalui pohon dapat di-hardcode.
Cabang Merkle yang membuktikan kunci verifikasi saat ini, mengingat akar status L2 yang memegang keystore. Di sini sekali lagi, kunci autentikasi disimpan di slot penyimpanan yang diketahui di alamat yang diketahui, sehingga jalurnya dapat di-hardcode.
Sayangnya, Ethereum Proofs of State rumit, tetapi perpustakaan ada untuk memvalidasinya, dan jika Anda menggunakan perpustakaan itu, mekanisme ini tidak terlalu rumit untuk diterapkan.
** Masalah yang lebih besar adalah biaya. ** Bukti Merkle sangat panjang, sayangnya pohon Patricia ~3,9 kali lebih lama dari yang diperlukan (tepatnya: bukti Merkle yang ideal untuk pohon yang memegang objek N panjangnya 32 * log2(N) byte, dan karena pohon Patricia Ethereum memiliki 16 daun per anak, dan bukti dari pohon ini adalah 32 * 15 * log16(N) ~= 125 * log2(N) byte). Dalam keadaan dengan sekitar 250 juta (~2²⁸) akun, ini membuat setiap bukti 125 * 28 = 3500 byte, atau sekitar 56.000 gas, ditambah biaya tambahan untuk mendekode dan memverifikasi hash.
Bersama-sama, kedua bukti tersebut akan menghabiskan biaya sekitar 100.000 hingga 150.000 gas (jika digunakan per transaksi, tidak termasuk verifikasi tanda tangan) - jauh lebih tinggi dari harga dasar saat ini sebesar 21.000 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 node yang jauh lebih sedikit daripada L1. Di sisi lain, data harus dipublikasikan ke L1. Jadi perbandingannya bukan 21k gas vs 15k gas; itu 21k L2 gas vs 100k L1 gas.
Kita dapat menghitung artinya dengan melihat perbandingan antara biaya gas L1 dan biaya gas L2:
Saat ini, L1 15-25 kali lebih mahal daripada L2 untuk pengiriman sederhana dan 20-50 kali lebih mahal untuk pertukaran token. Pengiriman sederhana adalah jumlah data yang relatif besar, tetapi perhitungan jumlah pertukaran jauh lebih besar. Oleh karena itu, swap adalah tolok ukur yang lebih baik untuk perkiraan biaya perhitungan L1 versus perhitungan L2. Mempertimbangkan semua ini, jika kita mengasumsikan rasio biaya 30x antara biaya komputasi L1 dan biaya komputasi L2, ini tampaknya menyiratkan bahwa biaya untuk menempatkan bukti Merkle pada L2 dapat setara dengan 50 transaksi reguler.
Tentu saja, menggunakan pohon Merkle biner mengurangi biaya dengan faktor ~4, tetapi meskipun demikian, dalam kebanyakan kasus, biayanya terlalu tinggi - jika kita rela berkorban karena tidak lagi kompatibel dengan pohon status heksagonal Ethereum saat ini, kita Cari opsi yang lebih baik.
5. Bagaimana cara kerja pembuktian 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. ZK-SNARK membutuhkan ~400.000 GAS untuk perhitungan, yang memakan waktu sekitar 400 byte (dibandingkan dengan: transaksi dasar membutuhkan 21.000 gas dan 100 byte, yang dapat dikurangi menjadi ~25 kata setelah kompresi di Festival mendatang). Oleh karena itu, dari sudut pandang komputasi, biaya ZK-SNARK adalah 19 kali lipat dari biaya transaksi dasar saat ini, dan dari sudut pandang data, biaya ZK-SNARK adalah 4 kali lipat dari biaya transaksi dasar saat ini dan 16 kali biaya transaksi dasar di masa mendatang.
Angka-angka itu merupakan peningkatan besar dibandingkan bukti Merkel, tetapi harganya masih cukup mahal. Ada dua cara untuk memperbaikinya: (i) bukti KZG tujuan khusus, atau (ii) agregasi, mirip dengan agregasi ERC-4337 tetapi menggunakan matematika yang lebih bagus. Kita bisa belajar keduanya sekaligus.
6. Bagaimana cara kerja pembuktian KZG tujuan khusus?
Peringatan, bagian ini lebih matematis daripada yang lain. Ini karena kami bergerak di luar alat tujuan umum, dan membangun beberapa alat tujuan khusus yang lebih murah, jadi kami harus lebih "bersembunyi". Jika Anda tidak menyukai matematika mendalam, langsung lompat ke bagian berikutnya.
Pertama, rekap tentang cara kerja komitmen KZG:
Kami dapat mewakili satu set data [D_1...D_n] menggunakan bukti KZG dari polinomial yang diturunkan dari data: khususnya, polinomial P, di mana P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n.w di sini adalah "akar seragam", nilai wN = 1 untuk beberapa ukuran domain evaluasi N (ini semua dilakukan dalam bidang terbatas).
Untuk "berkomitmen" ke P, kita membuat titik kurva elips com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk. Di Sini:
-G adalah titik generator untuk kurva
-Pi adalah koefisien ke-i dari polinomial P
-Si adalah titik ke-i dalam pengaturan tepercaya
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 elips pada bukti com(Q) dan komitmen polinomial com(P): kami memeriksa e(com(Q) ), com( X - z)) ? = e(com(P) - com(a), com(1))
Beberapa properti utama yang perlu diketahui meliputi:
buktinya hanya nilai com(Q), yaitu 48 byte
-com（P₁） + com（P₂） = com（P₁ + P₂）
Ini juga berarti 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, tetapi P(wⁱ) = b, dan tidak ada perubahan evaluasi lainnya", lalu kita tetapkan 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 Lagrange (com(Li)). Dalam kontrak on-chain, mungkin terlalu banyak untuk menyimpan semua komitmen N, sehingga Anda dapat membuat komitmen KZG ke kumpulan nilai com(L_i) (atau hash(com(L_i)), jadi kapan pun kebutuhan seseorang Saat memperbarui pohon rantai, mereka dapat dengan mudah memberikan bukti kebenarannya ke com(L_i) yang sesuai.
Jadi kami memiliki struktur di mana kami dapat terus menambahkan nilai ke akhir daftar yang terus bertambah, meskipun dengan batas ukuran tertentu (sebenarnya, ratusan juta mungkin bisa dilakukan). Kami kemudian menggunakan ini sebagai struktur data kami untuk mengelola (i) komitmen pada daftar kunci di setiap L2, disimpan di L2 itu dan dicerminkan ke L1, dan (ii) komitmen pada daftar komitmen kunci L2, Disimpan di Ethereum 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.
Oleh karena itu, bukti lengkap membutuhkan:
Keystore menyimpan com terbaru (daftar kunci) di L2 (48 byte)
-KZG membuktikan bahwa com(daftar kunci) adalah com(nilai di mirror_list), komitmen untuk semua daftar pengiriman daftar kunci (48 byte)
-KZG membuktikan bahwa kunci Anda ada di com (daftar kunci) (48 byte, ditambah 4 byte untuk indeks)
Sebenarnya dimungkinkan untuk menggabungkan dua bukti KZG menjadi satu, jadi kami mendapatkan ukuran total hanya 100 byte.
Perhatikan kehalusannya: karena daftar kunci adalah daftar, bukan peta kunci/nilai seperti keadaan, daftar kunci harus diberi posisi secara berurutan. Kontrak komitmen kunci akan berisi registri internalnya sendiri, memetakan setiap keystore ke ID, dan untuk setiap kunci, itu akan menyimpan hash (alamat keystore) bukan hanya kunci, Untuk berkomunikasi secara eksplisit dengan L2 lain yang keystore entri tertentu berbicara tentang.
Keuntungan dari teknik ini adalah performanya sangat baik di L2. Datanya 100 byte, yang ~4 kali lebih pendek dari ZK-SNARK dan lebih pendek dari bukti Merkle. Biaya perhitungan terutama satu pasang cek, atau sekitar 119.000 gas. Pada L1, data kurang penting daripada perhitungan, jadi sayangnya KZG sedikit lebih mahal daripada bukti Merkle.
7. Bagaimana cara kerja pohon Verkle?
Pohon Verkle pada dasarnya melibatkan penumpukan komitmen KZG (atau komitmen IPA, yang bisa lebih efisien dan menggunakan enkripsi yang lebih sederhana): untuk menyimpan 2⁴⁸ nilai, Anda membuat komitmen KZG ke daftar nilai 2²⁴, yang masing-masing merupakan Komitmen KZG untuk 2²⁴ Nilai. Pohon Verkle sangat dipertimbangkan untuk pohon status Ethereum, karena Pohon Verkle dapat digunakan untuk menyimpan pemetaan nilai kunci, bukan hanya daftar (pada dasarnya, Anda dapat membuat pohon berukuran 2²⁵⁶ tetapi mulai kosong, hanya jika Anda Hanya mengisi bagian tertentu dari pohon saat Anda benar-benar perlu mengisinya).
Seperti apa pohon Vicker itu. Nyatanya, Anda dapat memberikan setiap node lebar 256 == 2⁸ untuk pohon berbasis IPA, dan 2²⁴ untuk pohon berbasis KZG.
Bukti di pohon Verkle agak lebih panjang daripada di KZG; panjangnya bisa ratusan byte. Mereka juga sulit diverifikasi, terutama jika Anda mencoba menggabungkan banyak bukti menjadi satu.
Sebenarnya, pohon Verkle harus dianggap seperti pohon Merkle, tetapi lebih layak tanpa SNARKing (karena biaya data lebih rendah), dan SNARKing lebih murah (karena biaya bukti lebih rendah).
Keuntungan terbesar dari pohon Verkle adalah mereka dapat mengoordinasikan struktur data: Bukti Verkle dapat digunakan langsung untuk status L1 atau L2, tidak memiliki struktur superposisi, dan menggunakan mekanisme yang persis sama untuk L1 dan L2. Setelah komputer kuantum menjadi masalah, atau setelah percabangan Merkle terbukti cukup efisien, pohon Verkle dapat diganti di tempat dengan pohon hash biner dengan fungsi hash ramah-SNARK yang sesuai.
8. Agregat
Jika N pengguna melakukan N transaksi (atau lebih realistis, N ERC-4337 UserOperations) perlu membuktikan N klaim lintas rantai, kami dapat menghemat banyak uang dengan menggabungkan bukti ini: menggabungkan transaksi ini ke dalam satu blok atau Pembuat bundel yang masuk ke blok dapat membuat bukti yang membuktikan semua klaim ini pada saat yang bersamaan.
Ini bisa berarti:
Bukti ZK-SNARK untuk cabang N Merkle
KZG multi-bukti
Verkle multi-bukti (atau multi-bukti ZK-SNARK)
Dalam ketiga kasus tersebut, setiap pembuktian hanya membutuhkan beberapa ratus ribu gas. Pembangun perlu membuat salah satu dari ini pada setiap L2 untuk pengguna di L2 itu; dengan demikian, untuk kemudahan konstruksi, seluruh skema perlu digunakan secara memadai sehingga biasanya ada setidaknya beberapa transaksi di blok yang sama pada beberapa perdagangan L2 utama .
Jika ZK-SNARK digunakan, biaya marjinal utama hanyalah "logika bisnis" untuk menyampaikan angka di antara kontrak, sehingga setiap pengguna mungkin memerlukan beberapa ribu L2 gas. Jika multi-bukti KZG digunakan, pembukti perlu menambahkan 48 gas untuk setiap keystore yang menyimpan L2 yang digunakan di dalam blok, sehingga biaya marjinal skema per pengguna adalah per L2 (bukan per pengguna) dan kemudian Menambahkan ~800 gas L1 . Namun biaya ini jauh lebih rendah daripada tanpa agregasi, yang pasti melibatkan lebih dari 10.000 L1 gas dan ratusan ribu gas L2 per pengguna. Untuk pohon Verkle, Anda dapat menggunakan multi-bukti Verkle secara langsung, menambahkan sekitar 100-200 byte per pengguna, atau Anda dapat membuat ZK-SNARK dari Verkle multi-bukti, yang harganya mirip dengan ZK-SNARK bercabang Merkle, tetapi biaya bukti jauh lebih rendah.
Dari sudut pandang implementasi, lebih baik bundler menggabungkan bukti lintas rantai melalui standar abstraksi akun ERC-4337. ERC-4337 sudah memiliki mekanisme bagi pembuat untuk menggabungkan bagian tindakan pengguna dengan cara khusus. Bahkan ada implementasi untuk agregasi tanda tangan BLS, yang dapat mengurangi biaya bahan bakar pada L2 dengan faktor 1,5 hingga 3, bergantung pada bentuk kompresi lain yang disertakan.
Diagram dari postingan implementasi dompet BLS yang menunjukkan alur kerja untuk tanda tangan agregat BLS di versi awal ERC-4337. Alur kerja untuk menggabungkan bukti lintas rantai mungkin terlihat sangat mirip.
9. Membaca status langsung
Kemungkinan terakhir, juga hanya tersedia untuk L2 yang membaca L1 (dan bukan L1 yang membaca L2), adalah memodifikasi L2 sehingga mereka langsung melakukan panggilan statis ke kontrak di L1.
Hal ini dapat dilakukan dengan opcode atau prakompilasi, yang memungkinkan panggilan ke L1, di mana Anda memberikan alamat target, gas, dan data panggilan, dan mengembalikan output, tetapi karena panggilan ini statis, mereka tidak dapat benar-benar mengubah keadaan L1 apa pun. L2 harus tahu bahwa L1 telah memproses deposit, jadi tidak ada yang mencegah penerapan hal seperti itu; ini sebagian besar merupakan tantangan implementasi teknis (lihat: ini dari RFP yang optimis untuk mendukung panggilan statis ke L1).
Perhatikan bahwa jika keystore ada di L1, dan L2 mengintegrasikan panggilan statis L1, tidak diperlukan pengesahan sama sekali! Namun, jika L2 tidak mengintegrasikan panggilan statis L1, atau jika keystore ada di L2 (yang pada akhirnya harus dilakukan setelah L1 menjadi terlalu mahal bagi pengguna untuk digunakan meski hanya sedikit), maka bukti akan diperlukan.
10. Bagaimana L2 mempelajari root status Ethereum terbaru?
Semua skema di atas memerlukan L2 untuk mengakses akar status L1 terdekat atau seluruh status L1 terdekat. Untungnya, semua L2 sudah memiliki beberapa fungsi untuk mengakses status L1 terbaru. Ini karena mereka membutuhkan fungsionalitas seperti itu untuk menangani pesan dari L1 ke L2, terutama deposit.
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 meneruskannya ke L2 sebagai pesan deposit . Header blok lengkap dapat diterima di sisi L2 dan akar statusnya diekstraksi. 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 mengimplementasikan fungsionalitas "baca langsung L1" dengan cara yang malas, hanya membaca root status L1 terakhir, maka penundaan biasanya 15 menit, tetapi dalam kasus kebocoran aktivitas yang ekstrim (yang harus Anda toleransi), penundaan dapat terjadi 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 harus dapat pulih juga. Dari sudut pandang rekayasa perangkat lunak, ini menantang secara teknis, tetapi setidaknya Optimis memiliki kemampuan.
Jika Anda menggunakan jembatan deposit untuk membawa akar status L1 ke L2, maka ekonomi sederhana mungkin memerlukan waktu lama antara pembaruan deposit: jika biaya penuh deposit adalah 100.000 gas, mari kita asumsikan $1800 dalam ETH dan biaya sebesar 200 gwei, dan akar L1 masuk ke L2 sekali sehari, biayanya $236 per L per hari, atau $13.148 per L2 per tahun untuk memelihara sistem. Penundaan satu jam menelan biaya $315.569 per L2 per tahun. Paling-paling, ada aliran konstan pengguna kaya yang tidak sabar membayar untuk memperbarui dan menjaga agar sistem tetap mutakhir untuk orang lain. Paling buruk, beberapa aktor altruistik harus membayarnya sendiri.
"Oracle" (setidaknya teknologi yang oleh beberapa orang DeFi disebut "oracle") bukanlah solusi yang dapat diterima di sini: manajemen kunci dompet adalah fungsi tingkat rendah yang sangat kritis terhadap keamanan, jadi paling banyak harus bergantung pada beberapa A sangat sederhana, infrastruktur tingkat rendah yang tidak memerlukan kepercayaan kriptografi.
Juga, dalam arah yang berlawanan (L1 dibaca sebagai L2):
Dalam Agregasi Optimis, akar 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 - L1 harus mutlak: bahkan tidak mungkin mendorong root status L1 yang salah dengan mengambil alih set validator L2. 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.
Untuk banyak kasus penggunaan DeFi, beberapa di antaranya sangat lambat untuk operasi lintas rantai yang tidak dapat dipercaya; untuk kasus ini, Anda benar-benar membutuhkan jembatan yang lebih cepat dengan model keamanan yang lebih tidak sempurna. Namun, untuk kasus penggunaan pembaruan kunci dompet, penundaan yang lebih lama lebih dapat diterima: alih-alih menunda transaksi selama berjam-jam, Anda menunda perubahan kunci. Anda hanya perlu menyimpan kunci lama lebih lama. Jika Anda mengubah kunci Anda karena dicuri, Anda memiliki kerentanan untuk waktu 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.
Blok rantai L2 dapat bergantung tidak hanya pada blok L2 sebelumnya, tetapi juga pada blok L1. Jika L1 pulih melalui tautan seperti itu, L2 juga akan pulih. Perlu dicatat bahwa ini juga cara kerja versi sharding sebelumnya (pra-Dank); lihat di sini untuk kodenya.
11. Berapa banyak koneksi ke Ethereum yang diperlukan rantai lain untuk menyimpan keystore yang di-root di dompet Ethereum atau L2?
Anehnya, tidak banyak. Sebenarnya tidak perlu rollup: jika itu L3 atau validasi, tidak apa-apa menyimpan dompet di sana, selama Anda menahan keystore pada rollup L1 atau ZK. Apa yang benar-benar Anda butuhkan adalah rantai untuk memiliki akses langsung ke root status Ethereum, dan komitmen teknis dan sosial untuk bersedia mengatur ulang jika Ethereum melakukan reorganisasi, dan melakukan hard fork jika Ethereum melakukan hard fork.
Pertanyaan penelitian yang menarik adalah untuk menentukan sejauh mana suatu rantai dapat memiliki bentuk koneksi ini dengan beberapa rantai lainnya (mis. Ethereum dan Zcash). Melakukan hal ini secara naif adalah mungkin: jika Ethereum atau Zcash mengatur ulang, rantai Anda dapat setuju untuk mengatur ulang (dan hard fork jika hard fork Ethereum atau Zcash), tetapi operator node Anda dan komunitas Anda biasanya memiliki dua kali ketergantungan teknologi dan politik. Oleh karena itu, teknik ini dapat digunakan untuk menyambung ke beberapa rantai lain, tetapi dengan biaya yang meningkat. Skema berbasis jembatan ZK memiliki sifat teknis yang menarik, tetapi kelemahan utama mereka adalah bahwa mereka tidak kuat terhadap serangan 51% atau hard fork. Mungkin ada solusi yang lebih cerdas juga.
12. Perlindungan privasi
Idealnya, kami juga ingin menjaga privasi. Jika Anda memiliki banyak dompet yang dikelola oleh keystore yang sama, kami ingin memastikan bahwa:
Tidak jelas apakah semua dompet ini terhubung satu sama lain.
Wali Rehabilitasi Sosial tidak mengetahui alamat yang mereka lindungi.
Ini menciptakan beberapa masalah:
Kami tidak dapat menggunakan bukti Merkle secara langsung karena tidak melindungi privasi.
Jika kita menggunakan KZG atau SNARK, maka buktinya perlu memberikan versi kunci verifikasi yang dibutakan tanpa mengungkapkan lokasi kunci verifikasi.
Jika kita menggunakan agregasi, maka agregator tidak boleh mempelajari posisi dalam plaintext; sebaliknya, agregator harus menerima bukti buta dan memiliki cara untuk menggabungkan bukti tersebut.
Kami tidak dapat menggunakan "versi ringan" (memperbaharui kunci hanya menggunakan bukti rantai silang), karena ini menimbulkan kebocoran privasi: jika banyak dompet diperbarui pada saat yang sama karena proses pembaruan, informasi kebocoran waktu yang mungkin relevan untuk dompet ini.
Oleh karena itu, kita harus menggunakan "versi berat" (bukti lintas rantai dari setiap transaksi).
Dengan SNARK, solusinya sederhana secara konseptual: secara default, bukti disembunyikan oleh informasi, dan agregator perlu membuat SNARK rekursif untuk membuktikan SNARK.
Tantangan utama dengan pendekatan ini saat ini adalah agregasi membutuhkan agregator untuk membuat SNARK rekursif, yang saat ini sangat lambat.
Dengan KZG, kita dapat menggunakan karya ini (lihat juga: versi yang lebih formal dari karya ini di makalah Caulk) pada bukti KZG yang tidak diindeks sebagai titik awal. Namun, agregasi bukti buta merupakan masalah terbuka yang memerlukan perhatian lebih.
Sayangnya, membaca L1 langsung dari dalam L2 tidak menjaga privasi, meskipun penerapan fungsi baca langsung masih sangat berguna, baik untuk meminimalkan latensi maupun karena kegunaannya untuk aplikasi lain.
13. Ringkasan
Untuk memiliki dompet pemulihan sosial lintas rantai, alur kerja yang paling realistis adalah dompet yang menyimpan keystore di satu lokasi, dan dompet yang memelihara dompet di banyak lokasi, di mana dompet membaca keystore untuk (i) memperbarui kunci autentikasinya secara lokal lihat, atau (ii) dalam proses memvalidasi setiap transaksi.
Elemen kunci yang memungkinkan hal ini adalah bukti lintas rantai. Kita perlu bekerja untuk mengoptimalkan bukti-bukti ini. Solusi ZK-SNARK atau KZG khusus yang menunggu bukti Verkle tampaknya menjadi opsi terbaik.
Dalam jangka panjang, protokol agregasi (di mana bundler menghasilkan bukti agregat sebagai bagian dari pembuatan bundel dari semua tindakan pengguna yang dikirimkan oleh pengguna) diperlukan untuk meminimalkan biaya. Ini mungkin harus diintegrasikan ke dalam ekosistem ERC-4337, meskipun mungkin diperlukan perubahan pada ERC-4337.
L2 harus dioptimalkan untuk meminimalkan latensi pembacaan status L1 (atau setidaknya root status) dari dalam L2. Sangat ideal untuk L2 untuk membaca status L1 secara langsung, menghemat ruang bukti.
Dompet tidak hanya dapat berada di L2; Anda juga dapat menempatkan dompet pada sistem dengan tingkat konektivitas yang lebih rendah ke Ethereum (L3, atau bahkan hanya setuju untuk memasukkan root status Ethereum dan rantai garpu independen).
Namun, keystore harus berada di L1 atau L2 rollup ZK keamanan tinggi. Menggunakan L1 menghemat banyak kerumitan, tetapi bahkan itu bisa menjadi terlalu mahal dalam jangka panjang, jadi keystore perlu digunakan di L2.
Mempertahankan privasi akan membutuhkan kerja ekstra dan membuat pilihan tertentu menjadi lebih sulit. Namun, kita mungkin harus beralih ke solusi yang menjaga privasi, setidaknya memastikan bahwa apa pun yang kita hasilkan kompatibel dengan menjaga privasi.
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.
Buterin: Wawasan lintas-L2 membaca untuk dompet dan kasus penggunaan lainnya
Penulis: Vitalik Buterin Kompilasi: Vernacular Blockchain
Dalam artikel saya sebelumnya tentang tiga shift, saya menguraikan beberapa alasan utama mengapa sangat berharga untuk mulai memikirkan secara eksplisit tentang dukungan L1 + lintas-L2, keamanan dompet, dan privasi sebagai fitur dasar yang diperlukan dari tumpukan ekosistem Hal-hal dibuat sebagai plugin yang dapat dirancang secara individual oleh satu dompet.
Posting ini akan lebih fokus langsung pada aspek teknis dari submasalah tertentu, seperti: cara lebih mudah membaca L1 dari L2, L2 dari L1, atau L2 dari L2 yang lain. Mengatasi masalah ini sangat penting untuk mengaktifkan arsitektur pemisahan aset/keystore, tetapi juga memiliki kasus penggunaan yang berharga di area lain, terutama mengoptimalkan rantai panggilan lintas-L2 yang andal, termasuk kasus penggunaan seperti memindahkan aset antara L1 dan L2 . Katalog artikel ini Apa tujuannya? Seperti apa bukti lintas rantai itu? Skema bukti seperti apa yang bisa kita gunakan? Bukti Merkel ZK SNARK Sertifikat KZG khusus Bukti pohon Verkle polimerisasi status langsung terbaca Bagaimana L2 mempelajari root status Ethereum terbaru? Dompet pada rantai non-L2 perlindungan privasi Meringkaskan
1. Apa tujuannya?
Setelah L2 menjadi arus utama, pengguna akan memiliki aset di beberapa L2, dan mungkin juga L1. Setelah dompet kontrak pintar (multisig, pemulihan sosial, atau lainnya) menjadi arus utama, kunci yang diperlukan untuk mengakses akun tertentu akan berubah seiring waktu, dan kunci lama tidak perlu lagi valid. Setelah kedua hal itu terjadi, pengguna akan memerlukan cara untuk mengubah kunci yang memiliki akses ke banyak akun yang terletak di banyak tempat berbeda tanpa melakukan transaksi dalam jumlah yang sangat besar. Secara khusus, kami memerlukan cara untuk menangani alamat kontrafaktual: alamat yang belum "terdaftar" di rantai dengan cara apa pun, tetapi masih perlu menerima dan menyimpan dana dengan aman. Kita semua mengandalkan alamat kontrafaktual: ketika Anda pertama kali menggunakan Ethereum, Anda dapat menghasilkan alamat ETH yang dapat digunakan seseorang untuk membayar Anda tanpa "mendaftarkan" alamat on-chain (ini memerlukan pembayaran txfee, Jadi sudah memegang beberapa ETH). Untuk EOA, semua alamat dimulai dengan alamat kontrafaktual. Dengan dompet kontrak pintar, alamat kontrafaktual masih dimungkinkan sebagian besar berkat CREATE2, yang memungkinkan Anda memiliki alamat ETH yang hanya dapat diisi oleh kontrak pintar dengan kode yang cocok dengan hash tertentu.
EIP-1014 (CREATE2) Algoritma Perhitungan Alamat
Namun, dompet kontrak pintar memperkenalkan tantangan baru: kemungkinan perubahan kunci akses. Alamat ini adalah hash dari kode init dan hanya dapat berisi kunci verifikasi awal dompet. Kunci verifikasi saat ini akan disimpan di penyimpanan dompet, tetapi catatan penyimpanan itu tidak akan disebarkan secara ajaib ke L2 lainnya. Jika pengguna memiliki banyak alamat di banyak L2, termasuk alamat yang tidak diketahui oleh L2 tempat mereka berada (karena kontrafaktual), maka tampaknya hanya ada satu cara untuk memungkinkan pengguna mengubah kunci mereka: arsitektur pemisahan aset/keystore. Setiap pengguna memiliki (i) "kontrak keystore" (baik di L1 atau satu L2 tertentu) yang menyimpan kunci verifikasi untuk semua dompet dan aturan untuk mengubah kunci, dan (ii) "kontrak dompet" yang membaca seluruh rantai untuk kunci verifikasi.
Ada dua cara untuk mencapai ini:
Versi ringan (hanya memeriksa kunci yang diperbarui): Setiap dompet menyimpan kunci verifikasi secara lokal dan berisi fungsi yang dapat dipanggil untuk memeriksa bukti lintas rantai dari status keystore saat ini dan memperbarui kunci kunci verifikasi yang disimpan secara lokal agar cocok. Saat dompet pertama kali digunakan pada L2 tertentu, fungsi ini harus dipanggil untuk mendapatkan kunci autentikasi saat ini dari keystore. -Pro: Bukti lintas rantai digunakan dengan hemat, jadi tidak masalah jika bukti lintas rantai mahal. Semua dana hanya dapat digunakan dengan kunci saat ini, sehingga tetap aman.
2. Seperti apakah bukti rantai silang itu?
Untuk mendemonstrasikan kompleksitas penuh, kami akan mengeksplorasi kasus yang paling sulit: keystore di satu L2, dompet di L2 yang berbeda. Hanya setengah dari desain ini yang diperlukan jika keystore di dompet ada di L1.
Asumsikan keystore ada di Linea dan dompet ada di Kakarot. Bukti lengkap dari kunci dompet meliputi:
3. Jenis skema pembuktian apa yang dapat kita gunakan?
Ada lima opsi utama:
"Agregasi" mengacu pada agregasi semua bukti yang diberikan oleh pengguna dalam setiap blok menjadi satu bukti meta besar yang menggabungkan semua bukti. Ini dimungkinkan dengan SNARK dan KZG, tetapi tidak dengan garpu Merkle (Anda dapat menggabungkan garpu Merkle sedikit, tetapi itu hanya menghemat log (txs per blok) / log (jumlah total keystores), dalam praktiknya Mungkin 15-30% di tengah, jadi mungkin tidak sepadan dengan harganya). Agregasi hanya bermanfaat jika skenario memiliki banyak pengguna, sehingga dalam praktiknya implementasi versi 1 dapat menghilangkan agregasi dan menerapkannya dalam versi 2.
4. Bagaimana bukti Merkle bekerja?
Yang ini mudah: cukup ikuti diagram di bagian sebelumnya. Lebih tepatnya, setiap "bukti" (dengan asumsi kasus pembuktian kesulitan maksimum dari satu L2 ke L2 lainnya) akan berisi: Cabang Merkle yang membuktikan root status L2 yang memegang keystore, mengingat root status Ethereum terbaru yang diketahui L2. Keystore menyimpan root status L2 yang disimpan dalam slot penyimpanan yang diketahui di alamat yang diketahui (kontrak pada L1 mewakili L2), sehingga jalur melalui pohon dapat di-hardcode. Cabang Merkle yang membuktikan kunci verifikasi saat ini, mengingat akar status L2 yang memegang keystore. Di sini sekali lagi, kunci autentikasi disimpan di slot penyimpanan yang diketahui di alamat yang diketahui, sehingga jalurnya dapat di-hardcode. Sayangnya, Ethereum Proofs of State rumit, tetapi perpustakaan ada untuk memvalidasinya, dan jika Anda menggunakan perpustakaan itu, mekanisme ini tidak terlalu rumit untuk diterapkan. ** Masalah yang lebih besar adalah biaya. ** Bukti Merkle sangat panjang, sayangnya pohon Patricia ~3,9 kali lebih lama dari yang diperlukan (tepatnya: bukti Merkle yang ideal untuk pohon yang memegang objek N panjangnya 32 * log2(N) byte, dan karena pohon Patricia Ethereum memiliki 16 daun per anak, dan bukti dari pohon ini adalah 32 * 15 * log16(N) ~= 125 * log2(N) byte). Dalam keadaan dengan sekitar 250 juta (~2²⁸) akun, ini membuat setiap bukti 125 * 28 = 3500 byte, atau sekitar 56.000 gas, ditambah biaya tambahan untuk mendekode dan memverifikasi hash. Bersama-sama, kedua bukti tersebut akan menghabiskan biaya sekitar 100.000 hingga 150.000 gas (jika digunakan per transaksi, tidak termasuk verifikasi tanda tangan) - jauh lebih tinggi dari harga dasar saat ini sebesar 21.000 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 node yang jauh lebih sedikit daripada L1. Di sisi lain, data harus dipublikasikan ke L1. Jadi perbandingannya bukan 21k gas vs 15k gas; itu 21k L2 gas vs 100k L1 gas. Kita dapat menghitung artinya dengan melihat perbandingan antara biaya gas L1 dan biaya gas L2:
Saat ini, L1 15-25 kali lebih mahal daripada L2 untuk pengiriman sederhana dan 20-50 kali lebih mahal untuk pertukaran token. Pengiriman sederhana adalah jumlah data yang relatif besar, tetapi perhitungan jumlah pertukaran jauh lebih besar. Oleh karena itu, swap adalah tolok ukur yang lebih baik untuk perkiraan biaya perhitungan L1 versus perhitungan L2. Mempertimbangkan semua ini, jika kita mengasumsikan rasio biaya 30x antara biaya komputasi L1 dan biaya komputasi L2, ini tampaknya menyiratkan bahwa biaya untuk menempatkan bukti Merkle pada L2 dapat setara dengan 50 transaksi reguler. Tentu saja, menggunakan pohon Merkle biner mengurangi biaya dengan faktor ~4, tetapi meskipun demikian, dalam kebanyakan kasus, biayanya terlalu tinggi - jika kita rela berkorban karena tidak lagi kompatibel dengan pohon status heksagonal Ethereum saat ini, kita Cari opsi yang lebih baik.
5. Bagaimana cara kerja pembuktian 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. ZK-SNARK membutuhkan ~400.000 GAS untuk perhitungan, yang memakan waktu sekitar 400 byte (dibandingkan dengan: transaksi dasar membutuhkan 21.000 gas dan 100 byte, yang dapat dikurangi menjadi ~25 kata setelah kompresi di Festival mendatang). Oleh karena itu, dari sudut pandang komputasi, biaya ZK-SNARK adalah 19 kali lipat dari biaya transaksi dasar saat ini, dan dari sudut pandang data, biaya ZK-SNARK adalah 4 kali lipat dari biaya transaksi dasar saat ini dan 16 kali biaya transaksi dasar di masa mendatang. Angka-angka itu merupakan peningkatan besar dibandingkan bukti Merkel, tetapi harganya masih cukup mahal. Ada dua cara untuk memperbaikinya: (i) bukti KZG tujuan khusus, atau (ii) agregasi, mirip dengan agregasi ERC-4337 tetapi menggunakan matematika yang lebih bagus. Kita bisa belajar keduanya sekaligus.
6. Bagaimana cara kerja pembuktian KZG tujuan khusus?
Peringatan, bagian ini lebih matematis daripada yang lain. Ini karena kami bergerak di luar alat tujuan umum, dan membangun beberapa alat tujuan khusus yang lebih murah, jadi kami harus lebih "bersembunyi". Jika Anda tidak menyukai matematika mendalam, langsung lompat ke bagian berikutnya. Pertama, rekap tentang cara kerja komitmen KZG: Kami dapat mewakili satu set data [D_1...D_n] menggunakan bukti KZG dari polinomial yang diturunkan dari data: khususnya, polinomial P, di mana P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n.w di sini adalah "akar seragam", nilai wN = 1 untuk beberapa ukuran domain evaluasi N (ini semua dilakukan dalam bidang terbatas). Untuk "berkomitmen" ke P, kita membuat titik kurva elips com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk. Di Sini: -G adalah titik generator untuk kurva -Pi adalah koefisien ke-i dari polinomial P -Si adalah titik ke-i dalam pengaturan tepercaya 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 elips pada bukti com(Q) dan komitmen polinomial com(P): kami memeriksa e(com(Q) ), com( X - z)) ? = e(com(P) - com(a), com(1)) Beberapa properti utama yang perlu diketahui meliputi:
Oleh karena itu, bukti lengkap membutuhkan:
7. Bagaimana cara kerja pohon Verkle?
Pohon Verkle pada dasarnya melibatkan penumpukan komitmen KZG (atau komitmen IPA, yang bisa lebih efisien dan menggunakan enkripsi yang lebih sederhana): untuk menyimpan 2⁴⁸ nilai, Anda membuat komitmen KZG ke daftar nilai 2²⁴, yang masing-masing merupakan Komitmen KZG untuk 2²⁴ Nilai. Pohon Verkle sangat dipertimbangkan untuk pohon status Ethereum, karena Pohon Verkle dapat digunakan untuk menyimpan pemetaan nilai kunci, bukan hanya daftar (pada dasarnya, Anda dapat membuat pohon berukuran 2²⁵⁶ tetapi mulai kosong, hanya jika Anda Hanya mengisi bagian tertentu dari pohon saat Anda benar-benar perlu mengisinya).
Seperti apa pohon Vicker itu. Nyatanya, Anda dapat memberikan setiap node lebar 256 == 2⁸ untuk pohon berbasis IPA, dan 2²⁴ untuk pohon berbasis KZG. Bukti di pohon Verkle agak lebih panjang daripada di KZG; panjangnya bisa ratusan byte. Mereka juga sulit diverifikasi, terutama jika Anda mencoba menggabungkan banyak bukti menjadi satu. Sebenarnya, pohon Verkle harus dianggap seperti pohon Merkle, tetapi lebih layak tanpa SNARKing (karena biaya data lebih rendah), dan SNARKing lebih murah (karena biaya bukti lebih rendah). Keuntungan terbesar dari pohon Verkle adalah mereka dapat mengoordinasikan struktur data: Bukti Verkle dapat digunakan langsung untuk status L1 atau L2, tidak memiliki struktur superposisi, dan menggunakan mekanisme yang persis sama untuk L1 dan L2. Setelah komputer kuantum menjadi masalah, atau setelah percabangan Merkle terbukti cukup efisien, pohon Verkle dapat diganti di tempat dengan pohon hash biner dengan fungsi hash ramah-SNARK yang sesuai.
8. Agregat
Jika N pengguna melakukan N transaksi (atau lebih realistis, N ERC-4337 UserOperations) perlu membuktikan N klaim lintas rantai, kami dapat menghemat banyak uang dengan menggabungkan bukti ini: menggabungkan transaksi ini ke dalam satu blok atau Pembuat bundel yang masuk ke blok dapat membuat bukti yang membuktikan semua klaim ini pada saat yang bersamaan. Ini bisa berarti:
Diagram dari postingan implementasi dompet BLS yang menunjukkan alur kerja untuk tanda tangan agregat BLS di versi awal ERC-4337. Alur kerja untuk menggabungkan bukti lintas rantai mungkin terlihat sangat mirip.
9. Membaca status langsung
Kemungkinan terakhir, juga hanya tersedia untuk L2 yang membaca L1 (dan bukan L1 yang membaca L2), adalah memodifikasi L2 sehingga mereka langsung melakukan panggilan statis ke kontrak di L1. Hal ini dapat dilakukan dengan opcode atau prakompilasi, yang memungkinkan panggilan ke L1, di mana Anda memberikan alamat target, gas, dan data panggilan, dan mengembalikan output, tetapi karena panggilan ini statis, mereka tidak dapat benar-benar mengubah keadaan L1 apa pun. L2 harus tahu bahwa L1 telah memproses deposit, jadi tidak ada yang mencegah penerapan hal seperti itu; ini sebagian besar merupakan tantangan implementasi teknis (lihat: ini dari RFP yang optimis untuk mendukung panggilan statis ke L1). Perhatikan bahwa jika keystore ada di L1, dan L2 mengintegrasikan panggilan statis L1, tidak diperlukan pengesahan sama sekali! Namun, jika L2 tidak mengintegrasikan panggilan statis L1, atau jika keystore ada di L2 (yang pada akhirnya harus dilakukan setelah L1 menjadi terlalu mahal bagi pengguna untuk digunakan meski hanya sedikit), maka bukti akan diperlukan.
10. Bagaimana L2 mempelajari root status Ethereum terbaru?
Semua skema di atas memerlukan L2 untuk mengakses akar status L1 terdekat atau seluruh status L1 terdekat. Untungnya, semua L2 sudah memiliki beberapa fungsi untuk mengakses status L1 terbaru. Ini karena mereka membutuhkan fungsionalitas seperti itu untuk menangani pesan dari L1 ke L2, terutama deposit. 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 meneruskannya ke L2 sebagai pesan deposit . Header blok lengkap dapat diterima di sisi L2 dan akar statusnya diekstraksi. 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:
Blok rantai L2 dapat bergantung tidak hanya pada blok L2 sebelumnya, tetapi juga pada blok L1. Jika L1 pulih melalui tautan seperti itu, L2 juga akan pulih. Perlu dicatat bahwa ini juga cara kerja versi sharding sebelumnya (pra-Dank); lihat di sini untuk kodenya.
11. Berapa banyak koneksi ke Ethereum yang diperlukan rantai lain untuk menyimpan keystore yang di-root di dompet Ethereum atau L2?
Anehnya, tidak banyak. Sebenarnya tidak perlu rollup: jika itu L3 atau validasi, tidak apa-apa menyimpan dompet di sana, selama Anda menahan keystore pada rollup L1 atau ZK. Apa yang benar-benar Anda butuhkan adalah rantai untuk memiliki akses langsung ke root status Ethereum, dan komitmen teknis dan sosial untuk bersedia mengatur ulang jika Ethereum melakukan reorganisasi, dan melakukan hard fork jika Ethereum melakukan hard fork. Pertanyaan penelitian yang menarik adalah untuk menentukan sejauh mana suatu rantai dapat memiliki bentuk koneksi ini dengan beberapa rantai lainnya (mis. Ethereum dan Zcash). Melakukan hal ini secara naif adalah mungkin: jika Ethereum atau Zcash mengatur ulang, rantai Anda dapat setuju untuk mengatur ulang (dan hard fork jika hard fork Ethereum atau Zcash), tetapi operator node Anda dan komunitas Anda biasanya memiliki dua kali ketergantungan teknologi dan politik. Oleh karena itu, teknik ini dapat digunakan untuk menyambung ke beberapa rantai lain, tetapi dengan biaya yang meningkat. Skema berbasis jembatan ZK memiliki sifat teknis yang menarik, tetapi kelemahan utama mereka adalah bahwa mereka tidak kuat terhadap serangan 51% atau hard fork. Mungkin ada solusi yang lebih cerdas juga.
12. Perlindungan privasi
Idealnya, kami juga ingin menjaga privasi. Jika Anda memiliki banyak dompet yang dikelola oleh keystore yang sama, kami ingin memastikan bahwa:
Tantangan utama dengan pendekatan ini saat ini adalah agregasi membutuhkan agregator untuk membuat SNARK rekursif, yang saat ini sangat lambat. Dengan KZG, kita dapat menggunakan karya ini (lihat juga: versi yang lebih formal dari karya ini di makalah Caulk) pada bukti KZG yang tidak diindeks sebagai titik awal. Namun, agregasi bukti buta merupakan masalah terbuka yang memerlukan perhatian lebih. Sayangnya, membaca L1 langsung dari dalam L2 tidak menjaga privasi, meskipun penerapan fungsi baca langsung masih sangat berguna, baik untuk meminimalkan latensi maupun karena kegunaannya untuk aplikasi lain.
13. Ringkasan
Untuk memiliki dompet pemulihan sosial lintas rantai, alur kerja yang paling realistis adalah dompet yang menyimpan keystore di satu lokasi, dan dompet yang memelihara dompet di banyak lokasi, di mana dompet membaca keystore untuk (i) memperbarui kunci autentikasinya secara lokal lihat, atau (ii) dalam proses memvalidasi setiap transaksi. Elemen kunci yang memungkinkan hal ini adalah bukti lintas rantai. Kita perlu bekerja untuk mengoptimalkan bukti-bukti ini. Solusi ZK-SNARK atau KZG khusus yang menunggu bukti Verkle tampaknya menjadi opsi terbaik. Dalam jangka panjang, protokol agregasi (di mana bundler menghasilkan bukti agregat sebagai bagian dari pembuatan bundel dari semua tindakan pengguna yang dikirimkan oleh pengguna) diperlukan untuk meminimalkan biaya. Ini mungkin harus diintegrasikan ke dalam ekosistem ERC-4337, meskipun mungkin diperlukan perubahan pada ERC-4337. L2 harus dioptimalkan untuk meminimalkan latensi pembacaan status L1 (atau setidaknya root status) dari dalam L2. Sangat ideal untuk L2 untuk membaca status L1 secara langsung, menghemat ruang bukti. Dompet tidak hanya dapat berada di L2; Anda juga dapat menempatkan dompet pada sistem dengan tingkat konektivitas yang lebih rendah ke Ethereum (L3, atau bahkan hanya setuju untuk memasukkan root status Ethereum dan rantai garpu independen). Namun, keystore harus berada di L1 atau L2 rollup ZK keamanan tinggi. Menggunakan L1 menghemat banyak kerumitan, tetapi bahkan itu bisa menjadi terlalu mahal dalam jangka panjang, jadi keystore perlu digunakan di L2. Mempertahankan privasi akan membutuhkan kerja ekstra dan membuat pilihan tertentu menjadi lebih sulit. Namun, kita mungkin harus beralih ke solusi yang menjaga privasi, setidaknya memastikan bahwa apa pun yang kita hasilkan kompatibel dengan menjaga privasi.