Diskusi mendalam tentang desain akun kontrak pintar modular: memecahkan masalah teknis dalam implementasi

Penulis: Rui S, SevenX Ventures; Disusun oleh: Deep Wave TechFlow

memperkenalkan

Peralihan dari Akun Milik Eksternal (EOA) ke Akun Kontrak Cerdas (SCA) sedang booming dan didukung oleh banyak peminat, termasuk Vitalik sendiri. Meskipun terdapat kegembiraan, adopsi SCA belum seluas EOA. Permasalahan utama mencakup tantangan pasar yang sulit, kekhawatiran migrasi, masalah utama, overhead gas, dan yang paling penting, tantangan teknis.

Salah satu keuntungan terpenting dari Abstraksi Akun (AA) adalah kemampuan untuk menyesuaikan fungsionalitas menggunakan kode. Namun, tantangan teknik utama adalah tidak dapat dioperasikannya fungsi AA, dan fragmentasi ini menghambat integrasi dan membuka pintu bagi vendor lock-in. Selain itu, memastikan keamanan saat meningkatkan dan menggabungkan fitur secara bersamaan bisa jadi rumit.

Abstraksi akun modular muncul sebagai bagian dari gerakan AA yang lebih luas, sebuah pendekatan inovatif untuk memisahkan akun pintar dari fungsi kustomnya. Tujuannya adalah untuk menciptakan struktur modular untuk mengembangkan dompet yang aman dan terintegrasi dengan beragam fungsi. Di masa depan, mereka dapat mengimplementasikan akun kontrak pintar gratis “app store” sehingga dompet dan dApps tidak lagi fokus pada membangun fungsi, tetapi fokus pada pengalaman pengguna.

Deskripsi Singkat AA

EOA tradisional memperkenalkan banyak tantangan seperti frase awal, gas, lintas rantai, dan banyak transaksi. Kami tidak pernah bermaksud untuk memperkenalkan kompleksitas, namun kenyataannya blockchain bukanlah permainan yang mudah bagi banyak orang.

Abstraksi akun memanfaatkan akun kontrak pintar, memungkinkan verifikasi dan eksekusi yang dapat diprogram, memungkinkan pengguna menyetujui serangkaian transaksi sekaligus, daripada harus menandatangani dan menyiarkan setiap transaksi, dan mengaktifkan lebih banyak fungsi. Hal ini membawa manfaat bagi pengalaman pengguna (misalnya abstraksi Gas dan kunci sesi), biaya (misalnya transaksi batch), dan keamanan (misalnya pemulihan sosial, multi-tanda tangan). Saat ini, ada dua cara untuk menerapkan abstraksi akun:

• Lapisan protokol: Beberapa protokol sendiri menyediakan dukungan abstraksi akun lokal.Transaksi ZKsync, baik dari EOA atau SCA, mengikuti proses yang sama, menggunakan kumpulan memori tunggal dan proses transaksi untuk mendukung AA, sedangkan Starknet telah menghapus EOA dan semua akun Keduanya adalah SCA , dan mereka memiliki dompet kontrak pintar asli seperti Argent.
• Lapisan kontrak: Untuk Ethereum dan L2 yang setara, ERC 4337 memperkenalkan entri transaksi terpisah untuk mendukung AA tanpa mengubah lapisan konsensus. Proyek seperti Stackup, Alchemy, Etherspot, Biconomy, Candide, dan Plimico sedang membangun infrastruktur bundler, sementara proyek seperti Safe, Zerodev, Etherspot, dan Biconomy sedang membangun tumpukan dan SDK.

Dilema adopsi SCA

Topik Abstraksi Akun (AA) telah dibahas sejak tahun 2015 dan menjadi sorotan tahun ini oleh ERC 4337. Namun, jumlah akun kontrak pintar yang diterapkan masih jauh lebih sedikit dibandingkan EOA.

Mari kita gali lebih dalam dilema ini:

• Dampak pasar beruang:

Meskipun AA memperkenalkan manfaat seperti login tanpa batas dan abstraksi Gas, orang-orang yang saat ini mengalami pasar bearish sebagian besar terdiri dari pengguna EOA yang berpendidikan dibandingkan pengguna baru, sehingga tidak ada insentif untuk dApps dan dompet. Meski begitu, beberapa aplikasi terkemuka secara bertahap mengadopsi AA, seperti Cyberconnect, yang mendorong sekitar 360.000 UserOps (transaksi AA) hanya dalam satu bulan dengan memperkenalkan sistem AA dan solusi bebas Gas.

• Hambatan migrasi:

Untuk dompet dan aplikasi yang telah mengumpulkan pengguna dan aset, memigrasikan aset dengan aman dan nyaman tetap menjadi sebuah tantangan. Namun, inisiatif seperti EIP-7377 memungkinkan EOA memulai transaksi migrasi satu kali.

*Masalah tanda tangan:

Kontrak pintar itu sendiri tidak dapat menandatangani pesan secara alami karena tidak memiliki kunci pribadi seperti EOA. Upaya seperti ERC 1271 memungkinkan penandatanganan tersebut, namun penandatanganan pesan tidak berfungsi hingga transaksi pertama, yang menimbulkan tantangan bagi dompet yang menggunakan penerapan kontrafaktual. ERC-6492 yang diusulkan oleh Ambire adalah penerus ERC-1271 yang kompatibel dan dapat memecahkan masalah sebelumnya.

*Gas di atas:

Menyebarkan, mensimulasikan, dan melaksanakan SCA memerlukan biaya lebih tinggi daripada EOA standar. Hal ini menjadi hambatan dalam adopsi. Namun, ada beberapa pengujian, seperti memisahkan pembuatan akun dari tindakan pengguna dan mempertimbangkan menghilangkan garam akun dan pemeriksaan keberadaan, untuk mengurangi biaya ini.

• Masalah teknik:

Tim ERC-4337 telah membuat repositori eth-infinitiism untuk menyediakan implementasi dasar bagi pengembang. Namun, seiring kami mengembangkan fungsionalitas yang lebih terperinci atau spesifik dalam kasus penggunaan yang berbeda, integrasi dan decoding menjadi tantangan.

Dalam artikel ini, kita akan mempelajari lebih dalam isu kelima: tantangan teknis.

Akun kontrak pintar modular untuk memecahkan masalah teknis

Penjelasan lebih lanjut mengenai tantangan teknis adalah sebagai berikut:

• Fragmentasi: Berbagai fitur kini diaktifkan dengan cara berbeda, baik melalui SCA tertentu atau sistem plug-in independen. Masing-masing mengikuti standarnya sendiri, sehingga memaksa pengembang untuk memutuskan platform mana yang akan didukung. Hal ini dapat menyebabkan penguncian platform atau duplikasi upaya.
• Keamanan: Meskipun fleksibilitas antara akun dan fitur memberikan keuntungan, hal ini juga dapat memperburuk masalah keamanan. Fitur mungkin diaudit secara kolektif, namun kurangnya penilaian independen dapat meningkatkan risiko pelanggaran akun.
• Kemampuan untuk ditingkatkan: Seiring dengan berkembangnya fungsionalitas, penting untuk mempertahankan kemampuan untuk menambah, mengganti, atau menghapus fungsionalitas. Menerapkan ulang fungsionalitas yang ada dengan setiap pembaruan menimbulkan kompleksitas.

Untuk mengatasi masalah ini, kita memerlukan kontrak yang dapat diupgrade untuk memastikan peningkatan yang aman dan efisien, inti yang dapat digunakan kembali untuk meningkatkan efisiensi pengembangan secara keseluruhan, dan antarmuka standar untuk memastikan bahwa akun kontrak dapat bertransisi dengan lancar antar front end yang berbeda.

Istilah-istilah ini menyatu pada konsep umum: membangun arsitektur abstraksi akun modular (Modular AA).

Modular AA adalah ceruk dalam gerakan AA yang lebih luas yang membayangkan modularisasi akun pintar untuk menyesuaikan layanan kepada pengguna dan memungkinkan pengembang meningkatkan fungsionalitas secara lancar dengan batasan minimal.

