Penulis: ChiHaoLu (chihaolu.eth) Sumber: medium Terjemahan: Shanoba, Golden Finance

Artikel ini berfokus pada pengembangan Account Abstraction (AA) dalam solusi Aztec Layer 2 dan konten terkait. Saya mengutip sejumlah sumber daya resmi Aztec, termasuk dokumentasi resmi, blog, dan tutorial. Silakan temukan sumber daya yang sangat baik ini di bagian referensi di akhir artikel!

Latar belakang

Karena meningkatnya kompleksitas Aztec dibandingkan dengan implementasi AA Asli lainnya di ZK-Rollups, pembaca dapat mengambil manfaat dari memiliki beberapa konteks untuk lebih memahami artikel ini.

• Keakraban dengan dompet kontrak pintar dan fitur-fiturnya
• Keakraban dengan EIP-4337
• Keakraban dengan abstraksi akun asli di ZK-Rollups
• Konsep dasar UTXO
• Konsep dasar ZK-Rollups
• Konsep dasar program bukti tanpa pengetahuan

Pendahuluan

Lihatlah Aztec

Aztec adalah jaringan Layer 2 open-source yang dirancang untuk memberikan skalabilitas dan perlindungan privasi untuk Ethereum. Aztec memanfaatkan bukti zkSNARK untuk memberikan perlindungan privasi dan skalabilitas melalui layanan ZK-Rollup. Pengguna Aztec tidak memerlukan pihak ketiga tepercaya atau mekanisme konsensus tambahan untuk mengakses transaksi pribadi.

Kita semua tahu bahwa dalam ZK-Rollups tradisional, “ZK” tidak selalu berarti privasi; Ini berarti menggunakan zero-knowledge proofs (ZKPs) untuk membuktikan bahwa perhitungan tertentu telah dilakukan dengan benar di luar rantai. Namun, di Aztec, privasi diterapkan di ZK-Rollup selain skalabilitas. Menggali lebih dalam, di masa lalu, rincian setiap transaksi terlihat secara on-chain oleh publik, tetapi di Aztec, input dan output dari setiap transaksi dienkripsi. Transaksi ini diverifikasi oleh ZKP untuk membuktikan bahwa informasi yang dienkripsi akurat dan berasal dari plaintext. Hanya pengguna yang membangun transaksi pribadi ini yang mengetahui informasi plaintext yang sebenarnya.

Bahkan karakter penting dalam ZK-Rollup, seperti Sequencer dan Prover, tidak dapat menentukan apa plaintext itu. Semua informasi tentang transaksi, termasuk pengirim, penerima, data transaksi, dan nilai transfer, disembunyikan. Meskipun hanya pengguna sendiri yang mengetahui detail transaksi, mereka masih dapat mempercayai kebenaran transaksi. Keyakinan ini berasal dari fakta bahwa hanya transaksi yang sah yang dapat menghasilkan bukti tanpa pengetahuan yang valid untuk membuktikan keakuratannya.

Bagaimana menerapkan transaksi pribadi dan bagaimana memverifikasi fundamental mereka adalah topik besar yang berada di luar cakupan artikel ini. Secara sederhana, yang kita butuhkan adalah “lapisan tambahan untuk verifikasi bukti tanpa pengetahuan” untuk memvalidasi daftar ZKP, yang masing-masing memvalidasi transaksi pribadi. Itu sebabnya mereka disebut “ZK-ZK-Rollups”.

Apa itu Noir?

Di Aztec, abstraksi akun asli digunakan, yang berarti bahwa tidak ada perbedaan antara akun milik eksternal (EOA) dan akun kontrak. Semua akun adalah kontrak pintar. Oleh karena itu, kami akan memberikan gambaran singkat tentang ekosistem pengembangan kontrak Aztec, karena sangat penting untuk memahami pengembangan kontrak. Namun, jika Anda tidak berencana untuk mengembangkan kontrak akun sendiri, maka membaca dan memahami artikel ini tidak mengharuskan Anda untuk menyalakan komputer dan menulis kontrak. Anda hanya perlu memahami logika dalam kode kontrak akun. Anda dapat menjelajahi kedalaman topik sesuai kebijaksanaan Anda sendiri!

