Optimisasi Paralelisasi EVM: Membahas Jalan Peningkatan Kinerja dengan Contoh Reddio

Seperti yang kita ketahui, EVM adalah salah satu komponen inti dari Ethereum, yang berperan penting sebagai "mesin eksekusi" dan "lingkungan pelaksanaan kontrak pintar". Dalam jaringan terbuka yang terdiri dari ribuan node seperti blockchain, konfigurasi perangkat keras dari berbagai node dapat sangat bervariasi. Untuk memastikan bahwa kontrak pintar mendapatkan hasil eksekusi yang konsisten di semua node, teknologi mesin virtual menjadi solusi yang ideal.

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

Kontrak pintar yang kita lihat di penjelajah blockchain, semuanya terlebih dahulu dikompilasi menjadi bytecode EVM, kemudian 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 secara serial, di mana semua transaksi antre dalam satu antrean dan dieksekusi secara berurutan sesuai dengan urutan yang ditentukan. Alasan untuk tidak menggunakan metode paralel adalah karena blockchain perlu memastikan konsistensi yang ketat; batch transaksi yang sama harus diproses dalam urutan yang sama di semua node. Jika pemrosesan transaksi dilakukan secara paralel, akan sulit untuk memprediksi urutan transaksi dengan tepat, kecuali jika algoritma penjadwalan yang kompleks diperkenalkan.

Pada tahun 2014-2015, tim pendiri Ethereum memilih untuk merancang metode eksekusi serial yang sederhana dan mudah dipelihara karena keterbatasan waktu. Namun, seiring dengan iterasi teknologi blockchain dan perluasan basis pengguna, tuntutan terhadap TPS dan throughput semakin meningkat. Setelah teknologi Rollup muncul dan menjadi matang, hambatan kinerja yang disebabkan oleh eksekusi serial EVM telah menjadi jelas terlihat di jaringan lapisan kedua Ethereum.

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

Sebuah tim melakukan optimasi ekstrem pada lapisan DA dan modul baca tulis data, sehingga Sequencer dapat mengeksekusi lebih dari 2000 transaksi ERC-20 per detik. Angka ini terlihat sangat tinggi, tetapi jika transaksi yang harus diproses jauh lebih kompleks dibandingkan transaksi ERC-20, nilai TPS pasti akan turun secara signifikan. Oleh karena itu, paralelisasi pemrosesan transaksi akan menjadi tren yang tidak dapat dihindari di masa depan.

Dua Komponen Inti dalam Eksekusi Transaksi Ethereum

Selain EVM, komponen inti lain yang terkait dengan eksekusi transaksi dalam 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, di mana setiap eksekusi transaksi EVM akan mengubah beberapa data yang disimpan dalam stateDB, dan perubahan ini akhirnya akan tercermin dalam pohon status global.

stateDB bertanggung jawab untuk memelihara status semua akun Ethereum, termasuk akun EOA dan akun kontrak, yang menyimpan data seperti saldo akun, kode kontrak pintar, dan lainnya. Selama proses eksekusi transaksi, stateDB akan membaca dan menulis data untuk akun yang sesuai. Setelah eksekusi transaksi selesai, stateDB perlu mengirimkan status baru ke basis data bawah untuk pemrosesan persisten.

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

Proses pelaksanaan serial yang spesifik

Tipe transaksi Ethereum dibagi menjadi transfer EOA dan transaksi kontrak. Transfer EOA adalah tipe transaksi yang paling sederhana, yaitu transfer ETH antara akun biasa, tidak melibatkan pemanggilan kontrak, kecepatan pemrosesannya sangat cepat, dan biaya gas yang dikenakan juga sangat rendah.

Perdagangan kontrak melibatkan pemanggilan dan pelaksanaan kontrak pintar. Saat EVM memproses perdagangan kontrak, perlu untuk menafsirkan dan mengeksekusi instruksi bytecode dalam kontrak pintar satu per satu, semakin kompleks logika kontrak, semakin banyak instruksi yang terlibat, semakin banyak juga sumber daya yang dikonsumsi.

Misalnya, waktu pemrosesan transfer ERC-20 sekitar 2 kali lipat dari transfer EOA, sedangkan kontrak pintar yang lebih kompleks, seperti operasi perdagangan di DEX tertentu, bisa memakan waktu hingga belasan kali lipat dari transfer EOA. Ini karena protokol DeFi perlu menangani kumpulan likuiditas, perhitungan harga, pertukaran token, dan logika kompleks lainnya saat melakukan transaksi, yang memerlukan banyak perhitungan.

