Forward the Original Title：解读Starknet智能合约模型与原生AA：特立独行的技术巨匠

Penulis Asli: Shew & Faust, Penasihat Web3: CryptoNerdCn, Pengembang Inti Starknet, Platform Pengembangan Cairo Browser-Side WASM Pendiri Cairo

Abstrak:

Fitur teknologi utama Starknet termasuk bahasa Kairo, yang kondusif untuk menghasilkan bukti ZK, AA tingkat asli, dan model kontrak cerdas di mana logika bisnis tidak bergantung pada penyimpanan negara. Kairo adalah bahasa ZK serbaguna yang dapat digunakan untuk mengimplementasikan kontrak pintar di Starknet serta mengembangkan aplikasi dengan kecenderungan tradisional. Proses kompilasinya memperkenalkan Sierra sebagai bahasa perantara, memungkinkan iterasi Kairo yang sering tanpa mengubah bytecode yang mendasarinya secara langsung. Selain itu, perpustakaan standar Kairo mencakup banyak struktur data dasar yang diperlukan untuk abstraksi akun. Kontrak pintar Starknet memisahkan logika bisnis dari penyimpanan data negara, tidak seperti rantai EVM. Penyebaran kontrak Kairo melibatkan tiga tahap: kompilasi, deklarasi, dan penyebaran, di mana logika bisnis dinyatakan dalam kelas Kontrak. Contoh kontrak yang berisi data negara dapat dikaitkan dengan kelas dan memanggil kode yang dikandungnya.

Model smart contract Starknet yang disebutkan di atas mendukung penggunaan ulang kode, penggunaan ulang status kontrak, lapisan penyimpanan, dan deteksi kontrak sampah. Ini juga mendukung realisasi penyewaan penyimpanan dan paralelisasi transaksi. Meskipun dua yang terakhir belum diimplementasikan, struktur kontrak pintar Cairo telah menciptakan “kondisi yang diperlukan” bagi keduanya. · Hanya ada akun kontrak pintar di rantai Starknet dan tidak ada akun EOA. Ini mendukung abstraksi akun AA tingkat asli dari awal. Rencana AA-nya mencakup ide-ide ERC-4337 sampai batas tertentu, memungkinkan pengguna memilih solusi pemrosesan transaksi yang sangat disesuaikan. Untuk mencegah skenario serangan potensial, Starknet telah mengambil banyak langkah antisipasi dan melakukan eksplorasi penting ke dalam ekosistem AA.

text: Setelah penerbitan token di Starknet, STRK secara bertahap menjadi elemen yang sangat diperlukan di mata pengamat Ethereum. Bintang Ethereum Layer 2 ini, yang dikenal karena sikap "independen" dan "mengabaikan pengalaman pengguna", diam-diam mengukir wilayahnya sendiri di ekosistem Layer 2 yang berkembang yang kompatibel dengan EVM. Karena pengabaiannya yang berlebihan terhadap pengguna, dan bahkan secara terbuka membuat saluran "pengemis elektronik" di Discord, Starknet pernah dikritik oleh komunitas. Di tengah tuduhan sebagai "tidak manusiawi", keahlian teknisnya yang mendalam tampak langsung didevaluasi, seolah-olah hanya UX dan penciptaan kekayaan yang merupakan segalanya. Baris dari "Kuil Paviliun Emas" - "fakta tidak dipahami oleh orang lain telah menjadi satu-satunya sumber kebanggaan saya" - hampir merupakan potret diri Starknet. Namun, mengesampingkan hal-hal sepele dunia ini, murni berdasarkan selera teknis para geek kode, Starknet dan StarkEx, sebagai pelopor ZK Rollup, hampir merupakan harta karun di mata para penggemar Kairo. Di benak beberapa pengembang game blockchain, Starknet dan Cairo hanyalah segalanya di Web3, melampaui Solidity and Move. Kesenjangan terbesar antara "geek teknis" dan "pengguna" saat ini sebenarnya sebagian besar disebabkan oleh kurangnya pemahaman orang tentang Starknet. Didorong oleh minat pada teknologi blockchain dan eksplorasi nilai Starknet, penulis artikel ini mulai dari model kontrak pintar Starknet dan AA asli untuk secara singkat menguraikan solusi teknis dan desain mekanismenya, yang bertujuan untuk menampilkan fitur teknis Starknet kepada lebih banyak orang, sementara juga berharap untuk membantu orang memahami "ranger tunggal yang disalahpahami" ini. Setelah pengantar singkat bahasa Kairo di bagian selanjutnya, kami akan fokus membahas model kontrak pintar Starknet dan abstraksi akun asli, menjelaskan bagaimana Starknet mencapai AA asli. Setelah membaca artikel ini, pembaca juga akan mengerti mengapa frasa mnemonik dari dompet yang berbeda tidak dapat dicampur di Starknet. Tetapi sebelum memperkenalkan abstraksi akun asli, pertama-tama mari kita pahami bahasa Kairo inovatif yang dibuat oleh Starknet. Dalam proses pengembangan Kairo, ada versi awal yang disebut Cairo0, diikuti oleh versi modern. Sintaks keseluruhan versi modern Kairo mirip dengan Rust dan sebenarnya adalah bahasa ZK serbaguna. Selain digunakan untuk menulis kontrak pintar di Starknet, itu juga dapat digunakan untuk pengembangan aplikasi umum. Misalnya, kita dapat mengembangkan sistem verifikasi identitas ZK menggunakan bahasa Kairo, dan program ini dapat berjalan di server kita sendiri tanpa bergantung pada jaringan StarkNet. Dapat dikatakan bahwa setiap program yang membutuhkan properti komputasi yang dapat diverifikasi dapat diimplementasikan menggunakan bahasa Kairo. Dan Kairo saat ini mungkin menjadi bahasa pemrograman yang paling kondusif untuk menghasilkan bukti ZK.