Noir adalah bahasa untuk menulis program SNARK, mirip dengan Circcom dan ZoKrates. Tidak hanya memungkinkan Anda untuk secara otomatis menghasilkan kontrak Solidity Verifier setelah sirkuit dibuat, tetapi juga dapat digunakan untuk menulis protokol Anda sendiri atau bahkan blockchain. Karena Noir tidak sepenuhnya bergantung pada Aztec (tidak dikompilasi ke sistem bukti tertentu), Anda dapat mencapai tujuan Anda dengan menerapkan server backend dan antarmuka kontrak pintar untuk sistem bukti.

Di Aztec, Noir digunakan untuk menulis kontrak pintar di mana variabel (negara bagian) dan fungsi dapat dilindungi oleh privasi.

Apa itu Status Pribadi dan Catatan Pribadi

Menurut pemahaman kita tentang blockchain publik, biasanya semua negara bagian bersifat publik. Di Aztec, penting untuk memahami konsep negara pribadi dan cara mengelolanya (menambah, memodifikasi, menghapus). Negara pribadi dienkripsi dan dimiliki oleh pemegangnya. Misalnya, jika saya adalah pemilik kontrak, variabel tertentu dalam kontrak itu dapat dienkripsi dan disembunyikan status pribadi. Hanya saya, sebagai pemilik negara pribadi ini, yang dapat mendekripsi ciphertext untuk mendapatkan plaintext.

Status privat disimpan dengan melampirkan hanya pohon database. Hal ini dilakukan karena mengubah nilai state secara langsung dapat membocorkan banyak informasi dari diagram transaksi. Namun, database tidak secara langsung menyimpan nilai negara swasta. Sebaliknya, ia mencatatnya sebagai catatan pribadi dalam bentuk terenkripsi (misalnya, x = 0 -> x = 1) addr = 0x00 -> addr = 0x01. Jadi, pada kenyataannya, variabel-variabel pribadi ini, meskipun tampaknya merupakan variabel, sebenarnya terdiri dari sekelompok catatan pribadi yang tidak dapat diubah. Ini adalah abstraksi variabel. Jika tidak jelas, mari kita lanjutkan.

Saat Anda perlu menghapus status privat, Anda dapat menambahkan karakter tidak valid yang terkait dengan status privat tersebut ke database lain yang tidak valid untuk membatalkannya. Saat Anda perlu mengubah status privat, pertama-tama batalkan dan kemudian tambahkan komentar privat baru ke dalamnya.

Kami akan membahas konsep nullifier segera. Anda dapat menganggapnya sebagai kunci yang Anda butuhkan untuk menautkan catatan pribadi ke karakternya yang tidak valid. Hanya pemilik kunci yang tidak valid yang dapat mengidentifikasi dan menggunakan catatan pribadi yang terkait dengannya.

Pada titik ini, pembaca yang cerdas mungkin telah memperhatikan bahwa struktur ini sangat mirip dengan UTXO (output transaksi yang tidak terpakai), dan kita dapat mengulangi UTXO untuk menentukan keadaan negara swasta saat ini (meskipun penting untuk diingat bahwa penggunalah yang menandatangani transaksi, bukan UTXO; Kami akan menjelaskannya nanti).

! [TEg3TOpeZXF82AgjnmG7in3uwiZp3ZtIpGsNQvxc.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-2ad04801d9-dd1a6f-cd5cc0.webp “7128680”)

Apa itu Catatan Pribadi? UTXO disebut Catatan, dan kami melintasi Pohon Catatan ini untuk mendapatkan informasi tentang negara pribadi. Ketika kita ingin mengubah private state, langkah-langkahnya adalah sebagai berikut:

1. Pengguna mengambil semua catatan pribadi yang terkait dengan status pribadi tersebut dari database catatan.
2. Pengguna (yang sebenarnya adalah node Aztec yang dijalankan pengguna) membuktikan secara lokal keberadaan setiap anotasi yang diambil di pohon DB ini.
3. Pengguna menambahkan karakter yang tidak valid untuk mencegah orang lain membaca daun yang sama lagi.
4. Pengguna memasukkan daun baru (komentar baru) untuk memperbarui nilai status pribadi ini.

Mekanisme AA Aztec

Apa itu lapisan protokol dan apa lapisan aplikasinya?

Seperti yang kita semua tahu, EIP-4337 bertujuan untuk memindahkan seluruh proses transaksi ke lapisan aplikasi, menerapkan sistem relai terbuka, dan mengabstraksi tanda tangan (mekanisme verifikasi) dan model pembayaran melalui sifat kontrak pintar yang dapat diprogram. Namun, untuk Abstraksi Akun Asli, baik di era StarkNet, zkSync, atau Aztec, yang merupakan fokus artikel ini, elemen-elemen tertentu perlu terukir ke dalam protokol Layer 2 agar berfungsi dengan baik. Misalnya, di Aztec, kunci enkripsi dan kunci yang tidak valid perlu diimplementasikan di tingkat protokol.

Memahami abstraksi akun asli membutuhkan pemahaman yang lebih dalam tentang bagaimana seluruh rantai bekerja (dengan asumsi itu disebut “asli”, dengan logika eksekusi AA secara alami terkait dengan protokol Layer2 tertentu). Misalnya, di era zkSync, ada kebutuhan untuk memahami kontrak sistem, di StarkNet, ada kebutuhan untuk memahami cara kerja sequencer, dan di Aztec, sangat penting untuk memahami peran “kunci dan keadaan pribadi yang mendasarinya”.

Titik masuk akun dan fase verifikasi

Di Aztec, tidak seperti implementasi abstraksi akun lainnya, tidak ada nama fungsi yang didefinisikan secara ketat (tanda tangan fungsi) sebagai titik masuk ke kontrak akun (misalnya, validateUserOp di EIP-4337, validateTransactionzkSync Era, dan __validate__StarkNet). Pengguna bebas memilih fungsi apa pun dalam kontrak akun sebagai titik masuk dan mengirim transaksi dengan parameter yang relevan.

Fungsi yang dipilih oleh pengguna (kita menyebutnya entrypoint()) harus bersifat pribadi (dijalankan di lingkungan eksekusi pribadi pengguna). Itu hanya dapat dipanggil dari klien pemilik kontrak akun (dompet pengguna). Ketika entrypoint() dompet pengguna dieksekusi secara lokal, itu juga menghasilkan bukti tanpa pengetahuan. Pengesahan ini menginformasikan protokol Aztec dari fase verifikasi bahwa eksekusi off-chain telah terjadi dan telah berhasil.

Batasan fase validasi

Ini juga meluas ke pertanyaan apakah akan memberlakukan pembatasan pada apa yang dapat dilakukan selama fase validasi atau tidak. Sudah diketahui bahwa karena tidak ada batasan biaya untuk memvalidasi transaksi (pada dasarnya, memvalidasi transaksi adalah tampilan fungsi), penyerang dapat melakukan serangan denial-of-service (DOS) pada mempool untuk membahayakan bundler (EIP-4337) atau operator / sequencer (AA asli). EIP-4337 mendefinisikan opcode mana yang dilarang dan bagaimana akses penyimpanan dibatasi. zkSync Era melonggarkan beberapa penggunaan OpCode, sementara StarkNet tidak mengizinkan panggilan kontrak eksternal sama sekali.

Karena protokol Aztec melibatkan klien memvalidasi bukti tanpa pengetahuan terlampir, daripada benar-benar memanggil fungsi validasi untuk menentukan bahwa hasilnya adalah atau , trueAztecfalse, tidak seperti protokol lain, tidak memberlakukan batasan apa pun selama fase validasi. Titik masuk kontrak di akun dapat dengan bebas memanggil kontrak lain, mengakses penyimpanan apa pun, dan melakukan perhitungan apa pun.

