Basis Data Berindeks yang Dirancang Khusus untuk Operasi Pengguna Abstraksi Akun

Pasar mungkin tidak terlalu aktif, tetapi iterasi teknologi tidak pernah berhenti. Dalam ekosistem Ethereum, pengembangan Abstraksi Akun (AA) sangat menarik. Baik itu Ethereum Foundation, komunitas Ethereum, atau Vitalik sendiri, mereka semua bekerja tanpa lelah untuk memajukan dan mempromosikan adopsi AA. Alasannya sederhana: adopsi abstraksi akun secara luas merupakan prasyarat untuk adopsi Web3 secara luas. Seperti yang disebutkan Vitalik dalam artikel terbaru, semua orang yang pindah ke dompet kontrak pintar adalah salah satu dari tiga transisi teknis utama yang harus dijalani oleh stack untuk menjadikan Ethereum sebagai tumpukan teknologi yang matang yang mampu menghadirkan pengalaman terbuka, global, dan tanpa izin kepada pengguna biasa. Karena "Tanpa itu, Ethereum akan gagal karena pengguna merasa tidak nyaman menyimpan dana mereka (dan aset non-keuangan), dan semua orang akan berpindah ke bursa yang tersentralisasi."

Kami telah lama menyadari pentingnya AA untuk Ethereum dan sebelumnya telah menerbitkan sebuah artikel tentang bagaimana mendukung abstraksi akun dari perspektif infrastruktur. Selama pengembangan dan komunikasi kami yang sedang berlangsung dengan para pengembang AA, kami telah memperhatikan bahwa ada banyak area yang dapat dioptimalkan.

Salah satu masalah yang signifikan adalah pengindeksan UserOperations. Karena satu bundel UserOperations dianggap sebagai satu transaksi di blockchain Ethereum, maka UserOperation individu dianggap sebagai bagian dari transaksi (ketika transaksi berinteraksi dengan kontrak EntryPoint). Bundler menyediakan metode RPC eth_getUserOperationByHash kepada pengguna AA untuk meminta data UserOperation dengan hash-nya. Untuk mencapai hal tersebut, klien Bundler mengirimkan eth_getLogs untuk memindai kontrak EntryPoint dari klien node (Geth, Erigon, dll) untuk mencari hash dari UserOperation. Tidak seperti transaksi on-chain biasa, UserOperation tidak dapat ditemukan menggunakan eth_getTransactionByHash yang hanya mendapatkan informasi dasar dari transaksi bundel yang berisi beberapa UserOperation. Karena setiap UserOperation merupakan interaksi on-chain antara kontrak smart wallet dan kontrak EntryPoint, data UserOperation disimpan dalam log kontrak EntryPoint. Mari kita lihat bagaimana hal ini ditemukan dari muatan eth_getLogs yang dikirim oleh Bundler. Berikut ini adalah contoh permintaan eth_getLogs yang dikirim oleh Bundler ke node RPC.

{
    "method": "eth_getLogs",
    "params": [
        {
            "address": "0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789",
            "topics": [
                "0x49628fd1471006c1482da88028e9ce4dbb080b815c9b0344d39e5a8e6ec1419f",
                "0xd9c5cdba03c5c74887fb5a2aa4d8eeac676841c6dc8573713e1798e924f1086c"
            ],
            "fromBlock": "earliest",
            "toBlock": "latest"
        }
    ],
    "id": 1,
    "jsonrpc": "2.0"
}

dimana,

alamat adalah alamat kontrak EntryPoint, nilai tetap.

Baris pertama dari topik adalah deskriptor log, nilai tetap.

Baris kedua dari topik adalah hash dari UserOperation.

Kemudian datanglah bagian yang menantang. Karena hash dari UserOperation adalah satu-satunya parameter, permintaan harus memindai dari blok paling awal ke blok terbaru (seperti yang ditunjukkan pada contoh di atas) untuk menjamin eksekusi yang berhasil, yang membutuhkan data dari node blockchain arsip. Proses ini menghasilkan sejumlah besar pekerjaan baca pada node, yang tidak efisien dan menyebabkan pengembalian yang lambat untuk Bundler, yang pada akhirnya menghasilkan respons yang lambat kepada pengguna AA. Selain itu, hampir semua penyedia RPC memberlakukan batasan rentang permintaan blok pada metode eth_getLogs. Akibatnya, Bundler tidak dapat mengambil semua data blok dalam satu permintaan dan harus memilah-milahnya menjadi beberapa permintaan. Hal ini bahkan dapat menyebabkan kecepatan pemrosesan yang lebih lambat. Menggunakan layanan RPC yang disesuaikan dari beberapa penyedia layanan RPC dapat menghindari pembatasan tersebut, tetapi pendekatan ini tidak dapat diadopsi secara luas karena mahal dan tidak terjangkau untuk semua orang. Diagram alir di bawah ini menunjukkan prosedurnya.