Dari perspektif proses kompilasi, Cairo menggunakan metode kompilasi berbasis bahasa intermediate, seperti yang ditunjukkan dalam gambar di bawah ini. Sierra dalam gambar adalah representasi intermediate (IR) dalam proses kompilasi bahasa Cairo, dan Sierra akan dikompilasi menjadi representasi kode biner tingkat rendah, bernama CASM, yang berjalan langsung pada perangkat node Starknet.

Memperkenalkan Sierra sebagai representasi intermediate membuat lebih mudah bagi bahasa Cairo untuk menambah fitur-fitur baru. Dalam banyak kasus, hanya perlu memanipulasi bahasa intermediate Sierra tanpa langsung mengubah kode CASM yang mendasarinya. Hal ini menghemat banyak masalah, dan klien node Starknet tidak perlu sering diperbarui. Dengan cara ini, iterasi yang sering dari bahasa Cairo dapat dicapai tanpa mengubah logika dasar StarkNet. Perpustakaan standar Cairo juga mencakup banyak struktur data dasar yang diperlukan untuk abstraksi akun. Inovasi lain dari Cairo termasuk solusi teoritis yang disebut Cairo Native, yang berencana untuk mengkompilasi Cairo menjadi kode mesin tingkat rendah yang dapat beradaptasi dengan perangkat keras yang berbeda. Node Starknet tidak perlu bergantung pada mesin virtual CairoVM saat menjalankan smart contract. Hal ini dapat sangat meningkatkan kecepatan eksekusi kode [masih dalam tahap teoritis dan belum diimplementasikan].

Model kontrak pintar Starknet: membuang logika kode dan penyimpanan status

Tidak seperti rantai yang kompatibel dengan Ethereum, Starknet telah membuat inovasi terobosan dalam desain sistem kontrak pintar nya, terutama dalam persiapan untuk AA asli dan fitur-fitur mendatang seperti pemrosesan transaksi paralel. Di sini, penting untuk memahami bahwa, berbeda dengan rantai publik tradisional seperti Ethereum, implementasi kontrak pintar di Starknet mengikuti proses yang berbeda. Mari kita ambil contoh implementasi kontrak pintar Ethereum:

1. Pengembang menulis kode kontrak pintar secara lokal dan mengompilasi program Solidity ke dalam bytecode EVM menggunakan editor. Bytecode ini kemudian dapat dipahami dan diproses langsung oleh EVM.

1. Pengembang memulai transaksi untuk mendeploy kontrak cerdas, mendeploy bytekode EVM yang telah dikompilasi ke rantai Ethereum.

Sumber: not-satoshi.com

Meskipun kontrak pintar Starknet juga mengikuti ide ​​”compile terlebih dahulu dan kemudian deploy”, Kontrak pintar dideploy di rantai dalam bentuk bytekode CASM yang didukung oleh CairoVM. Namun, ada perbedaan besar antara Starknet dan rantai yang kompatibel dengan EVM dalam metode pemanggilan dan mode penyimpanan status kontrak pintar. Secara tepat, kontrak pintar Ethereum = logika bisnis + informasi status. Misalnya, kontrak USDT tidak hanya mengimplementasikan fungsi umum seperti Transfer dan Approval, tetapi juga menyimpan status aset dari semua pemegang USDT. Kode dan status dikopelkan bersama, yang membawa banyak masalah. Pertama-tama, itu tidak mendukung upgrade kontrak DAPP dan migrasi status, juga tidak mendukung pemrosesan transaksi secara paralel. Ini merupakan beban teknis yang berat.

