Singkatnya;

Sejak tahun 2022, abstraksi akun telah banyak dibahas dalam bidang ini, dan kerangka kerja yang berpusat di sekitar EIP-4337 nampaknya telah menjadi konsensus umum di industri. Popularitas konsep abstraksi telah mendorong orang untuk lebih memperhatikan komponen interaksi pengguna dengan ambang batas rendah seperti itu.

Namun, EIP-4337 masih menghadapi titik-titik kesulitan seperti Fragmentasi Akun Pintar dan pengalaman pengguna yang sangat terfragmentasi di berbagai rantai. Artikel ini mengambil proyek-proyek seperti Biconomy, Safe Core, dan Jaringan Partikel sebagai contoh untuk menjelajahi bagaimana mempromosikan lebih lanjut pengembangan bidang abstraksi akun dalam kerangka EIP-4337.

Dari perspektif abstraksi proses transaksi, memahami konsep "abstraksi akun"

Mengenai abstraksi akun, Vitalik telah berulang kali menekankan bahwa itu adalah kondisi yang diperlukan untuk mengurangi ambang batas pengguna untuk Ethereum dan mencapai adopsi massal. Visi intinya adalah memungkinkan pengguna untuk menyesuaikan metode verifikasi tanda tangan + menikmati pembayaran gas, dan memulai transaksi on-chain tanpa aset apa pun (yang dikenal sebagai transaksi bebas gas). Hanya dengan memenuhi prasyarat ini, tingkat konversi pengguna baru ke aplikasi Web3 dapat ditingkatkan.

Proposal sebelumnya yang tidak menggunakan abstraksi akun atau dompet kontrak pintar, meskipun dapat mencapai pengalaman serupa, masih belum cukup fleksibel dan efisien. Misalnya, Gnosis Safe masih memerlukan alamat EOA untuk memicu transaksi, dan biaya gas sangat tinggi.

Abstraksi akun bermaksud untuk mengoptimalkan dari struktur dasar akun kontrak pintar, membuka jalan bagi generasi berikutnya dari sistem akun cerdas.

Namun, jika kita melihat proposal abstraksi akun sebenarnya, kita akan menemukan bahwa fokusnya bukan pada model akun itu sendiri. Misalnya, proposal terkait abstraksi akun seperti EIP-86, EIP-4337, dan EIP-6900 berfokus pada mengabstraksi/memodulkan alur pemrosesan keseluruhan transaksi mulai dari inisiasi hingga diterima oleh node, verifikasi tanda tangan, pembayaran gas, dll., daripada benar-benar fokus pada mengabstraksi struktur akun. Oleh karena itu, tampaknya lebih tepat untuk merujuk berbagai proposal ini sebagai "abstraksi transaksi".

Jika kita memahami proposal abstraksi akun yang terkenal dari perspektif “abstraksi alur pemrosesan transaksi”, kita dapat lebih mudah memahami poin-poin kuncinya: abstraksi transaksi semacam ini sebenarnya bertujuan untuk membawa pengalaman pengguna tingkat Web2 saat memasuki dan menggunakan produk ke dalam sistem Ethereum, seperti daftar hitam/putih, transaksi yang dimulai dalam periode tanpa verifikasi identitas, transaksi tanpa biaya gas, pembayaran biaya dengan mata uang fiat, dll.

Beberapa orang mungkin bertanya: Bukankah fungsionalitas ini bisa dicapai di masa lalu dengan dompet kontrak pintar yang sudah ada? Apa nilai skema abstraksi akun seperti EIP-4337?

Esensi dari EIP-4337: Abstraksi Akun sebagai Solusi Optimal Lokal dalam Ekosistem Ethereum

Seperti yang diungkapkan pertanyaan, sementara dompet pintar masa lalu memang bisa mencapai fungsionalitas yang disebutkan, metode implementasinya sering kali kasar dan sering kali bergantung pada fasilitas pihak ketiga yang sangat terpusat. Misalnya, skema pembayaran gas sebelumnya memerlukan pengenalan node Relayer pihak ketiga (EIP-2771). Selain itu, kurangnya standar yang bersatu di antara implementasi dompet pintar yang berbeda menghambat pengembangan dan implementasi komponen-komponen yang saling melengkapi.