Namun, menetapkan dan mempromosikan standar baru merupakan tantangan besar di industri mana pun. Banyak solusi berbeda yang mungkin muncul pada tahap awal sebelum semua orang menerima solusi utama. Namun, hal yang menggembirakan adalah SDK 4337, pengembang dompet, tim infrastruktur, dan perancang protokol bekerja sama untuk mempercepat proses ini.

Struktur modular: akun utama dan modul

Delegasikan panggilan dan kontrak proxy

Panggilan eksternal dan panggilan delegasi:

Meskipun panggilan delegasi mirip dengan panggilan, alih-alih mengeksekusi kontrak target dalam konteksnya sendiri, panggilan tersebut mengeksekusi kontrak target dalam kondisi kontrak panggilan saat ini. Artinya, setiap perubahan status yang dibuat oleh kontrak target akan diterapkan pada penyimpanan kontrak pemanggilan.

Untuk menerapkan struktur yang dapat disusun dan ditingkatkan, diperlukan pengetahuan dasar yang disebut “kontrak keagenan”.

• Kontrak agen: Kontrak biasa menyimpan logika dan statusnya dan tidak dapat diperbarui setelah penerapan. Kontrak proksi menggunakan delegasi untuk memanggil kontrak lain. Menerapkan fungsi dengan referensi, yang dijalankan dalam kondisi kontrak agen saat ini.
• Kasus penggunaan: Meskipun kontrak proksi tetap sama, Anda dapat menerapkan implementasi baru di belakang proksi. Kontrak proxy digunakan untuk meningkatkan kemampuan dan lebih murah untuk diterapkan dan dipelihara pada blockchain publik.

Arsitektur Keamanan

Safe adalah infrastruktur akun cerdas modular terkemuka yang dirancang untuk memberikan keamanan dan fleksibilitas yang telah terbukti, memungkinkan pengembang membuat beragam aplikasi dan dompet. Perlu dicatat bahwa banyak tim yang membangun atau terinspirasi oleh Safe. Biconomy meluncurkan akunnya dengan memperluas 4337 asli dan 1/1 multi-tanda tangan di Safe. Dengan lebih dari 164.000 kontrak yang disebarkan dan nilai lebih dari $30,7 miliar yang terkunci, Safe tidak diragukan lagi merupakan pilihan utama di bidang ini.

Struktur aman

• Kontrak akun aman: kontrak agen utama (stateful)

Akun Aman adalah kontrak proksi karena mendelegasikan panggilan kontrak tunggal. Akun Aman berisi pemilik, ambang batas, dan alamat implementasi, yang ditetapkan sebagai variabel untuk agen, sehingga menentukan statusnya.

• Kontrak Singleton: pusat integrasi (tanpa kewarganegaraan)

Singleton melayani akun Aman dan mengintegrasikan serta mendefinisikan integrasi yang berbeda, termasuk plugin, hook, penangan fungsi, dan validator tanda tangan.

• Kontrak modul: logika dan fungsi khusus

Modul sangat kuat. Sebagai tipe modular, plug-in dapat menentukan fungsi berbeda seperti aliran pembayaran, mekanisme pemulihan, dan kunci sesi, dan berfungsi sebagai jembatan lintas rantai antara Web2 dan Web3 dengan memperoleh data off-chain. Modul lain seperti Hooks bertindak sebagai penjaga keselamatan, dan penangan fungsi merespons instruksi apa pun.

Apa yang terjadi jika kita mengadopsi Safe

• Kontrak yang dapat ditingkatkan:

Setiap kali plugin baru diperkenalkan, singleton baru perlu dikerahkan. Pengguna memiliki otonomi untuk meningkatkan Safe ke versi tunggal yang diinginkan agar sesuai dengan preferensi dan kebutuhan mereka.

• Modul yang dapat disusun dan digunakan kembali:

Sifat modular dari plugin memungkinkan pengembang membangun fungsionalitas secara mandiri. Mereka kemudian bebas memilih dan menggabungkan plug-in ini sesuai dengan kasus penggunaannya, sehingga memfasilitasi pendekatan yang dapat disesuaikan.