Menanggapi hal ini, Starknet telah meningkatkan cara status disimpan. Dalam solusi implementasi kontrak pintarnya, logika bisnis DApps sepenuhnya dipisahkan dari status aset dan disimpan secara terpisah. Manfaat dari pendekatan ini jelas: pertama, memungkinkan sistem untuk dengan cepat membedakan apakah ada penyebaran kode duplikat atau redundan. Begini cara kerjanya: di Ethereum, kontrak pintar terdiri dari logika bisnis dan data negara. Jika beberapa kontrak memiliki logika bisnis yang identik tetapi data negara yang berbeda, hash mereka juga akan berbeda, sehingga sulit bagi sistem untuk menentukan apakah "kontrak sampah" ada. Namun, dalam solusi Starknet, kode dan data status dipisahkan, sehingga memudahkan sistem untuk mendeteksi apakah kode yang sama telah digunakan beberapa kali berdasarkan hash bagian kode. Ini membantu mencegah penyebaran kode duplikat dan menghemat ruang penyimpanan pada node Starknet.

Dalam sistem kontrak pintar Starknet, penyebaran dan penggunaan kontrak dibagi menjadi tiga tahap: "kompilasi, nyatakan, dan sebarkan." Jika penerbit aset ingin menerapkan kontrak Kairo, mereka pertama-tama mengkompilasi kode Kairo tertulis ke Sierra dan formulir CASM bytecode tingkat rendah di perangkat lokal mereka. Kemudian, deployer kontrak menerbitkan transaksi "declare", menyebarkan bytecode CASM kontrak dan kode perantara Sierra ke rantai, dinamai sebagai Kelas Kontrak.

(Sumber: situs web resmi Starknet)

Kemudian, jika Anda ingin menggunakan kemampuan fungsi yang didefinisikan dalam kontrak aset, Anda dapat memulai transaksi 'deploy' melalui frontend DApp untuk mendeploy instansi Kontrak yang terkait dengan Kelas Kontrak. Instansi ini akan menyimpan status aset. Selanjutnya, pengguna dapat memanggil fungsi-fungsi dalam Kelas Kontrak untuk memodifikasi status instansi Kontrak. Sebenarnya, siapa pun yang akrab dengan pemrograman berorientasi objek seharusnya dengan mudah memahami apa yang Kelas dan Instansi wakili di Starknet. Kelas Kontrak yang dinyatakan oleh pengembang hanya berisi logika bisnis dari smart contract, terdiri dari fungsi-fungsi yang dapat dipanggil oleh siapa pun, tetapi tidak memiliki status aset aktual, sehingga tidak langsung menerapkan 'entitas aset,' hanya memiliki 'jiwa' tanpa 'tubuh.' Namun, ketika pengguna mendeploy instansi Kontrak tertentu, aset tersebut 'dimaterialisasikan.' Jika Anda perlu memodifikasi status 'entitas' aset, seperti mentransfer token Anda ke orang lain, Anda dapat langsung memanggil fungsi-fungsi yang ditulis dalam Kelas Kontrak. Proses di atas agak mirip dengan 'instansiasi' dalam bahasa pemrograman berorientasi objek tradisional (meskipun tidak sepenuhnya identik).

Setelah kontrak pintar dipisah menjadi kelas dan contoh, logika bisnis dan data status terpisah, membawa fitur-fitur berikut ke Starknet:

1. Kondusif untuk realisasi tiering penyimpanan dan "sistem penyewaan penyimpanan"

Lapisan penyimpanan yang disebutkan berarti bahwa pengembang dapat menempatkan data di lokasi yang disesuaikan sesuai dengan kebutuhan mereka sendiri, seperti di bawah rantai Starknet. StarkNet siap untuk kompatibel dengan lapisan DA seperti Celestia, dan pengembang DAPP dapat menyimpan data di lapisan DA pihak ketiga ini. Sebagai contoh, sebuah game dapat menyimpan data aset paling pentingnya di mainnet Starknet, dan menyimpan data lainnya di lapisan DA off-chain seperti Celestia. Solusi ini untuk menyesuaikan lapisan DA sesuai dengan persyaratan keamanan dinamakan “Volition” oleh Starknet.

Sistem penyewaan penyimpanan yang disebutkan berarti bahwa setiap orang seharusnya terus membayar ruang penyimpanan yang mereka tempati. Sebanyak ruang di rantai yang Anda tempati, seharusnya Anda teoretis terus membayar sewa.