Tujuan inti dari berbagai EIP yang terkait dengan abstraksi akun adalah untuk mengatasi kekurangan-kekurangan tersebut yang ada dalam berbagai proyek dompet dengan memperkenalkan kerangka kerja standar yang dirancang khusus untuk dompet kontrak pintar. Kerangka kerja ini bertujuan untuk mentransisi struktur akun dalam ekosistem Ethereum dari struktur fungsional dasar menjadi struktur cerdas yang lebih canggih, sehingga meningkatkan efisiensi dan skalabilitas keseluruhan ekosistem.

Hal ini analog dengan situasi sebelum ERC-20 atau ERC-721 muncul, di mana metode implementasi, fungsionalitas, dan fungsi antarmuka dari banyak token tidak konsisten. Ketidak konsistenan seperti itu tidak mendukung pengembangan fasilitas pihak ketiga yang saling mendukung dan pemeriksaan kode (sulit untuk membayangkan sejauh mana aplikasi DeFi bisa berkembang tanpa protokol ERC-20).

Protokol standar/standar implementasi fungsional adalah prasyarat untuk narasi modular, dan pendekatan pengembangan modular hampir menjadi prasyarat untuk pengembangan yang berkembang di bidang apa pun (pembagian kerja menjadi prinsip efisiensi yang pertama).

Pada akhirnya, EIP-4337 muncul.

EIP-4337 adalah solusi optimal lokal, tetapi ada beberapa sudut pandang dalam kerangka kerjanya yang memerlukan optimisasi dengan mendesak.

EIP-4337 mendefinisikan seperangkat standar antarmuka lengkap, menjelaskan modul-manakah yang harus dimiliki dompet pintar yang mengikuti protokol 4337, dan fungsi/antarmuka apa yang harus diimplementasikan oleh setiap modul, seperti Bundler, EntryPoint, dan Paymaster, serta fungsi yang dapat dipanggil yang harus disediakan oleh komponen-komponen tersebut.

Setelah spesifikasi ini jelas didefinisikan, interaksi antara komponen-komponen yang berbeda menjadi lebih jelas, sehingga lebih mudah untuk memperkenalkan pemikiran desain modular ke dalam desain abstraksi akun dan dompet pintar, sangat menguntungkan pengembang modul dompet.

Tentu saja, dari sudut pandang pengguna, nilai yang dibawa oleh paradigma pengembangan dompet pintar modular belum jelas karena pengguna mungkin tidak merasakan banyak perubahan di dompet abstraksi akun itu sendiri dalam jangka pendek. Namun, dalam jangka menengah hingga panjang, nilai protokol seperti EIP-4337 mirip dengan ERC-20 dan ERC-721. Ini meletakkan dasar bagi pengembangan jangka panjang dari dompet abstraksi akun dan merupakan tonggak penting yang bersejarah.

Namun, EIP-4337 masih memiliki banyak isu yang belum terselesaikan, seperti:

1. Fungsionalitas abstraksi akun tidak cukup plug-and-play, membuatnya mudah bagi pengembang yang berbeda untuk mengulangi hal yang sudah ada.

2. Kompatibilitas modul akun yang buruk menyebabkan ekosistem sistem akun yang terpecah belah.

3. Ekosistem abstraksi akun yang sangat terfragmentasi antar rantai yang berbeda membuat sulit bagi pengguna akhir dan pengembang untuk memberikan pengalaman yang seragam dan berkualitas tinggi untuk mencapai UX yang lebih baik.

Dalam bagian berikut, kami akan membahas solusi untuk masalah-masalah tersebut.

Orientasi Optimisasi Satu: Fungsionalitas Plug-and-play Modulasi Abstraksi Akun Akan Menjadi Konfigurasi Dasar

Bisa dikatakan bahwa salah satu titik diskusi inti saat ini terkait dengan abstraksi akun adalah bagaimana cara lebih baik mencapai modularisasi dompet abstraksi akun dan membuat pembagian setiap modul lebih halus.