Alur Interaksi

Secara lebih rinci, di zkSync Era dan StarkNet, hanya “kontrak akun” yang dapat memulai transaksi, karena protokol memanggil fungsi tertentu sebagai titik masuk, memberlakukan pembatasan ini. Namun, di Aztec, “semua kontrak” dapat memulai transaksi, karena tidak ada batasan fungsi mana yang disebut protokol sebagai titik masuk. Ini berarti bahwa di Aztec, ini bukan lagi aliran interaksi tetap di mana pengguna mengirim transaksi ke peran tertentu (seperti kontrak EntryPoint di EIP-4337 atau sequencer / operator di Native AA) dan kemudian memanggil kontrak target. Pengguna dapat mengirim transaksi melalui dompet, dan langsung membiarkan kontrak target menyelesaikan interaksi yang relevan, yang sangat meningkatkan fleksibilitas.

Jika Anda terbiasa dengan EIP-2938, implementasi AA lainnya, Anda akan menemukan bahwa Aztec lebih mirip dengan pendekatan multi-tenant di dalamnya. Namun, ini adalah topik yang lebih dalam yang dapat Anda jelajahi sendiri.

Kunci di akun Aztec Anda

Di Aztec, setiap akun biasanya memiliki dua kunci master: kunci penandatanganan dan kunci master privasi.

Kunci penandatanganan

Kunci penandatanganan digunakan untuk mewakili otorisasi pengguna untuk melakukan tindakan tertentu menggunakan kunci privat. Contoh sederhana adalah ketika pengguna merekam kunci publik yang berasal dari kunci penandatanganan dalam kontrak akun. Tanda tangan yang dihasilkan kemudian dapat dipulihkan dalam kontrak dengan menandatangani transaksi atau pesan menggunakan kunci penandatanganan ini untuk memeriksa apakah cocok dengan kunci publik yang dicatat dalam kontrak (juga dikenal sebagai kunci yang dikendalikan pemilik, yang disimpan dalam bentuk kunci). kontrak dompet addressSolidity).

Pilihan algoritma untuk kurva elips tanda tangan digital terserah pengguna. Misalnya, Ethereum menggunakan secp256k1, sementara Aztec memberikan contoh schnorr untuk digunakan. Dalam kontrak akun, fungsi entrypoint() bertindak sebagai titik masuk (sumber panggilan) dan digunakan oleh logika validasi (is_valid_impl()) untuk memeriksa apakah tanda tangan Schnorr cocok dengan kunci publik record std::schnorr::verify_signature(…).

! [eWwFvxmMF7pNt0axLcucSvjcig6QHMXl2HKH3luz.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-3454e57f80-dd1a6f-cd5cc0.webp “7128683”)

Kunci penandatanganan pada dasarnya sama dengan kunci yang dikendalikan pemilik di dompet kontrak pintar yang kita kenal, jadi seharusnya relatif mudah dimengerti. Bahkan, kunci penandatanganan tidak mutlak diperlukan. Jika developer akun telah menerapkan mekanisme verifikasi yang berbeda, akun mungkin tidak memiliki kunci penandatanganan.

Kunci Master Privasi

Kunci master privasi di akun Aztec Anda tidak dapat dipindahtangankan; Setiap akun Aztec terikat dengan kunci master pribadi. Kunci master pribadi berasal dari kunci master publik, yang kemudian di-hash dengan kode kontrak untuk menghasilkan alamat kontrak akun.

! [9WujRrvfd8YccfQkh9kbCtz0O1GVAKvNVJI7kXtm.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-709665cdb6-dd1a6f-cd5cc0.webp “7128684”)

Kami public_master_key account_address, partial_address, dan kolektif pengguna sebagai alamat lengkap akun. Ketika berhadapan dengan negara pribadi, pengguna perlu memberikan tiga informasi ini sehingga siapa pun dapat memverifikasi bahwa kunci publik sesuai dengan alamat yang dimaksud.