Agen Berlian ERC-2535

Tentang ERC 2535 dan Agen Diamond

ERC 2535 menstandardisasi Agen Berlian, sistem kontrak pintar modular yang dapat ditingkatkan/diperluas setelah penerapan dan hampir tidak memiliki batasan ukuran. Sejauh ini, banyak tim yang terinspirasi olehnya, seperti eksperimen Kernel Zerodev dan Soul Wallet.

Bagaimana struktur Intan?

• Kontrak Diamond: Kontrak Agen Utama (Stateful) Diamond adalah kontrak proxy yang memanggil fungsi dari implementasinya melalui panggilan delegasi.
• Modul/plugin/kontrak faceted: Logika dan fungsionalitas khusus (stateless) Modul atau yang disebut facet adalah kontrak stateless yang dapat menyebarkan fungsinya ke dalam satu atau lebih Diamond. Itu adalah kontrak independen yang dapat berbagi fungsi internal, perpustakaan, dan variabel negara.

Apa yang terjadi jika kita menggunakan Diamond

• Kontrak yang dapat ditingkatkan: Diamond menyediakan cara sistematis untuk mengisolasi plug-in yang berbeda dan menghubungkannya bersama-sama, dan menambah/mengganti/menghapus plug-in apa pun secara langsung melalui fungsi diamondCut. Tidak ada batasan jumlah plug-in yang dapat ditambahkan ke Diamond seiring berjalannya waktu.
• Plug-in modular dan dapat digunakan kembali: Plug-in yang diterapkan dapat digunakan oleh sejumlah Diamond, sehingga sangat mengurangi biaya penerapan.

Perbedaan antara akun pintar Aman dan metode Diamond

Ada banyak kesamaan antara arsitektur Safe dan Diamond, keduanya mengandalkan kontrak proxy sebagai inti dan merujuk pada kontrak logika untuk kemampuan upgrade dan modularitas.

Namun perbedaan utamanya terletak pada penanganan kontrak logis. Berikut petunjuk lebih detailnya:

• Fleksibilitas: Dengan mengaktifkan plugin baru, Safe perlu menerapkan ulang kontrak tunggalnya untuk menerapkan perubahan pada agennya. Sebaliknya, Diamond melakukan hal ini secara langsung melalui fungsi diamondCut di delegasinya. Perbedaan pendekatan ini berarti Safe mempertahankan tingkat kontrol yang lebih tinggi, sementara Diamond memperkenalkan fleksibilitas dan modularitas yang lebih besar.
• Keamanan: Saat ini, delegasicall digunakan di kedua struktur, yang memungkinkan kode eksternal memanipulasi penyimpanan kontrak utama. Dalam arsitektur Aman, panggilan delegasi menunjuk ke satu kontrak logis, sementara Diamond menggunakan panggilan delegasi antara beberapa kontrak modul (plug-in). Oleh karena itu, ada kemungkinan plugin berbahaya menimpa plugin lain, sehingga menimbulkan risiko konflik penyimpanan yang dapat membahayakan integritas agen.
• Biaya: Fleksibilitas yang melekat pada pendekatan Diamond disertai dengan peningkatan masalah keamanan. Hal ini menambah faktor biaya dan memerlukan audit penuh setiap kali plugin baru ditambahkan. Kuncinya adalah memastikan plugin-plugin ini tidak mengganggu fungsi satu sama lain, yang dapat menjadi tantangan bagi usaha kecil dan menengah yang mencoba mempertahankan standar keamanan yang kuat.

“Metode Akun Cerdas Aman” dan “Metode Berlian” adalah contoh struktur berbeda yang melibatkan agen dan modul. Cara menyeimbangkan fleksibilitas dan keamanan sangatlah penting, dan kedua pendekatan ini kemungkinan besar akan saling melengkapi di masa depan.

Urutan modul: validator, eksekutor, dan Hook

Mari kita perluas diskusi kita dengan memperkenalkan standar yang diusulkan oleh tim Alkimia, ERC 6900, yang terinspirasi oleh Diamond dan diadaptasi secara khusus untuk ERC-4337. Ini memecahkan tantangan modularitas dalam akun pintar dengan menyediakan antarmuka umum dan mengoordinasikan pekerjaan antara pengembang plugin dan dompet.

