Pengantar

Peralihan dari Akun Milik Eksternal (EOA) ke Akun Kontrak Cerdas (SCA) mendapatkan momentum dan telah diterima oleh banyak peminat, termasuk Vitalik sendiri. Meskipun terdapat kegembiraan, penerapan SCA tidak seluas EOA. Tantangan utama yang dihadapi adalah tantangan yang ditimbulkan oleh pasar yang sedang lesu, kekhawatiran akan migrasi, masalah penandatanganan, biaya overhead gas, dan yang paling penting, kesulitan teknis.

Keuntungan paling signifikan dari Abstraksi Akun (AA) adalah kemampuan menggunakan kode untuk menyesuaikan fungsionalitas. Namun, salah satu tantangan teknik utama adalah tidak dapat dioperasikannya fungsi AA, dan fragmentasi menghambat integrasi dan membuka pintu bagi vendor lock-in. Selain itu, memastikan keamanan sekaligus meningkatkan dan menyusun fitur bisa jadi rumit.

Masuk ke Abstraksi Akun Modular, sebagai bagian dari gerakan AA yang lebih luas, pendekatan inovatif ini dapat 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 mewujudkan “app store” gratis untuk akun kontrak pintar yang mengatur dompet dan dApps bebas dari fitur bangunan tetapi berfokus pada pengalaman pengguna.

Setelah membaca artikel ini, pembaca akan mendapatkan wawasan tentang:

1. Apa itu Abstraksi Akun Modular
2. Bagaimana akun berinteraksi dengan modul
3. Apa urutan pemanggilan modul
4. Cara menemukan dan memverifikasi modul secara terbuka

Review Singkat AA

Lanskap SCA

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 yang memungkinkan validasi dan eksekusi yang dapat diprogram, di mana pengguna dapat menyetujui serangkaian transaksi sekaligus, daripada menandatangani dan menyiarkan masing-masing transaksi, dan mengimplementasikan lebih banyak fitur. Ini memperkenalkan manfaat pada pengalaman pengguna (mis. abstraksi gas, dan kunci sesi), biaya (mis. transaksi batching), dan keamanan (mis. pemulihan sosial, multi-sig). Saat ini, ada dua cara untuk mencapai abstraksi akun:

1. Lapisan protokol: Beberapa protokol sendiri menyediakan dukungan abstraksi akun asli, transaksi ZKsync mengikuti alur yang sama baik berasal dari EOA atau SCA yang menggunakan mempool tunggal dan alur transaksi untuk mendukung AA, dan Starknet telah menghapus EOA dan semua akun adalah SCA, dan mereka memiliki dompet kontrak pintar asli seperti Argent.
2. Lapisan kontrak: Untuk Ethereum dan L2 yang setara, ERC4337 memperkenalkan titik masuk terpisah untuk transaksi guna mendukung AA tanpa mengubah lapisan konsensus. Proyek seperti Stackup, Alchemy, Etherspot, Biconomy, Candide, dan Plimico sedang membangun infrastruktur bundler, dan masih banyak lagi proyek seperti Safe, Zerodev, Etherspot, dan Biconomy yang sedang membangun stack dan SDK.

👉 Jika Anda belum familiar dengan AA atau ERC4337, lihat riset SevenX sebelumnya di sini.

Dilema Adopsi SCA

Topik Abstraksi Akun (AA) telah dibahas sejak tahun 2015 dan semakin menjadi pusat perhatian oleh ERC4337 tahun ini. Namun, jumlah akun kontrak pintar yang diterapkan masih kalah jika dibandingkan dengan EOA.

Mari kita selidiki dilema ini:

1. Dampak Pasar Beruang:
   Meskipun AA memperkenalkan manfaat seperti login tanpa batas dan abstraksi gas, pasar bearish yang ada terutama terdiri dari pengguna EOA yang berpendidikan dibandingkan pengguna baru, sehingga tidak ada insentif untuk dApps dan dompet. Meskipun demikian, aplikasi terkemuka masih dalam proses mengadopsi AA, seperti Cyberconnect yang mendorong sekitar 360.000 UserOps (transaksi AA) dalam sebulan saja dengan memperkenalkan sistem AA dan solusi tanpa gas.