Namun, jika itu adalah aplikasi public_master_key yang tidak bermaksud menangani negara pribadi dan hilang (misalnya DeFi), Anda cukup mengisi bidang public_master_key 0 untuk menunjukkan bahwa ia tidak ingin menerima catatan pribadi.

Jadi, sementara Aztec memungkinkan kami untuk menerapkan mekanisme verifikasi dan bahkan beberapa mekanisme pemulihan dalam kontrak akun untuk meningkatkan keamanan akun, mekanisme yang terkait dengan kunci master privasi dicetak dalam protokol dan diikat ke alamat. Oleh karena itu, tidak dapat dipertukarkan.

Implikasinya di sini adalah bahwa kunci ini sama pentingnya dengan kunci pribadi EOA (akun milik eksternal) di Ethereum, menjadikannya satu titik kegagalan (SPoF) untuk sebuah akun. Jika pengguna kehilangan atau kunci master privasi akun dicuri, tidak ada keraguan bahwa akun tersebut tidak akan dapat dipulihkan.

Kunci master privasi juga menggunakan proses yang mirip dengan BIP-32 untuk mengekspor kunci enkripsi dan kunci yang tidak valid. Pengguna dapat menggunakan kunci enkripsi yang berbeda dan kunci yang tidak valid dalam aplikasi atau tindakan yang berbeda untuk memastikan privasi dan keamanan.

Kunci enkripsi

Kunci publik dari kunci enkripsi digunakan untuk mengenkripsi catatan pribadi, sedangkan kunci pribadi digunakan untuk mendekripsinya. Misalnya, dalam skenario transfer token, jika saya (pengirim token) ingin mentransfer token ke teman saya (penerima token), saya perlu mengenkripsi catatan pribadi (transfer token melibatkan perubahan variabel, pada dasarnya keseimbangan adalah mengubah variabel status pribadi UTXO menggunakan kunci publik kriptografi teman saya) dan mengirimkannya.

Dari sudut pandang orang luar, tanpa mengetahui kunci pribadi kriptografi penerima token, mereka tidak dapat menguraikan catatan pribadi ini atau mengetahui siapa penerima token.

Karakter null

Setiap kali catatan pribadi digunakan, karakter tidak valid yang berasal dari komentar pribadi tersebut dihasilkan (dienkripsi dengan kunci yang tidak valid). Mekanisme ini digunakan untuk mencegah pengeluaran ganda (untuk mencegah orang lain menggunakan metode yang sama untuk menentukan lokasi uang kertas atau untuk mengurangi dana dua kali) karena protokol Aztec memeriksa apakah karakter yang tidak valid unik. Untuk mencocokkan karakter yang tidak valid itu dengan catatan pribadi, kunci pribadi yang tidak valid diperlukan untuk mendekripsinya, sehingga hanya pemiliknya yang dapat menjalin hubungan antara keduanya.

Transaksi Aztec

Menjelaskan konsep transaksi di Aztec dapat menjadi tantangan karena dapat dengan mudah dikacaukan dengan UTXO (Private Notes) dan mode eksekusi transaksi di EVM dan Aztec sama sekali berbeda.

Di Aztec, setiap transaksi disiarkan dalam bentuk bukti tanpa pengetahuan (jelas untuk alasan privasi). Pengguna harus melakukan perhitungan secara lokal pada node mereka (aplikasi dompet atau klien) untuk menghasilkan bukti yang sesuai dengan transaksi, daripada hanya mengirim objek transaksi ke mempool penambang atau operator Layer 2 melalui RPC API seperti yang biasa kita lakukan.

Hash dan nonce transaksi

Saat pengguna membuat transaksi secara lokal, ada dua elemen penting:

1. Alamat Pengirim: Ini mewakili alamat kontrak akun yang memproses transaksi. Dalam kontrak akun ini, ada titik masuk yang kami sebutkan sebelumnya, yang berfungsi sebagai fungsi verifikasi bagi pihak eksternal untuk memverifikasi apakah tindakan (transaksi) diizinkan oleh pemilik akun.
2. Data muatan: Ini termasuk informasi tentang transaksi, seperti tanda tangan, alamat kontrak tujuan, nilai, data, dll.