Dalam proses transaksi AA, ada tiga proses utama: Verifikasi, Eksekusi, dan Hook. Seperti yang telah kita bahas sebelumnya, langkah-langkah ini dapat dikelola dengan memanggil modul menggunakan akun proxy. Meskipun proyek yang berbeda mungkin menggunakan nama yang berbeda, penting untuk menangkap logika dasar yang serupa.

• Verifikasi: Pastikan keaslian dan otoritas akun penelepon.
• Eksekusi: Jalankan logika khusus apa pun yang diizinkan oleh akun. *Hook: sebagai modul yang berjalan sebelum atau sesudah fungsi lain. Itu dapat mengubah status atau menyebabkan seluruh panggilan dibatalkan.

Memisahkan modul berdasarkan logika yang berbeda sangatlah penting. Pendekatan standar harus menentukan bagaimana verifikasi akun kontrak pintar, eksekusi, dan fungsi Hook harus ditulis. Baik itu Safe atau ERC 6900, standardisasi membantu mengurangi kebutuhan akan upaya pengembangan unik untuk implementasi atau ekosistem tertentu dan mencegah vendor lock-in.

Penemuan dan keamanan modul

Salah satu solusi yang sedang booming melibatkan pembuatan tempat yang memungkinkan pengguna menemukan modul yang dapat diverifikasi, yang mungkin kita sebut sebagai “registrasi”. Registri ini mirip dengan “toko aplikasi” yang dirancang untuk memfasilitasi pasar modular yang disederhanakan namun berkembang.

Protokol{Inti} Aman

Safe{Core} Protocol adalah protokol akun kontrak cerdas sumber terbuka dan dapat dioperasikan yang dirancang untuk meningkatkan aksesibilitas bagi berbagai vendor dan pengembang melalui standar dan aturan yang jelas, sambil menjaga keamanan yang kuat.

• Akun: Dalam protokol Safe{Core}, konsep akun bersifat fleksibel dan tidak dibatasi oleh implementasi tertentu. Hal ini memungkinkan berbagai penyedia layanan akun untuk berpartisipasi.
• Manajer: Manajer bertindak sebagai koordinator antara akun, registri, dan modul. Ia juga bertanggung jawab atas keamanan, bertindak sebagai lapisan izin.
• Registri: Registri mendefinisikan atribut keamanan dan menerapkan standar modul seperti ERC 6900, yang bertujuan untuk menciptakan lingkungan “app store” terbuka untuk penemuan dan keamanan.
• Modul: Modul menangani fungsionalitas dan disediakan dalam berbagai tipe awal, termasuk plugin, Hooks, validator tanda tangan, dan penangan fungsi. Pengembang dapat berkontribusi selama mereka memenuhi standar yang ditetapkan.

Desain Berlian Imitasi

Prosesnya terungkap sebagai berikut:

• Buat definisi skema: skema berfungsi sebagai struktur data yang telah ditentukan sebelumnya sebagai bukti. Perusahaan dapat menyesuaikan pola berdasarkan kasus penggunaan spesifik mereka.
• Buat modul berdasarkan pola: kontrak pintar didaftarkan sebagai modul, mendapatkan bytecode dan memilih ID pola. Data ini kemudian disimpan di registri.
• Dapatkan bukti modul: Pemberi sertifikat/auditor dapat memberikan bukti modul berdasarkan skema. Sertifikat ini dapat mencakup pengidentifikasi unik (UID) dan referensi ke sertifikat lain untuk ditautkan. Mereka dapat disebarkan secara on-chain dan memverifikasi bahwa ambang batas tertentu terpenuhi pada rantai target.
• Gunakan parser untuk mengimplementasikan logika kompleks: parser diatur secara opsional dalam pola. Mereka dapat dipanggil selama pembuatan modul, pembuatan bukti, dan pembongkaran. Parser ini memungkinkan pengembang untuk menggabungkan logika yang kompleks dan beragam sambil mempertahankan struktur pembuktiannya.
• Akses kueri yang mudah digunakan: Kueri menyediakan cara bagi pengguna untuk mengakses informasi keamanan dari ujung depan. EIP dapat ditemukan di sini.