Dalam model kontrak pintar Ethereum, kepemilikan kontrak tidak jelas, dan sulit untuk membedakan apakah pengembang atau pemegang aset yang seharusnya membayar "sewa" untuk kontrak ERC-20. Fungsi penyewaan penyimpanan belum diluncurkan untuk waktu yang lama, dan pengembang hanya dikenai biaya saat kontrak diterapkan. Model biaya penyimpanan ini tidak masuk akal.

Di bawah model kontrak pintar Starknet, Sui, CKB, dan Solana, kepemilikan kontrak pintar lebih jelas terbagi, sehingga lebih mudah mengumpulkan dana penyimpanan [Saat ini, Starknet tidak langsung meluncurkan sistem penyewaan penyimpanan, tetapi akan diimplementasikan di masa depan]

1. Capai penggunaan kode yang benar-benar dapat digunakan kembali dan kurangi implementasi kontrak sampah

Kita dapat mendeklarasikan kontrak token umum untuk disimpan di rantai sebagai kelas, dan kemudian semua orang dapat memanggil fungsi-fungsi dalam kelas ini untuk mendeploy instansi token mereka. Selain itu, kontrak juga dapat langsung memanggil kode dalam kelas, yang mencapai efek yang mirip dengan fungsi perpustakaan dalam Solidity. Pada saat yang sama, model kontrak pintar Starknet membantu mengidentifikasi "kontrak sampah". Ini sudah dijelaskan sebelumnya. Setelah mendukung penggunaan ulang kode dan deteksi kontrak sampah, Starknet dapat secara signifikan mengurangi jumlah data yang diunggah ke rantai dan mengurangi tekanan penyimpanan pada node sebanyak mungkin.

1. Penggunaan kembali "negara" kontrak nyata

Peningkatan kontrak di blockchain umumnya melibatkan perubahan pada logika bisnis. Dalam skenario Starknet, logika bisnis dari kontrak pintar secara inheren terpisah dari status aset. Jika instansi kontrak mengubah kelas tipe kontrak terkait, peningkatan logika bisnis dapat diselesaikan. Tidak perlu untuk memigrasi status aset ke tempat baru. Bentuk peningkatan kontrak ini lebih menyeluruh dan asli daripada Ethereum.

Untuk mengubah logika bisnis dari kontrak Ethereum, seringkali diperlukan untuk “mengoutsourcing” logika bisnis ke kontrak agensi, dan mengubah logika bisnis dari kontrak utama dengan mengubah kontrak agensi yang tergantung. Namun, metode ini tidak cukup ringkas dan tidak “asli”.

Sumber: Akademi wtf

Dalam beberapa skenario, jika kontrak Ethereum lama benar-benar ditinggalkan, status aset di dalamnya tidak dapat langsung bermigrasi ke tempat baru, yang sangat merepotkan; kontrak Cairo tidak perlu memigrasikan status dan dapat langsung "menggunakan ulang" status lama.

1. Mendorong pemrosesan transaksi secara paralel

Untuk memaksimalkan paralelisme dari instruksi perdagangan yang berbeda, langkah yang diperlukan adalah menyimpan status aset dari orang yang berbeda di lokasi terpisah, seperti yang dapat dilihat di Bitcoin, CKB, dan Sui. Prasyarat untuk tujuan di atas adalah memisahkan logika bisnis dari smart contract dari data status aset. Meskipun Starknet belum melaksanakan implementasi teknis yang mendalam mengenai transaksi paralel, ini akan menganggap transaksi paralel sebagai tujuan penting di masa depan.

Pengimplementasian kontrak AA dan akun asli Starknet

Sebenarnya, konsep abstraksi akun (AA) dan EOA (akun dimiliki secara eksternal) ditemukan oleh komunitas Ethereum sebagai konsep unik. Di banyak rantai publik baru, tidak ada perbedaan antara akun EOA dan akun kontrak pintar, menghindari kelemahan sistem akun gaya Ethereum sejak awal. Sebagai contoh, di bawah pengaturan Ethereum, pengontrol akun EOA harus memiliki ETH di rantai sebelum dia dapat memulai transaksi. Tidak ada cara untuk langsung memilih berbagai metode otentikasi, dan sangat merepotkan untuk menambahkan beberapa logika pembayaran yang disesuaikan. Beberapa orang bahkan berpikir bahwa desain akun Ethereum sederhana tidak manusiawi.

