Seperti yang kita ketahui, EVM adalah mesin eksekusi inti Ethereum dan lingkungan menjalankan kontrak pintar. Sebagai jaringan terbuka yang terdiri dari sejumlah besar node, blockchain publik menghadapi tantangan tentang bagaimana mencapai eksekusi yang konsisten pada perangkat dengan parameter perangkat keras yang sangat berbeda. Teknologi mesin virtual memberikan kemungkinan untuk menyelesaikan masalah ini, memungkinkan kontrak pintar berjalan dengan cara yang sama di berbagai sistem operasi dan perangkat, memastikan konsistensi hasil.
Kontrak pintar akan dikompilasi menjadi bytecode EVM sebelum diunggah ke blockchain. EVM membaca bytecode ini secara berurutan saat menjalankan kontrak, dan setiap instruksi memiliki biaya Gas yang sesuai. EVM akan melacak konsumsi Gas selama proses eksekusi setiap instruksi, yang bergantung pada kompleksitas operasi.
Secara tradisional, EVM memproses transaksi secara serial, di mana semua transaksi mengantri dalam satu antrean dan dieksekusi dalam urutan yang ditentukan. Desain ini sederhana dan mudah dipelihara, tetapi seiring dengan perkembangan teknologi blockchain dan berkembangnya basis pengguna, tuntutan terhadap TPS dan throughput terus meningkat. Setelah teknologi Rollup matang, hambatan kinerja eksekusi serial EVM menjadi sangat jelas di jaringan lapisan kedua Ethereum.
Sequencer sebagai komponen kunci Layer2, bertanggung jawab atas semua tugas komputasi dalam bentuk satu server. Jika modul pendukung memiliki efisiensi yang cukup tinggi, maka bottleneck akhir akan tergantung pada efisiensi Sequencer itu sendiri, pada saat itu eksekusi serial akan menjadi hambatan besar. Oleh karena itu, paralelisasi pemrosesan transaksi menjadi tren yang tak terhindarkan di masa depan.
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. Setiap kali transaksi dieksekusi, 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, menyimpan saldo akun, kode kontrak pintar, dan data lainnya. Selama proses eksekusi transaksi, stateDB melakukan pembacaan dan penulisan data akun yang sesuai. Setelah eksekusi transaksi selesai, stateDB mengirimkan status baru ke basis data bawah untuk persisten.
Secara keseluruhan, EVM bertanggung jawab untuk menafsirkan dan mengeksekusi instruksi kontrak pintar, mengubah status blockchain berdasarkan hasil perhitungan, sedangkan stateDB 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, tanpa melibatkan pemanggilan kontrak, dengan kecepatan pemrosesan yang cepat dan biaya gas yang rendah.
Perdagangan kontrak melibatkan pemanggilan dan pelaksanaan kontrak pintar. Saat EVM memproses perdagangan kontrak, perlu untuk menafsirkan dan melaksanakan instruksi bytecode dalam kontrak pintar satu per satu. Semakin kompleks logika kontrak, semakin banyak instruksi yang terlibat, dan sumber daya yang dikonsumsi juga semakin banyak.
Misalnya, waktu pemrosesan transfer ERC-20 adalah sekitar 2 kali lipat dari transfer EOA, sedangkan kontrak pintar yang lebih kompleks, seperti operasi perdagangan di Uniswap, mungkin memakan waktu sepuluh kali lipat dari transfer EOA. Ini karena protokol DeFi perlu menangani kolam likuiditas, perhitungan harga, swap token, dan logika kompleks lainnya saat melakukan transaksi, yang memerlukan perhitungan yang besar.
Dalam mode eksekusi serial, proses kolaborasi EVM dengan stateDB adalah sebagai berikut:
Transaksi dalam blok diproses satu per satu sesuai urutan, setiap transaksi memiliki contoh independen untuk menjalankan operasi spesifik.
Semua transaksi menggunakan database status stateDB yang sama.
Selama proses eksekusi transaksi, EVM terus-menerus berinteraksi dengan stateDB, membaca data terkait dan menulis kembali data yang telah diubah ke stateDB.
Setelah semua transaksi dalam blok dieksekusi, data dalam stateDB diserahkan ke pohon status global, menghasilkan akar status baru.
Kelemahan jelas dari mode eksekusi serial ini: transaksi harus dieksekusi dalam urutan antrean, dan jika ada transaksi kontrak pintar yang memakan waktu lama, transaksi lainnya hanya bisa menunggu, tidak dapat memanfaatkan sumber daya perangkat keras secara maksimal, sehingga efisiensi sangat terbatas.
Solusi Optimasi Paralel Multithreading EVM
Mode eksekusi paralel dapat membuka beberapa thread untuk memproses beberapa transaksi secara bersamaan, efisiensinya dapat meningkat beberapa kali lipat, tetapi menghadapi masalah konflik status. Ketika beberapa transaksi secara bersamaan menyatakan ingin menulis ulang data akun tertentu, akan terjadi konflik yang memerlukan pengolahan koordinasi.
Prinsip Optimalisasi Paralel
Sebagai contoh dari pendekatan optimasi paralel proyek ZKRollup Reddio, fitur utamanya meliputi:
Eksekusi transaksi paralel multithread: Atur beberapa thread untuk memproses transaksi yang berbeda secara bersamaan, tanpa saling mengganggu, dapat meningkatkan kecepatan pemrosesan transaksi beberapa kali lipat.
Alokasikan database status sementara untuk setiap thread: setiap thread memiliki database status sementara (pending-stateDB) yang independen. Saat eksekusi transaksi, hasil perubahan status sementara dicatat di pending-stateDB, dan tidak langsung mengubah stateDB global.
Sinkronisasi Perubahan Status: Setelah semua transaksi dalam blok dieksekusi, hasil perubahan status yang tercatat dalam setiap pending-stateDB akan disinkronkan secara berurutan ke dalam global stateDB.
Reddio telah mengoptimalkan penanganan operasi baca dan tulis:
Operasi baca: Pertama, periksa ReadSet dari Pending-state. Jika data yang diperlukan ada, baca langsung dari pending-stateDB; jika tidak, baca data status historis dari global stateDB yang sesuai dengan blok sebelumnya.
Operasi tulis: Semua operasi tulis dicatat terlebih dahulu ke dalam WriteSet di Pending-state, dan setelah transaksi dieksekusi, hasil perubahan status akan dicoba untuk digabungkan ke dalam stateDB global melalui deteksi konflik.
Untuk mengatasi masalah konflik status, Reddio memperkenalkan mekanisme deteksi konflik:
Deteksi konflik: Memantau ReadSet dan WriteSet dari transaksi yang berbeda, jika ditemukan beberapa transaksi mencoba untuk membaca dan menulis item status yang sama, dianggap terjadi konflik.
Penanganan konflik: Transaksi konflik ditandai sebagai perlu dijalankan ulang.
Setelah semua transaksi dieksekusi, beberapa catatan perubahan dalam pending-stateDB digabungkan ke dalam global stateDB. Setelah penggabungan berhasil, status akhir diserahkan ke pohon status global, menghasilkan akar status baru.
Optimasi paralel multithreading secara signifikan meningkatkan kinerja, terutama saat menangani 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 teori, jika semua langkah optimasi diterapkan, bahkan dapat mencapai peningkatan hingga 60 kali lipat.
Ringkasan
Solusi optimisasi paralel multi-threading EVM dari Reddio secara signifikan meningkatkan kapasitas pemrosesan transaksi EVM dengan mengalokasikan pustaka status sementara untuk setiap transaksi dan mengeksekusi transaksi secara paralel dalam thread yang berbeda. Dengan mengoptimalkan operasi baca-tulis dan memperkenalkan mekanisme deteksi konflik, jaringan publik EVM dapat mencapai paralelisasi transaksi dalam skala besar dengan menjamin konsistensi status, mengatasi hambatan kinerja dari model eksekusi serial tradisional. Ini meletakkan dasar yang penting untuk perkembangan masa depan Ethereum Rollup.
Ke depan, kita dapat membahas lebih lanjut tentang rincian implementasi Reddio, termasuk bagaimana mengoptimalkan efisiensi penyimpanan, solusi optimasi dalam kasus konflik tinggi, serta bagaimana memanfaatkan GPU untuk optimasi.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
9 Suka
Hadiah
9
5
Bagikan
Komentar
0/400
GasFeeCrybaby
· 15jam yang lalu
gwei begitu tinggi tetap harus masuk!
Lihat AsliBalas0
GateUser-cff9c776
· 15jam yang lalu
on-chain炼丹呢这是
Lihat AsliBalas0
RugPullAlertBot
· 16jam yang lalu
Benda ini masih bisa berjalan ya?
Lihat AsliBalas0
NFTArtisanHQ
· 16jam yang lalu
disrupsi paradigma fr... paralelisasi reddio adalah puisi digital murni sejujurnya
Lihat AsliBalas0
BearMarketSurvivor
· 16jam yang lalu
On-chain concurrency tidak memberikan kita kesempatan untuk trading?
Optimasi paralelisasi EVM: Meningkatkan efisiensi pemrosesan transaksi dengan Reddio sebagai contoh
Jalan Optimasi Paralel EVM
Seperti yang kita ketahui, EVM adalah mesin eksekusi inti Ethereum dan lingkungan menjalankan kontrak pintar. Sebagai jaringan terbuka yang terdiri dari sejumlah besar node, blockchain publik menghadapi tantangan tentang bagaimana mencapai eksekusi yang konsisten pada perangkat dengan parameter perangkat keras yang sangat berbeda. Teknologi mesin virtual memberikan kemungkinan untuk menyelesaikan masalah ini, memungkinkan kontrak pintar berjalan dengan cara yang sama di berbagai sistem operasi dan perangkat, memastikan konsistensi hasil.
Kontrak pintar akan dikompilasi menjadi bytecode EVM sebelum diunggah ke blockchain. EVM membaca bytecode ini secara berurutan saat menjalankan kontrak, dan setiap instruksi memiliki biaya Gas yang sesuai. EVM akan melacak konsumsi Gas selama proses eksekusi setiap instruksi, yang bergantung pada kompleksitas operasi.
Secara tradisional, EVM memproses transaksi secara serial, di mana semua transaksi mengantri dalam satu antrean dan dieksekusi dalam urutan yang ditentukan. Desain ini sederhana dan mudah dipelihara, tetapi seiring dengan perkembangan teknologi blockchain dan berkembangnya basis pengguna, tuntutan terhadap TPS dan throughput terus meningkat. Setelah teknologi Rollup matang, hambatan kinerja eksekusi serial EVM menjadi sangat jelas di jaringan lapisan kedua Ethereum.
Sequencer sebagai komponen kunci Layer2, bertanggung jawab atas semua tugas komputasi dalam bentuk satu server. Jika modul pendukung memiliki efisiensi yang cukup tinggi, maka bottleneck akhir akan tergantung pada efisiensi Sequencer itu sendiri, pada saat itu eksekusi serial akan menjadi hambatan besar. Oleh karena itu, paralelisasi pemrosesan transaksi menjadi tren yang tak terhindarkan di masa depan.
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. Setiap kali transaksi dieksekusi, 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, menyimpan saldo akun, kode kontrak pintar, dan data lainnya. Selama proses eksekusi transaksi, stateDB melakukan pembacaan dan penulisan data akun yang sesuai. Setelah eksekusi transaksi selesai, stateDB mengirimkan status baru ke basis data bawah untuk persisten.
Secara keseluruhan, EVM bertanggung jawab untuk menafsirkan dan mengeksekusi instruksi kontrak pintar, mengubah status blockchain berdasarkan hasil perhitungan, sedangkan stateDB 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, tanpa melibatkan pemanggilan kontrak, dengan kecepatan pemrosesan yang cepat dan biaya gas yang rendah.
Perdagangan kontrak melibatkan pemanggilan dan pelaksanaan kontrak pintar. Saat EVM memproses perdagangan kontrak, perlu untuk menafsirkan dan melaksanakan instruksi bytecode dalam kontrak pintar satu per satu. Semakin kompleks logika kontrak, semakin banyak instruksi yang terlibat, dan sumber daya yang dikonsumsi juga semakin banyak.
Misalnya, waktu pemrosesan transfer ERC-20 adalah sekitar 2 kali lipat dari transfer EOA, sedangkan kontrak pintar yang lebih kompleks, seperti operasi perdagangan di Uniswap, mungkin memakan waktu sepuluh kali lipat dari transfer EOA. Ini karena protokol DeFi perlu menangani kolam likuiditas, perhitungan harga, swap token, dan logika kompleks lainnya saat melakukan transaksi, yang memerlukan perhitungan yang besar.
Dalam mode eksekusi serial, proses kolaborasi EVM dengan stateDB adalah sebagai berikut:
Kelemahan jelas dari mode eksekusi serial ini: transaksi harus dieksekusi dalam urutan antrean, dan jika ada transaksi kontrak pintar yang memakan waktu lama, transaksi lainnya hanya bisa menunggu, tidak dapat memanfaatkan sumber daya perangkat keras secara maksimal, sehingga efisiensi sangat terbatas.
Solusi Optimasi Paralel Multithreading EVM
Mode eksekusi paralel dapat membuka beberapa thread untuk memproses beberapa transaksi secara bersamaan, efisiensinya dapat meningkat beberapa kali lipat, tetapi menghadapi masalah konflik status. Ketika beberapa transaksi secara bersamaan menyatakan ingin menulis ulang data akun tertentu, akan terjadi konflik yang memerlukan pengolahan koordinasi.
Prinsip Optimalisasi Paralel
Sebagai contoh dari pendekatan optimasi paralel proyek ZKRollup Reddio, fitur utamanya meliputi:
Eksekusi transaksi paralel multithread: Atur beberapa thread untuk memproses transaksi yang berbeda secara bersamaan, tanpa saling mengganggu, dapat meningkatkan kecepatan pemrosesan transaksi beberapa kali lipat.
Alokasikan database status sementara untuk setiap thread: setiap thread memiliki database status sementara (pending-stateDB) yang independen. Saat eksekusi transaksi, hasil perubahan status sementara dicatat di pending-stateDB, dan tidak langsung mengubah stateDB global.
Sinkronisasi Perubahan Status: Setelah semua transaksi dalam blok dieksekusi, hasil perubahan status yang tercatat dalam setiap pending-stateDB akan disinkronkan secara berurutan ke dalam global stateDB.
Reddio telah mengoptimalkan penanganan operasi baca dan tulis:
Operasi baca: Pertama, periksa ReadSet dari Pending-state. Jika data yang diperlukan ada, baca langsung dari pending-stateDB; jika tidak, baca data status historis dari global stateDB yang sesuai dengan blok sebelumnya.
Operasi tulis: Semua operasi tulis dicatat terlebih dahulu ke dalam WriteSet di Pending-state, dan setelah transaksi dieksekusi, hasil perubahan status akan dicoba untuk digabungkan ke dalam stateDB global melalui deteksi konflik.
Untuk mengatasi masalah konflik status, Reddio memperkenalkan mekanisme deteksi konflik:
Deteksi konflik: Memantau ReadSet dan WriteSet dari transaksi yang berbeda, jika ditemukan beberapa transaksi mencoba untuk membaca dan menulis item status yang sama, dianggap terjadi konflik.
Penanganan konflik: Transaksi konflik ditandai sebagai perlu dijalankan ulang.
Setelah semua transaksi dieksekusi, beberapa catatan perubahan dalam pending-stateDB digabungkan ke dalam global stateDB. Setelah penggabungan berhasil, status akhir diserahkan ke pohon status global, menghasilkan akar status baru.
Optimasi paralel multithreading secara signifikan meningkatkan kinerja, terutama saat menangani 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 teori, jika semua langkah optimasi diterapkan, bahkan dapat mencapai peningkatan hingga 60 kali lipat.
Ringkasan
Solusi optimisasi paralel multi-threading EVM dari Reddio secara signifikan meningkatkan kapasitas pemrosesan transaksi EVM dengan mengalokasikan pustaka status sementara untuk setiap transaksi dan mengeksekusi transaksi secara paralel dalam thread yang berbeda. Dengan mengoptimalkan operasi baca-tulis dan memperkenalkan mekanisme deteksi konflik, jaringan publik EVM dapat mencapai paralelisasi transaksi dalam skala besar dengan menjamin konsistensi status, mengatasi hambatan kinerja dari model eksekusi serial tradisional. Ini meletakkan dasar yang penting untuk perkembangan masa depan Ethereum Rollup.
Ke depan, kita dapat membahas lebih lanjut tentang rincian implementasi Reddio, termasuk bagaimana mengoptimalkan efisiensi penyimpanan, solusi optimasi dalam kasus konflik tinggi, serta bagaimana memanfaatkan GPU untuk optimasi.