Sebagai contoh, Biconomy, berdasarkan EIP-4337 (dan akan memperkenalkan EIP-6900 yang lebih halus di masa depan), mengusulkan narasi fungsionalitas modular plug-and-play modularisasi abstraksi akun untuk lebih mempromosikan pengembangan modular dari ekosistem abstraksi akun.

Fungsionalitas plug-and-play dari modularisasi abstraksi akun yang disebutkan telah secara esensial dicapai melalui protokol yang secara eksplisit menguraikan modul kunci yang terlibat dalam dompet kontrak pintar, antarmuka/fungsi apa yang harus diimplementasikan oleh modul ini, dan bagaimana antarmuka ini dinamai dan dipanggil. Selanjutnya, pengembang pihak ketiga akan mengembangkan komponen dengan berbagai detail sesuai dengan ide mereka sendiri, tetapi komponen-komponen ini akan sesuai dengan persyaratan yang diuraikan dalam protokol.

Versi V2 Biconomy, berbasis pada EIP-4337 sebagai kerangka protokol, telah menetapkan standar yang lebih terperinci dan menambahkan sekelompok antarmuka yang tidak disebutkan dalam 4337. Sambil menetapkan fungsionalitas yang harus dimiliki oleh Bundler, Smart Contract Wallet, Paymaster, dan modul lainnya, Biconomy memungkinkan pengembang pihak ketiga untuk mengimplementasikan modul dengan detail kode yang berbeda namun fitur yang serupa dan versi yang berbeda, selama sesuai dengan aturan protokol yang telah ditetapkan oleh Biconomy (kompatibel dengan EIP-4337).

Sementara itu, Biconomy juga memperkenalkan slogan dari “Module Store.” Sambil secara aktif meluncurkan SDK modul abstraksi akun, Biconomy mendorong para pengembang untuk mengirimkan modul abstraksi akun yang mereka desain sendiri dan memulai “Module as a Service,” memungkinkan semua proyek dompet yang mematuhi protokol EIP-4337 untuk langsung mengadopsi modul abstraksi akun yang ditulis oleh pihak ketiga ini. Ketika pengguna membuat akun pintar melalui antarmuka front-end, mereka juga akan memiliki pilihan modul yang lebih beragam untuk dipilih.

Modularisasi tidak hanya memudahkan pembagian kerja tetapi juga memungkinkan pengguna untuk dengan cepat beralih, menambahkan, atau menghapus fitur-fitur tertentu dalam dompet pintar (dalam istilah yang lebih sederhana, ini memecah granularitas menjadi komponen-komponen yang lebih halus).

Biconomy menunjukkan bahwa semakin tinggi tingkat modularisasi dalam dompet kontrak pintar, semakin sedikit perubahan yang diperlukan saat memperbarui atau meng-upgrade (tidak perlu memperbarui kontrak Dompet Kontrak Pintar yang sudah ada pengguna atau menggunakan DelegateCall, hanya beberapa modul eksternal tertentu perlu diperbarui), sehingga lebih mudah bagi pengguna atau pengembang yang berbeda untuk mengganti beberapa komponen tertentu.

Pada versi masa depan solusi abstraksi akun baru Biconomy, juga akan merujuk ke EIP-6900, yang lebih mendukung modularisasi daripada EIP-4337.

Optimisasi Arah Dua: Segmentasi Modul Lebih Halus untuk Mengatasi Masalah Fragmentasi Akun

Terkait proposal EIP-6900, Safe (dulu Gnosis Safe) sebenarnya merilis whitepaper Protokol Inti Safe terkait hal itu pada bulan Agustus tahun ini, yang sangat dipengaruhi oleh EIP-6900.

EIP-6900 menunjukkan bahwa masalah saat ini dengan abstraksi akun termodulasi adalah masalah "fragmentasi" atau "pulau" akun. Misalnya, sementara penyedia modul abstraksi akun yang berbeda atau aplikasi DApp yang berbeda mungkin kompatibel dengan EIP-4337, tingkat abstraksi EIP-4337 untuk modul yang berbeda tidak cukup tinggi, dan granularitasnya relatif kasar. Ini meninggalkan kebebasan "berlebihan" bagi pengembang modul Akun Pintar (akun pintar menyimpan informasi pengguna dan mencatat bagian inti dari verifikasi transaksi khusus dan logika pembayaran gas).