Dalam mode eksekusi serial, proses kolaborasi antara EVM dan stateDB dalam menangani transaksi adalah sebagai berikut:

Dalam desain Ethereum, transaksi dalam satu blok akan diproses satu per satu sesuai urutan. Setiap transaksi memiliki instance independen untuk melaksanakan operasi tertentu. Meskipun setiap transaksi menggunakan instance EVM yang berbeda, semua transaksi berbagi database status yang sama, yaitu stateDB.

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

Setelah semua transaksi dalam sebuah blok dieksekusi, data dalam stateDB akan disimpan ke dalam 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.

Bottleneck dari mode eksekusi serial EVM sangat jelas: transaksi harus dieksekusi sesuai urutan dalam antrean, jika ada transaksi kontrak pintar yang memakan waktu lama, transaksi lainnya hanya dapat menunggu sampai yang tersebut selesai diproses, ini jelas tidak dapat memanfaatkan sumber daya perangkat keras seperti CPU secara maksimal, efisiensinya sangat terbatas.

Solusi Optimasi Paralel Multithreading EVM

Eksekusi serial dan eksekusi paralel dapat disamakan dengan bank yang memiliki satu loket dan bank yang memiliki beberapa loket. Dalam mode paralel, beberapa thread dapat dibuka untuk memproses beberapa transaksi secara bersamaan, efisiensi dapat meningkat beberapa kali lipat, tetapi masalah konflik status menjadi rumit.

Jika beberapa transaksi menyatakan ingin mengubah data akun tertentu, akan terjadi konflik ketika mereka diproses secara bersamaan. Misalnya, jika sebuah NFT hanya dapat dicetak satu kali, dan transaksi 1 serta transaksi 2 keduanya menyatakan ingin mencetak NFT tersebut, jika kedua permintaan terpenuhi, jelas akan terjadi kesalahan. Konflik status dalam praktik sering kali lebih sering terjadi, sehingga pemrosesan transaksi secara paralel harus memiliki langkah untuk menangani konflik status.

Prinsip Optimasi Paralel Reddio untuk EVM

Sebuah proyek ZKRollup mengusulkan pendekatan optimasi paralel untuk EVM dengan mengalokasikan satu transaksi untuk setiap thread, dan menyediakan database status sementara di setiap thread, yang disebut pending-stateDB. Rincian spesifiknya adalah sebagai berikut:

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

2. Alokasikan basis data status sementara untuk setiap thread: alokasikan basis data status sementara yang independen untuk setiap thread (pending-stateDB). Setiap thread saat melakukan transaksi, tidak langsung memodifikasi stateDB global, melainkan mencatat hasil perubahan status sementara di pending-stateDB.

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

Proyek ini mengoptimalkan cara penanganan operasi baca dan tulis untuk 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 berisi data yang diperlukan, langsung dibaca dari pending-stateDB. Jika pasangan kunci-nilai yang sesuai tidak ditemukan dalam ReadSet, maka dibaca dari data status historis di global stateDB dari blok sebelumnya.

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

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

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

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

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

Peningkatan kinerja melalui optimasi paralel multithreading sangat signifikan, terutama saat menangani transaksi kontrak pintar yang kompleks. Penelitian menunjukkan bahwa dalam beban kerja dengan konflik rendah, transaksi dalam kolam transaksi ( yang memiliki sedikit konflik atau menggunakan sumber daya yang sama, pengujian benchmark TPS meningkat sekitar 3-5 kali dibandingkan dengan eksekusi serial tradisional. Dalam beban kerja dengan konflik tinggi, secara teori, jika semua metode optimasi diterapkan, bahkan dapat mencapai peningkatan hingga 60 kali.

![Menggunakan Reddio sebagai contoh, menjelaskan jalan optimasi EVM paralel])https://img-cdn.gateio.im/webp-social/moments-4966960247a4550afa25f04eaaabbbd8.webp(

Ringkasan

Solusi optimasi paralel multithreading EVM proyek ini, dengan memberikan perpustakaan 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, blockchain publik EVM dapat mencapai paralelisasi transaksi dalam skala besar dengan menjamin konsistensi status, mengatasi hambatan kinerja yang ditimbulkan oleh model eksekusi serial tradisional. Ini memberikan dasar penting untuk perkembangan Rollup Ethereum di masa depan.

![Menggunakan Reddio sebagai contoh, menjelaskan jalan optimasi EVM paralel])https://img-cdn.gateio.im/webp-social/moments-af377193cf86df94c08df49ba217e327.webp(