Jika kita melihat produk unggulan seperti Starknet atau zkSyncEra “Native AA” chain, jelas perbedaan dapat diamati: pertama, Starknet dan zkSyncEra memiliki tipe akun yang terpadu. Hanya ada akun kontrak pintar di rantai. Tidak ada sesuatu yang disebut akun EOA sejak awal. (Era zkSync akan mendeploy seperangkat kode kontrak secara default pada akun yang baru dibuat pengguna untuk mensimulasikan karakteristik akun EOA Ethereum, sehingga kompatibel dengan Metamask).

Namun, Starknet tidak mempertimbangkan langsung kompatibilitas dengan perangkat tambahan Ethereum seperti Metamask. Ketika pengguna menggunakan dompet Starknet untuk pertama kalinya, rekening kontrak khusus secara otomatis didirikan. Dengan kata lain, contoh kontrak yang disebutkan sebelumnya didirikan, dan contoh ini terkait dengan kelas kontrak yang didirikan sebelumnya oleh proyek dompet. Pengguna dapat langsung memanggil beberapa fungsionalitas yang tertulis dalam kelas tersebut. Sekarang, mari kita telusuri topik menarik: saat mengklaim airdrop STRK, banyak orang menemukan bahwa dompet Argent dan Braavos tidak kompatibel satu sama lain. Mengimpor mnemonik dari Argent ke Braavos tidak memungkinkan untuk mengekspor akun yang sesuai, terutama karena algoritma generasi akun yang berbeda yang digunakan oleh Argent dan Braavos, mengakibatkan alamat akun yang berbeda dihasilkan dari mnemonik yang sama. Secara khusus, dalam Starknet, alamat kontrak yang baru didirikan dapat diturunkan melalui algoritma deterministik seperti berikut ini:

Fungsi ‘pedersen()’ yang disebutkan di atas adalah algoritma hash yang mudah digunakan dalam sistem ZK. Proses pembuatan akun melibatkan penyediaan beberapa parameter khusus ke fungsi pedersen untuk menghasilkan hash yang sesuai, yaitu alamat akun yang dihasilkan. Gambar di atas menunjukkan parameter-parameter yang digunakan oleh Starknet untuk menghasilkan “alamat kontrak baru”. ‘deployer_address’ mewakili alamat “pengimplementasian kontrak”. Parameter ini dapat kosong, artinya meskipun Anda tidak memiliki akun kontrak Starknet sebelumnya, Anda masih dapat menerapkan kontrak baru. ‘salt’ adalah nilai salt yang digunakan untuk menghitung alamat kontrak, yang pada dasarnya adalah nomor acak yang diperkenalkan untuk menghindari alamat kontrak ganda. ‘class_hash’ sesuai dengan nilai hash dari kelas yang disebutkan sebelumnya, yang dikaitkan dengan instansi kontrak. ‘constructor_calldata_hash’ mewakili hash parameter inisialisasi kontrak.

Berdasarkan rumus di atas, pengguna dapat menghitung alamat kontrak yang dihasilkan sebelum mendeploy kontrak ke rantai. Starknet memungkinkan pengguna untuk mendeploy kontrak secara langsung tanpa harus memiliki akun Starknet terlebih dahulu, sebagai berikut:

1. Pengguna pertama kali menentukan contoh kontrak yang ingin mereka implementasikan dan kelas kontrak mana yang akan dikaitkannya, menggunakan hash dari kelas sebagai salah satu parameter inisialisasi, dan menghitung salt untuk menentukan alamat kontrak yang dihasilkan.
2. Setelah mengetahui di mana mereka akan mendeploy kontrak, pengguna pertama-tama mentransfer sejumlah ETH ke alamat tersebut sebagai biaya pendeployan kontrak. Umumnya, ETH ini perlu ditransfer dari L1 ke jaringan Starknet melalui jembatan lintas-rantai.
3. Pengguna memulai permintaan transaksi untuk penyebaran kontrak.

Sebenarnya, semua akun Starknet dideploy melalui proses di atas, namun sebagian besar dompet melindungi detailnya, dan pengguna tidak menyadari proses tersebut sebagai akun kontrak mereka yang dideploy begitu mereka mentransfer ETH.

Solusi di atas telah menimbulkan beberapa masalah kompatibilitas, karena ketika dompet yang berbeda menghasilkan alamat akun, hasil yang dihasilkan tidak konsisten. Hanya dompet yang memenuhi kondisi berikut yang dapat dicampur:

1. Kunci privat yang dihasilkan kunci publik yang digunakan oleh dompet sama dengan algoritma tanda tangan;
2. Proses perhitungan salt dompet sama;
3. Kelas kontrak pintar dompet tidak secara mendasar berbeda dalam detail implementasi; \

