Dalam artikel kami sebelumnya, kami menyebutkan beberapa masalah yang saat ini belum jelas dalam ekosistem Account Abstraction (AA), termasuk risiko dalam cara Bundler memproses UserOperations. Resikonya adalah jika pengguna mengirimkan UserOperations dengan nonce yang sama ke dua Bundler secara bersamaan dan kedua Bundler tersebut mengirimkan transaksi di blok yang sama, maka salah satu transaksi akan gagal. Dalam kasus ini, Bundler yang gagal akan membayar sejumlah kecil biaya gas secara cuma-cuma. Kami menyebutnya sebagai tabrakan nonce. Meskipun ini bukan perilaku pengujian, situasi ini telah terjadi di blockchain selama ini.

Dalam dokumentasi resmi ERC-4337, disebutkan bahwa Bundler adalah pembuat blok itu sendiri atau berkolaborasi dengan pembuat blok. Secara teori, Bundler yang berkolaborasi dengan pembuat blok dapat sepenuhnya menghindari kegagalan transaksi yang disebabkan oleh tabrakan nonce. Akan tetapi, karena tahap awal pengembangan AA, hal ini tidak selalu terjadi pada kenyataannya.

Dalam artikel ini, saya akan membahas masalah ini secara mendetail serta kondisi ekosistem Bundler saat ini, dan memberikan beberapa wawasan tentang potensi munculnya mempool publik dan masa depan ekosistem Bundler setelah adopsi AA secara luas.

Apa yang Sebenarnya Terjadi?

Untuk menunjukkan masalahnya, kami melakukan pengujian pada Polygon Mumbai dengan mengikuti langkah-langkah berikut,

Siapkan dompet kontrak yang sudah digunakan
Setor dana yang cukup untuk mengisi gas dari beberapa UserOperation
Buat UserOperation dengan calldata yang singkat dan tanpa Paymaster atau Aggregator, agar tetap sederhana.
Kirim UserOperation ini dengan nonce yang sama ke dua Bundler yang berbeda secara bersamaan. Periksa riwayat kontrak EntryPoint untuk melihat transaksi yang dikirim oleh dua Bundler ini.
Tabel di bawah ini mencantumkan beberapa detail dari kedua transaksi tersebut. (Transaksi 1; Transaksi 2)

Inilah yang terjadi pada kedua bundler tersebut. Setelah menerima UserOperation, setiap bundler mensimulasikannya berdasarkan kondisi blockchain saat ini. Masing-masing berhasil karena ada cukup gas dalam kontrak dompet, calldata baik-baik saja, nonce benar. Berdasarkan perhitungan gas, UserOperation ini menguntungkan. Jadi mereka mengirimkannya secara on-chain dalam sebuah transaksi.

Selanjutnya, masalah terjadi karena EVM memproses transaksi secara linier, sehingga kedua transaksi ini harus memiliki urutan, dengan satu transaksi diproses sebelum yang lain. Ketika transaksi pertama selesai, EVM menemukan bahwa nonce dari UserOperation tidak benar ketika memproses transaksi kedua, sehingga transaksi kedua dikembalikan. Akibatnya, kedua Bundler memperoleh hasil yang sangat berbeda. Seperti yang ditunjukkan pada tabel di atas, Bundler pertama mendapatkan 0,00028 $Matic, sedangkan Bundler kedua kehilangan 0,0000728 $Matic. Bagan berikut ini menunjukkan alur kerjanya.

Ini hanyalah kehilangan gas dari transaksi yang gagal (satu paket) dengan satu UserOperation. Bagaimana jika transaksi mencakup lebih banyak UserOperation? Berikut adalah hasil pengujian lainnya. Mengikuti langkah-langkah yang sama dengan pengujian sebelumnya, kecuali setiap bundler mengirimkan transaksi yang mencakup dua UserOperation, bukan hanya satu. (Transaksi 1; Transaksi 2). UserOperation pertama dari Bundler A identik dengan UserOperation pertama dari Bundler B. Lebih spesifiknya, selama mereka memiliki pengirim dan nonce yang sama, maka masalah terjadi. Kami menemukan bahwa seluruh transaksi gagal, yang menyebabkan bundler membayar semua gas secara cuma-cuma. Dibandingkan dengan transaksi dengan satu UserOperation, gas meningkat sebesar 5408, dan UserOperation lain yang dapat dieksekusi dalam transaksi yang sama juga tidak dieksekusi secara on-chain. Jadi, transaksi ini tidak hanya menyebabkan lebih banyak kerugian ekonomi bagi bundler, tetapi juga menyebabkan kerugian waktu bagi pengguna lain.

