Optimisasi Paralel EVM: Kunci untuk Mengatasi Bottleneck Kinerja

Seperti yang kita ketahui, EVM adalah salah satu komponen inti terpenting dari Ethereum, yang diposisikan sebagai "mesin eksekusi" dan "lingkungan eksekusi kontrak pintar". Karena blockchain publik adalah jaringan terbuka yang terdiri dari banyak node, perbedaan besar dalam parameter perangkat keras node yang berbeda. Untuk memastikan bahwa kontrak pintar dapat memberikan hasil yang sama di berbagai node dan memenuhi persyaratan "konsistensi", teknologi mesin virtual dapat membangun lingkungan yang sama di berbagai perangkat.

EVM dapat menjalankan kontrak pintar dengan cara yang sama di berbagai sistem operasi dan perangkat, kompatibilitas lintas platform ini memastikan bahwa setiap node mendapatkan hasil yang konsisten setelah mengeksekusi kontrak. Ini mirip dengan prinsip mesin virtual Java (JVM).

Kontrak pintar yang kita lihat di penjelajah blok, semuanya terlebih dahulu dikompilasi menjadi bytecode EVM, lalu disimpan di blockchain. Ketika EVM mengeksekusi kontrak, ia akan membaca bytecode ini secara berurutan, setiap instruksi memiliki biaya Gas yang sesuai. EVM akan melacak konsumsi Gas selama proses eksekusi setiap instruksi, jumlah konsumsi tergantung pada kompleksitas operasi.

Sebagai mesin eksekusi inti Ethereum, EVM memproses transaksi dengan cara serial, di mana semua transaksi antre dalam satu antrean dan dieksekusi dalam urutan yang ditentukan. Alasan mengapa tidak menggunakan cara paralel adalah bahwa blockchain perlu memenuhi konsistensi secara ketat, di mana sekelompok transaksi harus diproses dalam urutan yang sama di semua node. Jika pemrosesan transaksi diparalelkan, akan sulit untuk memprediksi urutan transaksi secara tepat, kecuali jika algoritma penjadwalan yang kompleks diperkenalkan.

Tim pendiri Ethereum pada tahun 2014-2015 karena waktu yang mendesak, memilih untuk merancang cara eksekusi serial yang sederhana dan mudah dipelihara. Namun, seiring dengan iterasi teknologi blockchain dan berkembangnya jumlah pengguna, tuntutan terhadap TPS dan throughput semakin tinggi. Setelah teknologi Rollup matang, batasan kinerja yang dibawa oleh eksekusi serial EVM sudah jelas terlihat di jaringan lapisan kedua Ethereum.

Sequencer sebagai komponen kunci Layer2, mengambil semua tugas komputasi dalam bentuk satu server. Jika modul eksternal yang bekerja sama dengan Sequencer memiliki efisiensi yang cukup tinggi, maka bottleneck akhir akan bergantung pada efisiensi Sequencer itu sendiri, pada saat itu eksekusi serial akan menjadi hambatan besar.

Sebuah tim melakukan optimasi ekstrem pada lapisan DA dan modul pembacaan serta penulisan data, sehingga Sequencer dapat mengeksekusi lebih dari 2000 transaksi ERC-20 per detik. Angka ini terlihat tinggi, tetapi jika transaksi yang diproses jauh lebih kompleks daripada transfer ERC-20, nilai TPS pasti akan turun drastis. Oleh karena itu, paralelisasi pemrosesan transaksi akan menjadi tren yang tidak terhindarkan di masa depan.

Selanjutnya, kita akan mendalami keterbatasan EVM tradisional dan keuntungan EVM paralel.

Dua Komponen Inti dalam Eksekusi Transaksi Ethereum

Pada tingkat modul kode, selain EVM, komponen inti lain yang terkait dengan eksekusi transaksi di go-ethereum adalah stateDB, yang digunakan untuk mengelola status akun dan penyimpanan data di Ethereum. Ethereum menggunakan struktur pohon yang disebut Merkle Patricia Trie sebagai indeks basis data. Setiap kali eksekusi transaksi dilakukan oleh EVM, beberapa data dalam stateDB akan berubah, dan perubahan ini pada akhirnya akan tercermin dalam pohon status global.

stateDB bertanggung jawab untuk memelihara status semua akun Ethereum, termasuk akun EOA dan akun kontrak, data yang disimpan mencakup saldo akun, kode kontrak pintar, dan lainnya. Selama proses eksekusi transaksi, stateDB akan melakukan pembacaan dan penulisan data akun yang sesuai. Setelah eksekusi transaksi selesai, stateDB perlu mengirimkan status baru ke database bawah untuk diproses secara permanen.