2. Hambatan Migrasi:
   Untuk dompet dan aplikasi yang telah mengumpulkan pengguna dan menyimpan aset di EOA, memigrasikan aset dengan aman dan nyaman tetap menjadi tantangan. Namun demikian, inisiatif seperti EIP-7377 mengizinkan EOA untuk memulai transaksi migrasi satu kali.
3. Masalah Penandatanganan:
   Kontrak pintar itu sendiri secara alami tidak dapat menandatangani pesan, karena tidak memiliki kunci pribadi seperti EOA. Upaya seperti ERC1271 memungkinkan hal ini tetapi penandatanganan pesan tidak akan berfungsi hingga transaksi pertama, yang menimbulkan tantangan bagi dompet yang menggunakan penerapan kontrafaktual. Dan ERC-6492 yang diusulkan oleh Ambire adalah penerus ERC-1271 yang kompatibel dengan versi sebelumnya yang berpotensi memecahkan masalah sebelumnya.
4. Biaya Overhead Gas:
   Penerapan, simulasi, dan pelaksanaan SCA memerlukan biaya yang lebih tinggi dibandingkan dengan EOA standar. Hal ini menjadi penghalang untuk diadopsi. Namun, beberapa pengujian telah dilakukan, seperti memisahkan pembuatan akun dari operasi pengguna, dan menghilangkan garam akun serta pemeriksaan keberadaan sedang dipertimbangkan untuk mengurangi biaya ini.
5. Kesulitan Teknik:
   Tim ERC-4337 telah menyiapkan repo eth-infinitism untuk memberikan implementasi dasar kepada pengembang. Namun, seiring kami memperluas fungsi yang lebih bernuansa atau spesifik untuk berbagai kasus penggunaan, integrasi dan decoding menjadi tantangan.

Pada artikel ini, kita akan mendalami masalah #5: kesulitan teknis.

🤔️

Akun Kontrak Cerdas Modular untuk Mengatasi Kesulitan Teknik

Untuk menguraikan lebih lanjut kesulitan teknis:

1. Fragmentasi:
   Fitur kini diaktifkan dengan berbagai cara, baik secara asli oleh SCA tertentu atau melalui sistem plugin independen. Masing-masing mengikuti standarnya, memaksa pengembang untuk memutuskan platform mana yang akan didukung. Hal ini menyebabkan potensi penguncian platform atau upaya yang berlebihan.
2. Keamanan:
   Meskipun fleksibilitas antara akun dan fitur menawarkan keuntungan, hal ini dapat memperburuk masalah keamanan. Fitur mungkin diaudit secara kolektif, namun tidak adanya penilaian independen dapat meningkatkan risiko kerentanan akun.
3. Kemampuan untuk ditingkatkan:
   Seiring berkembangnya fitur, penting untuk mempertahankan kapasitas untuk menambah, mengganti, atau menghapus fungsi. Menerapkan ulang fitur yang ada dengan setiap pembaruan menimbulkan kompleksitas.

Untuk menavigasi situasi 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 terstandarisasi untuk memastikan akun kontrak dapat bertransisi dengan lancar antar frontend yang berbeda.

Istilah-istilah ini menyatu pada konsep tunggal: Membangun Arsitektur Abstraksi Akun Modular (Modular AA).

Modular AA adalah ceruk dalam gerakan AA yang lebih luas yang membayangkan modularisasi akun pintar untuk menyesuaikannya bagi pengguna dan memberdayakan pengembang untuk menyempurnakan fitur dengan batasan minimal.

Namun, di industri mana pun, menetapkan dan mempromosikan standar baru merupakan tantangan besar. Fase awal mungkin menyaksikan banyak solusi berbeda sebelum semua orang menentukan solusi utama. Namun, sangat menggembirakan melihat mereka yang mengerjakan abstraksi akun, baik itu SDK 4337, pengembang dompet, tim infrastruktur, atau perancang protokol, semuanya bersatu untuk mempercepat prosesnya.