! [xReWU4p6VrxP45q5EYNXZGAziaZhIG1DTrjeO4yD.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-c9db8c15b3-dd1a6f-cd5cc0.webp “7128688”)

Pada tingkat protokol Aztec, hash dari setiap transaksi yang valid digunakan sebagai sarana untuk mencegah transaksi yang sama dieksekusi beberapa kali. Pengembang kontrak akun dapat memutuskan apakah harus ada nonce dalam kontrak akun dan logika terkait. Misalnya, mereka dapat menetapkan persyaratan seperti memastikan bahwa bidang nonce dalam transaksi meningkat secara ketat atau bahwa transaksi dapat diproses dalam urutan apa pun.

Karena tidak ada persyaratan nonce yang ketat di tingkat protokol, Aztec tidak dapat membatalkan transaksi yang tertunda dengan mengirimkan transaksi baru dengan nonce yang sama dan biaya gas yang lebih tinggi.

Jalankan permintaan

Seperti disebutkan sebelumnya, pengguna dapat menentukan fungsi apa pun dalam kontrak akun sebagai titik masuk tergantung pada situasinya, dan operasi di Aztec tidak dikendalikan oleh objek perdagangan sederhana. Bahkan, apa yang memberi tahu akun kontrak apa yang harus dilakukan adalah objek yang disebut “permintaan eksekusi”. Objek mewakili perilaku pengguna, seperti “Panggil fungsi transfer pada kontrak dengan 0x1234 parameter berikut”.

Pengguna memulai transaksi secara lokal di dompet, di mana sender_address adalah alamat kontrak akun, yang berisi data pengkodean fungsi yang relevan dalam payload call target contract transfer(), dan tanda tangan yang dapat diverifikasi oleh kontrak akun. Dompet mengubah kedua elemen ini menjadi permintaan eksekusi.

Dompet kemudian memasukkan catatan pribadi, kunci enkripsi, atau rahasia yang tidak valid ke mesin virtual lokal untuk mensimulasikan permintaan eksekusi ini. Selama proses simulasi, jejak eksekusi akan dihasilkan, yang akan diserahkan kepada prover untuk menghasilkan bukti tanpa pengetahuan. Bukti ini menunjukkan bahwa perhitungan ini (eksekusi fungsi pribadi) memang dilakukan secara lokal oleh pengguna.

Melalui proses ini, kita mendapatkan dua informasi: bukti dan private_data (output dari sirkuit kernel pribadi untuk transaksi ini). Dompet kemudian mengirimkan objek transaksi yang berisi dua informasi ini ke mempool Sequencer Aztec dan menyelesaikan transaksi.

ZKP berbasis klien alih-alih lingkungan eksekusi tipe EVM

Di Aztec, kami tidak hanya memasukkan semua informasi ke mesin Turing seperti EVM untuk menghasilkan status yang diperbarui. Sebaliknya, itu bergantung pada sirkuit dalam setiap Dapp untuk menentukan bagaimana informasi privasi harus bekerja. Ini berarti bahwa pengembang Dapp perlu memiliki cara untuk membuktikan keadaan variabel kontrak. Misalnya, mari kita pertimbangkan saldo pengguna dalam kontrak token ERC-20. Jika kami ingin mentransfer 10 token DAI, kontrak mungkin memiliki logika berikut:

1. Periksa apakah saldo pengirim lebih besar dari 10 DAI (yaitu, > 10 DAI).
2. Jika pengirim memiliki saldo yang cukup, karakter yang tidak valid dibuat untuk menunjukkan penghancuran 10 DAI pengirim (yang dapat mengimbangi kepemilikan pengirim atas 10 nota pribadi DAI).
3. Buat catatan pribadi baru untuk penerima.
4. Siarkan dan enkripsi semua pesan yang dikirimkan dengan 10 DAI.