Sebagai hasilnya, proyek dompet yang berbeda cenderung mendesain modul Akun Pintar dengan atribut unik. Seiring waktu, penyedia modul abstraksi akun lainnya harus memprioritaskan kompatibilitas dengan modul Akun Pintar yang disediakan, menyebabkan munculnya rantai pasokan hulu dan hilir yang tetap. Hal ini tak terelakkan menyebabkan fragmentasi dan putusnya hubungan dalam ekosistem modul abstraksi akun. (Hal ini mirip dengan di awal industri komputer ketika pengembang sistem operasi harus mempertimbangkan kompatibilitas dengan perangkat keras dari berbagai produsen perangkat keras komputer yang berbeda.)

Untuk mengatasi masalah fragmentasi ekosistem dan meningkatkan kompatibilitas antara modul abstraksi akun yang dikembangkan oleh penyedia yang berbeda, pendekatan terbaik adalah dengan lebih memabstract akun dompet kontrak pintar dan membuat granularitas segmentasi modul menjadi lebih halus.

Setelah menggabungkan gagasan dari EIP-6900, whitepaper Protokol Inti Aman melakukan optimisasi yang lebih detail terhadap Akun Pintar (akun dompet kontrak pintar pengguna). Protokol Inti Aman membagi setiap modul yang dapat dipanggil dari akun dompet kontrak pintar ke berbagai kategori seperti Plugin, Hook, validator tanda tangan, dan pengolah fungsi.

Modul akun pintar dibuat se ringan mungkin, dengan kontrak akun hanya menyimpan data dan fungsi paling dasar, sementara fungsi yang dapat dipindahkan ke luar diimplementasikan oleh modul khusus seperti "pemroses fungsi" atau "Plugins." Ini sesuai dengan prinsip Occam's Razor: "Entitas tidak boleh diperbanyak secara tidak perlu."

Jika akun pintar itu sendiri cukup ringan dan tidak melibatkan terlalu banyak detail rumit, akun pintar yang dikembangkan oleh produsen yang berbeda akan lebih mirip dalam struktur internal, dan kompatibilitas juga akan lebih tinggi.

Protokol inti Safe juga memperkenalkan registri, mirip dengan iPhone App Store, yang berisi semua modul yang disetujui dan tersedia. Pengguna dapat memilih modul mana yang akan diaktifkan, dan setiap kali modul baru diaktifkan, itu harus diproses melalui kontrak Manger.

Secara umum, UserOperation akan pertama kali memicu Plugin tertentu, dan kemudian kontrak Manager akan memeriksa apakah status Plugin normal (tercatat dalam registri). Jika normal, kontrak Manager akan mengizinkan permintaan Plugin untuk dilanjutkan. Jika perlu, Plugin dapat memanggil beberapa fungsionalitas yang disediakan oleh beberapa Hooks, atau mungkin tidak. Setelah itu, status akun pintar yang terlibat dalam UserOperation akan dimodifikasi.

Melalui segmentasi modul yang halus dan proses penjadwalan di atas, Protokol Inti Aman mencoba mempromosikan protokol interoperabilitas modul abstraksi akun sumber terbuka. Ide intinya adalah untuk membuat Akun Pintar semudah mungkin, menjadikannya seringan mungkin seperti akun EOA, guna meningkatkan kompatibilitas antara modul Akun Pintar yang dikembangkan oleh produsen yang berbeda.

Optimalkan Arah Tiga: Abstraksi Akun yang Tersentralisasi di Seluruh Rantai, Mencapai Akun yang Konsisten di Rantai yang Berbeda