Struktur Modular: Akun Utama dan Modul

Bagaimana modul panggilan akun untuk mewujudkan fungsi

Delegasikan panggilan dan kontrak proxy

Panggilan eksternal dan panggilan delegasi:

Tentang delegasiCall

Meskipun panggilan delegasi mirip dengan panggilan, namun alih-alih mengeksekusi kontrak target dalam konteksnya sendiri, ia mengeksekusinya dalam konteks status kontrak panggilan saat ini. Ini berarti bahwa setiap perubahan status yang dilakukan oleh kontrak target akan disimpan dalam penyimpanan kontrak panggilan.

Kontrak proxy dan delegasiCall

Untuk mewujudkan struktur yang dapat disusun dan ditingkatkan, diperlukan pengetahuan dasar yang disebut “Kontrak Proxy”.

1. Kontrak proxy: Kontrak normal menyimpan logika dan statusnya, yang tidak dapat diperbarui setelah penerapan. Kontrak proksi menggunakan panggilan delegasi ke kontrak lain. Dengan mengacu pada fungsi implementasi, ia mengeksekusinya dalam kondisi kontrak proksi saat ini.
2. Kasus penggunaan: Meskipun kontrak proksi tetap tidak dapat diubah, 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 Aman

Arsitektur Aman

Apa yang Aman:

Safe adalah Infrastruktur Akun Cerdas Modular terkemuka yang dirancang untuk memberikan keamanan dan fleksibilitas yang telah teruji, memberdayakan pengembang untuk membuat beragam aplikasi dan dompet. Khususnya, banyak tim yang membangun Safe atau terinspirasi olehnya. Biconomy meluncurkan akunnya dengan memperluas Safe dengan 4337 asli dan 1/1 multi-tanda tangan. Menyaksikan penerapan lebih dari 164.000 kontrak dan mengunci nilai lebih dari 30,7 miliar, Safe tidak diragukan lagi adalah yang terdepan di luar angkasa.

Apa struktur Safe

1. Kontrak akun aman: Kontrak proxy utama (Stateful)
   Akun aman adalah kontrak proksi karena mendelegasikan panggilan kontrak tunggal. Akun Aman berisi pemilik, ambang batas, dan alamat implementasi yang semuanya ditetapkan sebagai variabel proksi, sehingga menentukan statusnya.
2. Kontrak Singleton: Hub Integrasi (Tanpa Negara)
   Singleton melayani akun Aman dan mengintegrasikan serta mendefinisikan berbagai integrasi termasuk Plugin, Hook, Function Handler, dan Signature Validator.
3. Kontrak modul: Logika dan fitur khusus:
   Modul sangat kuat. Plugin sebagai tipe modular dapat menentukan fitur berbeda seperti streaming pembayaran, mekanisme pemulihan, dan kunci sesi, dan dapat berfungsi sebagai jembatan antara web2 dan web3 dengan mengambil data off-chain. Modul lain seperti Hook sebagai penjaga keamanan, dan Function Handler merespons instruksi apa pun.

Apa yang terjadi jika kita mengadopsi Safe:

1. Kontrak yang Dapat Diupgrade:
   Menyebarkan singleton baru diperlukan setiap kali plugin baru diperkenalkan. Pengguna mempunyai otonomi untuk meningkatkan Brankas mereka ke versi tunggal yang diinginkan, selaras dengan preferensi dan kebutuhan mereka.
2. Modul yang Dapat Disusun dan Digunakan Kembali:
   Sifat modular dari plugin memberdayakan pengembang untuk membuat fungsionalitas secara mandiri. Mereka kemudian dapat dengan bebas memilih dan menggabungkan plugin-plugin ini berdasarkan kasus penggunaannya, sehingga mendorong pendekatan yang sangat dapat disesuaikan.

Proksi Berlian ERC-2535

Arsitektur Berlian ERC2535

Tentang ERC2535, Proksi Berlian:

ERC2535 menstandarkan berlian, sistem kontrak pintar modular yang dapat ditingkatkan/diperluas setelah penerapan dan hampir tidak memiliki batasan ukuran. Hingga saat ini, banyak tim yang terinspirasi olehnya, seperti Kernel Zerodev, dan eksperimen Soul Wallet.