Secara keseluruhan, EVM bertanggung jawab untuk menginterpretasikan dan mengeksekusi instruksi kontrak pintar, mengubah status di blockchain berdasarkan hasil perhitungan, sementara stateDB berfungsi sebagai penyimpanan status global, mengelola semua perubahan status akun dan kontrak. Keduanya bekerja sama membangun lingkungan eksekusi transaksi Ethereum.

proses eksekusi serial yang spesifik

Transaksi Ethereum dibagi menjadi dua jenis: transfer EOA dan transaksi kontrak. Transfer EOA adalah jenis transaksi yang paling sederhana, yaitu transfer ETH antara akun biasa, yang tidak melibatkan pemanggilan kontrak, dengan kecepatan pemrosesan yang sangat cepat dan biaya gas yang sangat rendah.

Perdagangan kontrak melibatkan pemanggilan dan pelaksanaan kontrak pintar. Ketika EVM memproses perdagangan kontrak, ia perlu menjelaskan dan melaksanakan instruksi bytecode dalam kontrak pintar satu per satu. Semakin kompleks logika kontrak, semakin banyak instruksi yang terlibat, semakin banyak sumber daya yang digunakan.

Misalnya, waktu pemrosesan transfer ERC-20 sekitar 2 kali lipat dari transfer EOA, dan kontrak pintar yang lebih kompleks ( seperti operasi perdagangan di DEX tertentu ) memerlukan waktu lebih lama, mungkin 10 kali lebih lambat dari transfer EOA. Ini karena protokol DeFi perlu menangani kolam likuiditas, perhitungan harga, pertukaran token, dan logika kompleks lainnya saat melakukan transaksi, yang memerlukan banyak perhitungan.

Dalam mode eksekusi serial, proses penanganan transaksi oleh EVM dan stateDB adalah sebagai berikut:

Dalam desain Ethereum, transaksi dalam satu blok diproses secara berurutan satu per satu, di mana setiap transaksi memiliki instance independen untuk menjalankan operasi spesifik. Meskipun setiap transaksi menggunakan instance EVM yang berbeda, semua transaksi berbagi satu database status yang sama yaitu stateDB.

Selama proses eksekusi transaksi, EVM perlu terus berinteraksi dengan stateDB, membaca data terkait darinya, dan menulis kembali data yang telah diubah ke stateDB.

Dari sudut pandang kode, proses umum kolaborasi EVM dan stateDB dalam mengeksekusi transaksi adalah sebagai berikut:

1. fungsi processBlock() memanggil fungsi Process() untuk memproses transaksi dalam sebuah blok.

2. Proses() fungsi mendefinisikan sebuah loop for, transaksi dieksekusi satu per satu.

3. Setelah semua transaksi diproses, fungsi processBlock() memanggil fungsi writeBlockWithState(), kemudian memanggil fungsi statedb.Commit() untuk mengirimkan hasil perubahan status.

Ketika semua transaksi dalam sebuah blok telah dieksekusi, data dalam stateDB akan diserahkan ke pohon status global dan menghasilkan akar status baru. Akar status adalah parameter penting dalam setiap blok, yang mencatat "hasil kompresi" dari status global baru setelah eksekusi blok.

Mode eksekusi serial EVM memiliki batasan yang jelas: transaksi harus dieksekusi dalam urutan antrean, jika ada transaksi kontrak pintar yang memakan waktu lama, transaksi lainnya hanya bisa menunggu, tidak dapat memanfaatkan sumber daya perangkat keras seperti CPU secara maksimal, efisiensinya sangat terbatas.

Solusi Optimasi Paralel Multi-Threading EVM

Membandingkan eksekusi serial dan eksekusi paralel, yang pertama seperti bank dengan satu loket, sedangkan EVM paralel seperti bank dengan banyak loket. Dalam mode paralel, beberapa utas dapat dibuka untuk memproses beberapa transaksi secara bersamaan, efisiensinya dapat meningkat beberapa kali lipat, tetapi tantangan yang dihadapi adalah masalah konflik status.

Jika beberapa transaksi menyatakan ingin mengubah data dari akun tertentu, pemrosesan secara bersamaan akan menyebabkan konflik. Misalnya, jika suatu NFT hanya dapat dicetak 1 buah, dan transaksi 1 dan transaksi 2 keduanya ingin mencetak NFT tersebut, jika kedua permintaan dipenuhi, jelas akan terjadi kesalahan. Dalam praktiknya, konflik status seringkali lebih sering terjadi, sehingga pemrosesan transaksi secara paralel harus memiliki langkah-langkah untuk menangani konflik status.