Namun, bahkan dengan solusi yang disebutkan di atas, masih ada masalah utama yang belum terselesaikan: rantai yang berbeda dan solusi Layer 2 yang berbeda sedang mengembangkan berbagai skema implementasi abstraksi akun yang bertentangan dengan bentuk yang berbeda, banyak di antaranya bertentangan dengan EIP-4337, seperti Era zkSync, Starknet, Flow, dan lainnya. Fragmentasi ini dalam UX dompet, misalnya, membuat tidak mungkin untuk menyatukan alamat dompet pintar pengguna di Starknet dengan yang di Arbitrum.

Selain itu, dalam lingkungan multi-rantai, pengguna telah mandiri mendeploy Akun Pintar di rantai-rantai yang berbeda, dan data pengguna mereka yang sesuai sering disimpan dalam kontrak-kontrak ini. Jika data pengguna seperti kunci perlu diperbarui, transaksi harus diulang di sejumlah rantai, sehingga sulit untuk memastikan konsistensi Akun Pintar.

Vitalik sendiri sebelumnya mengusulkan solusi akun pintar yang terpadu dan mudah dikelola di semua rantai. Solusi ini menggunakan Ethereum atau ZKRollup yang sangat aman sebagai rantai sumber, mendeploy kontrak Keystore untuk menyimpan kunci global pengguna, dan kemudian semua akun kontrak pintar di Layer 2 membagi kunci global yang disimpan dalam kontrak Keystore.

Namun, solusi ini datang dengan biaya yang sangat tinggi. Setiap kali terjadi perubahan kunci global yang dicatat oleh kontrak Keystore pada rantai sumber, setiap akun pada rantai L2/tujuan perlu melakukan sinkronisasi kunci baru melalui interaksi lintas-rantai. Namun, biaya interaksi lintas-rantai antara Ethereum dan L2 terlalu tinggi bagi pengguna untuk mampu. Selain itu, penting untuk dicatat bahwa akun kontrak pintar berbeda dari akun EOA. Sementara yang terakhir, karena metode penghasilan alamat unik mereka, secara alami disatukan di berbagai rantai (di dalam ekosistem EVM), akun kontrak pintar benar-benar berbeda, sehingga sulit bagi pengguna untuk mendapatkan akun kontrak pintar dengan alamat yang sama di rantai yang berbeda.

Sebagai respons atas hal ini, Jaringan Particle telah mengusulkan pendekatan mereka sendiri. Meskipun ide umumnya sejalan dengan konsep Vitalik tentang memisahkan Penyimpanan dan Kode dari akun pintar, Jaringan Particle berencana untuk menggunakan rantai terpisah—Rantai Jaringan Particle—sebagai database Penyimpanan penuh rantai untuk akun pintar. Melalui solusi pesan lintas rantai pihak ketiga (seperti LayerZero, CCIP, Axelar, Connext, dll.), Particle Network bermaksud untuk menyinkronkan perubahan Penyimpanan akun ke Akun lokal rantai lainnya.

(Struktur Abstraksi Akun Multi-Chain Jaringan Particle)

Secara khusus, sistem abstraksi akun lengkap Jaringan Particle bertujuan untuk memberikan pengguna dengan alamat akun kontrak pintar yang seragam di berbagai rantai EVM. Ini memerlukan penyebaran serangkaian Kontrak Deployer di berbagai rantai. Pengguna harus memicu pembangkitan akun baru di Rantai Jaringan Particle, setelah itu Rantai Particle akan memicu semua Kontrak Deployer di berbagai rantai untuk memastikan bahwa alamat akun kontrak pintar yang dihasilkan untuk pengguna di berbagai rantai konsisten. Atau, pengguna dapat menyelesaikan interaksi multi-rantai melalui kontrak di rantai Particle tanpa menyadari rantai lain, dan mereka dapat menggunakan Token Gas Tersatukan sebagai metode pembayaran biaya yang seragam.

Abstraksi akun full-chain juga memungkinkan Operasi Pengguna lintas Rantai, memungkinkan pengguna untuk memicu transaksi pada rantai target melalui Operasi Pengguna dan membayar gas yang sesuai pada rantai sumber. Sebagai contoh, ini memungkinkan pembelian NFT di Base menggunakan USDC Polygon.