Data panggilannya sama dan cukup sederhana dalam pengujian di sini. Jika UserOperations tersebut lebih kompleks, melibatkan lebih banyak kontrak yang berinteraksi atau memiliki lebih banyak konten, maka kehilangan gas akan lebih tinggi. Di sisi lain, bayangkan jika AA menjadi lebih populer, Bundler akan menggabungkan lebih banyak UserOperations. Jika terjadi pengembalian, kehilangan gas akan semakin besar. Tabel di bawah ini menunjukkan gas dari transaksi yang gagal yang berisi satu UserOperation yang diduplikasi dengan jumlah UserOperation yang semakin banyak dimana calldata sama dengan pengujian yang dilakukan di atas.

Hutan Gelap atau Lapangan Terbuka
Terlepas dari pengujian yang disengaja atau penyerang yang mengirimkan transaksi ke beberapa Bundler, situasi di atas terkadang terjadi pada chain. Alasannya adalah sejumlah besar Bundler mengirimkan transaksi Bundle ke mempool Ethereum tanpa perlindungan MEV. Karena UserOperation dalam bentuk plaintext, ketika bot MEV menemukan UserOperation yang menguntungkan di mempool Ethereum, bot tersebut akan langsung mengemas UserOperation tersebut, mengirimkan transaksi Bundle baru di blok yang sama dengan harga gas yang lebih tinggi. Node penghasil blok secara alami memprioritaskan transaksi dengan harga gas yang lebih tinggi, membuat pengirim asli transaksi menjadi korban tabrakan nonce. Dalam proses ini, bot MEV tidak hanya meningkatkan harga gas tetapi juga mengkonsumsi lebih banyak gas pada akhirnya, karena mereka memiliki kontrak bot MEV sendiri, membuat perlombaan untuk mengirimkan transaksi menjadi lebih kompleks. Transaksi Bundle di mempool Ethereum ini seperti orang yang memegang obor di hutan yang gelap, membuat diri mereka menjadi mangsa predator.

Apakah itu disengaja oleh penyerang atau bot MEV yang sedang berjalan di depan, sebelum mempool publik ERC4337, situasi di atas dapat dianggap sebagai serangan tabrakan UserOperation nonce. Dan ini harus dicegah. Di sini, kami telah menemukan beberapa solusi sementara ketika belum ada mempool publik.

Mempool Pra Publik
Untuk pendekatan yang lebih langsung, Bundler dapat secara proaktif memblokir pengirim atau alamat IP UserOperation dari para penyerang setelah pengembalian terjadi. Namun, ada dua masalah dengan pendekatan ini. Pertama, memblokir alamat IP dapat menyebabkan false positive, dan penyerang dapat mengubah pengirim dan alamat IP. Kedua, pengguna mungkin tidak sengaja melakukan tindakan ini.

Mengenai bot MEV, salah satu solusinya adalah dengan menggunakan proteksi MEV terhadap front-running, seperti Flashbots, tetapi hal ini tentunya akan menimbulkan biaya atau mengorbankan efisiensi. Solusi lain adalah menghitung selisih antara gas yang dikirimkan untuk transaksi Bundle dan gas yang dikembalikan oleh kontrak EntryPoint saat mengirimkan transaksi Bundle, menjaganya tetap pada tingkat keuntungan yang rendah, sehingga tidak menguntungkan bagi bot MEV untuk melakukan front-running. Ini seharusnya menjadi solusi paling sederhana dan paling langsung dalam adopsi awal AA, karena saat ini, sebagian besar transaksi Bundle hanya berisi satu UserOperation dan hanya ada sedikit transaksi AA dalam satu blok.