Dari sudut pandang orang luar, mereka hanya dapat melihat pembatalan dan komentar baru muncul, dan semuanya dienkripsi. Jadi, semua orang tahu bahwa kesepakatan baru telah terjadi, tetapi apa yang sebenarnya terjadi di dalam hanya diketahui oleh para peserta yang terlibat.

! [B2NwqMIhntBOllrlchIWeaetEbkSSdoTARJiM27A.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-e6bc34e04b-dd1a6f-cd5cc0.webp “7128690”)

Pelajari lebih lanjut tentang kontrak akun Aztec

Dompet

Dompet di Aztec adalah bagian penting dalam mengelola interaksi pengguna dengan blockchain dan data pribadi mereka. Berikut ringkasan tugas yang harus ditangani dompet Aztec:

1. Buat akun: Dompet harus memungkinkan pengguna untuk membuat kontrak akun baru, yang pada dasarnya berarti menyebarkan kontrak akun baru di blockchain.
2. Manajemen kunci pribadi: Dompet bertanggung jawab untuk mengelola frase benih dan kunci pribadi pengguna, termasuk kunci master privasi dan kunci penandatanganan (tergantung pada desain kontrak akun). Manajemen ini juga dapat diperluas ke integrasi dompet perangkat keras.
3. Lihat akun: Pengguna harus dapat melihat akun mereka dan status terkait, termasuk saldo dan status pribadi lainnya. Ini berarti bahwa dompet perlu memelihara database lokal dari semua catatan pribadi yang terkait dengan pengguna.
4. Berinteraksi dengan Dapps: Dompet perlu memfasilitasi interaksi antara pengguna dan Dapps. Saat pengguna berinteraksi dengan Dapp, Dapp dapat meminta transaksi dikirim dari akun pengguna.
5. Persetujuan Pengguna: Dapps mungkin memerlukan persetujuan pengguna untuk menampilkan status kontrak tertentu, seperti saldo dalam kontrak token. Untuk mengekspos status ini, dompet harus dapat menerima permintaan pengguna (karena mengekspos saldo memerlukan persetujuan kunci pengguna).
6. Hasilkan bukti: Untuk mengirim transaksi atas nama pengguna, dompet harus dapat menghasilkan bukti secara lokal. Ini melibatkan pembuatan dan pemrosesan bukti tanpa pengetahuan tentang validitas transaksi.

Poin penting yang perlu diperhatikan adalah bahwa dompet perlu memindai semua blok dimulai dengan blok genesis, menggunakan kunci pengguna untuk menemukan dan mendekripsi catatan pribadi yang relevan, dan kemudian menyimpannya dalam database lokal untuk digunakan di masa mendatang. Ini sangat penting untuk memfasilitasi interaksi pengguna dan memastikan bahwa data negara pribadi dapat dikelola secara efektif.

Anda menyebutkan aspek penting lain dari Aztec, yaitu kebutuhan pengguna untuk menyiarkan alamat lengkap. Ketika dompet membuat catatan kripto untuk penerima transaksi target, dompet juga harus dapat memperoleh alamat lengkap penerima. Ini dapat dicapai dengan memasukkan atau memelihara database lokal alamat penerima secara manual. Untuk detail lebih lanjut tentang ini, silakan merujuk ke dokumentasi resmi Aztec.

Kontrak Akun

Di Aztec, tugas utama kontrak akun adalah memverifikasi tanda tangan (mengonfirmasi bahwa transaksi disahkan oleh pemilik akun, dan oleh karena itu disahkan secara lebih luas, daripada harus “diverifikasi oleh algoritma tanda tangan digital tertentu”), mengelola konsumsi gas, dan meminta kontrak lain.

Ini adalah contoh resmi dari kontrak akun Aztec menggunakan algoritma tanda tangan Schnorr. Titik masuk untuk semua transaksi adalah fungsi entrypoint() (Anda bebas memilih fungsi atau nama sebagai titik awal, tetapi dalam hal ini entrypoint() digunakan).

! [LahY9kfNGKkYkSm5ULPlReKATiTA3K5bjFGIClh0.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-be4c89f0e2-dd1a6f-cd5cc0.webp “7128692”)