Prinsip optimasi paralel EVM pada suatu proyek

Sebuah proyek ZKRollup mengoptimalkan EVM dengan cara memberikan satu transaksi untuk setiap thread, dan menyediakan basis data status sementara di setiap thread, yang disebut pending-stateDB. Detail spesifiknya adalah sebagai berikut:

1. Eksekusi transaksi paralel multithreading: Mengatur beberapa thread untuk memproses transaksi yang berbeda secara bersamaan, tanpa saling mengganggu, dapat meningkatkan kecepatan pemrosesan transaksi berkali-kali.

2. Alokasikan basis data status sementara untuk setiap thread: setiap thread diberikan basis data status sementara yang independen (pending-stateDB). Saat thread mengeksekusi transaksi, tidak langsung memodifikasi stateDB global, tetapi mencatat hasil perubahan status sementara di pending-stateDB.

3. Sinkronisasi Perubahan Status: Setelah semua transaksi dalam satu blok dieksekusi, EVM akan menyinkronkan hasil perubahan status yang tercatat di setiap pending-stateDB secara berurutan ke dalam global stateDB. Jika tidak ada konflik status selama proses eksekusi transaksi yang berbeda, maka catatan dalam pending-stateDB dapat digabungkan dengan lancar ke dalam global stateDB.

Proyek ini telah mengoptimalkan penanganan operasi baca dan tulis, memastikan transaksi dapat mengakses data status dengan benar dan menghindari konflik:

Operasi baca: Ketika transaksi perlu membaca status, EVM pertama-tama memeriksa ReadSet dari Pending-state. Jika ReadSet memiliki data yang diperlukan, data tersebut langsung dibaca dari pending-stateDB. Jika tidak ada pasangan kunci yang sesuai dalam ReadSet, maka data status historis dibaca dari global stateDB dari blok sebelumnya.

Operasi tulis: Semua operasi tulis (, yaitu perubahan status ), tidak langsung ditulis ke global stateDB, tetapi terlebih dahulu dicatat ke WriteSet Pending-state. Setelah eksekusi transaksi selesai, hasil perubahan status dicoba untuk digabungkan ke dalam global stateDB melalui deteksi konflik.

Masalah kunci dalam eksekusi paralel adalah konflik status, yang sangat mencolok ketika beberapa transaksi mencoba membaca dan menulis status akun yang sama. Untuk itu, mekanisme deteksi konflik diperkenalkan:

Deteksi konflik: Selama proses eksekusi transaksi, EVM memantau ReadSet dan WriteSet dari transaksi yang berbeda. Jika ditemukan beberapa transaksi yang mencoba membaca dan menulis item status yang sama, maka dianggap telah terjadi konflik.

Penanganan konflik: Ketika konflik terdeteksi, transaksi konflik ditandai sebagai perlu dieksekusi ulang.

Setelah semua transaksi dieksekusi, beberapa catatan perubahan dalam pending-stateDB akan digabungkan ke dalam global stateDB. Jika penggabungan berhasil, EVM akan mengirimkan status akhir ke pohon status global dan menghasilkan akar status baru.

Optimasi paralel multithreading secara signifikan meningkatkan kinerja, terutama saat memproses transaksi kontrak pintar yang kompleks. Penelitian menunjukkan bahwa dalam beban kerja dengan konflik rendah, TPS pengujian benchmark meningkat 3-5 kali lipat dibandingkan dengan eksekusi serial tradisional. Dalam beban kerja dengan konflik tinggi, secara teoritis jika semua metode optimasi diterapkan, bahkan dapat mencapai peningkatan hingga 60 kali lipat.

Ringkasan

Solusi optimisasi paralel multithreading EVM di atas, dengan mengalokasikan pustaka status sementara untuk setiap transaksi dan mengeksekusi transaksi secara paralel di berbagai thread, secara signifikan meningkatkan kemampuan pemrosesan transaksi EVM. Dengan mengoptimalkan operasi baca/tulis dan memperkenalkan mekanisme deteksi konflik, rantai publik EVM dapat mewujudkan paralelisasi transaksi dalam skala besar tanpa mengorbankan konsistensi status, menyelesaikan hambatan kinerja yang dihadirkan oleh model eksekusi serial tradisional. Ini meletakkan dasar yang penting untuk perkembangan Rollup Ethereum di masa depan.

Arah penelitian di masa depan mencakup: mengoptimalkan efisiensi penyimpanan untuk meningkatkan kinerja, solusi optimasi untuk menghadapi situasi konflik tinggi, serta bagaimana memanfaatkan GPU untuk optimasi dan konten lainnya.