Namun, solusi Jaringan Particle memerlukan upaya yang sangat terkoordinasi antara Kontrak Pengepakan dan komponen pesan lintas rantai untuk menyinkronkan akun multi-rantai dan Penyimpanan rantai sumber. Hal ini menempatkan tuntutan tinggi pada oracle atau jembatan pesan lintas rantai yang digunakan (sebuah tantangan yang tampaknya ada dalam semua solusi terkait interoperabilitas rantai penuh).

Namun demikian, sinkronisasi akun lintas rantai pengguna dapat dikonfigurasi secara fleksibel dengan berbagai kombinasi Jembatan Pesan, daripada bergantung pada satu Jembatan saja. Sebagai contoh, dapat dikonfigurasi dengan kebijakan 2/3, di mana perubahan pada Penyimpanan di rantai target dikonfirmasi hanya setelah dua dari LayerZero, Axelar, atau Connext mengonfirmasi perubahan tersebut, yang dapat mengurangi masalah ketergantungan pada satu titik.

Interoperabilitas yang mulus di seluruh rantai EVM dan non-EVM merupakan langkah lebih lanjut dalam abstraksi rekening penuh rantai dalam ekosistem Ethereum. Meskipun terdapat kemajuan dalam manajemen kunci dan rekening yang terpadu di seluruh rantai EVM, masih ada ruang untuk optimasi dalam abstraksi rekening penuh rantai. Rantai yang tidak kompatibel dengan EVM, seperti Aptos, Solana, dan Sui, tidak dapat menjamin konsistensi alamat rekening kontrak pintar yang dihasilkan oleh pengguna dengan yang ada di rantai EVM. Selain itu, rantai non-EVM mungkin mengalami kesulitan dalam mengadopsi konsep abstraksi rekening penuh rantai yang diusulkan oleh Vitalik dan Particle Network tanpa menerapkan solusi equivalen untuk protokol EIP-4337.

Selain itu, masih ada ruang untuk perbaikan dalam proyek dompet yang kompatibel dengan EIP-4337. Sebagian besar dompet pintar menggunakan node Bundler yang dioperasikan secara independen oleh platform masing-masing, yang seringkali tidak saling terhubung. Isolasi ini menimbulkan risiko seperti resistensi sensor dan ketersediaan. Membangun antarmuka frontend yang terpadu di sebagian besar rantai akan sangat menantang. Salah satu pendekatan untuk mengatasi hal ini adalah dengan memperkenalkan desain yang berpusat pada niat, menambahkan lapisan di atas abstraksi akun penuh rantai, memperlakukan ekosistem EIP-4337 Ethereum atau fasilitas abstraksi akun asli rantai lainnya (seperti zkSync) sebagai contoh spesifik di bawah kategori Solver/Reaktor, dengan pemilihan Solver yang cocok menjadi tugas tingkat lebih tinggi.

Mengambil Jaringan Partikel sebagai contoh, ia mengusulkan abstraksi yang ringkas dari implementasi Berbasis-Intent, di mana proyek abstraksi akun yang berbeda hanyalah contoh yang disertakan dalam kategori Solver dalam skema Intent.

Pertama, antarmuka pengguna bertanggung jawab untuk menerjemahkan permintaan bahasa alami atau interaksi pengguna apa pun menjadi deskripsi programatik tertentu, yang mencakup kendala input dan kendala output (dengan kata lain, kondisi untuk input yang dapat diterima dan rentang hasil output yang dapat diterima). Selanjutnya, satu atau lebih Penyelesaian dalam jaringan Penyelesaian akan meneruskan Transaksi yang berisi kendala input-output tertentu ke kontrak Penyelesaian yang diterapkan di rantai (Penyelesaian mencakup tidak hanya fasilitas node tetapi juga komponen kontrak on-chain). Kontrak Penyelesaian kemudian akan meneruskan instruksi Tujuan ke kontrak Reaktor (yang mengelola akun on-chain pengguna), mendelegasikan eksekusi untuk menyelesaikan interaksi akhir.