Apa struktur berlian:

1. Kontrak berlian: Kontrak proksi utama (Stateful) Berlian adalah kontrak proksi yang memanggil fungsi dari implementasinya menggunakan panggilan delegasi.
2. Modul/ Plugin/ Kontrak Facet: Logika dan fitur khusus (Tanpa Negara) Modul atau biasa disebut Facet adalah kontrak tanpa kewarganegaraan yang dapat menerapkan fitur-fiturnya ke satu atau lebih berlian. Ini adalah kontrak terpisah dan independen yang dapat berbagi fungsi internal, perpustakaan, dan variabel status.

Apa yang terjadi jika kita mengadopsi Diamond:

1. Kontrak yang Dapat Diupgrade: Diamond menyediakan cara sistematis untuk mengisolasi plugin yang berbeda dan menghubungkannya bersama-sama serta berbagi data di antara plugin tersebut, juga secara langsung menambah/mengganti/menghapus plugin apa pun menggunakan fungsi diamondCut. Tidak ada batasan jumlah plugin yang dapat ditambahkan ke berlian seiring waktu.
2. Plugin modular dan dapat digunakan kembali: Plugin yang diterapkan dapat digunakan oleh sejumlah berlian untuk mengurangi biaya penerapan secara signifikan.

Perbedaan antara Akun Cerdas Aman dan Pendekatan Diamond:

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

Meskipun demikian, perbedaan utamanya terletak pada penanganan kontrak logika. Berikut ini melihat lebih dekat:

1. Fleksibilitas:
   Dalam konteks mengaktifkan plugin baru, Safe mengharuskan penerapan ulang kontrak Singleton untuk mengimplementasikan perubahan pada Proxy-nya. Sebaliknya, Diamond mencapai hal ini secara langsung melalui fungsi diamondCut di Proxy-nya. Perbedaan dalam pendekatan ini berarti Safe mempertahankan tingkat kontrol yang lebih tinggi, sementara Diamond memperkenalkan peningkatan fleksibilitas dan modularitas.
2. Keamanan:
   delegasicall, yang digunakan di kedua struktur untuk saat ini, dapat mengizinkan kode eksternal memanipulasi penyimpanan kontrak utama. Dalam arsitektur Aman, panggilan delegasi menunjuk ke satu kontrak logika, sedangkan Diamond menggunakan panggilan delegasi di beberapa modul kontrak-plugin. Akibatnya, plugin berbahaya berpotensi menimpa plugin lain, sehingga menimbulkan risiko tabrakan penyimpanan yang dapat membahayakan integritas Proxy.
3. Biaya:
   Fleksibilitas yang melekat dalam pendekatan Diamond sejalan dengan meningkatnya masalah keamanan. Hal ini meningkatkan faktor biaya, sehingga memerlukan audit komprehensif dengan setiap penambahan plugin baru. Kuncinya adalah memastikan bahwa plugin-plugin ini tidak mengganggu fungsi masing-masing plugin, sehingga menimbulkan tantangan, terutama bagi perusahaan kecil atau menengah yang berupaya mempertahankan standar keamanan yang kuat.

“Pendekatan Akun Cerdas Aman” dan “Pendekatan Berlian” berfungsi sebagai contoh struktur berbeda yang melibatkan proxy dan modul. Bagaimana menyeimbangkan fleksibilitas dan keamanan sangatlah penting, dan kedua metode ini berpotensi saling melengkapi di masa depan.

Urutan Modul: Validator, Executor, dan Hook

Apa urutan pemanggilan modul

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

Dalam proses transaksi AA, ada tiga proses utama: validasi, eksekusi, dan hook. Semua langkah ini dapat dikelola dengan menggunakan akun proxy untuk memanggil modul, seperti yang telah kita bahas sebelumnya. Meskipun proyek yang berbeda mungkin menggunakan nama yang berbeda, penting untuk memahami logika dasar yang serupa.

Nama fungsi dalam desain berbeda