Solusi lain yang dapat kita pikirkan adalah untuk memperkenalkan beberapa keacakan ke dalam proses bundling. Alih-alih langsung membundel dan mengirimkan UserOperation yang diterima ke blockchain, Bundler dapat menunggu sejumlah blok secara acak (misalnya, antara 0 dan 5 blok) sebelum mensimulasikan dan membundelnya. Hal ini membuat serangan menjadi kurang efektif, karena penyerang tidak dapat menjamin bahwa Bundler akan membundel UserOperation di blok yang sama. Biaya serangan meningkat seiring dengan meningkatnya jangkauan nomor acak. Solusi ini mungkin dapat dilakukan pada chain berkecepatan tinggi, seperti Arbitrum, di mana waktu blok relatif singkat. Akan tetapi, pada chain berkecepatan rendah seperti Ethereum, di mana setiap blok membutuhkan waktu 12 detik, pengalaman pengguna mungkin tidak sebaik itu.

Solusi di atas bersifat sementara sebelum mempool publik tersedia. Ketika mempool publik sudah tersedia, situasinya akan berubah.

Pasca Mempool Publik
Setelah mempool publik diperkenalkan, sebagian besar UserOperations berasal dari pool ini. Harus ada mekanisme untuk mencegah beberapa Bundler mem-bundling UserOperation yang sama di mempool. Etherspot, yang mengembangkan klien bundler Skandha, sedang mengembangkan jaringan p2p dari mempool. Menurut informasi dari Etherspot, mempool akan tersedia pada bulan Oktober. UserOperations yang akan dibundel akan ditransmisikan dalam jaringan p2p ini, dan setelah dibundel dan diproses secara on-chain, mereka akan ditandai dan dihapus. Tidak ada artinya mengirim UserOperations duplikat ke mempool karena dapat dengan mudah dideteksi oleh jaringan p2p.

Pada titik ini, beberapa Bundler akan mengakses kumpulan UserOperations yang belum diproses yang sama. Bundler akan mulai mengemas lebih banyak UserOperations ke dalam transaksi Bundle yang sama. Jika transaksi masih dikirim ke mempool Ethereum, selama satu UserOperation dijalankan di depan, seluruh transaksi akan dikembalikan. Probabilitas kegagalan meningkat secara signifikan. Hal ini berbahaya bagi komunitas Bundler dan ekosistem AA.

Seperti yang dikomentari oleh Parthasarathy, pengembang inti dari Etherspot, antarmuka p2p akan diujicobakan dalam sebuah rantai yang mendukung pembangun mev-boost / block. Ini akan memastikan penghapusan pengiriman duplikat dan mengurangi penolakan online. Marc dari tim Candide juga mengatakan kepada kami bahwa berkolaborasi dengan block builder adalah berdasarkan desain dan bukan opsional, seseorang tidak dapat dan tidak boleh menjalankan bundler di mempool p2p tanpa layanan seperti mevboost pada mempool publik di Ethereum.

Dalam kondisi ideal, Bundlers setelah peluncuran mempool publik akan terhindar dari terjebak dalam kondisi persaingan yang kacau di hutan gelap. Dengan menggabungkan mempool pribadi mereka, Bundlers dapat memproses UserOperations dengan lebih efisien sambil mendapatkan keuntungan maksimal.

Kami percaya bahwa pengembangan AA pasti akan melalui proses penemuan dan pemecahan masalah, dan apa yang kita diskusikan di sini hanyalah salah satunya. Setelah melalui perkembangan ini, AA pada akhirnya akan diadopsi secara luas. Sebagai infrastruktur web3 yang inovatif, kami akan terus melakukan lebih banyak penelitian dan pengujian di bidang AA, dan berharap lebih banyak pengembang akan berpartisipasi dalam komunitas AA kami.

Tentang BlockPI

BlockPI Network adalah penyedia infrastruktur terdesentralisasi yang menawarkan layanan satu atap di lebih dari 33 jaringan dan memproses lebih dari 20 miliar permintaan setiap bulannya. Sebagai penyedia RPC terkemuka, layanan RPC BlockPI terkenal karena stabilitas yang kokoh, tingkat respons tercepat, dan kinerja harga terbaik. Dengan mendukung ERC-4337 sebagai pelopor dalam industri ini, BlockPI juga merupakan satu-satunya yang menyediakan layanan Bundler yang paling beragam di pasar saat ini.

Website | Twitter | Telegram | Discord | Medium