Permintaan pengguna awalnya diterima oleh jaringan Solver, memungkinkan pengguna tidak perlu terlalu khawatir dengan rantai-rantai yang mendasarinya atau konstruksi skema abstraksi akun yang berbeda, karena bagian ini ditangani oleh Solver untuk membuat solusi-solusi spesifik.

Tentu saja, gagasan-gagasan ini saat ini hanya merupakan kerangka teoritis, dan detail implementasinya masih menunggu penyebaran resmi oleh Jaringan Particle. Yang jelas adalah bahwa akan muncul pasar Solver yang kompetitif di masa depan, di mana pengguna dapat memulai lelang untuk beberapa Solver untuk mengajukan solusi yang berbeda. Melalui transaksi simulasi lokal, solusi optimal dapat dipilih dan Solver yang sesuai dapat diberi imbalan. Mengenai bentuk insentif, itu bergantung pada pertimbangan para perancang protokol jaringan Solver (Particle Network bermaksud menggunakan token PNT sebagai insentif untuk pasar lelang Solver-nya).

Intent saat ini pada dasarnya melindungi detail-detail kompleks yang mendasarinya dan mengabstraksi lapisan yang lebih tinggi. Desain berlapis seperti protokol TCP/IP diperlukan untuk pengalaman pengguna dan pengembang yang mulus dalam interoperabilitas lintas rantai.

Merangkul adopsi luas abstraksi akun

Ketika kami mengoptimalkan kerangka 4337 dalam ekosistem Ethereum dari berbagai sudut pandang dan secara bersamaan mempromosikan interoperabilitas yang mulus di seluruh ekosistem Ethereum dan non-Ethereum, untuk mendukung adopsi luas abstraksi akun, kami percaya bahwa masih diperlukan produk yang mencakup kedua sisi pasokan dan permintaan. Ini tidak hanya harus mengurangi hambatan bagi pengguna akhir untuk menggunakan berbagai layanan produk Web3 tetapi juga fokus pada pengembang layanan untuk menurunkan ambang batas mereka.

Salah satu produk terbaik untuk memainkan peran ini adalah produk Modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-a-Service) dari Particle Network:

Layanan ini menyediakan API yang mudah digunakan yang memungkinkan pengembang untuk secara mulus mengintegrasikan fungsionalitas abstraksi akun modular ke dalam aplikasi mereka. Pengembang dapat menggunakan layanan ini untuk membuat dan mengelola akun di berbagai rantai, melakukan interaksi lintas rantai, dan memanfaatkan metode pembayaran biaya yang terpadu. Layanan seperti ini akan menawarkan para pengembang cara yang lebih fleksibel dan nyaman untuk membangun aplikasi multi-rantai, sehingga mempromosikan adopsi luas dari abstraksi akun.

Selain fitur yang ramah pengembang yang disebutkan di atas, aspek paling penting adalah bahwa produk Wallet Pintar Modular-as-a-Service (Modular Smart Wallet-as-a-Service) dari Jaringan Particle telah membangun ekosistem terbuka untuk abstraksi akun dalam komunitas pengembang, berdasarkan perhitungan tanda tangan. Selain menyediakan modul produk abstraksi akun yang dikembangkan sendiri, itu mengintegrasikan berbagai jenis produk dan layanan abstraksi akun, memfasilitasi adopsi cepat produk dan layanan dari berbagai pengembang di seluruh domain abstraksi akun.

Dengan menyelaraskan teknologi dengan permintaan dan mengatasi batasan kerangka kerja ERC-4337 dari segala sudut, peningkatan dalam pengalaman pengembang akan mempercepat munculnya lebih banyak produk dengan pengalaman pengguna yang luar biasa. Hal ini akan mempercepat transisi industri Web3 dari yang ramah bagi para penggemar kripto yang berorientasi keuangan menjadi ramah konsumen dan mainstream.

Disclaimer：

1. Artikel ini dicetak ulang dari[Tencent website], Semua hak cipta milik penulis asli [Peter Pan, Co-founder dan CTO dari Jaringan Partikel & Faust，极客Web3]. Jika ada keberatan terhadap pencetakan ulang ini, harap hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran 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.