Ketika kita memanggil akun entrypoint() dengan payload lampiran, entrypoint() kontrak akun akan memanggil entrypoint() pustaka akun Aztec AA().

! [OskBKScb0LqWpcTMIuhBMjeSB151sFvSWbwXl.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-c46b7b5d32-dd1a6f-cd5cc0.webp “7128697”)

Aztec tidak memerlukan kontrak akun kami untuk mengimpor ke perpustakaan akun EntrypointPayload dan Aztec AA; Anda bebas merancang logika kontrak akun Anda sendiri.

! [HNskT1CkOOPiZZaAVvqlJNf7L5VxU39Fz9ir2Ica.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-dbf6df09b4-dd1a6f-cd5cc0.webp “7128698”)

adalah konteks, objek yang tersedia di setiap fungsi dalam Aztec.nr. Berisi semua informasi kernel yang diperlukan untuk eksekusi aplikasi konteks. Dikutip dari dokumentasi resmi Aztec. - Apa latar belakangnya

Di atas adalah kode entrypoint() dari pustaka akun Aztec AA. Ini bertanggung jawab untuk menentukan apakah operasi disahkan oleh pemilik akun berdasarkan fungsi validasi () yang ditentukan pada kontrak akun _valid_impl, dan membuat panggilan yang diperlukan untuk mengimplementasikan operasi _calls yang diperlukan untuk transaksi.

Ini berarti bahwa jika Anda ingin mereferensikan pustaka AA Aztec ini, dan kontrak akun Anda tidak memiliki implementasi _valid_impl dengan tanda tangan fungsi yang sama, langkah ini akan gagal.

! [QZuhkG4BTiKMQF4hFZKGw0gi9MBlU5VGcDjyQyU9.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-92b47183b4-dd1a6f-cd5cc0.webp “7128699”)

Detail implementasi utama lainnya adalah menggunakan get_auth_witness() untuk mengambil tanda tangan. Anda bisa merujuk ke referensi di bawah ini untuk mempelajari lebih lanjut tentang cara kerja Saksi. Secara sederhana, saksi adalah “otorisasi kepada pengguna untuk melakukan apa yang ingin mereka lakukan”.

Saksi otentikasi adalah skema untuk memverifikasi operasi di Aztec, sehingga pengguna dapat mengizinkan pihak ketiga, seperti protokol atau pengguna lain, untuk melakukan tindakan atas nama mereka. Dikutip dari dokumentasi resmi Aztec. — Saksi Bersertifikat

Alasan mengapa itu disebut “saksi” daripada hanya “tanda tangan” adalah karena cara kontrak akun diverifikasi tidak selalu melibatkan verifikasi tanda tangan.

Misalnya, katakanlah ada operasi yang mentransfer 1000 token dari akun Alice ke platform DeFi. Dalam hal ini, kontrak token perlu menanyakan kontrak akun Alice untuk melihat apakah dia menyetujui “tindakan”. “Tindakan” ini membutuhkan saksi otentikasi untuk dihasilkan di dompet Alice (secara lokal), yang kemudian dapat diverifikasi melalui kontrak akunnya. Jika kontrak akun berhasil diverifikasi, kontrak token akan tahu bahwa “tindakan” telah diotorisasi.

! [WJkuu8NWicgcHvCyH08YpHhjYtTtYiP8GbRxwwKs.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-a797a836e2-dd1a6f-cd5cc0.webp “7128700”)

Kesimpulan

Sampai sekarang, Aztec belum menerapkan mekanisme biaya, dan tujuan mereka juga untuk mengabstraksi pembayaran biaya. Ini berarti bahwa agar suatu transaksi dianggap valid, ia harus membuktikan bahwa ia telah mengunci dana yang cukup untuk menutupi biayanya sendiri. Namun, itu tidak menentukan dari mana dana ini harus berasal, melakukan pembayaran atau pembayaran dalam bentuk barang dengan mudah melalui pertukaran instan.