Pada kasus yang disebutkan sebelumnya, baik Argent maupun Braavos menggunakan algoritma tanda tangan ECDSA, tetapi metode perhitungan garam berbeda antara keduanya, sehingga menghasilkan alamat akun yang tidak konsisten yang dihasilkan dari mnemonik yang sama.

Sekarang, mari kita kembali ke topik abstraksi akun. Starknet dan Era zkSync telah memindahkan serangkaian proses yang terlibat dalam pemrosesan transaksi, seperti verifikasi identitas (memverifikasi tanda tangan digital) dan pembayaran biaya gas, di luar “lapisan rantai.” Pengguna dapat menyesuaikan detail implementasi logika di atas di akun mereka sendiri. Misalnya, Anda dapat mendeploy fungsi verifikasi tanda tangan digital khusus di akun kontrak pintar Starknet Anda. Ketika sebuah node Starknet menerima transaksi yang diinisiasi oleh Anda, itu akan memanggil serangkaian logika pemrosesan transaksi yang disesuaikan oleh Anda di rantai.

Pendekatan ini jelas menawarkan lebih banyak fleksibilitas. Namun, dalam desain Ethereum, logika seperti verifikasi identitas (tanda tangan digital) diharcode ke dalam kode klien node dan tidak dapat secara native mendukung fitur akun yang dapat disesuaikan.

Diagram skematis dari solusi AA asli yang ditentukan oleh arsitek Starknet. Verifikasi transaksi dan verifikasi kualifikasi biaya gas ditransfer ke kontrak on-chain untuk diproses. Mesin virtual dasar dari rantai dapat memanggil fungsi-fungsi ini yang disesuaikan atau ditentukan oleh pengguna.

Menurut pejabat zkSyncEra dan Starknet, pendekatan modular terhadap fungsionalitas akun ini terinspirasi oleh EIP-4337. Namun, yang membedakan mereka adalah bahwa zkSync dan Starknet menggabungkan jenis akun sejak awal, jenis transaksi yang disatukan, dan menggunakan titik masuk tunggal untuk menerima dan memproses semua transaksi. Sebaliknya, Ethereum, karena beban sejarah dan keinginan yayasan untuk menghindari strategi iterasi agresif seperti hard fork sebanyak mungkin, mendukung EIP-4337, menggunakan cara yang berbeda untuk memecahkan masalah tersebut. Namun, akibatnya adalah bahwa akun EOA dan solusi EIP-4337 masing-masing memiliki alur kerja pemrosesan transaksi independen, yang terlihat canggung dan merepotkan, tidak seperti kegesitan AAs asli.

Sumber: ArgentWallet

Namun, abstraksi akun asli di Starknet belum mencapai kematangan penuh. Dari sudut pandang praktis, sementara akun AA Starknet telah menerapkan algoritma verifikasi tanda tangan kustom, saat ini hanya mendukung pembayaran biaya gas dalam ETH dan STRK, dan belum mendukung pembayaran gas pihak ketiga. Oleh karena itu, kemajuan Starknet dalam AA asli dapat dijelaskan sebagai “kerangka teoritis sebagian besar sudah matang, sementara implementasi praktis masih dalam proses”. Karena Starknet hanya memiliki akun kontrak pintar secara internal, seluruh proses transaksinya mempertimbangkan pengaruh kontrak pintar akun. Pertama, setelah transaksi diterima oleh memori pool (Mempool) node Starknet, transaksi tersebut menjalani verifikasi, yang meliputi:

1. Memeriksa apakah tanda tangan digital transaksi tersebut benar, pada titik tersebut fungsi verifikasi kustom akun penandatangan dipanggil;
2. Memverifikasi apakah saldo akun inisiator dapat menutupi biaya gas. \

Perlu dicatat di sini bahwa menggunakan fungsi verifikasi tanda tangan yang disesuaikan di kontrak pintar akun berarti ada skenario serangan. Karena memori pool tidak mengenakan biaya gas saat memverifikasi tanda tangan transaksi baru. (Jika biaya gas dikenakan langsung, skenario serangan yang lebih serius akan terjadi). Pengguna jahat dapat pertama-tama menyesuaikan fungsi verifikasi tanda tangan super kompleks di kontrak akun mereka, dan kemudian memulai sejumlah besar transaksi. Ketika transaksi ini diverifikasi, mereka akan memanggil fungsi verifikasi tanda tangan kompleks yang disesuaikan, yang dapat langsung menghabiskan sumber daya komputasi node. Untuk menghindari situasi ini, StarkNet memberlakukan pembatasan berikut pada transaksi:

1. Terdapat batasan atas jumlah transaksi yang dapat dilakukan oleh seorang pengguna tunggal dalam satu unit waktu;
2. Fungsi verifikasi tanda tangan kustom dalam kontrak akun Starknet memiliki batasan kompleksitas, dan fungsi verifikasi tanda tangan yang terlalu kompleks tidak akan dieksekusi. Starknet membatasi batas konsumsi gas dari fungsi verifikasi tanda tangan. Jika jumlah gas yang dikonsumsi oleh fungsi verifikasi tanda tangan terlalu tinggi, transaksi akan langsung ditolak. Pada saat yang sama, fungsi verifikasi tanda tangan dalam kontrak akun tidak diizinkan untuk memanggil kontrak lain.

Diagram alur transaksi Starknet adalah sebagai berikut:

Perlu dicatat bahwa, untuk lebih mempercepat proses verifikasi transaksi, klien node Starknet telah secara langsung menerapkan algoritma verifikasi tanda tangan dompet Braavos dan Argent. Ketika sebuah node mendeteksi transaksi yang dihasilkan dari dua dompet Starknet utama utama ini, ia akan memanggil algoritma tanda tangan Braavos/Argent bawaan di klien. Melalui pendekatan seperti caching ini, Starknet dapat mempersingkat waktu verifikasi transaksi. Setelah data transaksi divalidasi oleh sequencer (langkah-langkah verifikasi sequencer jauh lebih menyeluruh daripada kumpulan memori), sequencer akan mengemas dan mengirimkan transaksi dari kumpulan memori ke generator bukti ZK. Transaksi yang memasuki tahap ini akan dikenakan biaya gas meskipun gagal. Namun, jika pembaca terbiasa dengan sejarah Starknet, mereka akan melihat bahwa versi Starknet sebelumnya tidak membebankan biaya untuk transaksi yang gagal. Skenario paling umum untuk kegagalan transaksi adalah ketika pengguna hanya memiliki 1 ETH tetapi mencoba untuk mentransfer 10 ETH secara eksternal, yang jelas menunjukkan kesalahan logika dan pasti akan gagal, tetapi tidak ada yang tahu hasilnya sebelum eksekusi. Namun, di masa lalu, StarkNet tidak membebankan biaya untuk transaksi yang gagal tersebut. Transaksi keliru bebas biaya ini membuang sumber daya komputasi node Starknet dan dapat menyebabkan skenario serangan DDoS. Di permukaan, membebankan biaya untuk transaksi yang salah tampaknya mudah, tetapi dalam kenyataannya, ini cukup rumit. Starknet memperkenalkan versi baru dari bahasa Cairo1 sebagian besar untuk mengatasi masalah biaya gas untuk transaksi yang gagal. Seperti yang kita semua tahu, bukti ZK adalah bukti validitas, dan hasil dari transaksi yang gagal tidak valid dan tidak dapat meninggalkan hasil keluaran pada rantai. Mencoba menggunakan bukti validitas untuk membuktikan bahwa eksekusi instruksi tertentu tidak valid dan tidak dapat menghasilkan hasil output terdengar aneh dan sebenarnya tidak bisa dijalankan. Oleh karena itu, di masa lalu, Starknet mengecualikan transaksi gagal yang tidak dapat menghasilkan hasil keluaran saat menghasilkan bukti. Tim Starknet kemudian mengadopsi solusi yang lebih cerdas dan membangun bahasa kontrak baru, Cairo1, yang memastikan bahwa "semua instruksi transaksi dapat menghasilkan hasil output dan on-chain." Pada pandangan pertama, fakta bahwa semua transaksi dapat menghasilkan hasil output berarti bahwa kesalahan logis tidak pernah terjadi. Namun, sebagian besar waktu, transaksi gagal karena mereka menemukan bug yang mengganggu eksekusi instruksi. Memastikan bahwa transaksi tidak pernah mengganggu dan berhasil menghasilkan hasil output sulit dicapai, tetapi sebenarnya ada solusi alternatif sederhana, yaitu memungkinkan transaksi menghasilkan hasil output ketika menghadapi kesalahan logika yang menyebabkan gangguan, meskipun mengembalikan nilai False yang menunjukkan bahwa eksekusi transaksi tidak lancar. Penting untuk dicatat bahwa mengembalikan nilai False juga mengembalikan hasil output, yang berarti bahwa di Cairo1, terlepas dari apakah instruksi mengalami kesalahan logika atau terganggu sementara, itu dapat menghasilkan hasil output dan menjadi on-chain. Hasil keluaran ini bisa benar atau pesan kesalahan salah. Misalnya, pertimbangkan cuplikan kode berikut:

Pada titik ini, _balances::read(from) - jumlah dapat menyebabkan kesalahan underflow, yang mengakibatkan instruksi transaksi yang sesuai terganggu dan dihentikan tanpa meninggalkan hasil transaksi pada rantai. Namun, jika ditulis ulang dalam bentuk berikut, masih mengembalikan hasil output ketika transaksi gagal, meninggalkannya pada rantai. Murni dari sudut pandang estetika, tampaknya seolah-olah semua transaksi dapat lancar meninggalkan output transaksi pada rantai, membuat pengumpulan biaya seragam tampak sangat wajar.

Ikhtisar Kontrak StarknetAA

Mempertimbangkan bahwa beberapa pembaca artikel ini mungkin memiliki latar belakang pemrograman, berikut adalah demonstrasi singkat antarmuka kontrak abstrak akun di Starknet:

The memvalidasi_menunjukkanantarmuka yang disebutkan di atas digunakan untuk memvalidasi transaksi deklarasi yang diinisiasi oleh pengguna, sementara memvalidasiDigunakan untuk validasi transaksi umum, terutama memverifikasi kebenaran tanda tangan pengguna. Di sisi lain, eksekusi digunakan untuk pelaksanaan transaksi. Perlu dicatat, akun kontrak Starknet secara inheren mendukung multicall, memungkinkan beberapa panggilan dilakukan. Fungsi multicall dapat memfasilitasi berbagai fitur menarik, seperti menggabungkan tiga transaksi berikut saat berinteraksi dengan protokol DeFi tertentu:

1. Mengotorisasi token ke kontrak DeFi dalam transaksi pertama.
2. Memicu logika kontrak DeFi dalam transaksi kedua.
3. Mencabut otorisasi ke kontrak DeFi dalam transaksi ketiga.

Tentu saja, karena atomisitas multicall, ada kasus penggunaan yang lebih kompleks, seperti mengeksekusi perdagangan arbitrase.

Ringkasan

Fitur teknologi utama Starknet meliputi bahasa Cairo yang dioptimalkan untuk pembangkitan bukti ZK, abstraksi akun tingkat native, dan model kontrak pintar yang memisahkan logika bisnis dari penyimpanan status.

Cairo adalah bahasa ZK yang serbaguna yang dapat digunakan untuk smart contract di Starknet serta untuk mengembangkan aplikasi yang lebih tradisional. Proses kompilasi memperkenalkan Sierra sebagai bahasa perantara, memungkinkan Cairo untuk mengulang secara sering tanpa mengubah bytecode dasar, hanya menyebarkan perubahan ke bahasa perantara. Perpustakaan standar Cairo juga mencakup banyak struktur data dasar yang diperlukan untuk abstraksi akun.

Kontrak pintar Starknet memisahkan logika bisnis dari penyimpanan data status, tidak seperti rantai EVM. Penyebaran kontrak Cairo melibatkan tiga tahap: kompilasi, deklarasi, dan penyebaran. Logika bisnis dinyatakan dalam kelas Kontrak, dan contoh Kontrak yang berisi data status dapat terkait dengan sebuah kelas dan memanggil kode yang berisi.

Model kontrak pintar Starknet memfasilitasi penggunaan ulang kode, penggunaan ulang status kontrak, lapisan penyimpanan, dan deteksi kontrak sampah. Ini juga memfasilitasi implementasi penyewaan penyimpanan dan paralelisasi transaksi, meskipun fitur-fitur ini belum sepenuhnya diimplementasikan. Arsitektur kontrak pintar Cairo menciptakan kondisi yang diperlukan untuk fitur-fitur ini.

Starknet hanya memiliki akun smart contract, tanpa akun EOA, dan mendukung abstraksi akun AA tingkat native sejak awal. Solusi AA-nya sebagian menyerap ide-ide dari ERC-4337, memungkinkan pengguna memilih solusi pemrosesan transaksi yang sangat disesuaikan. Untuk mencegah skenario serangan potensial, Starknet telah menerapkan berbagai langkah pencegahan, melakukan eksplorasi penting bagi ekosistem AA.

Penafian：

1. Artikel ini dicetak ulang dari [Geek Web3]. *Teruskan Judul Asli‘解读Starknet智能合约模型与原生AA：特立独行的技术巨匠’. Semua hak cipta milik penulis asli [Shew & Faust]. Jika ada keberatan terhadap penerbitan ulang ini, silakan hubungi Gerbang Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penolakan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.