Seperti yang kita ketahui, EVM adalah salah satu komponen inti terpenting dari Ethereum, berfungsi sebagai "mesin eksekusi" dan "lingkungan eksekusi kontrak pintar" yang memainkan peran kunci. Dalam jaringan publik yang terdiri dari ribuan node, keberadaan mesin virtual memungkinkan kontrak pintar untuk dijalankan dengan cara yang sama di node dengan konfigurasi perangkat keras yang berbeda, memastikan konsistensi hasil. Kompatibilitas lintas platform ini sangat mirip dengan mesin virtual Java (JVM).
Kontrak pintar akan dikompilasi menjadi bytecode EVM sebelum diunggah ke blockchain. Saat EVM mengeksekusi kontrak, ia membaca bytecode ini secara berurutan, di mana setiap instruksi memiliki biaya Gas yang sesuai. EVM akan melacak konsumsi Gas selama proses eksekusi instruksi, dan jumlah yang dikonsumsi tergantung pada kompleksitas operasi.
Sebagai mesin eksekusi inti Ethereum, EVM menggunakan metode eksekusi serial untuk memproses transaksi. Semua transaksi mengantri dalam satu antrean, dieksekusi satu per satu sesuai urutan yang ditentukan. Desain ini sederhana dan mudah untuk dipelihara, tetapi seiring dengan meningkatnya jumlah pengguna dan iterasi teknologi, hambatan kinerjanya semakin nyata, terutama setelah teknologi Rollup matang, yang menjadi sangat jelas di jaringan lapisan dua Ethereum.
Sequencer sebagai komponen kunci Layer2, menjalankan semua tugas perhitungan dalam bentuk server tunggal. Jika modul eksternal yang dipasangkan cukup efisien, maka akhirnya bottleneck akan bergantung pada efisiensi Sequencer itu sendiri, dan pada saat itu, eksekusi serial akan menjadi hambatan besar.
Sebuah tim telah melakukan optimasi yang ekstrem pada lapisan DA dan modul pembacaan serta penulisan data, sehingga Sequencer dapat mengeksekusi hingga sekitar 2000 transaksi ERC-20 per detik. Angka ini terlihat sangat tinggi, tetapi untuk transaksi yang kompleks, nilai TPS pasti akan turun drastis. Oleh karena itu, paralelisasi pemrosesan transaksi akan menjadi tren yang tidak terhindarkan di masa depan.
Dua Komponen Inti 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 Merkle Patricia Trie sebagai indeks basis data, di mana setiap kali eksekusi transaksi EVM, beberapa data dalam stateDB akan berubah, dan perubahan ini akhirnya tercermin dalam pohon status global.
stateDB bertanggung jawab untuk memelihara status semua akun Ethereum, termasuk akun EOA dan akun kontrak, data yang disimpan termasuk saldo akun, kode kontrak pintar, dll. Selama proses eksekusi transaksi, stateDB akan melakukan operasi baca dan tulis pada data akun yang sesuai. Setelah eksekusi transaksi selesai, stateDB perlu mengirimkan status baru ke database dasar 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 untuk membangun lingkungan eksekusi transaksi Ethereum.
Proses eksekusi serial yang spesifik
Jenis transaksi Ethereum dibagi menjadi transfer EOA dan transaksi kontrak. Transfer EOA adalah jenis transaksi yang paling sederhana, yaitu transfer ETH antar akun biasa, tidak melibatkan panggilan kontrak, kecepatan pemrosesan sangat cepat, dan biaya gas sangat rendah.
Perdagangan kontrak melibatkan pemanggilan dan eksekusi kontrak pintar. EVM saat memproses perdagangan kontrak, perlu menafsirkan dan mengeksekusi instruksi bytecode dalam kontrak pintar satu per satu. Semakin kompleks logika kontrak, semakin banyak instruksi yang terlibat, semakin banyak sumber daya yang dikonsumsi.
Misalnya, waktu pemrosesan transfer ERC-20 adalah sekitar 2 kali lipat dari transfer EOA, sementara 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 logika kompleks seperti kolam likuiditas, perhitungan harga, pertukaran token, dan lain-lain saat melakukan transaksi, yang memerlukan perhitungan yang sangat rumit.
Dalam mode eksekusi serial, proses kolaborasi EVM dengan stateDB adalah sebagai berikut:
Transaksi dalam blok diproses satu per satu sesuai urutan, setiap transaksi memiliki instansinya sendiri untuk melakukan 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 dan menulis kembali data yang telah diubah ke stateDB.
Setelah semua transaksi diproses, data dalam stateDB akan diserahkan ke pohon status global dan menghasilkan akar status baru.
Bottleneck mode eksekusi serial EVM sangat jelas: transaksi harus dijalankan secara berurutan, jika ada transaksi kontrak pintar yang memakan waktu lama, transaksi lainnya hanya bisa menunggu, tidak dapat memanfaatkan sumber daya perangkat keras secara maksimal, efisiensi sangat terbatas.
Solusi Optimasi Paralel Multithreading EVM
EVM paralel mirip dengan bank yang memiliki beberapa konter, dapat membuka beberapa utas untuk memproses beberapa transaksi secara bersamaan, efisiensinya dapat meningkat beberapa kali lipat. Namun, masalah konflik status yang rumit perlu ditangani dengan koordinasi.
Sebuah proyek ZKRollup memiliki pemikiran tentang optimasi paralel EVM sebagai berikut:
Eksekusi transaksi paralel multithreading: Mengatur beberapa thread untuk memproses transaksi yang berbeda secara bersamaan, thread tidak saling mengganggu, dapat meningkatkan kecepatan pemrosesan transaksi beberapa kali lipat.
Alokasikan basis data status sementara untuk setiap thread: Setiap thread dialokasikan basis data status sementara yang independen (pending-stateDB). Ketika thread menjalankan transaksi, ia tidak langsung mengubah stateDB global, tetapi mencatat hasil perubahan status sementara di pending-stateDB.
Sinkronisasi Perubahan Status: Setelah semua transaksi dalam satu blok dieksekusi, EVM akan secara berurutan menyinkronkan hasil perubahan status yang tercatat di setiap pending-stateDB ke dalam global stateDB. Jika tidak ada konflik status yang terjadi selama pelaksanaan transaksi yang berbeda, catatan di pending-stateDB dapat dengan lancar digabungkan ke dalam global stateDB.
Proyek ini telah mengoptimalkan pengolahan 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 data yang diperlukan ada, langsung dibaca dari pending-stateDB. Jika tidak ditemukan pasangan kunci nilai yang sesuai dalam ReadSet, maka baca data status historis dari global stateDB yang sesuai di blok sebelumnya.
Operasi tulis: Semua operasi tulis tidak langsung ditulis ke stateDB global, tetapi 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.
Untuk menyelesaikan masalah konflik status, mekanisme deteksi konflik diperkenalkan:
Deteksi konflik: EVM memantau ReadSet dan WriteSet dari transaksi yang berbeda. Jika ditemukan beberapa transaksi mencoba membaca dan menulis item status yang sama, maka dianggap terjadi konflik.
Penanganan konflik: Ketika konflik terdeteksi, transaksi yang konflik akan ditandai untuk dieksekusi ulang.
Setelah semua transaksi dieksekusi, beberapa catatan perubahan dalam pending-stateDB akan digabungkan ke dalam global stateDB. Jika penggabungan berhasil, EVM akan menyerahkan status akhir ke dalam pohon status global dan menghasilkan root status baru.
Optimisasi paralel multi-threading secara signifikan meningkatkan kinerja, terutama dalam menangani transaksi kontrak pintar yang kompleks. Penelitian menunjukkan bahwa dalam beban kerja dengan konflik rendah, TPS dari pengujian acuan meningkat 3 hingga 5 kali dibandingkan dengan eksekusi serial tradisional. Dalam beban kerja dengan konflik tinggi, secara teoritis jika semua metode optimasi diterapkan, peningkatan bahkan dapat mencapai 60 kali.
Ringkasan
Solusi optimasi paralel multithreading EVM secara signifikan meningkatkan kapasitas pemrosesan transaksi EVM dengan mengalokasikan pustaka status sementara untuk setiap transaksi dan mengeksekusi transaksi secara paralel di thread yang berbeda. Dengan mengoptimalkan operasi baca-tulis dan memperkenalkan mekanisme deteksi konflik, jaringan publik EVM dapat mewujudkan paralelisasi transaksi dalam skala besar dengan menjaga konsistensi status, mengatasi hambatan kinerja yang ditimbulkan oleh mode eksekusi serial tradisional. Ini membangun dasar yang penting untuk perkembangan Rollup Ethereum di masa depan.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
EVM dioptimalkan: Peningkatan efisiensi pemrosesan transaksi melalui paralel multithreading
Jalan Optimasi Paralelisasi EVM
Seperti yang kita ketahui, EVM adalah salah satu komponen inti terpenting dari Ethereum, berfungsi sebagai "mesin eksekusi" dan "lingkungan eksekusi kontrak pintar" yang memainkan peran kunci. Dalam jaringan publik yang terdiri dari ribuan node, keberadaan mesin virtual memungkinkan kontrak pintar untuk dijalankan dengan cara yang sama di node dengan konfigurasi perangkat keras yang berbeda, memastikan konsistensi hasil. Kompatibilitas lintas platform ini sangat mirip dengan mesin virtual Java (JVM).
Kontrak pintar akan dikompilasi menjadi bytecode EVM sebelum diunggah ke blockchain. Saat EVM mengeksekusi kontrak, ia membaca bytecode ini secara berurutan, di mana setiap instruksi memiliki biaya Gas yang sesuai. EVM akan melacak konsumsi Gas selama proses eksekusi instruksi, dan jumlah yang dikonsumsi tergantung pada kompleksitas operasi.
Sebagai mesin eksekusi inti Ethereum, EVM menggunakan metode eksekusi serial untuk memproses transaksi. Semua transaksi mengantri dalam satu antrean, dieksekusi satu per satu sesuai urutan yang ditentukan. Desain ini sederhana dan mudah untuk dipelihara, tetapi seiring dengan meningkatnya jumlah pengguna dan iterasi teknologi, hambatan kinerjanya semakin nyata, terutama setelah teknologi Rollup matang, yang menjadi sangat jelas di jaringan lapisan dua Ethereum.
Sequencer sebagai komponen kunci Layer2, menjalankan semua tugas perhitungan dalam bentuk server tunggal. Jika modul eksternal yang dipasangkan cukup efisien, maka akhirnya bottleneck akan bergantung pada efisiensi Sequencer itu sendiri, dan pada saat itu, eksekusi serial akan menjadi hambatan besar.
Sebuah tim telah melakukan optimasi yang ekstrem pada lapisan DA dan modul pembacaan serta penulisan data, sehingga Sequencer dapat mengeksekusi hingga sekitar 2000 transaksi ERC-20 per detik. Angka ini terlihat sangat tinggi, tetapi untuk transaksi yang kompleks, nilai TPS pasti akan turun drastis. Oleh karena itu, paralelisasi pemrosesan transaksi akan menjadi tren yang tidak terhindarkan di masa depan.
Dua Komponen Inti 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 Merkle Patricia Trie sebagai indeks basis data, di mana setiap kali eksekusi transaksi EVM, beberapa data dalam stateDB akan berubah, dan perubahan ini akhirnya tercermin dalam pohon status global.
stateDB bertanggung jawab untuk memelihara status semua akun Ethereum, termasuk akun EOA dan akun kontrak, data yang disimpan termasuk saldo akun, kode kontrak pintar, dll. Selama proses eksekusi transaksi, stateDB akan melakukan operasi baca dan tulis pada data akun yang sesuai. Setelah eksekusi transaksi selesai, stateDB perlu mengirimkan status baru ke database dasar 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 untuk membangun lingkungan eksekusi transaksi Ethereum.
Proses eksekusi serial yang spesifik
Jenis transaksi Ethereum dibagi menjadi transfer EOA dan transaksi kontrak. Transfer EOA adalah jenis transaksi yang paling sederhana, yaitu transfer ETH antar akun biasa, tidak melibatkan panggilan kontrak, kecepatan pemrosesan sangat cepat, dan biaya gas sangat rendah.
Perdagangan kontrak melibatkan pemanggilan dan eksekusi kontrak pintar. EVM saat memproses perdagangan kontrak, perlu menafsirkan dan mengeksekusi instruksi bytecode dalam kontrak pintar satu per satu. Semakin kompleks logika kontrak, semakin banyak instruksi yang terlibat, semakin banyak sumber daya yang dikonsumsi.
Misalnya, waktu pemrosesan transfer ERC-20 adalah sekitar 2 kali lipat dari transfer EOA, sementara 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 logika kompleks seperti kolam likuiditas, perhitungan harga, pertukaran token, dan lain-lain saat melakukan transaksi, yang memerlukan perhitungan yang sangat rumit.
Dalam mode eksekusi serial, proses kolaborasi EVM dengan stateDB adalah sebagai berikut:
Bottleneck mode eksekusi serial EVM sangat jelas: transaksi harus dijalankan secara berurutan, jika ada transaksi kontrak pintar yang memakan waktu lama, transaksi lainnya hanya bisa menunggu, tidak dapat memanfaatkan sumber daya perangkat keras secara maksimal, efisiensi sangat terbatas.
Solusi Optimasi Paralel Multithreading EVM
EVM paralel mirip dengan bank yang memiliki beberapa konter, dapat membuka beberapa utas untuk memproses beberapa transaksi secara bersamaan, efisiensinya dapat meningkat beberapa kali lipat. Namun, masalah konflik status yang rumit perlu ditangani dengan koordinasi.
Sebuah proyek ZKRollup memiliki pemikiran tentang optimasi paralel EVM sebagai berikut:
Eksekusi transaksi paralel multithreading: Mengatur beberapa thread untuk memproses transaksi yang berbeda secara bersamaan, thread tidak saling mengganggu, dapat meningkatkan kecepatan pemrosesan transaksi beberapa kali lipat.
Alokasikan basis data status sementara untuk setiap thread: Setiap thread dialokasikan basis data status sementara yang independen (pending-stateDB). Ketika thread menjalankan transaksi, ia tidak langsung mengubah stateDB global, tetapi mencatat hasil perubahan status sementara di pending-stateDB.
Sinkronisasi Perubahan Status: Setelah semua transaksi dalam satu blok dieksekusi, EVM akan secara berurutan menyinkronkan hasil perubahan status yang tercatat di setiap pending-stateDB ke dalam global stateDB. Jika tidak ada konflik status yang terjadi selama pelaksanaan transaksi yang berbeda, catatan di pending-stateDB dapat dengan lancar digabungkan ke dalam global stateDB.
Proyek ini telah mengoptimalkan pengolahan 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 data yang diperlukan ada, langsung dibaca dari pending-stateDB. Jika tidak ditemukan pasangan kunci nilai yang sesuai dalam ReadSet, maka baca data status historis dari global stateDB yang sesuai di blok sebelumnya.
Operasi tulis: Semua operasi tulis tidak langsung ditulis ke stateDB global, tetapi 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.
Untuk menyelesaikan masalah konflik status, mekanisme deteksi konflik diperkenalkan:
Setelah semua transaksi dieksekusi, beberapa catatan perubahan dalam pending-stateDB akan digabungkan ke dalam global stateDB. Jika penggabungan berhasil, EVM akan menyerahkan status akhir ke dalam pohon status global dan menghasilkan root status baru.
Optimisasi paralel multi-threading secara signifikan meningkatkan kinerja, terutama dalam menangani transaksi kontrak pintar yang kompleks. Penelitian menunjukkan bahwa dalam beban kerja dengan konflik rendah, TPS dari pengujian acuan meningkat 3 hingga 5 kali dibandingkan dengan eksekusi serial tradisional. Dalam beban kerja dengan konflik tinggi, secara teoritis jika semua metode optimasi diterapkan, peningkatan bahkan dapat mencapai 60 kali.
Ringkasan
Solusi optimasi paralel multithreading EVM secara signifikan meningkatkan kapasitas pemrosesan transaksi EVM dengan mengalokasikan pustaka status sementara untuk setiap transaksi dan mengeksekusi transaksi secara paralel di thread yang berbeda. Dengan mengoptimalkan operasi baca-tulis dan memperkenalkan mekanisme deteksi konflik, jaringan publik EVM dapat mewujudkan paralelisasi transaksi dalam skala besar dengan menjaga konsistensi status, mengatasi hambatan kinerja yang ditimbulkan oleh mode eksekusi serial tradisional. Ini membangun dasar yang penting untuk perkembangan Rollup Ethereum di masa depan.