*Catatan editor: Akun Kontrak Cerdas (SCA) mendapatkan momentum dan didukung oleh banyak pengusaha inti, termasuk Vitalik, tetapi masih ada banyak tantangan untuk adopsi SCA. Account Abstraction (AA) memiliki keuntungan menggunakan kustomisasi kode, tetapi non-interoperabilitasnya memperkenalkan masalah integrasi dan penguncian vendor. Abstraksi akun modular bertujuan untuk menciptakan struktur modular untuk mengembangkan dompet yang serbaguna, aman, dan terintegrasi dengan mulus. *
Rui, seorang investor di SevenX Ventures >, mengidentifikasi lima tantangan teratas untuk mengadopsi SCA — dampak pasar beruang, kesulitan migrasi, masalah khas, biaya gas yang tinggi, dan tantangan teknik — dan mendiskusikannya lebih lanjut. Selain itu, analisis arsitektur akun kontrak pintar modular menunjukkan bahwa SCA modular hanyalah sebagian kecil dari tantangan adopsi.
Untuk mewujudkan potensi penuh SCA, solusi Layer 2 diperlukan untuk memberikan dukungan lapisan protokol tambahan, infrastruktur bundler yang kuat dan kumpulan memori peer-to-peer, mekanisme tanda tangan SCA yang lebih hemat biaya dan layak, sinkronisasi dan manajemen SCA lintas rantai, dan pengembangan antarmuka yang ramah pengguna.
Apa yang akan terjadi selanjutnya di masa depan, karena tantangan saat ini diselesaikan dan lebih banyak orang mengadopsi SCA? Rui juga mengajukan beberapa pertanyaan menarik. BlockBeats menyusun teks asli sebagai berikut:
Pergeseran dari akun milik eksternal (EOA) ke akun kontrak pintar (SCA) mendapatkan momentum dan sudah didukung oleh banyak pengusaha inti, termasuk Vitalik. Meskipun demikian, adopsi SCA belum seluas EOA. Masalah utama termasuk dampak pasar bearish, kesulitan memigrasikan EOA ke SCA, masalah tanda tangan, biaya gas yang tinggi, dan yang paling kritis, tantangan pengembangan.
Keuntungan paling signifikan dari Account Abstraction (AA) adalah kemampuan untuk menyesuaikan fungsionalitas menggunakan kode. Namun, non-interoperabilitas fungsionalitas AA menghadirkan tantangan besar, karena fragmentasi ini menghambat integrasi AA dan memperkuat penguncian vendor. Selain itu, ini juga merupakan tantangan penting untuk memastikan keamanan sekaligus dapat ditingkatkan dan disusun.
Munculnya abstraksi akun modular adalah ceruk dalam tren AA, pendekatan inovatif yang memisahkan akun pintar dari fitur khusus mereka. Tujuannya adalah untuk menciptakan struktur modular untuk mengembangkan dompet dengan banyak fitur, keamanan, dan integrasi tanpa batas. Di masa depan, abstraksi akun modular akan memungkinkan akun kontrak pintar gratis "toko aplikasi", memungkinkan dompet dan dApps untuk fokus pada peningkatan pengalaman pengguna daripada harus menghabiskan terlalu banyak usaha membangun fitur.
Abstraksi Akun Singkat (AA)
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-e77dfd1eb3-dd1a6f-cd5cc0.webp)
EOA tradisional membawa banyak tantangan bagi paparan orang terhadap blockchain, seperti frase benih, biaya gas, operasi lintas rantai, dan banyak transaksi.
Abstraksi akun memanfaatkan akun kontrak pintar untuk memungkinkan validasi dan ution yang dapat diprogram. Ini berarti bahwa pengguna akan dapat menyetujui serangkaian transaksi sekaligus, daripada harus menandatangani dan menyiarkan setiap transaksi. Abstraksi akun juga dapat memungkinkan lebih banyak fitur seperti peningkatan pengalaman pengguna (misalnya, abstraksi gas dan kunci sesi), pengurangan biaya (misalnya, transaksi massal), dan peningkatan keamanan (misalnya, pemulihan sosial, multi-tanda tangan). Saat ini, ada dua cara untuk mengabstraksi akun:
· Lapisan protokol: Beberapa protokol secara native menyediakan dukungan abstraksi akun asli, transaksi ZKSync menggunakan mempool tunggal dan aliran transaksi untuk mendukung AA, baik dari EOA dan SCA mengikuti proses yang sama, sementara Starknet telah menghapus EOA, semua akun adalah SCA, dan mereka memiliki dompet kontrak pintar asli seperti Argent.
· Lapisan kontrak: Untuk Ethereum dan L2 serupa, ERC4337 memperkenalkan mempool terpisah untuk mendukung AA tanpa mengubah lapisan konsensus. Tempat-tempat seperti Stackup, Alchemy, Etherspot, Biconomy, Candide, dan Plimico sedang membangun infrastruktur bundler, sementara hal-hal seperti Safe, Zerodev, Etherspot, dan Biconomy sedang membangun bundler dan SDK.
Dilema mengadopsi SCA
Topik abstraksi akun (AA) telah dibahas sejak 2015 dan semakin menjadi sorotan tahun ini oleh ERC 4337. Namun, jumlah akun kontrak pintar yang digunakan masih serendah EOA.
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cd53d3972e-dd1a6f-cd5cc0.webp)
Mari kita selidiki dilema ini:
Dampak pasar beruang
Terlepas dari keunggulan AA seperti login yang mulus dan abstraksi gas, di pasar beruang saat ini, di mana semua pengguna adalah pengguna EOA yang terdidik dan tidak banyak pengguna baru, tidak ada insentif bagi dApps dan dompet untuk mengadopsi SCA. Meski begitu, beberapa dApps 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 tanpa gas mereka.
Hambatan migrasi
Untuk dompet dan aplikasi yang telah mengumpulkan pengguna dan aset, tetap menjadi tantangan untuk memigrasikan aset dengan aman dan nyaman. Namun, skema seperti EIP-7377 memungkinkan EOA untuk memulai transaksi migrasi satu kali.
Masalah tanda tangan
Kontrak pintar itu sendiri tidak dapat menandatangani pesan karena tidak memiliki kunci pribadi seperti EOA. Upaya seperti ERC1271 memungkinkan hal ini, tetapi penandatanganan pesan tidak berfungsi sampai transaksi pertama, yang pada gilirannya menimbulkan tantangan bagi dompet yang digunakan dengan kontrafaktual. ERC-6492, yang diusulkan oleh Ambire, adalah penerus ERC-1271 yang kompatibel ke belakang dan mungkin dapat memecahkan masalah sebelumnya.
Biaya gas
Biaya yang lebih tinggi untuk menyebarkan, mensimulasikan, dan melaksanakan SCA dibandingkan dengan EOA standar juga merupakan penghalang untuk adopsi. Namun, beberapa tes telah dilakukan, seperti memisahkan pembuatan akun dari tindakan pengguna, menghilangkan "garam" yang terkait dengan akun, dan banyak lagi.
Masalah teknik
Tim ERC-4337 telah membangun repo eth-infinitism yang menyediakan implementasi dasar bagi pengembang. Namun, karena pengembang menskalakan ke fitur yang lebih terperinci dan spesifik untuk kasus penggunaan yang berbeda, integrasi dan decoding menghadapi lebih banyak tantangan. Dalam artikel ini, kita akan menyelami tantangan teknik.
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b50e21334e-dd1a6f-cd5cc0.webp)
Selesaikan tantangan teknik dengan akun kontrak pintar modular
Tantangan teknik dapat dijabarkan lebih lanjut menjadi tiga aspek: fragmentasi, keamanan, dan kemampuan upgrade.
· Fragmentasi: Fitur sekarang dapat diaktifkan dalam berbagai cara, baik melalui SCA tertentu atau melalui sistem plug-in mandiri. Setiap platform dan penyedia layanan mengikuti standarnya sendiri, mendorong pengembang untuk memutuskan platform dan penyedia layanan mana yang akan didukung. Hal ini dapat menyebabkan potensi penguncian platform (vendor) atau pekerjaan yang berlebihan.
· Keamanan: Meskipun memisahkan akun dan fungsi membawa manfaat fleksibilitas, itu juga dapat membuat masalah keamanan menjadi lebih serius. Karena semua fitur dapat ditinjau bersama, kurangnya penilaian independen dapat meningkatkan risiko kerentanan akun.
· Upgradeability: Seiring pertumbuhan akun Anda, penting untuk mempertahankan kemampuan untuk menambahkan, mengganti, atau menghapus fitur, dan setiap pembaruan yang menerapkan ulang fitur yang ada memperkenalkan kompleksitas.
Untuk mengatasi masalah ini, kami memerlukan kontrak yang dapat ditingkatkan untuk memastikan peningkatan yang aman dan efisien, inti yang dapat digunakan kembali untuk meningkatkan efisiensi pengembangan secara keseluruhan, dan antarmuka standar untuk memastikan transisi yang mulus antara frontend yang berbeda.
Istilah-istilah ini bertemu pada konsep umum: membangun arsitektur abstraksi akun modular (Modular AA).
Abstraksi akun modular adalah subdivisi dari pengembangan AA yang lebih luas yang membayangkan modularisasi akun pintar untuk menyediakan layanan yang disesuaikan kepada pengguna dan memungkinkan pengembang untuk meningkatkan fungsionalitas dengan mulus dengan kendala minimal.
Namun, menetapkan dan mempromosikan standar baru dalam industri apa pun merupakan tantangan besar. Sampai semua orang menerima standar yang sama, banyak solusi berbeda dapat muncul pada fase awal. Sangat menggembirakan melihat bahwa mereka yang bekerja untuk memperbaiki dan mempromosikan abstraksi akun, apakah itu 4337 SDK, dompet, tim infrastruktur, atau perancang lapisan protokol, bekerja sama untuk mempercepat proses ini.
Struktur modular: akun master dan modul
Bagaimana akun memanggil modul untuk mengimplementasikan fungsi
Mendelegasikan panggilan dan kontrak proxy
Panggilan eksternal dan delegasi :
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-26b1e8ab3b-dd1a6f-cd5cc0.webp)
Tentang panggilan delegasi
Sementara "panggilan yang didelegasikan" mirip dengan "panggilan", itu tidak dijalankan dalam konteks kontrak target, tetapi dalam konteks keadaan kontrak panggilan saat ini. Ini berarti bahwa setiap perubahan negara yang dibuat oleh kontrak target akan mengubah penyimpanan kontrak panggilan.
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-421fd8f0e1-dd1a6f-cd5cc0.webp)
Kontrak proksi dan panggilan delegasi
** Untuk mencapai struktur yang dapat disusun dan diupgrade, konsep dasar "kontrak agensi" perlu diperkenalkan. **
Kontrak proksi: Kontrak normal menyimpan logika dan statusnya, dan tidak dapat diperbarui setelah penyebaran. Kontrak proksi disebarkan ke kontrak lain menggunakan panggilan delegasi. Terapkan fungsi dengan referensi untuk menjalankannya dalam keadaan kontrak proxy saat ini.
Kasus penggunaan: Meskipun kontrak proxy tetap sama, Anda dapat menerapkan implementasi baru di belakang broker. Kontrak proxy dapat ditingkatkan dan lebih murah untuk digunakan dan dipelihara di blockchain publik.
** Arsitektur Aman **! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4dc82c32d1-dd1a6f-cd5cc0.webp)
Arsitektur yang aman
Apa itu Aman: Aman adalah infrastruktur akun pintar modular terkemuka yang dirancang untuk memberikan keamanan dan fleksibilitas yang telah teruji, dan memungkinkan pengembang untuk membuat beragam aplikasi dan dompet. Banyak tim membangun aplikasi selain (atau terinspirasi oleh) Safe. Misalnya, Biconomy memperluas Safe dengan native 4337 dan 1/1 multisig saat meluncurkan akun kontrak pintarnya. Setelah menyaksikan penyebaran lebih dari 164.000 kontrak dan mengunci nilai lebih dari $ 30,7 miliar, Safe tidak diragukan lagi adalah pemimpin dalam ruangnya.
Struktur Safe mencakup kontrak akun aman, kontrak singleton, dan kontrak modul.
Kontrak proxy: Stateful
Akun aman adalah kontrak proxy karena panggilan yang didelegasikan adalah kontrak tunggal. Akun keamanan berisi variabel di mana pemilik, ambang batas, dan alamat implementasi semuanya ditetapkan sebagai agen, dan statusnya ditentukan berdasarkan ini.
单例合约(singleton contract):Integration Hub(无状态)
Kontrak singleton melayani akun Aman dan mendefinisikan integrasi kontrak modul yang berbeda, termasuk Plugin, Hook, Function Handler, dan Signature Validator.
Modul: Logika dan fungsionalitas kustom
Kontrak modul sangat kuat. Plugin sebagai tipe modular dapat menentukan fungsi yang berbeda seperti alur pembayaran, mekanisme pemulihan, dan kunci sesi, dan dapat bertindak sebagai jembatan antara Web2 dan Web3 dengan mengambil data off-chain. Modul lain, seperti Hook dan Function Handler sebagai penjaga keamanan, dapat menanggapi perintah apa pun.
Perubahan yang telah berubah sejak mengadopsi Safe:
Kontrak yang dapat ditingkatkan: Setiap kali plugin baru diperkenalkan, singleton baru perlu digunakan. Pengguna mempertahankan otonomi untuk meningkatkan Aman ke versi singleton yang diinginkan.
Modul yang dapat disusun dan digunakan kembali: Sifat modular plugin memungkinkan pengembang untuk mengembangkan fitur secara mandiri. Mereka bebas memilih dan menggabungkan plugin ini sesuai dengan kasus penggunaannya, menghasilkan pendekatan yang sangat dapat disesuaikan.
ERC-2535 Berlian 代理
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-dfa51cc0ce-dd1a6f-cd5cc0.webp)
Tentang ERC2535, Agen Berlian:
ERC2535 model Diamond standar, sistem kontrak pintar modular yang dapat ditingkatkan / diskalakan setelah penerapan dengan hampir tidak ada batasan ukuran. Saat ini, banyak tim seperti eksperimen Zerodev's Kernel dan Soul Wallet telah terinspirasi oleh struktur Diamond.
Apa itu Struktur Berlian:**
Kontrak Berlian: Kontrak Proksi Utama (Stateful) Diamond adalah kontrak proksi yang menggunakan metode pemanggilan yang didelegasikan untuk memanggil fungsi dari implementasinya.
Kontrak Modul / Plugin / Facet: Logika dan Fungsionalitas Kustom (Stateless) Modul atau yang disebut Facet adalah kontrak stateless yang dapat menyebarkan fungsinya ke satu atau lebih Berlian. Mereka terpisah, kontrak independen yang dapat berbagi fungsi intrinsik, perpustakaan, dan variabel negara.
Perubahan dengan Diamond:
Kontrak yang Dapat Diupgrade: Diamond menyediakan cara sistematis untuk mengisolasi plugin yang berbeda dan menghubungkannya bersama-sama, berbagi data di antara mereka, dan juga menambah / mengganti / menghapus plugin apa pun secara langsung menggunakan fitur diamondCut. Seiring waktu, tidak akan ada batasan jumlah plugin yang dapat ditambahkan ke Diamond.
Plugin modular dan dapat digunakan kembali: Plugin yang digunakan dapat digunakan oleh sejumlah Berlian, secara dramatis mengurangi biaya penyebaran.
Perbedaan antara Safe Smart Account dan metode Diamond:
Ada banyak kesamaan antara arsitektur Safe dan Diamond, keduanya bergantung pada kontrak proxy inti mereka dan referensi kontrak logis untuk upgradeability dan modularitas.
Perbedaan utama antara keduanya adalah penanganan kontrak logis. Khusus:
· Fleksibilitas: Dengan plugin baru diaktifkan, Safe perlu menerapkan ulang kontrak singleton-nya untuk menerapkan perubahan dalam proxy-nya. Sebaliknya, Diamond mencapai ini secara langsung melalui fungsi diamondCut dalam kontrak proxy-nya. Perbedaan dalam pendekatan berarti bahwa Safe mempertahankan tingkat kontrol yang lebih tinggi, sementara Diamond memperkenalkan peningkatan fleksibilitas dan modularitas.
· Aman: Saat ini digunakan di kedua struktur, memungkinkan kode eksternal untuk memanipulasi penyimpanan kontrak utama. Dalam arsitektur Safe, panggilan delegasi menunjuk ke satu kontrak logis, sementara Diamond menggunakan panggilan delegasi di beberapa modul contracts-plugins. Akibatnya, ada kemungkinan plugin berbahaya menimpa plugin lain, memperkenalkan risiko konflik penyimpanan dan membahayakan integritas proxy.
· Biaya: Dalam pendekatan Diamond, fleksibilitas dan keamanan bersatu. Ini meningkatkan biaya, dan setiap kali plugin baru ditambahkan, itu perlu diaudit sepenuhnya. Kuncinya adalah memastikan bahwa plugin ini tidak mengganggu fungsionalitas satu sama lain, tujuan yang menantang, terutama untuk usaha kecil dan menengah yang berjuang untuk mempertahankan standar keamanan yang tinggi.
"Metode Akun Cerdas Aman" dan "Metode Berlian" adalah contoh struktur berbeda yang melibatkan agen dan modul. Menyeimbangkan fleksibilitas dan keamanan sangat penting, dan kedua pendekatan ini akan terus berkembang dan saling melengkapi di masa depan.
Urutan Modul: Validator, Pelaksana dan Hook
Mari kita bahas ini lebih lanjut dengan memperkenalkan ERC6900, standar yang terinspirasi Diamond dari tim Alchemy yang dirancang khusus untuk ERC-4337. Ini memecahkan tantangan modularitas akun pintar dengan menyediakan antarmuka umum dan mengoordinasikan pekerjaan antara pengembang plugin dan dompet.
Ketika datang ke proses transaksi AA, ada tiga proses utama: validasi, eksekusi, dan pegging. Seperti yang telah kita bahas sebelumnya, langkah-langkah ini semua dapat dikelola dengan menggunakan modul panggilan akun proxy. Sementara proyek yang berbeda mungkin menggunakan nama yang berbeda, penting untuk memahami logika kesamaan yang mendasarinya.
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b01f250655-dd1a6f-cd5cc0.webp)
Nama fungsi dalam desain yang berbeda
Validator: Memastikan keaslian dan izin penelepon akun.
Eksekusi (UTOR): Jalankan logika kustom apa pun yang diizinkan akun.
Hook: Bertindak sebagai modul yang berjalan sebelum atau sesudah fungsi lain. Itu dapat mengubah status atau membatalkan seluruh panggilan.
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-42db1d92a0-dd1a6f-cd5cc0.webp)
Penting untuk memisahkan modul sesuai dengan logika yang berbeda. Pendekatan standar harus menentukan cara menulis fungsi validasi, eksekusi, dan pegging untuk akun kontrak pintar. Baik itu Aman atau ERC6900, standardisasi membantu mengurangi kebutuhan akan upaya pengembangan unik khusus untuk implementasi atau ekosistem tertentu dan mencegah penguncian vendor.
Penemuan dan keamanan modul
Cara menemukan dan memvalidasi modul secara terbuka: Salah satu solusi yang sedang dikembangkan melibatkan pembuatan area yang memungkinkan pengguna menemukan modul yang dapat diverifikasi, yang dapat disebut "registri". Registri berfungsi seperti "toko aplikasi" dan bertujuan untuk mendorong pasar modular yang disederhanakan namun berkembang.
Safe{Core} 协议
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4ff8171cf4-dd1a6f-cd5cc0.webp)
Protokol Safe {Core} adalah protokol sumber terbuka yang dapat dioperasikan untuk akun kontrak pintar yang dirancang untuk meningkatkan aksesibilitas bagi berbagai vendor dan pengembang sambil mempertahankan keamanan yang kuat melalui standar dan aturan yang terdefinisi dengan baik.
· Akun: Dalam protokol Safe {Core}, konsep akun fleksibel dan tidak terikat pada implementasi tertentu. Ini memungkinkan penyedia layanan akun yang berbeda untuk terlibat.
· Manajer: Manajer bertindak sebagai koordinator antara akun, registri, dan modul. Ini juga menjaga keamanan sebagai lapisan lisensi.
· Registri: Registri mendefinisikan atribut keamanan dan memberlakukan standar modul seperti ERC6900 untuk membuat lingkungan "toko aplikasi" terbuka untuk dapat ditemukan dan keamanan.
· Modul: Modul menangani fungsionalitas dan memiliki berbagai jenis awal, termasuk plugin, hook, validator tanda tangan, dan penangan fungsi. Pengembang dapat terlibat selama mereka memenuhi kriteria yang ditetapkan.
Rhinestone 设计
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-96de12199c-dd1a6f-cd5cc0.webp)
Prosesnya terungkap sebagai berikut:
· Buat skema: Skema menyediakan struktur data yang telah ditentukan sebelumnya. Orang dapat menyesuaikannya agar sesuai dengan kasus penggunaan khusus mereka.
· Buat modul berdasarkan skema: Kontrak pintar yang terdaftar sebagai modul mendapatkan bytecode dan memilih ID skema, dan data disimpan dalam registri.
· Dapatkan pengesahan modul: Prover / auditor dapat memberikan bukti modul berdasarkan arsitektur. Pengesahan ini dapat mencakup pengidentifikasi unik (UID) dan referensi ke pengesahan lain yang digunakan untuk tautan. Mereka dapat menyebar di seluruh rantai dan memverifikasi bahwa rantai target memenuhi ambang batas tertentu.
· Terapkan logika kompleks dengan resolver: Parser (opsional) ikut bermain. Mereka dapat dipanggil selama pembuatan modul, penetapan pengesahan, dan pencabutan. Pengurai ini memungkinkan pengembang untuk mengintegrasikan logika yang kompleks dan beragam sambil mempertahankan struktur bukti.
Akses kueri yang mudah digunakan: Kueri menyediakan cara bagi pengguna untuk mengakses informasi keamanan dari ujung depan.
Sementara model ini masih dalam tahap awal, ia memiliki potensi untuk menetapkan standar dengan cara yang terdesentralisasi dan kolaboratif. Registri memungkinkan pengembang untuk mendaftarkan modul mereka, auditor untuk memverifikasi keamanan mereka, dompet untuk mengintegrasikan, dan memungkinkan pengguna untuk dengan mudah menemukan modul dan memverifikasi informasi pengesahan mereka. Beberapa kegunaan di masa depan dapat berupa:
· Attestor: Entitas tepercaya seperti Safe dapat bekerja dengan Rhinestone sebagai prover untuk modul internal. Pada saat yang sama, pemberi sertifikasi independen juga dapat bergabung.
· Pengembang modul: Dengan pembentukan pasar terbuka, pengembang modul dapat memonetisasi pekerjaan mereka melalui registri.
· Pengguna: Berpartisipasi melalui antarmuka yang ramah pengguna, seperti dompet atau dApp, memungkinkan pengguna untuk memeriksa informasi modul dan mendelegasikan kepercayaan kepada berbagai provers.
Konsep "registri modul" membuka cara bagi pengembang plugin dan modul untuk menghasilkan uang. Ini selanjutnya bisa membuka jalan bagi "pasar modul". Beberapa aspek mungkin diawasi oleh tim Safe, sementara yang lain mungkin bermanifestasi sebagai pasar terdesentralisasi yang mengundang semua orang untuk berkontribusi dan memberikan jejak audit yang transparan. Menggabungkan ini menghindari penguncian vendor dan mendukung perluasan EVM dengan menambahkan pengalaman pengguna yang ditingkatkan yang menarik bagi khalayak yang lebih luas.
Meskipun metode ini menjamin keamanan modul individual, akun kontrak pintar tidak mudah dalam hal keamanan yang lebih luas. Ini bisa menjadi tantangan untuk digabungkan dengan modul kepatuhan dan membuktikan bahwa mereka tidak memiliki konflik penyimpanan, yang menyoroti pentingnya dompet atau infrastruktur AA dalam mengatasi masalah tersebut.
Ringkasan
Dengan memanfaatkan tumpukan akun kontrak pintar modular, penyedia dompet dan dApps dapat dibebaskan dari kerumitan pemeliharaan teknis. Pada saat yang sama, pengembang modul eksternal memiliki kesempatan untuk memberikan layanan profesional yang dipersonalisasi. Namun, tantangan yang perlu diatasi termasuk mencapai keseimbangan antara fleksibilitas dan keamanan, mendorong standar modular, dan menerapkan antarmuka standar yang memungkinkan pengguna untuk dengan mudah meningkatkan dan memodifikasi akun pintar mereka.
Selain itu, Akun Kontrak Cerdas Modular (SCA) hanyalah sebagian kecil dari teka-teki adopsi. Untuk mewujudkan potensi penuh SCA, solusi Layer 2 diperlukan untuk memberikan dukungan lapisan protokol tambahan, seperti infrastruktur bundler yang kuat dan kumpulan memori peer-to-peer, mekanisme penandatanganan SCA yang lebih hemat biaya dan layak, sinkronisasi SCA lintas rantai dan mekanisme manajemen, dan pengembangan antarmuka yang ramah pengguna.
Di masa depan, akan ada lebih banyak adopsi SCA, tetapi juga akan menimbulkan beberapa pertanyaan menarik: bagaimana mekanisme nilai ekstraksi penambang tradisional (MEV) memasuki ruang untuk membangun bundler dan menangkap nilai setelah aliran pesanan SCA menjadi cukup menguntungkan, dan bagaimana abstraksi akun (AA) berfungsi sebagai lapisan dasar untuk transaksi "berbasis niat" ketika infrastruktur matang?
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.
Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular
作者:Rui,Investor SevenX Ventures
编译:Luccy,Joyce,BlockBeats
Rui, seorang investor di SevenX Ventures >, mengidentifikasi lima tantangan teratas untuk mengadopsi SCA — dampak pasar beruang, kesulitan migrasi, masalah khas, biaya gas yang tinggi, dan tantangan teknik — dan mendiskusikannya lebih lanjut. Selain itu, analisis arsitektur akun kontrak pintar modular menunjukkan bahwa SCA modular hanyalah sebagian kecil dari tantangan adopsi.
Pergeseran dari akun milik eksternal (EOA) ke akun kontrak pintar (SCA) mendapatkan momentum dan sudah didukung oleh banyak pengusaha inti, termasuk Vitalik. Meskipun demikian, adopsi SCA belum seluas EOA. Masalah utama termasuk dampak pasar bearish, kesulitan memigrasikan EOA ke SCA, masalah tanda tangan, biaya gas yang tinggi, dan yang paling kritis, tantangan pengembangan.
Keuntungan paling signifikan dari Account Abstraction (AA) adalah kemampuan untuk menyesuaikan fungsionalitas menggunakan kode. Namun, non-interoperabilitas fungsionalitas AA menghadirkan tantangan besar, karena fragmentasi ini menghambat integrasi AA dan memperkuat penguncian vendor. Selain itu, ini juga merupakan tantangan penting untuk memastikan keamanan sekaligus dapat ditingkatkan dan disusun.
Munculnya abstraksi akun modular adalah ceruk dalam tren AA, pendekatan inovatif yang memisahkan akun pintar dari fitur khusus mereka. Tujuannya adalah untuk menciptakan struktur modular untuk mengembangkan dompet dengan banyak fitur, keamanan, dan integrasi tanpa batas. Di masa depan, abstraksi akun modular akan memungkinkan akun kontrak pintar gratis "toko aplikasi", memungkinkan dompet dan dApps untuk fokus pada peningkatan pengalaman pengguna daripada harus menghabiskan terlalu banyak usaha membangun fitur.
Abstraksi Akun Singkat (AA)
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-e77dfd1eb3-dd1a6f-cd5cc0.webp)
EOA tradisional membawa banyak tantangan bagi paparan orang terhadap blockchain, seperti frase benih, biaya gas, operasi lintas rantai, dan banyak transaksi.
Abstraksi akun memanfaatkan akun kontrak pintar untuk memungkinkan validasi dan ution yang dapat diprogram. Ini berarti bahwa pengguna akan dapat menyetujui serangkaian transaksi sekaligus, daripada harus menandatangani dan menyiarkan setiap transaksi. Abstraksi akun juga dapat memungkinkan lebih banyak fitur seperti peningkatan pengalaman pengguna (misalnya, abstraksi gas dan kunci sesi), pengurangan biaya (misalnya, transaksi massal), dan peningkatan keamanan (misalnya, pemulihan sosial, multi-tanda tangan). Saat ini, ada dua cara untuk mengabstraksi akun:
· Lapisan protokol: Beberapa protokol secara native menyediakan dukungan abstraksi akun asli, transaksi ZKSync menggunakan mempool tunggal dan aliran transaksi untuk mendukung AA, baik dari EOA dan SCA mengikuti proses yang sama, sementara Starknet telah menghapus EOA, semua akun adalah SCA, dan mereka memiliki dompet kontrak pintar asli seperti Argent.
· Lapisan kontrak: Untuk Ethereum dan L2 serupa, ERC4337 memperkenalkan mempool terpisah untuk mendukung AA tanpa mengubah lapisan konsensus. Tempat-tempat seperti Stackup, Alchemy, Etherspot, Biconomy, Candide, dan Plimico sedang membangun infrastruktur bundler, sementara hal-hal seperti Safe, Zerodev, Etherspot, dan Biconomy sedang membangun bundler dan SDK.
Dilema mengadopsi SCA
Topik abstraksi akun (AA) telah dibahas sejak 2015 dan semakin menjadi sorotan tahun ini oleh ERC 4337. Namun, jumlah akun kontrak pintar yang digunakan masih serendah EOA.
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cd53d3972e-dd1a6f-cd5cc0.webp)
Mari kita selidiki dilema ini:
Terlepas dari keunggulan AA seperti login yang mulus dan abstraksi gas, di pasar beruang saat ini, di mana semua pengguna adalah pengguna EOA yang terdidik dan tidak banyak pengguna baru, tidak ada insentif bagi dApps dan dompet untuk mengadopsi SCA. Meski begitu, beberapa dApps 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 tanpa gas mereka.
Untuk dompet dan aplikasi yang telah mengumpulkan pengguna dan aset, tetap menjadi tantangan untuk memigrasikan aset dengan aman dan nyaman. Namun, skema seperti EIP-7377 memungkinkan EOA untuk memulai transaksi migrasi satu kali.
Kontrak pintar itu sendiri tidak dapat menandatangani pesan karena tidak memiliki kunci pribadi seperti EOA. Upaya seperti ERC1271 memungkinkan hal ini, tetapi penandatanganan pesan tidak berfungsi sampai transaksi pertama, yang pada gilirannya menimbulkan tantangan bagi dompet yang digunakan dengan kontrafaktual. ERC-6492, yang diusulkan oleh Ambire, adalah penerus ERC-1271 yang kompatibel ke belakang dan mungkin dapat memecahkan masalah sebelumnya.
Biaya yang lebih tinggi untuk menyebarkan, mensimulasikan, dan melaksanakan SCA dibandingkan dengan EOA standar juga merupakan penghalang untuk adopsi. Namun, beberapa tes telah dilakukan, seperti memisahkan pembuatan akun dari tindakan pengguna, menghilangkan "garam" yang terkait dengan akun, dan banyak lagi.
Tim ERC-4337 telah membangun repo eth-infinitism yang menyediakan implementasi dasar bagi pengembang. Namun, karena pengembang menskalakan ke fitur yang lebih terperinci dan spesifik untuk kasus penggunaan yang berbeda, integrasi dan decoding menghadapi lebih banyak tantangan. Dalam artikel ini, kita akan menyelami tantangan teknik.
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b50e21334e-dd1a6f-cd5cc0.webp)
Selesaikan tantangan teknik dengan akun kontrak pintar modular
Tantangan teknik dapat dijabarkan lebih lanjut menjadi tiga aspek: fragmentasi, keamanan, dan kemampuan upgrade.
· Fragmentasi: Fitur sekarang dapat diaktifkan dalam berbagai cara, baik melalui SCA tertentu atau melalui sistem plug-in mandiri. Setiap platform dan penyedia layanan mengikuti standarnya sendiri, mendorong pengembang untuk memutuskan platform dan penyedia layanan mana yang akan didukung. Hal ini dapat menyebabkan potensi penguncian platform (vendor) atau pekerjaan yang berlebihan.
· Keamanan: Meskipun memisahkan akun dan fungsi membawa manfaat fleksibilitas, itu juga dapat membuat masalah keamanan menjadi lebih serius. Karena semua fitur dapat ditinjau bersama, kurangnya penilaian independen dapat meningkatkan risiko kerentanan akun.
· Upgradeability: Seiring pertumbuhan akun Anda, penting untuk mempertahankan kemampuan untuk menambahkan, mengganti, atau menghapus fitur, dan setiap pembaruan yang menerapkan ulang fitur yang ada memperkenalkan kompleksitas.
Untuk mengatasi masalah ini, kami memerlukan kontrak yang dapat ditingkatkan untuk memastikan peningkatan yang aman dan efisien, inti yang dapat digunakan kembali untuk meningkatkan efisiensi pengembangan secara keseluruhan, dan antarmuka standar untuk memastikan transisi yang mulus antara frontend yang berbeda.
Istilah-istilah ini bertemu pada konsep umum: membangun arsitektur abstraksi akun modular (Modular AA).
Abstraksi akun modular adalah subdivisi dari pengembangan AA yang lebih luas yang membayangkan modularisasi akun pintar untuk menyediakan layanan yang disesuaikan kepada pengguna dan memungkinkan pengembang untuk meningkatkan fungsionalitas dengan mulus dengan kendala minimal.
Namun, menetapkan dan mempromosikan standar baru dalam industri apa pun merupakan tantangan besar. Sampai semua orang menerima standar yang sama, banyak solusi berbeda dapat muncul pada fase awal. Sangat menggembirakan melihat bahwa mereka yang bekerja untuk memperbaiki dan mempromosikan abstraksi akun, apakah itu 4337 SDK, dompet, tim infrastruktur, atau perancang lapisan protokol, bekerja sama untuk mempercepat proses ini.
Struktur modular: akun master dan modul
Bagaimana akun memanggil modul untuk mengimplementasikan fungsi
Mendelegasikan panggilan dan kontrak proxy
Panggilan eksternal dan delegasi :
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-26b1e8ab3b-dd1a6f-cd5cc0.webp)
Tentang panggilan delegasi
Sementara "panggilan yang didelegasikan" mirip dengan "panggilan", itu tidak dijalankan dalam konteks kontrak target, tetapi dalam konteks keadaan kontrak panggilan saat ini. Ini berarti bahwa setiap perubahan negara yang dibuat oleh kontrak target akan mengubah penyimpanan kontrak panggilan.
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-421fd8f0e1-dd1a6f-cd5cc0.webp)
Kontrak proksi dan panggilan delegasi
** Untuk mencapai struktur yang dapat disusun dan diupgrade, konsep dasar "kontrak agensi" perlu diperkenalkan. **
Kontrak proksi: Kontrak normal menyimpan logika dan statusnya, dan tidak dapat diperbarui setelah penyebaran. Kontrak proksi disebarkan ke kontrak lain menggunakan panggilan delegasi. Terapkan fungsi dengan referensi untuk menjalankannya dalam keadaan kontrak proxy saat ini.
Kasus penggunaan: Meskipun kontrak proxy tetap sama, Anda dapat menerapkan implementasi baru di belakang broker. Kontrak proxy dapat ditingkatkan dan lebih murah untuk digunakan dan dipelihara di blockchain publik.
** Arsitektur Aman **! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4dc82c32d1-dd1a6f-cd5cc0.webp)
Arsitektur yang aman
Apa itu Aman: Aman adalah infrastruktur akun pintar modular terkemuka yang dirancang untuk memberikan keamanan dan fleksibilitas yang telah teruji, dan memungkinkan pengembang untuk membuat beragam aplikasi dan dompet. Banyak tim membangun aplikasi selain (atau terinspirasi oleh) Safe. Misalnya, Biconomy memperluas Safe dengan native 4337 dan 1/1 multisig saat meluncurkan akun kontrak pintarnya. Setelah menyaksikan penyebaran lebih dari 164.000 kontrak dan mengunci nilai lebih dari $ 30,7 miliar, Safe tidak diragukan lagi adalah pemimpin dalam ruangnya.
Struktur Safe mencakup kontrak akun aman, kontrak singleton, dan kontrak modul.
Kontrak proxy: Stateful
Akun aman adalah kontrak proxy karena panggilan yang didelegasikan adalah kontrak tunggal. Akun keamanan berisi variabel di mana pemilik, ambang batas, dan alamat implementasi semuanya ditetapkan sebagai agen, dan statusnya ditentukan berdasarkan ini.
单例合约(singleton contract):Integration Hub(无状态)
Kontrak singleton melayani akun Aman dan mendefinisikan integrasi kontrak modul yang berbeda, termasuk Plugin, Hook, Function Handler, dan Signature Validator.
Modul: Logika dan fungsionalitas kustom
Kontrak modul sangat kuat. Plugin sebagai tipe modular dapat menentukan fungsi yang berbeda seperti alur pembayaran, mekanisme pemulihan, dan kunci sesi, dan dapat bertindak sebagai jembatan antara Web2 dan Web3 dengan mengambil data off-chain. Modul lain, seperti Hook dan Function Handler sebagai penjaga keamanan, dapat menanggapi perintah apa pun.
Perubahan yang telah berubah sejak mengadopsi Safe:
Kontrak yang dapat ditingkatkan: Setiap kali plugin baru diperkenalkan, singleton baru perlu digunakan. Pengguna mempertahankan otonomi untuk meningkatkan Aman ke versi singleton yang diinginkan.
Modul yang dapat disusun dan digunakan kembali: Sifat modular plugin memungkinkan pengembang untuk mengembangkan fitur secara mandiri. Mereka bebas memilih dan menggabungkan plugin ini sesuai dengan kasus penggunaannya, menghasilkan pendekatan yang sangat dapat disesuaikan.
ERC-2535 Berlian 代理
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-dfa51cc0ce-dd1a6f-cd5cc0.webp)
Tentang ERC2535, Agen Berlian:
ERC2535 model Diamond standar, sistem kontrak pintar modular yang dapat ditingkatkan / diskalakan setelah penerapan dengan hampir tidak ada batasan ukuran. Saat ini, banyak tim seperti eksperimen Zerodev's Kernel dan Soul Wallet telah terinspirasi oleh struktur Diamond.
Apa itu Struktur Berlian:**
Kontrak Berlian: Kontrak Proksi Utama (Stateful) Diamond adalah kontrak proksi yang menggunakan metode pemanggilan yang didelegasikan untuk memanggil fungsi dari implementasinya.
Kontrak Modul / Plugin / Facet: Logika dan Fungsionalitas Kustom (Stateless) Modul atau yang disebut Facet adalah kontrak stateless yang dapat menyebarkan fungsinya ke satu atau lebih Berlian. Mereka terpisah, kontrak independen yang dapat berbagi fungsi intrinsik, perpustakaan, dan variabel negara.
Perubahan dengan Diamond:
Kontrak yang Dapat Diupgrade: Diamond menyediakan cara sistematis untuk mengisolasi plugin yang berbeda dan menghubungkannya bersama-sama, berbagi data di antara mereka, dan juga menambah / mengganti / menghapus plugin apa pun secara langsung menggunakan fitur diamondCut. Seiring waktu, tidak akan ada batasan jumlah plugin yang dapat ditambahkan ke Diamond.
Plugin modular dan dapat digunakan kembali: Plugin yang digunakan dapat digunakan oleh sejumlah Berlian, secara dramatis mengurangi biaya penyebaran.
Perbedaan antara Safe Smart Account dan metode Diamond:
Ada banyak kesamaan antara arsitektur Safe dan Diamond, keduanya bergantung pada kontrak proxy inti mereka dan referensi kontrak logis untuk upgradeability dan modularitas.
Perbedaan utama antara keduanya adalah penanganan kontrak logis. Khusus:
· Fleksibilitas: Dengan plugin baru diaktifkan, Safe perlu menerapkan ulang kontrak singleton-nya untuk menerapkan perubahan dalam proxy-nya. Sebaliknya, Diamond mencapai ini secara langsung melalui fungsi diamondCut dalam kontrak proxy-nya. Perbedaan dalam pendekatan berarti bahwa Safe mempertahankan tingkat kontrol yang lebih tinggi, sementara Diamond memperkenalkan peningkatan fleksibilitas dan modularitas.
· Aman: Saat ini digunakan di kedua struktur, memungkinkan kode eksternal untuk memanipulasi penyimpanan kontrak utama. Dalam arsitektur Safe, panggilan delegasi menunjuk ke satu kontrak logis, sementara Diamond menggunakan panggilan delegasi di beberapa modul contracts-plugins. Akibatnya, ada kemungkinan plugin berbahaya menimpa plugin lain, memperkenalkan risiko konflik penyimpanan dan membahayakan integritas proxy.
· Biaya: Dalam pendekatan Diamond, fleksibilitas dan keamanan bersatu. Ini meningkatkan biaya, dan setiap kali plugin baru ditambahkan, itu perlu diaudit sepenuhnya. Kuncinya adalah memastikan bahwa plugin ini tidak mengganggu fungsionalitas satu sama lain, tujuan yang menantang, terutama untuk usaha kecil dan menengah yang berjuang untuk mempertahankan standar keamanan yang tinggi.
"Metode Akun Cerdas Aman" dan "Metode Berlian" adalah contoh struktur berbeda yang melibatkan agen dan modul. Menyeimbangkan fleksibilitas dan keamanan sangat penting, dan kedua pendekatan ini akan terus berkembang dan saling melengkapi di masa depan.
Urutan Modul: Validator, Pelaksana dan Hook
Mari kita bahas ini lebih lanjut dengan memperkenalkan ERC6900, standar yang terinspirasi Diamond dari tim Alchemy yang dirancang khusus untuk ERC-4337. Ini memecahkan tantangan modularitas akun pintar dengan menyediakan antarmuka umum dan mengoordinasikan pekerjaan antara pengembang plugin dan dompet.
Ketika datang ke proses transaksi AA, ada tiga proses utama: validasi, eksekusi, dan pegging. Seperti yang telah kita bahas sebelumnya, langkah-langkah ini semua dapat dikelola dengan menggunakan modul panggilan akun proxy. Sementara proyek yang berbeda mungkin menggunakan nama yang berbeda, penting untuk memahami logika kesamaan yang mendasarinya.
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b01f250655-dd1a6f-cd5cc0.webp)
Nama fungsi dalam desain yang berbeda
Validator: Memastikan keaslian dan izin penelepon akun.
Eksekusi (UTOR): Jalankan logika kustom apa pun yang diizinkan akun.
Hook: Bertindak sebagai modul yang berjalan sebelum atau sesudah fungsi lain. Itu dapat mengubah status atau membatalkan seluruh panggilan.
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-42db1d92a0-dd1a6f-cd5cc0.webp)
Penting untuk memisahkan modul sesuai dengan logika yang berbeda. Pendekatan standar harus menentukan cara menulis fungsi validasi, eksekusi, dan pegging untuk akun kontrak pintar. Baik itu Aman atau ERC6900, standardisasi membantu mengurangi kebutuhan akan upaya pengembangan unik khusus untuk implementasi atau ekosistem tertentu dan mencegah penguncian vendor.
Penemuan dan keamanan modul
Cara menemukan dan memvalidasi modul secara terbuka: Salah satu solusi yang sedang dikembangkan melibatkan pembuatan area yang memungkinkan pengguna menemukan modul yang dapat diverifikasi, yang dapat disebut "registri". Registri berfungsi seperti "toko aplikasi" dan bertujuan untuk mendorong pasar modular yang disederhanakan namun berkembang.
Safe{Core} 协议
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4ff8171cf4-dd1a6f-cd5cc0.webp)
Protokol Safe {Core} adalah protokol sumber terbuka yang dapat dioperasikan untuk akun kontrak pintar yang dirancang untuk meningkatkan aksesibilitas bagi berbagai vendor dan pengembang sambil mempertahankan keamanan yang kuat melalui standar dan aturan yang terdefinisi dengan baik.
· Akun: Dalam protokol Safe {Core}, konsep akun fleksibel dan tidak terikat pada implementasi tertentu. Ini memungkinkan penyedia layanan akun yang berbeda untuk terlibat.
· Manajer: Manajer bertindak sebagai koordinator antara akun, registri, dan modul. Ini juga menjaga keamanan sebagai lapisan lisensi.
· Registri: Registri mendefinisikan atribut keamanan dan memberlakukan standar modul seperti ERC6900 untuk membuat lingkungan "toko aplikasi" terbuka untuk dapat ditemukan dan keamanan.
· Modul: Modul menangani fungsionalitas dan memiliki berbagai jenis awal, termasuk plugin, hook, validator tanda tangan, dan penangan fungsi. Pengembang dapat terlibat selama mereka memenuhi kriteria yang ditetapkan.
Rhinestone 设计
! [Pandangan mendalam tentang arsitektur dan tantangan akun kontrak pintar modular] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-96de12199c-dd1a6f-cd5cc0.webp)
Prosesnya terungkap sebagai berikut:
· Buat skema: Skema menyediakan struktur data yang telah ditentukan sebelumnya. Orang dapat menyesuaikannya agar sesuai dengan kasus penggunaan khusus mereka.
· Buat modul berdasarkan skema: Kontrak pintar yang terdaftar sebagai modul mendapatkan bytecode dan memilih ID skema, dan data disimpan dalam registri.
· Dapatkan pengesahan modul: Prover / auditor dapat memberikan bukti modul berdasarkan arsitektur. Pengesahan ini dapat mencakup pengidentifikasi unik (UID) dan referensi ke pengesahan lain yang digunakan untuk tautan. Mereka dapat menyebar di seluruh rantai dan memverifikasi bahwa rantai target memenuhi ambang batas tertentu.
· Terapkan logika kompleks dengan resolver: Parser (opsional) ikut bermain. Mereka dapat dipanggil selama pembuatan modul, penetapan pengesahan, dan pencabutan. Pengurai ini memungkinkan pengembang untuk mengintegrasikan logika yang kompleks dan beragam sambil mempertahankan struktur bukti.
Akses kueri yang mudah digunakan: Kueri menyediakan cara bagi pengguna untuk mengakses informasi keamanan dari ujung depan.
Sementara model ini masih dalam tahap awal, ia memiliki potensi untuk menetapkan standar dengan cara yang terdesentralisasi dan kolaboratif. Registri memungkinkan pengembang untuk mendaftarkan modul mereka, auditor untuk memverifikasi keamanan mereka, dompet untuk mengintegrasikan, dan memungkinkan pengguna untuk dengan mudah menemukan modul dan memverifikasi informasi pengesahan mereka. Beberapa kegunaan di masa depan dapat berupa:
· Attestor: Entitas tepercaya seperti Safe dapat bekerja dengan Rhinestone sebagai prover untuk modul internal. Pada saat yang sama, pemberi sertifikasi independen juga dapat bergabung.
· Pengembang modul: Dengan pembentukan pasar terbuka, pengembang modul dapat memonetisasi pekerjaan mereka melalui registri.
· Pengguna: Berpartisipasi melalui antarmuka yang ramah pengguna, seperti dompet atau dApp, memungkinkan pengguna untuk memeriksa informasi modul dan mendelegasikan kepercayaan kepada berbagai provers.
Konsep "registri modul" membuka cara bagi pengembang plugin dan modul untuk menghasilkan uang. Ini selanjutnya bisa membuka jalan bagi "pasar modul". Beberapa aspek mungkin diawasi oleh tim Safe, sementara yang lain mungkin bermanifestasi sebagai pasar terdesentralisasi yang mengundang semua orang untuk berkontribusi dan memberikan jejak audit yang transparan. Menggabungkan ini menghindari penguncian vendor dan mendukung perluasan EVM dengan menambahkan pengalaman pengguna yang ditingkatkan yang menarik bagi khalayak yang lebih luas.
Meskipun metode ini menjamin keamanan modul individual, akun kontrak pintar tidak mudah dalam hal keamanan yang lebih luas. Ini bisa menjadi tantangan untuk digabungkan dengan modul kepatuhan dan membuktikan bahwa mereka tidak memiliki konflik penyimpanan, yang menyoroti pentingnya dompet atau infrastruktur AA dalam mengatasi masalah tersebut.
Ringkasan
Dengan memanfaatkan tumpukan akun kontrak pintar modular, penyedia dompet dan dApps dapat dibebaskan dari kerumitan pemeliharaan teknis. Pada saat yang sama, pengembang modul eksternal memiliki kesempatan untuk memberikan layanan profesional yang dipersonalisasi. Namun, tantangan yang perlu diatasi termasuk mencapai keseimbangan antara fleksibilitas dan keamanan, mendorong standar modular, dan menerapkan antarmuka standar yang memungkinkan pengguna untuk dengan mudah meningkatkan dan memodifikasi akun pintar mereka.
Selain itu, Akun Kontrak Cerdas Modular (SCA) hanyalah sebagian kecil dari teka-teki adopsi. Untuk mewujudkan potensi penuh SCA, solusi Layer 2 diperlukan untuk memberikan dukungan lapisan protokol tambahan, seperti infrastruktur bundler yang kuat dan kumpulan memori peer-to-peer, mekanisme penandatanganan SCA yang lebih hemat biaya dan layak, sinkronisasi SCA lintas rantai dan mekanisme manajemen, dan pengembangan antarmuka yang ramah pengguna.
Di masa depan, akan ada lebih banyak adopsi SCA, tetapi juga akan menimbulkan beberapa pertanyaan menarik: bagaimana mekanisme nilai ekstraksi penambang tradisional (MEV) memasuki ruang untuk membangun bundler dan menangkap nilai setelah aliran pesanan SCA menjadi cukup menguntungkan, dan bagaimana abstraksi akun (AA) berfungsi sebagai lapisan dasar untuk transaksi "berbasis niat" ketika infrastruktur matang?