Artikel ini terutama memperkenalkan pengembangan dan konten terkait akun abstrak (AA, akun abstrak) dalam solusi Lapisan 2 zkSync. Fokusnya ada pada tiga bagian:
Kontrak akun: jenis akun, titik masuk penting, dan poin penting terkait kontrak akun
Transaksi: metode verifikasi, metode eksekusi dan proses transaksi AA
Biaya penanganan: biaya transaksi, Paymaster
Daftar isi
kata pengantar
Ikhtisar singkat kontrak zkSync AA
Model biaya dan Paymaster di era zkSync
Ringkasan dan perbandingan
Kesimpulan
latar belakang
Familiar dengan dompet kontrak pintar dan fitur-fitur umumnya
Dapatkan gambaran umum tentang cara kerja transaksi Ethereum
Pemahaman umum tentang mode operasi EIP-4337
Pemahaman umum tentang mode operasi ZK (validitas) Rollup
Lihat Cepat zkSync
Di sini, demi kenyamanan membaca, tidak perlu memahami zkSync secara mendalam, tetapi meninjau secara singkat informasi dasar zkSync. Ada dua versi utama zkSync, versi 1.0 (zkSync Lite) dan versi 2.0 (zkSync Era).
zkSync versi 1.0 hanya mendukung EOA (akun eksternal) dan tidak mendukung kontrak pintar (hanya mendukung transfer dan pertukaran token), sedangkan zkSync 2.0 yaitu zkSync Era milik AA asli (akun abstrak) (semua jenis akun adalah kontrak, tidak ada EOA , yang merupakan perbedaan antara EOA dan akun kontrak di Ethereum), dan kompatibel dengan EVM (Ethereum Virtual Machine), dan mendukung pengembangan kontrak pintar menggunakan Rust, Yul, Vyper, Solidity, dll.
ZkSync yang disebutkan di bawah mengacu pada zkSync 2.0, yaitu zkSync Era, kecuali ditentukan lain.
Di Era zkSync, terdapat beberapa kontrak, yang dapat dipahami karena kontrak tersebut mengimplementasikan beberapa fungsi sistem operasi penting zkSync dalam kontrak pintar. Kontrak ini adalah kontrak yang telah dikompilasi sebelumnya yang belum pernah diterapkan (dijalankan langsung di node), namun semuanya memiliki alamat formal.
Saat menerapkan protokol AA, zkSync akan melakukan operasi logis dan penilaian melalui beberapa kontrak. Misalnya, ketika memverifikasi nonce, itu dinilai oleh NonceHolder, sedangkan implementasi mekanisme akun abstrak dan pengumpulan biaya dinilai oleh bootloader. Berikut ini akan diperkenalkan mereka satu per satu.
Rekap Abstraksi Akun
Konsep inti abstraksi akun dapat diringkas menjadi dua poin utama: abstraksi tanda tangan dan abstraksi pembayaran.
Tujuan dari abstraksi tanda tangan adalah untuk memungkinkan berbagai kontrak akun menggunakan skema verifikasi yang berbeda. Artinya, pengguna tidak terbatas pada algoritma tanda tangan digital yang hanya dapat menggunakan kurva tertentu, namun dapat memilih mekanisme verifikasi apa pun yang mereka suka.
Abstraksi pembayaran bertujuan untuk memberikan pengguna berbagai pilihan pembayaran transaksi. Misalnya, pembayaran dapat dilakukan menggunakan token ERC-20 dan bukan token asli, atau transaksi dapat disponsori oleh pihak ketiga, atau bahkan model pembayaran ad hoc lainnya.
Akun di zkSync 2.0 dapat memulai transaksi seperti EOA, tetapi juga dapat menggunakan kemampuan programnya untuk menerapkan logika arbitrer, seperti akun kontrak. Inilah yang kami sebut Abstraksi Akun, yang menggabungkan keunggulan dua jenis akun di Ethereum untuk membuat pengalaman menggunakan akun AA lebih fleksibel, sehingga mencapai dua tujuan di atas: abstraksi tanda tangan dan abstraksi pembayaran.
Mekanisme AA di Era zkSync
Di Era zkSync, peran terpenting zkSync AA adalah bootloader, yang merupakan Kontrak, yang terutama digunakan untuk memproses transaksi dan menjalankan mekanisme AA, sesuai dengan Kontrak EntryPoint EIP-4337. Bootloader tidak dapat dipanggil oleh pengguna (hanya dapat dipicu oleh Operator), dan belum pernah diterapkan (berjalan langsung pada node), tetapi memiliki alamat resmi (dapat digunakan untuk menerima pembayaran).
Operator adalah peran penting dalam ZK Rollup. Ini adalah Server Off-Chain terpusat. Mirip dengan Sequencer yang mungkin pernah Anda lihat, ia bertanggung jawab untuk memicu kontrak seperti bootloader dari luar.
Protokol abstraksi akun asli (seperti StarkNet, zkSync) pada dasarnya dirancang dengan mengacu pada EIP-4337. Dalam implementasi zkSync, pengguna akan mengirimkan transaksi ke Operator, dan Operator akan mengirimkan transaksi ke bootloader dan memulai a serangkaian pemrosesan.
Dari sudut pandang blok:
Ketika bootloader menerima masukan dari Operator, bootloader pertama-tama akan menentukan beberapa variabel lingkungan untuk blok tersebut (seperti harga bahan bakar, nomor blok, stempel waktu blok, dll.). Kemudian, bootloader akan membaca daftar transaksi secara berurutan, pertama menanyakan apakah kontrak akun setuju dengan transaksi tersebut (yaitu, memanggil fungsi validasi dalam mekanisme AA), dan kemudian memasukkannya ke dalam blok.
Setelah setiap transaksi diverifikasi, Operator memverifikasi apakah blok tersebut cukup besar untuk dikirim ke verifikator (atau apakah waktunya habis). Jika ukurannya cukup besar atau waktu habis, Operator menutup blok, berhenti menambahkan transaksi baru ke bootloader, dan menyelesaikan eksekusi transaksi.
Dari sudut pandang transaksi, ketika Operator memicu bootloader, bootloader akan memproses setiap transaksi secara berurutan:
Konfirmasikan apakah nonce yang sesuai dengan alamat kontrak akun pengguna adalah sah
Panggil fungsi validasi pada kontrak akun pengguna untuk verifikasi
Setelah verifikasi selesai, kontrak akun akan mengirimkan biaya bahan bakar ke alamat bootloader (atau melalui Paymaster, yang akan diperkenalkan nanti), dan bootloader akan memeriksa apakah ia telah menerima cukup uang.
Panggil fungsi ute pada kontrak akun pengguna untuk menjalankan transaksi.
Tiga langkah pertama di atas berhubungan dengan putaran verifikasi (Verification Loop) dari EIP-4337, dan langkah keempat berhubungan dengan putaran eksekusi (ution Loop) dari EIP-4337.
Berikut ini terutama merupakan pengenalan ikhtisar, dan detail serta peran setiap langkah akan diuraikan satu per satu dalam uraian terperinci berikut.
Ikhtisar singkat kontrak akun abstrak zkSync
Tidak Sekali
Nonce akun zkSync dicatat dalam kontrak sistem bernama NonceHolder, yang mengingat apakah setiap pasangan (akun_alamat, nonce) digunakan dengan pemetaan (mapping) untuk menilai apakah nonce itu sah.
Berdasarkan penjelasan di atas, langkah pertama setelah Operator memicu bootloader adalah memeriksa nonce. Oleh karena itu, sebelum setiap transaksi dimulai, NonceHolder akan digunakan untuk mengonfirmasi apakah kumpulan nonce yang digunakan saat ini sah (saat ini hanya memeriksa apakah telah digunakan). Jika nonce tersebut sah maka akan memasuki tahap verifikasi (Verification Phase), yang mana pada saat itu nonce akan ditandai sebagai sudah dipakai, jika tidak sah maka transaksi (verifikasi) akan gagal.
Poin penting tentang nonce zkSync saat ini:
Meskipun saat ini pengguna dapat mengirim beberapa transaksi dengan nonce berbeda ke akun untuk dieksekusi pada saat yang sama, karena zkSync tidak mendukung pemrosesan paralel, transaksi dengan nonce berbeda akan tetap diproses secara berurutan.
Secara teori, pengguna dapat menggunakan bilangan bulat bukan nol 256-bit apa pun sebagai nonce, namun zkSync tetap merekomendasikan penggunaan incrementNonceIfEquals sebagai cara mengelola nonce untuk memastikan bahwa nonce bertambah secara berurutan (saat ini mekanisme AA zkSync hanya mengonfirmasi nonce yang tidak digunakan, Namun yang resmi dokumen menunjukkan bahwa kenaikan berurutan mungkin diperlukan di masa depan).
Kontrak Akun
Kontrak akun di zkSync memiliki empat titik masuk (Entry Point) yang diperlukan berikut ini, yaitu:
validasiTransaksi: Dipanggil selama fase verifikasi untuk mengonfirmasi apakah operasi tersebut diizinkan oleh pemilik akun, di mana pengguna dapat menyesuaikan logika verifikasi mereka sendiri (seperti berbagai algoritme tanda tangan, multi-tanda tangan, dll.).
payForTransaction: Ketika biaya transaksi dibayar oleh akun ini (alih-alih menggunakan paymaster), operator akan memanggil fungsi ini untuk membayar setidaknya tx.gasprice * tx.gaslimit ETH ke alamat bootloader.
PrepareForPaymaster: Ketika biaya transaksi akan dibayar oleh Paymaster, operator akan memanggil fungsi ini untuk menyelesaikan pekerjaan persiapan sebelum berinteraksi dengan paymaster. Contoh yang diberikan oleh zkSync adalah token ERC-20 yang disetujui oleh Paymaster.
uteTransaction: Setelah tahap verifikasi berhasil dilewati dan biaya transaksi berhasil dibebankan, fungsi ini akan digunakan untuk melakukan operasi yang ingin dicapai pengguna (seperti berinteraksi dengan kontrak, pengiriman uang, dll.).
Mengenai Paymaster, besaran biaya penanganan (tx.gasprice * tx.gaslimit), dll akan dijelaskan pada bab selanjutnya.
Ada juga fungsi asuransi yang tidak penting uteTransactionFromOutside di akun zkSync. Dana dapat ditarik ke L1 menggunakan "mekanisme pelarian" ketika operasi tidak dapat dilakukan (seperti ketika generator urutan tidak responsif atau zkSync dianggap sebagai risiko regulasi). Bagian ini tidak ada kaitannya dengan protokol AA, sehingga tidak akan dijelaskan secara detail disini, Bagi yang berminat bisa mengecek dokumen resmi dan spesifikasi zkSync.
Poin Penting dan Keterbatasan Fungsi Validasi
Dalam fungsi validasiTransaksi, berbagai logika kustom dapat diimplementasikan. Misalnya, jika akun telah menerapkan standar EIP-1271, logika verifikasi di EIP-1271 dapat langsung diterapkan ke validasiTransaksi, atau merujuk ke kontrak akun multi-tanda tangan implementasi dalam dokumen resmi zkSync.
Pada saat yang sama, untuk menghindari ancaman DoS pada Fase Verifikasi EIP-4337, terdapat beberapa batasan (tidak dapat melibatkan opcode eksternal dan kedalaman terbatas, dll.), dan terdapat batasan serupa di zkSync, misalnya:
1. Logika kontrak hanya dapat menyentuh slotnya sendiri (jika alamat kontrak akun adalah A):
slot milik alamat A
slot A di alamat lain mana pun
Slot keccak256(A||X) dari alamat lain, yang dapat langsung menggunakan alamat tersebut sebagai kunci pemetaan (seperti pemetaan (alamat=>nilai)), juga setara dengan mengizinkan akses ke slot keccak256( A||X), untuk mencapai ekspansi. Misalnya saldo token pada ERC-20.
2. Logika kontrak tidak boleh menggunakan variabel global, seperti block.number
Poin-Poin Penting dan Keterbatasan dalam Menjalankan Fungsi
Yang perlu diperhatikan dalam fungsi uteTransaction adalah jika ingin melakukan panggilan sistem (Call), Anda perlu memastikan bahwa fungsi tersebut memiliki flag is. Karena kontrak sistem ini memiliki dampak yang besar pada sistem akun. Misalnya, satu-satunya cara untuk meningkatkan nonce adalah dengan berinteraksi dengan NonceHolder. Untuk menerapkan kontrak, Anda harus berinteraksi dengan ContractDeployer. Menggunakan tanda is dapat memastikan bahwa pengembang akun berinteraksi secara sadar dengan kontrak sistem.
Namun, disarankan agar Anda menggunakan pustaka ContractsCaller yang disediakan oleh zkSync untuk menghindari penanganan sendiri tanda is, dan menggunakan CallWithPropagatedRevert untuk menyelesaikan panggilan sistem.
Contoh kode di atas melibatkan interaksi dengan DEPLOYER__CONTRACT. Situasi kontrak sistem yang paling umum ditemui oleh pengembang akun adalah kami ingin menggunakan akun untuk menyebarkan kontrak. Saat ini, kami harus berinteraksi dengan kontrak sistem ContractDeployer. Dalam hal ini, pengembang akun perlu berkomunikasi dengan kontrak ContractDeployer untuk memastikan bahwa kontrak berhasil diterapkan dan melakukan operasi yang diperlukan.
Model biaya dan Paymaster di era zkSync
Biaya dan Batas Bahan Bakar
Model biaya zkSync sangat mirip dengan Ethereum, token biayanya tetap ETH. Namun, seperti solusi Layer 2 lainnya (seperti Arbitrum, Optimism), zkSync juga perlu mempertimbangkan biaya tambahan penerbitan ke L1 (biaya keamanan) selain perhitungan dasar dan biaya slot tulis. Karena harga gas yang mempublikasikan data ke L1 sangat tidak stabil, Operator zkSync menentukan parameter dinamis berikut ketika setiap blok dibuka (mulai mencatat transaksi):
gasPrice: harga gas dalam gwei, yaitu tx.gasprice pada objek transaksi yang disebutkan di atas
gasPerPubdata: Jumlah gas yang diperlukan untuk mempublikasikan satu byte data di Ethereum
Selain itu, tidak seperti EIP-4337, zkSync tidak perlu menentukan tiga batasan gas: verifikasiGas, utionGas, dan preVerificationGas, namun hanya memerlukan gasLimit untuk menutupi semua biaya di atas, sehingga pengguna perlu memastikan bahwa gasLimit cukup untuk menutupi Tahap verifikasi, tahap penggunaan dan upload data Semua biaya seperti biaya keamanan ke L1. Biaya biaya ini sudah termasuk dalam tx.gaslimit pada objek transaksi tersebut di atas.
Lipat gandakan keduanya (tx.gasprice * tx.gaslimit) untuk mendapatkan biaya transaksi yang dibayarkan ke bootloader.
Juru bayar
Paymaster terutama membayar ETH ke bootloader alih-alih kontrak akun pengguna pada tahap biaya pembayaran transaksi pengguna. Pengguna dapat memilih Paymaster dan mode pembayaran yang berbeda untuk membayar biaya penanganan, seperti (namun tidak terbatas pada):
Pembayaran token ERC-20 ke Paymaster sebelum transaksi dimulai atau setelah transaksi dijalankan
Isi ulang kontrak Paymaster dengan kartu kredit
Paymaster akan terus membayar sebagian atau seluruh biaya untuk pengguna secara gratis
Cara pengguna berinteraksi dengan Paymaster bergantung pada protokol yang berbeda, bisa terpusat atau terdesentralisasi; bisa sebelum atau sesudah transaksi; bisa menggunakan token ERC-20 atau alat pembayaran yang sah, atau bahkan gratis.
Kontrak Paymaster zkSync terutama terdiri dari dua fungsi, yaitu validasiAndPayForPaymasterTransaction (wajib) dan postTransaction (opsional), keduanya hanya dapat dipanggil oleh bootloader:
validasiAndPayForPaymasterTransaction adalah satu-satunya fungsi yang harus diterapkan di seluruh kontrak Paymaster. Ketika operator menerima transaksi dengan parameter Paymaster, berarti biaya penanganannya tidak dibayar oleh kontrak akun pengguna, tetapi oleh Paymaster. Pada titik ini, operator akan menghubungi validasiAndPayForPaymasterTransaction untuk menentukan apakah Paymaster bersedia membayar biaya transaksi. Jika Paymaster setuju, fungsi ini akan mengirimkan setidaknya tx.gasprice * tx.gaslimit ETH ke bootloader.
postTransaction adalah fungsi opsional, biasanya digunakan untuk refund (mengembalikan gas yang tidak terpakai ke pengirim). Namun, zkSync saat ini belum mendukung operasi ini.
Paymaster di zkSync akan mengeksekusi postTransaction setelah postTransaction diimplementasikan, yang berbeda dengan EIP-4337. EIP-4337 tidak akan memanggil postOp ketika validasiPaymasterUserOp tidak mengembalikan konteksnya, dan sebaliknya.
Berdasarkan contoh di atas, pengguna sekarang ingin mengirimkan transaksi yang biaya penanganannya ditanggung oleh Paymaster, prosesnya sebagai berikut:
Gunakan NonceHolder untuk mengonfirmasi apakah nonce tersebut sah
Panggil validasiTransaksi pada Kontrak Akun pengguna untuk memverifikasi bahwa transaksi tersebut diotorisasi oleh pemilik akun
Hubungi prepForPaymaster pada Kontrak Akun pengguna, yang dapat mengeksekusi, misalnya, menyetujui sejumlah Token ERC-20 tertentu ke Paymaster atau tidak melakukan apa pun
Hubungi validasiAndPayForPaymasterTransaction pada Kontrak Paymaster untuk mengonfirmasi bahwa Paymaster bersedia membayar dan membebankan biaya penanganan, dan pada saat yang sama, Paymaster akan menagih pengguna sejumlah ERC-20 (disetujui sebelumnya)
Konfirmasikan bahwa bootloader menerima jumlah biaya ETH yang benar (setidaknya tx.gasprice * tx.gaslimit)
Panggil uteTransaction pada Kontrak Akun pengguna untuk mengeksekusi transaksi yang diinginkan pengguna
Apabila Paymaster Contract melaksanakan postTransaction dan gas masih mencukupi (tidak ada out of gas error), maka jalankan postTransaction
Pada langkah terakhir, meskipun postTransaction tidak dapat dijalankan karena kesalahan kehabisan gas, transaksi AA ini dianggap berhasil, namun tindakan pemanggilan postTransaction dihilangkan.
Jika Anda mempelajari lebih dalam tentang Paymaster zkSync, Anda akan menemukan bahwa Aturan Verifikasinya sedikit berbeda dari 4337 (zkSync Paymaster dapat menginjak slot kontrak lainnya), dan ada juga berbagai jenis (seperti berbasis Persetujuan). untuk perbandingan detailnya, bagi yang berminat bisa mengacu pada dokumen resmi atau implementasi saya sebelumnya.
Ringkasan & Perbandingan
Melalui penjelasan sebelumnya, kita telah mempelajari apa saja titik masuk penting yang dimiliki kontrak akun, serta fungsi dan batasan terkaitnya. Pada saat yang sama, kami juga mempelajari fungsi kontrak sistem. Selanjutnya mari kita rangkum proses transaksi operasi otomatis (AA) di zkSync mulai dari konstruksi hingga penyelesaian, dan saya juga akan memberikan referensi lebih detail bagi yang ingin mempelajari lebih lanjut:
Pengguna menggunakan SDK atau dompet secara lokal untuk membuat objek transaksi (misalnya: dari, ke, data, nilai, dll.).
Pengguna menandatangani transaksi. Tanda tangan di sini belum tentu format EIP-712 tradisional dan tanda tangan kurva ECDSA. zkSync juga mendukung EIP-2718 dan EIP-1559. Kunci untuk memilih metode tanda tangan dan metode verifikasi adalah memverifikasi melalui fungsi verifikasi dalam kontrak akun.
Kirim transaksi yang ditandatangani ke operator melalui RPC API. Pada titik ini transaksi memasuki status tertunda. Operator meneruskan transaksi ke bootloader (memanggil fungsi processL2Tx pada kontrak bootloader), dan memulai serangkaian proses protokol AA.
Bootloader akan memeriksa apakah Nonce tersebut legal, dan menggunakan NonceHolder untuk memeriksanya.
Bootloader akan memanggil fungsi validasiTransaksi pada kontrak akun pengguna untuk mengonfirmasi bahwa transaksi telah diotorisasi oleh pemilik akun.
Ada dua cara bagi Bootloader untuk membebankan biaya, dan metode penagihan spesifik bergantung pada parameter transaksi (apakah parameter paymaster dilampirkan saat membuat objek transaksi):
a.Panggil fungsi payForTransaction dan kontrak akun untuk membebankan biaya transaksi;
b. Panggil fungsi prepForPaymaster dan validasiAndPayForPaymasterTransaction untuk memungut biaya transaksi dengan kontrak Paymaster.
"Panggil payForTransaction ke biaya kontrak dengan Akun" atau "hubungi prepForPaymaster dan validasiAndPayForPaymasterTransaction ke biaya kontrak dengan Paymaster"
Periksa apakah bootloader telah menerima setidaknya biaya transaksi tx.gasprice * tx.gaslimit.
Bootloader akan memanggil fungsi uteTransaction pada kontrak akun pengguna untuk mengeksekusi transaksi.
(Opsional) Jika menggunakan Paymaster untuk membayar biaya transaksi, bootloader akan memanggil fungsi postTransaction. Jika Paymaster tidak menerapkan postTransaction, atau bahan bakar habis, langkah ini akan dilewati.
Langkah 4.~7. di atas adalah fase verifikasi (didefinisikan dalam l2TxValidation bootloader), dan fase eksekusi langkah 8.~9. (didefinisikan dalam l2Txution bootloader).
Perbandingan Era EIP-4337, StarkNet dan zkSync
Pada dasarnya proses mekanisme AA ketiganya sama, yaitu tahap verifikasi→mekanisme biaya penanganan (dibayar melalui kontrak rekening atau Paymaster)→tahap eksekusi. Perbedaan utamanya adalah:
Peran penerapan mekanisme AA adalah: perbedaan antara pembukaan di era zkSync dan dua AA lainnya adalah Operator perlu bekerja sama dengan bootloader (kontrak sistem), misalnya bootloader akan membuka blok baru dan mendefinisikan parameter blok yang relevan, dan menerima operasi Pedagang yang dikirim oleh anggota dan diverifikasi. Di 4337, bagian ini dikoordinasikan oleh Bundler dan EntryPoint, sedangkan di StarkNet, bagian ini semuanya bertanggung jawab atas Sequencer.
Apakah Biaya Gas perlu mempertimbangkan biaya keamanan L1: L2 AA perlu mempertimbangkan biaya pengunggahan data ke L1, bukan hanya ZK (Validity) Rollups Native AA yang disebutkan dalam push, tetapi juga perlu disertakan dalam L1 ketika Optimis Rollup menerapkan biaya Keamanan 4337 (dihitung dalam preVerificationGas, lihat dokumen terkait Alkimia untuk detailnya).
Apakah mungkin untuk mengirim transaksi sebelum kontrak akun diterapkan: Di era StarkNet dan zkSync, tidak ada EntryPoint seperti 4337 yang memiliki bidang initCode untuk memungkinkan pengguna menerapkan kontrak akun, sehingga tidak mengirim transaksi sebelum akun dapat dikonfigurasi.
Dibandingkan
Karena StarkNet belum merealisasikan mekanisme Paymaster, dan zkSync belum menyelesaikan desain mekanisme pengembalian bahan bakar, beberapa perbandingan yang lebih rinci tidak tercantum di sini.
Selain itu, kami telah menyelesaikan mempool P2P untuk bundler 4337 saat ini, dan Sequencer dan Operator zkRollups juga merupakan satu-satunya server resmi, jadi ada komponen terpusat tertentu.
Dalam proses pengembangan, karena zkSync tidak memiliki masalah koneksi dengan berbagai bundler (hanya perlu berinteraksi dengan API Operator), 4337 mudah digunakan, dan pengalaman mengembangkan kontrak akun (SDK) juga lebih baik; di pada saat yang sama, zkSync dapat menggunakan Soliditas sebagai bahasa Pengembangan kontrak, sehingga tidak perlu melewati ambang batas Kairo dalam pengembangan StarkNet.
Kesimpulan
Karena StarkNet dan zkSync termasuk dalam kategori AA lokal (AA Asli), Anda juga dapat merujuk pada pengantar saya sebelumnya tentang StarkNet AA, yang berjudul "Pengenalan Abstraksi Akun StarkNet" (Pengenalan Abstraksi Akun StarkNet). Anda juga dapat membaca artikel lain terkait EIP-4337 untuk informasi lebih lanjut.
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Pengantar Abstraksi Akun asli di zkSync
Penulis: Ditulis oleh ChiHaoLu, imToken Labs
Artikel ini terutama memperkenalkan pengembangan dan konten terkait akun abstrak (AA, akun abstrak) dalam solusi Lapisan 2 zkSync. Fokusnya ada pada tiga bagian:
Daftar isi
latar belakang
Di sini, demi kenyamanan membaca, tidak perlu memahami zkSync secara mendalam, tetapi meninjau secara singkat informasi dasar zkSync. Ada dua versi utama zkSync, versi 1.0 (zkSync Lite) dan versi 2.0 (zkSync Era).
zkSync versi 1.0 hanya mendukung EOA (akun eksternal) dan tidak mendukung kontrak pintar (hanya mendukung transfer dan pertukaran token), sedangkan zkSync 2.0 yaitu zkSync Era milik AA asli (akun abstrak) (semua jenis akun adalah kontrak, tidak ada EOA , yang merupakan perbedaan antara EOA dan akun kontrak di Ethereum), dan kompatibel dengan EVM (Ethereum Virtual Machine), dan mendukung pengembangan kontrak pintar menggunakan Rust, Yul, Vyper, Solidity, dll.
ZkSync yang disebutkan di bawah mengacu pada zkSync 2.0, yaitu zkSync Era, kecuali ditentukan lain.
Di Era zkSync, terdapat beberapa kontrak, yang dapat dipahami karena kontrak tersebut mengimplementasikan beberapa fungsi sistem operasi penting zkSync dalam kontrak pintar. Kontrak ini adalah kontrak yang telah dikompilasi sebelumnya yang belum pernah diterapkan (dijalankan langsung di node), namun semuanya memiliki alamat formal.
Saat menerapkan protokol AA, zkSync akan melakukan operasi logis dan penilaian melalui beberapa kontrak. Misalnya, ketika memverifikasi nonce, itu dinilai oleh NonceHolder, sedangkan implementasi mekanisme akun abstrak dan pengumpulan biaya dinilai oleh bootloader. Berikut ini akan diperkenalkan mereka satu per satu.
Rekap Abstraksi Akun
Konsep inti abstraksi akun dapat diringkas menjadi dua poin utama: abstraksi tanda tangan dan abstraksi pembayaran.
Tujuan dari abstraksi tanda tangan adalah untuk memungkinkan berbagai kontrak akun menggunakan skema verifikasi yang berbeda. Artinya, pengguna tidak terbatas pada algoritma tanda tangan digital yang hanya dapat menggunakan kurva tertentu, namun dapat memilih mekanisme verifikasi apa pun yang mereka suka.
Abstraksi pembayaran bertujuan untuk memberikan pengguna berbagai pilihan pembayaran transaksi. Misalnya, pembayaran dapat dilakukan menggunakan token ERC-20 dan bukan token asli, atau transaksi dapat disponsori oleh pihak ketiga, atau bahkan model pembayaran ad hoc lainnya.
Akun di zkSync 2.0 dapat memulai transaksi seperti EOA, tetapi juga dapat menggunakan kemampuan programnya untuk menerapkan logika arbitrer, seperti akun kontrak. Inilah yang kami sebut Abstraksi Akun, yang menggabungkan keunggulan dua jenis akun di Ethereum untuk membuat pengalaman menggunakan akun AA lebih fleksibel, sehingga mencapai dua tujuan di atas: abstraksi tanda tangan dan abstraksi pembayaran.
Mekanisme AA di Era zkSync
Di Era zkSync, peran terpenting zkSync AA adalah bootloader, yang merupakan Kontrak, yang terutama digunakan untuk memproses transaksi dan menjalankan mekanisme AA, sesuai dengan Kontrak EntryPoint EIP-4337. Bootloader tidak dapat dipanggil oleh pengguna (hanya dapat dipicu oleh Operator), dan belum pernah diterapkan (berjalan langsung pada node), tetapi memiliki alamat resmi (dapat digunakan untuk menerima pembayaran).
Operator adalah peran penting dalam ZK Rollup. Ini adalah Server Off-Chain terpusat. Mirip dengan Sequencer yang mungkin pernah Anda lihat, ia bertanggung jawab untuk memicu kontrak seperti bootloader dari luar.
Protokol abstraksi akun asli (seperti StarkNet, zkSync) pada dasarnya dirancang dengan mengacu pada EIP-4337. Dalam implementasi zkSync, pengguna akan mengirimkan transaksi ke Operator, dan Operator akan mengirimkan transaksi ke bootloader dan memulai a serangkaian pemrosesan.
Dari sudut pandang blok:
Ketika bootloader menerima masukan dari Operator, bootloader pertama-tama akan menentukan beberapa variabel lingkungan untuk blok tersebut (seperti harga bahan bakar, nomor blok, stempel waktu blok, dll.). Kemudian, bootloader akan membaca daftar transaksi secara berurutan, pertama menanyakan apakah kontrak akun setuju dengan transaksi tersebut (yaitu, memanggil fungsi validasi dalam mekanisme AA), dan kemudian memasukkannya ke dalam blok.
Setelah setiap transaksi diverifikasi, Operator memverifikasi apakah blok tersebut cukup besar untuk dikirim ke verifikator (atau apakah waktunya habis). Jika ukurannya cukup besar atau waktu habis, Operator menutup blok, berhenti menambahkan transaksi baru ke bootloader, dan menyelesaikan eksekusi transaksi.
Dari sudut pandang transaksi, ketika Operator memicu bootloader, bootloader akan memproses setiap transaksi secara berurutan:
Tiga langkah pertama di atas berhubungan dengan putaran verifikasi (Verification Loop) dari EIP-4337, dan langkah keempat berhubungan dengan putaran eksekusi (ution Loop) dari EIP-4337.
Berikut ini terutama merupakan pengenalan ikhtisar, dan detail serta peran setiap langkah akan diuraikan satu per satu dalam uraian terperinci berikut.
Ikhtisar singkat kontrak akun abstrak zkSync
Tidak Sekali
Nonce akun zkSync dicatat dalam kontrak sistem bernama NonceHolder, yang mengingat apakah setiap pasangan (akun_alamat, nonce) digunakan dengan pemetaan (mapping) untuk menilai apakah nonce itu sah.
Berdasarkan penjelasan di atas, langkah pertama setelah Operator memicu bootloader adalah memeriksa nonce. Oleh karena itu, sebelum setiap transaksi dimulai, NonceHolder akan digunakan untuk mengonfirmasi apakah kumpulan nonce yang digunakan saat ini sah (saat ini hanya memeriksa apakah telah digunakan). Jika nonce tersebut sah maka akan memasuki tahap verifikasi (Verification Phase), yang mana pada saat itu nonce akan ditandai sebagai sudah dipakai, jika tidak sah maka transaksi (verifikasi) akan gagal.
Poin penting tentang nonce zkSync saat ini:
Meskipun saat ini pengguna dapat mengirim beberapa transaksi dengan nonce berbeda ke akun untuk dieksekusi pada saat yang sama, karena zkSync tidak mendukung pemrosesan paralel, transaksi dengan nonce berbeda akan tetap diproses secara berurutan.
Secara teori, pengguna dapat menggunakan bilangan bulat bukan nol 256-bit apa pun sebagai nonce, namun zkSync tetap merekomendasikan penggunaan incrementNonceIfEquals sebagai cara mengelola nonce untuk memastikan bahwa nonce bertambah secara berurutan (saat ini mekanisme AA zkSync hanya mengonfirmasi nonce yang tidak digunakan, Namun yang resmi dokumen menunjukkan bahwa kenaikan berurutan mungkin diperlukan di masa depan).
Kontrak Akun
Kontrak akun di zkSync memiliki empat titik masuk (Entry Point) yang diperlukan berikut ini, yaitu:
Mengenai Paymaster, besaran biaya penanganan (tx.gasprice * tx.gaslimit), dll akan dijelaskan pada bab selanjutnya.
Ada juga fungsi asuransi yang tidak penting uteTransactionFromOutside di akun zkSync. Dana dapat ditarik ke L1 menggunakan "mekanisme pelarian" ketika operasi tidak dapat dilakukan (seperti ketika generator urutan tidak responsif atau zkSync dianggap sebagai risiko regulasi). Bagian ini tidak ada kaitannya dengan protokol AA, sehingga tidak akan dijelaskan secara detail disini, Bagi yang berminat bisa mengecek dokumen resmi dan spesifikasi zkSync.
Poin Penting dan Keterbatasan Fungsi Validasi
Dalam fungsi validasiTransaksi, berbagai logika kustom dapat diimplementasikan. Misalnya, jika akun telah menerapkan standar EIP-1271, logika verifikasi di EIP-1271 dapat langsung diterapkan ke validasiTransaksi, atau merujuk ke kontrak akun multi-tanda tangan implementasi dalam dokumen resmi zkSync.
Pada saat yang sama, untuk menghindari ancaman DoS pada Fase Verifikasi EIP-4337, terdapat beberapa batasan (tidak dapat melibatkan opcode eksternal dan kedalaman terbatas, dll.), dan terdapat batasan serupa di zkSync, misalnya:
1. Logika kontrak hanya dapat menyentuh slotnya sendiri (jika alamat kontrak akun adalah A):
slot milik alamat A
slot A di alamat lain mana pun
Slot keccak256(A||X) dari alamat lain, yang dapat langsung menggunakan alamat tersebut sebagai kunci pemetaan (seperti pemetaan (alamat=>nilai)), juga setara dengan mengizinkan akses ke slot keccak256( A||X), untuk mencapai ekspansi. Misalnya saldo token pada ERC-20.
2. Logika kontrak tidak boleh menggunakan variabel global, seperti block.number
Poin-Poin Penting dan Keterbatasan dalam Menjalankan Fungsi
Yang perlu diperhatikan dalam fungsi uteTransaction adalah jika ingin melakukan panggilan sistem (Call), Anda perlu memastikan bahwa fungsi tersebut memiliki flag is. Karena kontrak sistem ini memiliki dampak yang besar pada sistem akun. Misalnya, satu-satunya cara untuk meningkatkan nonce adalah dengan berinteraksi dengan NonceHolder. Untuk menerapkan kontrak, Anda harus berinteraksi dengan ContractDeployer. Menggunakan tanda is dapat memastikan bahwa pengembang akun berinteraksi secara sadar dengan kontrak sistem.
Namun, disarankan agar Anda menggunakan pustaka ContractsCaller yang disediakan oleh zkSync untuk menghindari penanganan sendiri tanda is, dan menggunakan CallWithPropagatedRevert untuk menyelesaikan panggilan sistem.
Contoh kode di atas melibatkan interaksi dengan DEPLOYER__CONTRACT. Situasi kontrak sistem yang paling umum ditemui oleh pengembang akun adalah kami ingin menggunakan akun untuk menyebarkan kontrak. Saat ini, kami harus berinteraksi dengan kontrak sistem ContractDeployer. Dalam hal ini, pengembang akun perlu berkomunikasi dengan kontrak ContractDeployer untuk memastikan bahwa kontrak berhasil diterapkan dan melakukan operasi yang diperlukan.
Model biaya dan Paymaster di era zkSync
Biaya dan Batas Bahan Bakar
Model biaya zkSync sangat mirip dengan Ethereum, token biayanya tetap ETH. Namun, seperti solusi Layer 2 lainnya (seperti Arbitrum, Optimism), zkSync juga perlu mempertimbangkan biaya tambahan penerbitan ke L1 (biaya keamanan) selain perhitungan dasar dan biaya slot tulis. Karena harga gas yang mempublikasikan data ke L1 sangat tidak stabil, Operator zkSync menentukan parameter dinamis berikut ketika setiap blok dibuka (mulai mencatat transaksi):
gasPrice: harga gas dalam gwei, yaitu tx.gasprice pada objek transaksi yang disebutkan di atas
gasPerPubdata: Jumlah gas yang diperlukan untuk mempublikasikan satu byte data di Ethereum
Selain itu, tidak seperti EIP-4337, zkSync tidak perlu menentukan tiga batasan gas: verifikasiGas, utionGas, dan preVerificationGas, namun hanya memerlukan gasLimit untuk menutupi semua biaya di atas, sehingga pengguna perlu memastikan bahwa gasLimit cukup untuk menutupi Tahap verifikasi, tahap penggunaan dan upload data Semua biaya seperti biaya keamanan ke L1. Biaya biaya ini sudah termasuk dalam tx.gaslimit pada objek transaksi tersebut di atas.
Lipat gandakan keduanya (tx.gasprice * tx.gaslimit) untuk mendapatkan biaya transaksi yang dibayarkan ke bootloader.
Juru bayar
Paymaster terutama membayar ETH ke bootloader alih-alih kontrak akun pengguna pada tahap biaya pembayaran transaksi pengguna. Pengguna dapat memilih Paymaster dan mode pembayaran yang berbeda untuk membayar biaya penanganan, seperti (namun tidak terbatas pada):
Pembayaran token ERC-20 ke Paymaster sebelum transaksi dimulai atau setelah transaksi dijalankan
Isi ulang kontrak Paymaster dengan kartu kredit
Paymaster akan terus membayar sebagian atau seluruh biaya untuk pengguna secara gratis
Cara pengguna berinteraksi dengan Paymaster bergantung pada protokol yang berbeda, bisa terpusat atau terdesentralisasi; bisa sebelum atau sesudah transaksi; bisa menggunakan token ERC-20 atau alat pembayaran yang sah, atau bahkan gratis.
Kontrak Paymaster zkSync terutama terdiri dari dua fungsi, yaitu validasiAndPayForPaymasterTransaction (wajib) dan postTransaction (opsional), keduanya hanya dapat dipanggil oleh bootloader:
validasiAndPayForPaymasterTransaction adalah satu-satunya fungsi yang harus diterapkan di seluruh kontrak Paymaster. Ketika operator menerima transaksi dengan parameter Paymaster, berarti biaya penanganannya tidak dibayar oleh kontrak akun pengguna, tetapi oleh Paymaster. Pada titik ini, operator akan menghubungi validasiAndPayForPaymasterTransaction untuk menentukan apakah Paymaster bersedia membayar biaya transaksi. Jika Paymaster setuju, fungsi ini akan mengirimkan setidaknya tx.gasprice * tx.gaslimit ETH ke bootloader.
postTransaction adalah fungsi opsional, biasanya digunakan untuk refund (mengembalikan gas yang tidak terpakai ke pengirim). Namun, zkSync saat ini belum mendukung operasi ini.
Paymaster di zkSync akan mengeksekusi postTransaction setelah postTransaction diimplementasikan, yang berbeda dengan EIP-4337. EIP-4337 tidak akan memanggil postOp ketika validasiPaymasterUserOp tidak mengembalikan konteksnya, dan sebaliknya.
Berdasarkan contoh di atas, pengguna sekarang ingin mengirimkan transaksi yang biaya penanganannya ditanggung oleh Paymaster, prosesnya sebagai berikut:
Pada langkah terakhir, meskipun postTransaction tidak dapat dijalankan karena kesalahan kehabisan gas, transaksi AA ini dianggap berhasil, namun tindakan pemanggilan postTransaction dihilangkan.
Jika Anda mempelajari lebih dalam tentang Paymaster zkSync, Anda akan menemukan bahwa Aturan Verifikasinya sedikit berbeda dari 4337 (zkSync Paymaster dapat menginjak slot kontrak lainnya), dan ada juga berbagai jenis (seperti berbasis Persetujuan). untuk perbandingan detailnya, bagi yang berminat bisa mengacu pada dokumen resmi atau implementasi saya sebelumnya.
Ringkasan & Perbandingan
Melalui penjelasan sebelumnya, kita telah mempelajari apa saja titik masuk penting yang dimiliki kontrak akun, serta fungsi dan batasan terkaitnya. Pada saat yang sama, kami juga mempelajari fungsi kontrak sistem. Selanjutnya mari kita rangkum proses transaksi operasi otomatis (AA) di zkSync mulai dari konstruksi hingga penyelesaian, dan saya juga akan memberikan referensi lebih detail bagi yang ingin mempelajari lebih lanjut:
Pengguna menggunakan SDK atau dompet secara lokal untuk membuat objek transaksi (misalnya: dari, ke, data, nilai, dll.).
Pengguna menandatangani transaksi. Tanda tangan di sini belum tentu format EIP-712 tradisional dan tanda tangan kurva ECDSA. zkSync juga mendukung EIP-2718 dan EIP-1559. Kunci untuk memilih metode tanda tangan dan metode verifikasi adalah memverifikasi melalui fungsi verifikasi dalam kontrak akun.
Kirim transaksi yang ditandatangani ke operator melalui RPC API. Pada titik ini transaksi memasuki status tertunda. Operator meneruskan transaksi ke bootloader (memanggil fungsi processL2Tx pada kontrak bootloader), dan memulai serangkaian proses protokol AA.
Bootloader akan memeriksa apakah Nonce tersebut legal, dan menggunakan NonceHolder untuk memeriksanya.
Bootloader akan memanggil fungsi validasiTransaksi pada kontrak akun pengguna untuk mengonfirmasi bahwa transaksi telah diotorisasi oleh pemilik akun.
Ada dua cara bagi Bootloader untuk membebankan biaya, dan metode penagihan spesifik bergantung pada parameter transaksi (apakah parameter paymaster dilampirkan saat membuat objek transaksi):
a.Panggil fungsi payForTransaction dan kontrak akun untuk membebankan biaya transaksi;
b. Panggil fungsi prepForPaymaster dan validasiAndPayForPaymasterTransaction untuk memungut biaya transaksi dengan kontrak Paymaster.
"Panggil payForTransaction ke biaya kontrak dengan Akun" atau "hubungi prepForPaymaster dan validasiAndPayForPaymasterTransaction ke biaya kontrak dengan Paymaster"
Periksa apakah bootloader telah menerima setidaknya biaya transaksi tx.gasprice * tx.gaslimit.
Bootloader akan memanggil fungsi uteTransaction pada kontrak akun pengguna untuk mengeksekusi transaksi.
(Opsional) Jika menggunakan Paymaster untuk membayar biaya transaksi, bootloader akan memanggil fungsi postTransaction. Jika Paymaster tidak menerapkan postTransaction, atau bahan bakar habis, langkah ini akan dilewati.
Langkah 4.~7. di atas adalah fase verifikasi (didefinisikan dalam l2TxValidation bootloader), dan fase eksekusi langkah 8.~9. (didefinisikan dalam l2Txution bootloader).
Perbandingan Era EIP-4337, StarkNet dan zkSync
Pada dasarnya proses mekanisme AA ketiganya sama, yaitu tahap verifikasi→mekanisme biaya penanganan (dibayar melalui kontrak rekening atau Paymaster)→tahap eksekusi. Perbedaan utamanya adalah:
Dibandingkan
Selain itu, kami telah menyelesaikan mempool P2P untuk bundler 4337 saat ini, dan Sequencer dan Operator zkRollups juga merupakan satu-satunya server resmi, jadi ada komponen terpusat tertentu.
Dalam proses pengembangan, karena zkSync tidak memiliki masalah koneksi dengan berbagai bundler (hanya perlu berinteraksi dengan API Operator), 4337 mudah digunakan, dan pengalaman mengembangkan kontrak akun (SDK) juga lebih baik; di pada saat yang sama, zkSync dapat menggunakan Soliditas sebagai bahasa Pengembangan kontrak, sehingga tidak perlu melewati ambang batas Kairo dalam pengembangan StarkNet.
Kesimpulan
Karena StarkNet dan zkSync termasuk dalam kategori AA lokal (AA Asli), Anda juga dapat merujuk pada pengantar saya sebelumnya tentang StarkNet AA, yang berjudul "Pengenalan Abstraksi Akun StarkNet" (Pengenalan Abstraksi Akun StarkNet). Anda juga dapat membaca artikel lain terkait EIP-4337 untuk informasi lebih lanjut.