Penjelajahan Bottleneck Eksekusi Serial EVM dan Optimasi Paralel
Seperti yang kita ketahui, EVM adalah mesin eksekusi inti Ethereum dan lingkungan operasi smart contract, serta merupakan salah satu komponen terpenting dari Ethereum. Dalam jaringan blockchain publik yang terdiri dari banyak node, untuk memastikan bahwa smart contract dapat dieksekusi dengan hasil yang konsisten di berbagai node, teknologi mesin virtual memainkan peran yang sangat penting.
EVM dapat menjalankan kontrak pintar dengan cara yang konsisten di berbagai sistem operasi dan perangkat, yang menjamin bahwa setiap node mendapatkan hasil yang konsisten setelah menjalankan kontrak. Ini mirip dengan cara kerja Java Virtual Machine (JVM).
Dalam kondisi normal, kontrak pintar akan dikompilasi menjadi bytecode EVM terlebih dahulu, kemudian disimpan di blockchain. Ketika EVM mengeksekusi kontrak, ia akan membaca bytecode ini secara berurutan, di mana setiap instruksi memiliki biaya Gas tertentu. EVM akan melacak konsumsi Gas selama proses eksekusi setiap instruksi, dan jumlah konsumsi tersebut bergantung pada tingkat kompleksitas operasi.
Sebagai mesin eksekusi inti Ethereum, EVM memproses transaksi dalam cara serial, di mana semua transaksi mengantri dalam satu antrean dan dieksekusi dalam urutan yang ditentukan. Alasan untuk memilih serial daripada paralel adalah untuk memenuhi persyaratan konsistensi blockchain secara ketat, memastikan sekelompok transaksi diproses dalam urutan yang sama di semua node.
Antara tahun 2014-2015, tim pendiri Ethereum memilih metode eksekusi serial yang sederhana dan mudah dipelihara karena terbatasnya waktu. Namun, seiring perkembangan teknologi blockchain dan semakin luasnya basis pengguna, tuntutan terhadap TPS dan throughput terus meningkat. Terutama setelah teknologi Rollup matang dan diterapkan, hambatan kinerja yang dibawa oleh eksekusi serial EVM menjadi semakin jelas dalam jaringan lapisan kedua Ethereum.
Sebagai komponen kunci Layer2, Sequencer mengambil semua tugas penghitungan dalam bentuk server tunggal. Jika modul eksternal yang bekerja sama dengan Sequencer memiliki efisiensi yang cukup tinggi, maka bottleneck akhir akan bergantung pada efisiensi Sequencer itu sendiri, dan pada saat itu, eksekusi serial akan menjadi hambatan yang signifikan.
Sebuah tim melakukan optimalisasi ekstrem pada lapisan DA dan modul baca-tulis data, sehingga Sequencer dapat melakukan sekitar 2000 lebih transaksi ERC-20 per detik. Angka ini terlihat sangat tinggi, tetapi untuk transaksi yang lebih kompleks, nilai TPS pasti akan menurun secara signifikan. Oleh karena itu, paralelisasi pemrosesan transaksi akan menjadi tren yang tak terhindarkan di masa depan.
Dua Komponen Inti Eksekusi Transaksi Ethereum
Selain EVM, komponen inti lain yang terkait dengan eksekusi transaksi adalah stateDB, yang digunakan untuk mengelola status akun dan penyimpanan data di Ethereum. Ethereum menggunakan struktur pohon Merkle Patricia Trie sebagai indeks basis data, dan setiap eksekusi transaksi oleh EVM akan mengubah beberapa data dalam stateDB, 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, dll. Selama proses eksekusi transaksi, stateDB akan membaca dan menulis 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, sedangkan stateDB berfungsi sebagai penyimpanan status global, mengelola semua perubahan status akun dan kontrak. Keduanya bersama-sama membangun lingkungan eksekusi transaksi Ethereum.
proses eksekusi serial yang spesifik
Jenis transaksi Ethereum dibagi menjadi dua: transfer EOA dan transaksi kontrak. Transfer EOA adalah jenis transaksi yang paling sederhana, yaitu transfer ETH antara akun biasa, tidak melibatkan pemanggilan kontrak, kecepatan pemrosesannya sangat cepat, dan biaya gas yang dikenakan sangat rendah.
Sebaliknya, perdagangan kontrak melibatkan pemanggilan dan pelaksanaan kontrak pintar. EVM dalam 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 sekitar 2 kali lipat dari transfer EOA, sedangkan kontrak pintar yang lebih kompleks, seperti operasi perdagangan di DEX tertentu, dapat memakan waktu hingga belasan kali lebih lama daripada transfer EOA. Ini karena protokol DeFi perlu menangani logika kompleks seperti kolam likuiditas, perhitungan harga, pertukaran token, dan memerlukan banyak perhitungan saat melakukan transaksi.
Dalam mode eksekusi serial, proses di mana EVM dan stateDB bekerja sama untuk memproses transaksi adalah sebagai berikut:
Dalam desain Ethereum, transaksi dalam sebuah blok diproses satu per satu sesuai urutan, dan setiap transaksi memiliki instansinya sendiri untuk melakukan operasi tertentu. Meskipun setiap transaksi menggunakan instansi EVM yang berbeda, semua transaksi berbagi satu database status yang sama, yaitu stateDB.
Dalam 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 diserahkan ke pohon status global dan menghasilkan akar status baru. Akar status adalah parameter penting dalam setiap blok, mencatat "hasil kompresi" dari status global baru setelah eksekusi blok.
Jelas bahwa mode eksekusi serial EVM memiliki bottleneck yang signifikan: transaksi harus dieksekusi dalam urutan antrean, jika ada transaksi kontrak pintar yang memakan waktu lama, transaksi lainnya hanya bisa menunggu, yang mengakibatkan pemanfaatan sumber daya perangkat keras yang tidak maksimal dan efisiensi yang sangat terbatas.
Solusi Optimasi Paralel Multithreading EVM
Jika dianalogikan dengan contoh dalam kehidupan sehari-hari, eksekusi serial itu seperti bank dengan hanya satu loket, sementara EVM paralel mirip dengan bank yang memiliki banyak loket. Dalam mode paralel, beberapa utas dapat dijalankan secara bersamaan untuk memproses beberapa transaksi, efisiensinya dapat meningkat beberapa kali lipat, tetapi perlu menyelesaikan masalah konflik status.
Jika beberapa transaksi menyatakan ingin mengubah data akun tertentu, akan terjadi konflik saat memprosesnya. Misalnya, sebuah NFT hanya bisa dicetak 1 buah, dan transaksi 1 dan transaksi 2 keduanya menyatakan ingin mencetak NFT tersebut. Jika kedua permintaan dipenuhi, jelas akan terjadi kesalahan. Konflik status dalam praktik biasanya jauh lebih sering terjadi, sehingga pemrosesan paralel harus memiliki langkah untuk menangani konflik status.
Prinsip optimasi paralel EVM pada suatu proyek
Sebuah proyek ZKRollup memiliki pemikiran tentang optimasi paralel untuk EVM dengan cara memberikan satu transaksi untuk setiap utas, dan menyediakan basis data status sementara dalam setiap utas, yang disebut pending-stateDB. Detail spesifiknya adalah sebagai berikut:
Eksekusi transaksi secara paralel dengan multithreading: Mengatur beberapa thread untuk memproses transaksi yang berbeda secara bersamaan, di mana thread-thread tersebut tidak saling mengganggu, dapat meningkatkan kecepatan pemrosesan transaksi beberapa kali lipat.
Alokasikan database status sementara untuk setiap thread: Alokasikan database status sementara (pending-stateDB) yang independen untuk setiap thread. Setiap thread saat melakukan transaksi, tidak langsung mengubah stateDB global, tetapi sementara mencatat hasil perubahan status di pending-stateDB.
Sinkronisasi Perubahan Status: Setelah semua transaksi dalam satu blok dieksekusi, EVM akan menyinkronkan hasil perubahan status yang tercatat di setiap pending-stateDB ke dalam global stateDB secara berurutan. Jika transaksi yang berbeda tidak mengalami konflik status selama proses eksekusi, catatan di pending-stateDB dapat digabungkan dengan sukses ke dalam global stateDB.
Proyek ini telah mengoptimalkan cara penanganan operasi baca-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 pada Pending-state. Jika data yang diperlukan ada dalam ReadSet, maka dibaca langsung dari pending-stateDB. Jika pasangan kunci-nilai yang sesuai tidak ditemukan dalam ReadSet, maka dibaca data status historis dari global stateDB yang sesuai dengan blok sebelumnya.
Operasi tulis: Semua operasi tulis (yaitu modifikasi terhadap status) tidak akan langsung ditulis ke dalam global stateDB, tetapi terlebih dahulu dicatat ke dalam WriteSet dari Pending-state. Setelah eksekusi transaksi selesai, hasil perubahan status akan dicoba untuk digabungkan ke dalam global stateDB setelah deteksi konflik.
Masalah kunci dari eksekusi paralel adalah konflik status, yang sangat signifikan ketika beberapa transaksi mencoba untuk membaca dan menulis status akun yang sama. Untuk itu, mekanisme deteksi konflik diperkenalkan:
Deteksi konflik: Selama proses eksekusi transaksi, EVM akan memantau ReadSet dan WriteSet dari transaksi yang berbeda. Jika ditemukan beberapa transaksi yang mencoba membaca dan menulis item status yang sama, maka dianggap terjadi konflik.
Penanganan konflik: Ketika konflik terdeteksi, transaksi konflik akan ditandai untuk dieksekusi ulang.
Setelah semua transaksi selesai 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 akar status baru.
Peningkatan kinerja dari optimasi paralel multi-threading sangat signifikan, terutama saat menangani transaksi kontrak pintar yang kompleks. Penelitian menunjukkan bahwa dalam beban kerja dengan konflik rendah, TPS dari pengujian benchmark meningkat sekitar 3-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 mendistribusikan perpustakaan status sementara untuk setiap transaksi dan menjalankan transaksi secara paralel dalam berbagai thread. 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 mode eksekusi serial tradisional. Ini meletakkan dasar penting untuk pengembangan Rollup Ethereum di masa depan.
Di masa depan, kita masih dapat menjelajahi bagaimana mengoptimalkan efisiensi penyimpanan untuk meningkatkan kinerja, solusi optimasi dalam situasi dengan banyak konflik, serta bagaimana memanfaatkan GPU untuk optimasi dan konten lainnya.
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.
9 Suka
Hadiah
9
3
Bagikan
Komentar
0/400
LeverageAddict
· 07-20 10:07
Ada orang lain yang melakukan paralel lagi, sama seperti posisi L2 saya yang terjebak.
Lihat AsliBalas0
WenMoon
· 07-20 09:51
Wah, L2 juga harus dipercepat.
Lihat AsliBalas0
EntryPositionAnalyst
· 07-20 09:44
L2 paralelisasi sudah dipahami, sekarang baru mengikuti evm
Optimisasi paralelisasi EVM: Mengatasi kendala eksekusi serial untuk meningkatkan kinerja Layer2
Penjelajahan Bottleneck Eksekusi Serial EVM dan Optimasi Paralel
Seperti yang kita ketahui, EVM adalah mesin eksekusi inti Ethereum dan lingkungan operasi smart contract, serta merupakan salah satu komponen terpenting dari Ethereum. Dalam jaringan blockchain publik yang terdiri dari banyak node, untuk memastikan bahwa smart contract dapat dieksekusi dengan hasil yang konsisten di berbagai node, teknologi mesin virtual memainkan peran yang sangat penting.
EVM dapat menjalankan kontrak pintar dengan cara yang konsisten di berbagai sistem operasi dan perangkat, yang menjamin bahwa setiap node mendapatkan hasil yang konsisten setelah menjalankan kontrak. Ini mirip dengan cara kerja Java Virtual Machine (JVM).
Dalam kondisi normal, kontrak pintar akan dikompilasi menjadi bytecode EVM terlebih dahulu, kemudian disimpan di blockchain. Ketika EVM mengeksekusi kontrak, ia akan membaca bytecode ini secara berurutan, di mana setiap instruksi memiliki biaya Gas tertentu. EVM akan melacak konsumsi Gas selama proses eksekusi setiap instruksi, dan jumlah konsumsi tersebut bergantung pada tingkat kompleksitas operasi.
Sebagai mesin eksekusi inti Ethereum, EVM memproses transaksi dalam cara serial, di mana semua transaksi mengantri dalam satu antrean dan dieksekusi dalam urutan yang ditentukan. Alasan untuk memilih serial daripada paralel adalah untuk memenuhi persyaratan konsistensi blockchain secara ketat, memastikan sekelompok transaksi diproses dalam urutan yang sama di semua node.
Antara tahun 2014-2015, tim pendiri Ethereum memilih metode eksekusi serial yang sederhana dan mudah dipelihara karena terbatasnya waktu. Namun, seiring perkembangan teknologi blockchain dan semakin luasnya basis pengguna, tuntutan terhadap TPS dan throughput terus meningkat. Terutama setelah teknologi Rollup matang dan diterapkan, hambatan kinerja yang dibawa oleh eksekusi serial EVM menjadi semakin jelas dalam jaringan lapisan kedua Ethereum.
Sebagai komponen kunci Layer2, Sequencer mengambil semua tugas penghitungan dalam bentuk server tunggal. Jika modul eksternal yang bekerja sama dengan Sequencer memiliki efisiensi yang cukup tinggi, maka bottleneck akhir akan bergantung pada efisiensi Sequencer itu sendiri, dan pada saat itu, eksekusi serial akan menjadi hambatan yang signifikan.
Sebuah tim melakukan optimalisasi ekstrem pada lapisan DA dan modul baca-tulis data, sehingga Sequencer dapat melakukan sekitar 2000 lebih transaksi ERC-20 per detik. Angka ini terlihat sangat tinggi, tetapi untuk transaksi yang lebih kompleks, nilai TPS pasti akan menurun secara signifikan. Oleh karena itu, paralelisasi pemrosesan transaksi akan menjadi tren yang tak terhindarkan di masa depan.
Dua Komponen Inti Eksekusi Transaksi Ethereum
Selain EVM, komponen inti lain yang terkait dengan eksekusi transaksi adalah stateDB, yang digunakan untuk mengelola status akun dan penyimpanan data di Ethereum. Ethereum menggunakan struktur pohon Merkle Patricia Trie sebagai indeks basis data, dan setiap eksekusi transaksi oleh EVM akan mengubah beberapa data dalam stateDB, 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, dll. Selama proses eksekusi transaksi, stateDB akan membaca dan menulis 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, sedangkan stateDB berfungsi sebagai penyimpanan status global, mengelola semua perubahan status akun dan kontrak. Keduanya bersama-sama membangun lingkungan eksekusi transaksi Ethereum.
proses eksekusi serial yang spesifik
Jenis transaksi Ethereum dibagi menjadi dua: transfer EOA dan transaksi kontrak. Transfer EOA adalah jenis transaksi yang paling sederhana, yaitu transfer ETH antara akun biasa, tidak melibatkan pemanggilan kontrak, kecepatan pemrosesannya sangat cepat, dan biaya gas yang dikenakan sangat rendah.
Sebaliknya, perdagangan kontrak melibatkan pemanggilan dan pelaksanaan kontrak pintar. EVM dalam 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 sekitar 2 kali lipat dari transfer EOA, sedangkan kontrak pintar yang lebih kompleks, seperti operasi perdagangan di DEX tertentu, dapat memakan waktu hingga belasan kali lebih lama daripada transfer EOA. Ini karena protokol DeFi perlu menangani logika kompleks seperti kolam likuiditas, perhitungan harga, pertukaran token, dan memerlukan banyak perhitungan saat melakukan transaksi.
Dalam mode eksekusi serial, proses di mana EVM dan stateDB bekerja sama untuk memproses transaksi adalah sebagai berikut:
Dalam desain Ethereum, transaksi dalam sebuah blok diproses satu per satu sesuai urutan, dan setiap transaksi memiliki instansinya sendiri untuk melakukan operasi tertentu. Meskipun setiap transaksi menggunakan instansi EVM yang berbeda, semua transaksi berbagi satu database status yang sama, yaitu stateDB.
Dalam 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 diserahkan ke pohon status global dan menghasilkan akar status baru. Akar status adalah parameter penting dalam setiap blok, mencatat "hasil kompresi" dari status global baru setelah eksekusi blok.
Jelas bahwa mode eksekusi serial EVM memiliki bottleneck yang signifikan: transaksi harus dieksekusi dalam urutan antrean, jika ada transaksi kontrak pintar yang memakan waktu lama, transaksi lainnya hanya bisa menunggu, yang mengakibatkan pemanfaatan sumber daya perangkat keras yang tidak maksimal dan efisiensi yang sangat terbatas.
Solusi Optimasi Paralel Multithreading EVM
Jika dianalogikan dengan contoh dalam kehidupan sehari-hari, eksekusi serial itu seperti bank dengan hanya satu loket, sementara EVM paralel mirip dengan bank yang memiliki banyak loket. Dalam mode paralel, beberapa utas dapat dijalankan secara bersamaan untuk memproses beberapa transaksi, efisiensinya dapat meningkat beberapa kali lipat, tetapi perlu menyelesaikan masalah konflik status.
Jika beberapa transaksi menyatakan ingin mengubah data akun tertentu, akan terjadi konflik saat memprosesnya. Misalnya, sebuah NFT hanya bisa dicetak 1 buah, dan transaksi 1 dan transaksi 2 keduanya menyatakan ingin mencetak NFT tersebut. Jika kedua permintaan dipenuhi, jelas akan terjadi kesalahan. Konflik status dalam praktik biasanya jauh lebih sering terjadi, sehingga pemrosesan paralel harus memiliki langkah untuk menangani konflik status.
Prinsip optimasi paralel EVM pada suatu proyek
Sebuah proyek ZKRollup memiliki pemikiran tentang optimasi paralel untuk EVM dengan cara memberikan satu transaksi untuk setiap utas, dan menyediakan basis data status sementara dalam setiap utas, yang disebut pending-stateDB. Detail spesifiknya adalah sebagai berikut:
Eksekusi transaksi secara paralel dengan multithreading: Mengatur beberapa thread untuk memproses transaksi yang berbeda secara bersamaan, di mana thread-thread tersebut tidak saling mengganggu, dapat meningkatkan kecepatan pemrosesan transaksi beberapa kali lipat.
Alokasikan database status sementara untuk setiap thread: Alokasikan database status sementara (pending-stateDB) yang independen untuk setiap thread. Setiap thread saat melakukan transaksi, tidak langsung mengubah stateDB global, tetapi sementara mencatat hasil perubahan status di pending-stateDB.
Sinkronisasi Perubahan Status: Setelah semua transaksi dalam satu blok dieksekusi, EVM akan menyinkronkan hasil perubahan status yang tercatat di setiap pending-stateDB ke dalam global stateDB secara berurutan. Jika transaksi yang berbeda tidak mengalami konflik status selama proses eksekusi, catatan di pending-stateDB dapat digabungkan dengan sukses ke dalam global stateDB.
Proyek ini telah mengoptimalkan cara penanganan operasi baca-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 pada Pending-state. Jika data yang diperlukan ada dalam ReadSet, maka dibaca langsung dari pending-stateDB. Jika pasangan kunci-nilai yang sesuai tidak ditemukan dalam ReadSet, maka dibaca data status historis dari global stateDB yang sesuai dengan blok sebelumnya.
Operasi tulis: Semua operasi tulis (yaitu modifikasi terhadap status) tidak akan langsung ditulis ke dalam global stateDB, tetapi terlebih dahulu dicatat ke dalam WriteSet dari Pending-state. Setelah eksekusi transaksi selesai, hasil perubahan status akan dicoba untuk digabungkan ke dalam global stateDB setelah deteksi konflik.
Masalah kunci dari eksekusi paralel adalah konflik status, yang sangat signifikan ketika beberapa transaksi mencoba untuk membaca dan menulis status akun yang sama. Untuk itu, mekanisme deteksi konflik diperkenalkan:
Deteksi konflik: Selama proses eksekusi transaksi, EVM akan memantau ReadSet dan WriteSet dari transaksi yang berbeda. Jika ditemukan beberapa transaksi yang mencoba membaca dan menulis item status yang sama, maka dianggap terjadi konflik.
Penanganan konflik: Ketika konflik terdeteksi, transaksi konflik akan ditandai untuk dieksekusi ulang.
Setelah semua transaksi selesai 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 akar status baru.
Peningkatan kinerja dari optimasi paralel multi-threading sangat signifikan, terutama saat menangani transaksi kontrak pintar yang kompleks. Penelitian menunjukkan bahwa dalam beban kerja dengan konflik rendah, TPS dari pengujian benchmark meningkat sekitar 3-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 mendistribusikan perpustakaan status sementara untuk setiap transaksi dan menjalankan transaksi secara paralel dalam berbagai thread. 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 mode eksekusi serial tradisional. Ini meletakkan dasar penting untuk pengembangan Rollup Ethereum di masa depan.
Di masa depan, kita masih dapat menjelajahi bagaimana mengoptimalkan efisiensi penyimpanan untuk meningkatkan kinerja, solusi optimasi dalam situasi dengan banyak konflik, serta bagaimana memanfaatkan GPU untuk optimasi dan konten lainnya.