1. Validasi: Memastikan keaslian dan otoritas penelepon terhadap akun.
2. Eksekusi: Melakukan logika kustom apa pun yang diizinkan oleh akun.
3. Hook: Bertindak sebagai modul yang berjalan sebelum atau sesudah fungsi lain. Ini dapat mengubah status atau menyebabkan seluruh panggilan dibatalkan.

ERC6900

Sangat penting untuk memisahkan modul berdasarkan logika yang berbeda. Pendekatan standar harus menentukan bagaimana fungsi validasi, eksekusi, dan kait untuk akun kontrak pintar harus ditulis. Baik itu Safe atau ERC6900, standardisasi membantu mengurangi kebutuhan akan upaya pengembangan unik yang spesifik untuk implementasi atau ekosistem tertentu dan mencegah vendor lock-in.

Penemuan dan Keamanan Modul

Cara menemukan dan memverifikasi modul secara terbuka

Sebuah solusi yang mendapatkan momentum melibatkan penciptaan sebuah tempat yang memungkinkan pengguna menemukan modul yang dapat diverifikasi, yang dapat kita sebut “registrasi.” Registri ini berfungsi mirip dengan “App Store” dan bertujuan untuk mengembangkan pasar modular yang disederhanakan namun berkembang.

Protokol{Core} Aman

Protokol{Core} Aman

Protokol{Core} Aman adalah protokol sumber terbuka dan dapat dioperasikan untuk akun kontrak cerdas, yang dirancang untuk meningkatkan aksesibilitas bagi berbagai vendor dan pengembang sambil menjaga keamanan yang kuat melalui standar dan aturan yang ditentukan dengan baik.

1. Akun: Dalam Protokol{Core} Aman, konsep akun bersifat fleksibel dan tidak terikat pada penerapan tertentu. Hal ini memungkinkan beragam penyedia layanan akun untuk berpartisipasi.
2. Manajer: Manajer berfungsi sebagai koordinator antara Akun, Registri, dan Modul. Ini juga bertanggung jawab atas keamanan sebagai lapisan perizinan.
3. Registri: Registri menentukan atribut keamanan dan menerapkan standar seperti ERC6900 untuk Modul, yang bertujuan untuk menciptakan lingkungan “app store” terbuka agar dapat ditemukan dan aman.
4. Modul: Modul menangani fungsionalitas dan hadir dalam berbagai tipe awal, termasuk Plugin, Hooks, Signature Validator, dan Function Handler. Ini terbuka bagi pengembang untuk berkontribusi, asalkan memenuhi standar yang ditetapkan.

Desain Berlian Imitasi

Desain Berlian Imitasi

Prosesnya terungkap sebagai berikut:

1. Membuat Skema Definisi: Skema berfungsi sebagai struktur data yang telah ditentukan sebelumnya yang diperlukan untuk pengesahan. Hal ini dapat disesuaikan oleh bisnis agar selaras dengan kasus penggunaan spesifik mereka.
2. Membuat Modul Berdasarkan Skema: Kontrak pintar didaftarkan sebagai modul, memperoleh bytecode dan memilih ID skema. Data ini kemudian disimpan dalam registri.
3. Memperoleh Pengesahan untuk Modul: Atestor/auditor dapat memberikan pengesahan untuk modul berdasarkan skema. Pengesahan ini dapat mencakup pengidentifikasi unik (UID), dan referensi ke pengesahan lain untuk rangkaian. Mereka dapat menyebar ke seluruh rantai dan memverifikasi apakah ambang batas tertentu terpenuhi pada rantai tujuan.
4. Menerapkan Logika Kompleks dengan Resolver: Resolver, yang diatur secara opsional dalam skema, ikut berperan. Mereka dapat dipanggil selama pembuatan modul, pembuatan pengesahan, dan pencabutan. Penyelesai ini memungkinkan pengembang untuk menggabungkan logika yang rumit dan beragam sambil mempertahankan struktur pengesahan.
5. Akses Kueri yang Ramah Pengguna: Kueri menawarkan sarana bagi pengguna untuk mengakses informasi keamanan dari front-end. Temukan EIP ini di sini.