Meskipun model ini masih dalam tahap awal, model ini mempunyai potensi untuk menetapkan standar dengan cara yang terdesentralisasi dan kolaboratif. Registri mereka memungkinkan pengembang untuk mendaftarkan modul mereka, auditor untuk memverifikasi keamanan mereka, dompet untuk diintegrasikan dan pengguna untuk dengan mudah menemukan modul dan memverifikasi informasi pengesahan mereka. Mungkin ada kegunaan berikut di masa depan:

• Pemberi Sertifikasi: Entitas tepercaya, seperti Safe, dapat bekerja sama dengan Berlian Imitasi sebagai pemberi sertifikasi untuk modul internal. Pada saat yang sama, pembuktian independen juga dapat bergabung.
• Pengembang modul: Dengan terbentuknya pasar terbuka, pengembang modul dapat mengkomersialkan karyanya melalui registri.
• Pengguna: Melalui antarmuka yang ramah pengguna seperti dompet atau dApps, pengguna dapat melihat informasi modul dan mendelegasikan kepercayaan ke penyedia yang berbeda.

Konsep “registrasi modul” memberikan peluang menguntungkan bagi pengembang plugin dan modul. Hal ini juga dapat membuka jalan bagi “pasar modul”. Beberapa dari aspek ini mungkin diawasi oleh tim Safe, sementara aspek lainnya mungkin terwujud sebagai pasar terdesentralisasi yang mengundang semua orang untuk berkontribusi dan memberikan jejak audit yang transparan. Dengan mengambil pendekatan ini, kami dapat menghindari vendor lock-in dan mendukung perluasan EVM dengan memberikan pengalaman pengguna yang lebih baik dan menarik khalayak yang lebih luas.

Meskipun metode ini menjamin keamanan masing-masing modul, keamanan keseluruhan akun kontrak pintar tidak sepenuhnya dapat diandalkan. Menggabungkan modul yang sah dan membuktikan bahwa modul tersebut tidak memiliki konflik penyimpanan dapat menjadi sebuah tantangan, menekankan pentingnya dompet atau infrastruktur AA dalam memecahkan masalah tersebut.

Ringkaslah

Dengan memanfaatkan tumpukan akun kontrak pintar modular, penyedia dompet dan dApps dapat menghindari kerumitan pemeliharaan teknis. Pada saat yang sama, pengembang modul eksternal memiliki kesempatan untuk memberikan layanan profesional yang disesuaikan dengan kebutuhan individu. Namun, tantangan yang perlu diatasi termasuk mencapai keseimbangan antara fleksibilitas dan keamanan, mendorong kemajuan standar modular, dan menerapkan antarmuka standar yang memungkinkan pengguna meningkatkan dan memodifikasi Akun Cerdas mereka dengan mudah.

Namun, akun kontrak pintar modular (SCA) hanyalah salah satu bagian dari teka-teki adopsi. Untuk sepenuhnya mewujudkan potensi SCA, dukungan lapisan protokol dari solusi lapisan kedua juga diperlukan, serta infrastruktur bundler yang kuat dan kumpulan memori peer-to-peer, mekanisme penandatanganan SCA yang lebih hemat biaya dan layak, sinkronisasi SCA lintas rantai dan manajemen, serta mengembangkan antarmuka yang ramah pengguna.

Kami membayangkan masa depan dengan partisipasi yang luas, yang menimbulkan beberapa pertanyaan menarik: Setelah proses pemesanan SCA menjadi cukup menguntungkan, bagaimana mekanisme nilai yang dapat diekstraksi (MEV) penambang tradisional akan memasuki ruang, membangun bundler, dan menangkap nilai? Ketika infrastruktur sudah matang, bagaimana Abstraksi Akun (AA) bisa menjadi lapisan dasar untuk transaksi “berbasis niat”? Harap pantau terus karena area ini terus berkembang.