Untungnya, hanya ada satu kontrak EntryPoint pada saat yang sama, dan karena pertimbangan cermat yang diberikan pada setiap peningkatan, pada dasarnya tidak sering mengalami perubahan. Sementara itu, nilai deskriptor log tetap. Jadi untuk mengatasi masalah ini, kita harus membuat database yang diindeks untuk UserOperation, baik secara eksternal sebagai pengindeks atau diintegrasikan ke dalam klien node. Dan pengindeks hanya perlu mengekstrak data dari node dengan alamat tetap dan deskriptor log tetap sebagai parameter untuk membuat database, membuat logika eksekusi backend pengindeks menjadi sangat sederhana. Ada beberapa proyek di pasar yang berkonsentrasi pada pengindeksan data, yang, secara teori, dapat digunakan untuk mengatasi masalah ini. Namun, jika menggunakan solusi seperti membuat Subgraph dari The Graph secara langsung, itu sama saja dengan mengandalkan layanan pihak ketiga, yang tidak dapat diterima. Jadi, klien sumber terbuka adalah solusi yang ideal.

Klien Ringan yang berdiri sendiri
Manfaat pengindeksan adalah tidak perlu melakukan pekerjaan yang berulang-ulang. Setelah database dibangun dengan memindai dari blok paling awal ke blok terbaru, hanya log di blok yang baru ditambahkan yang perlu diperbarui di masa mendatang.

Kami telah mengembangkan UserOperation Indexer sumber terbuka ini dan mengujinya di Jaringan BlockPI. Karena hanya pengindeksan UserOperation yang dilakukan, klien ini menggunakan sumber daya sistem yang relatif sedikit dan mampu memberikan QPS yang jauh lebih tinggi untuk kueri UserOperation daripada eth_getLogs yang asli. Di bawah ini adalah perbandingan hasil uji coba stres yang menanyakan data UserOperation pada Polygon Mumbai (UserOperation hash: 0xcf8b2943927b6b905e5d3c870d19ff7cbfc8bce6c5fd3e59581cebe51f3400c1). Hasilnya menunjukkan perbedaan yang signifikan antara data yang sudah diindeks atau belum.

Klien ringan sekarang mendukung tiga basis data: Memory DB, Redis, dan Pebble. Setelah dibuat, perintah jalankan hanya dengan parameter blockchain target, titik akhir RPC backend, dan basis data yang dipanggil. Mengambil Memory DB sebagai contoh:

./build/indexer \
  --chain polygon-mumbai  \
  --backend https://polygon-mumbai.blockpi.network/v1/rpc/{APIKEY}  \
  --db.engin memory

Perlu dicatat bahwa alamat EntryPoint telah dikonfigurasi sebelumnya secara internal. Jika kontrak EntryPoint ditingkatkan, alamatnya juga perlu diperbarui. Sekarang dengan pengindeks ini, kita dapat mengabstraksikan bagian permintaan eth_getLogs ini dan menggunakan nama metode yang berbeda untuk membedakannya dari API klien simpul mentah lainnya. Kita menggunakan eth_getLogsByUserOperation hanya dengan hash dari UserOperation sebagai parameter masukan. Karena bersifat open-source, pengembang dapat memodifikasi nama metode sendiri. Metode ini juga mengimplementasikan fungsi untuk menanyakan beberapa UserOperation. Anda hanya perlu membuat daftar hash yang perlu ditanyakan dalam parameter. Hal ini tidak dapat dilakukan dengan eth_getlogs. Di bawah ini adalah contoh permintaan dan respons.

curl 'http://127.0.0.1:2052' \
-X POST -H "Content-Type: application/json" \
--data '{
    "jsonrpc": "2.0",
    "method": "eth_getLogsByUserOperation",
    "params": [
        "0xaa6f620266962dbed7778bff708be6891d92935ba1b6120781aca1aa37f9c560",
        "0xcf8b2943927b6b905e5d3c870d19ff7cbfc8bce6c5fd3e59581cebe51f3400c1"
    ],
    "id": 1
}'

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": [
        {LOGS1},
        {LOGS2}
    ]
}

Pengindeks ini dapat dijalankan secara individual, dengan node RPC, atau dengan Bundler. Ketika menjalankan dengan node RPC, pastikan bahwa backend diatur ke titik akhir RPC lokal. Ketika berjalan dengan Bundler, komunikasi antara Bundler dan pengindeks lebih fleksibel, baik memodifikasi kode backend Bundler atau mengubah kode Pengindeks untuk secara langsung menerima eth_getLog dari Bundler.

Terintegrasi ke dalam klien Node

Meskipun pengembang dapat dengan bebas menggunakan klien pengindeks, membuat klien Node mendukung pengindeksan UserOperation secara native adalah solusi optimal, karena ini menghilangkan kebutuhan aktor eksternal untuk menjalankan beberapa klien atau menambahkan database. Kami ingin memulai dengan mengintegrasikan fungsionalitas pengindeks UserOperation ke dalam Geth. Tugas ini jauh lebih rumit, membutuhkan studi yang lebih mendalam tentang kode dan pemeriksaan menyeluruh terhadap basis data klien Geth, berkomunikasi dengan tim klien Geth dan kemudian menemukan solusi terbaik untuk mengimplementasikan pengindeks UserOperations. Setelah memodifikasi klien, diperlukan pengujian ekstensif dalam berbagai aspek. Kami secara aktif mendorong maju dengan masalah ini.

GitHub: https://github.com/BlockPILabs/erc4337_user_operation_indexer

Jika Anda adalah pengembang atau pengguna AA, kami mengundang Anda untuk bergabung dengan komunitas BlockPI untuk mendiskusikan masalah dan saran yang terkait dengan AA. Mari bekerja sama untuk berkontribusi pada adopsi massal AA.

---

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