Meskipun skema ini masih dalam tahap awal, skema 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, dan dompet untuk mengintegrasikan dan memungkinkan pengguna untuk dengan mudah menemukan modul dan memverifikasi informasi pengesahan mereka. Beberapa kegunaan di masa depan mungkin:

1. Attestor: Entitas yang dapat dipercaya, seperti Safe, dapat berkolaborasi dengan Berlian Imitasi sebagai attestor untuk modul internal. Pada saat yang sama, attestor independen dapat ikut serta.
2. Pengembang Modul: Ketika pasar terbuka mulai terbentuk, pengembang modul berpotensi memonetisasi pekerjaan mereka melalui registri.
3. Pengguna: Dengan berinteraksi melalui antarmuka yang mudah digunakan, seperti dompet atau dApps, pengguna dapat memeriksa informasi modul dan mendelegasikan kepercayaan kepada beragam attestor.

Konsep “Module Registry” membuka jalan monetisasi bagi pengembang plugin dan modul. Hal ini selanjutnya dapat membuka jalan bagi “Pasar Modul.” Beberapa aspek mungkin diawasi oleh tim Safe, sementara aspek lainnya dapat terwujud sebagai pasar yang terdesentralisasi, yang mengundang kontribusi dan catatan audit yang transparan bagi semua orang. Dengan menggabungkan hal ini, kami dapat menghindari vendor lock-in dan mendukung perluasan EVM dengan menambahkan pengalaman pengguna yang lebih baik sehingga menarik khalayak yang lebih luas.

Meskipun pendekatan ini menjamin keamanan satu modul, keamanan yang lebih luas pada akun kontrak pintar bukanlah hal yang mudah. Menggabungkan modul yang sah dan bukti bahwa modul tersebut tidak mengalami benturan penyimpanan dapat menjadi sebuah tantangan, hal ini menggarisbawahi pentingnya infrastruktur dompet atau AA dalam mengatasi masalah tersebut.

Menutup pikiran

Dengan memanfaatkan tumpukan akun kontrak pintar modular, penyedia dompet dan dApps dapat terbebas dari kerumitan pemeliharaan teknologi. Sementara itu, pengembang modul eksternal mempunyai peluang untuk menawarkan layanan khusus yang disesuaikan dengan kebutuhan individu. Namun, tantangan yang harus diatasi termasuk mencapai keseimbangan antara fleksibilitas dan keamanan, memajukan standar modular, dan menerapkan antarmuka terstandar yang memberdayakan pengguna untuk dengan mudah meningkatkan dan memodifikasi akun pintar mereka.

Namun, Akun Kontrak Cerdas (SCA) modular hanya mewakili satu bagian dari teka-teki adopsi. Untuk sepenuhnya mewujudkan potensi SCA, diperlukan dukungan lapisan protokol tambahan dari solusi Lapisan 2, sehingga infrastruktur bundler yang kuat dan mempool peer-to-peer, mekanisme penandatanganan SCA yang lebih hemat biaya dan layak, sinkronisasi dan manajemen SCA lintas rantai , dan mengembangkan antarmuka yang ramah pengguna.

Ke depan, kami membayangkan masa depan dimana partisipasi tersebar luas, sehingga memicu pertanyaan menarik: Ketika aliran pesanan SCA sudah cukup menguntungkan, bagaimana mekanisme tradisional Miner Extractable Value (MEV) akan memasuki lapangan untuk membangun bundler dan menangkap nilai? Ketika infrastruktur sudah matang, bagaimana Abstraksi Akun (AA) dapat berfungsi sebagai lapisan dasar untuk transaksi “berbasis niat”? Pantau terus; lanskap berkembang dari menit ke menit.

Potongan penting

1. Buku putih yang aman: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. Dokumen berlian imitasi: https://docs.rhinestone.wtf/
3. Dokumen Biconomy: https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

Penafian:

1. Artikel ini dicetak ulang dari [SevenX Ventures ]. Semua hak cipta milik penulis asli [SevenX Ventures]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.