Penulis: Tia, Techub News
Blockchain mengorbankan efisiensi karena desain desentralisasinya, sehingga meningkatkan kecepatan eksekusi selalu menjadi salah satu masalah yang mendesak untuk dipecahkan. 'Lapisan eksekusi' blockchain adalah bagian kunci yang menangani setiap transaksi dan menambahkannya ke rantai. Untuk mempercepat kapasitas pemrosesan, meningkatkan lapisan eksekusi menjadi salah satu strategi inti, dan eksekusi paralel adalah terobosan penting dalam hal ini.
Blockchain tradisional biasanya menggunakan cara serial untuk memproses transaksi satu per satu, yang sangat membatasi kecepatan transaksi, terutama dalam jaringan yang padat transaksi dapat menyebabkan kemacetan. Namun, melalui eksekusi paralel, banyak transaksi dapat diproses secara bersamaan, sehingga secara signifikan meningkatkan efisiensi eksekusi dan mengurangi tekanan di rantai.
Untuk memahami apa itu paralel dengan lebih baik, kita akan mulai dengan menjelaskan eksekusi, menggunakan Ethereum dalam mode PBS setelah Merge sebagai contoh, untuk menjelaskan apa itu eksekusi dan menunjukkan posisi eksekusi dalam seluruh siklus hidup transaksi.
Tahapan konkret eksekusi transaksi
Transaksi masuk ke mempool dan disaring serta diurutkan: ini adalah tahap pra-proses setelah transaksi diajukan, mencakup interaksi antara Mempool, Pencari, dan Pembuat, untuk menyelesaikan penyaringan dan pengurutan transaksi.
Pembuat membangun blok (tetapi tidak mengeksekusi): Pembuat mengurutkan transaksi yang menguntungkan menjadi satu blok untuk menyelesaikan pengemasan dan pengurutan transaksi.
Proposer memverifikasi dan menyerahkan blok: Setelah blok selesai dibangun, Pembuat akan mengirimkan proposal blok ke Proposer. Proposer memverifikasi struktur blok dan konten transaksi, kemudian secara resmi menyerahkan blok ke jaringan untuk memulai eksekusi.
Eksekusi transaksi: setelah blok diajukan, node mengeksekusi transaksi dalam blok satu per satu. Ini adalah tahap kunci pembaruan status, di mana setiap transaksi akan memicu panggilan kontrak pintar, perubahan saldo akun, atau perubahan status.
Saksi menyaksikan: Validator menyaksikan hasil eksekusi blok dan akar status, dan mengonfirmasi sebagai konfirmasi akhir. Ini memastikan bahwa blok tersebut benar dan valid di lapisan eksekusi, dan mencegah ketidakkonsistenan.
Sinkronisasi status: Setiap node akan menyinkronkan hasil eksekusi blok (seperti saldo akun, pembaruan status kontrak, dll.) ke status lokalnya, setelah mengeksekusi setiap transaksi, node menghitung dan menyimpan akar status baru, untuk digunakan sebagai status awal dalam blok berikutnya.
Tentu saja, ini hanya sinkronisasi status transaksi berdasarkan blok; untuk mempertahankan status di rantai yang terbaru, biasanya node akan menyinkronkan data blok satu per satu dan terus memvalidasi blok dan status. Namun, untuk mencapai finalitas di bawah mekanisme POS, agregator perlu menggabungkan tanda tangan saksi dalam setiap Slot menjadi satu tanda tangan yang lengkap dan menyampaikannya kepada pengusul di Slot berikutnya, dan validator perlu mengonfirmasi status semua blok dalam Epoch tersebut berdasarkan jumlah suara setelah satu Epoch berlalu, membentuk titik pemeriksaan konsensus status sementara. Setelah dua Epoch berturut-turut mendapatkan dukungan saksi dari mayoritas validator, blok dan transaksi akan mencapai finalitas.
Dari seluruh siklus hidup transaksi, eksekusi terjadi setelah Proposer memverifikasi struktur dan konten transaksi dari blok yang dikirim oleh Pembuat. Proses eksekusi yang sebenarnya memerlukan pemrosesan setiap transaksi satu per satu dan pembaruan status akun atau kontrak terkait. Setelah semua transaksi dieksekusi, Proposer akan menghitung akar status baru (Merkle root), yang merupakan ringkasan hasil eksekusi semua transaksi dalam blok saat ini dan status global akhir. Secara sederhana, seluruh proses eksekusi blok mencakup serangkaian perhitungan yang diperlukan untuk mengubah Ethereum dari status sebelumnya ke status berikutnya, dari eksekusi setiap transaksi hingga perhitungan akar Merkle.
Eksekusi berurutan
Berlawanan dengan paralel adalah eksekusi berurutan, yaitu cara eksekusi yang lebih umum dalam blockchain saat ini. Biasanya, transaksi dieksekusi secara bertahap sesuai urutan. Setelah satu transaksi selesai dieksekusi, Ethereum akan memperbarui status akun dan informasi terkait (seperti saldo, data penyimpanan kontrak) ke dalam pohon status akun, menghasilkan hash status akun baru. Setelah semua pohon status akun diperbarui, akan terbentuk root hash pohon status yang disebut root Merkle status. Setelah root Merkle status, root Merkle transaksi, dan root Merkle bukti selesai, header blok akan dihitung hash-nya, menghasilkan hash blok untuk blok tersebut.
Di antara ini, urutan eksekusi transaksi sangat penting. Karena pohon Merkle adalah pohon biner dari nilai hash, nilai akar Merkle yang terbentuk dalam urutan yang berbeda akan berbeda.
Eksekusi paralel
Dalam lingkungan eksekusi paralel, node akan mencoba memproses transaksi dalam blok secara paralel. Transaksi tidak dieksekusi satu per satu, tetapi dialokasikan ke berbagai 'jalur eksekusi' agar dapat dijalankan secara bersamaan. Melalui eksekusi paralel, sistem dapat menangani transaksi dalam blok dengan lebih efisien, meningkatkan throughput.
Setelah semua transaksi dieksekusi, node akan mengumpulkan hasil eksekusi (yaitu pembaruan status yang dipengaruhi transaksi) untuk membentuk status blok baru. Status ini akan ditambahkan ke blockchain, mewakili status global terbaru di rantai.
Konflik status
Karena paralel memproses transaksi di jalur yang berbeda secara bersamaan, salah satu tantangan besar dari paralel adalah konflik status. Ini berarti ada kemungkinan beberapa transaksi melakukan operasi baca atau tulis pada bagian data (status) yang sama di blockchain dalam waktu yang sama. Jika tidak ditangani dengan baik, ini dapat menyebabkan hasil eksekusi yang tidak pasti. Karena urutan pembaruan status berbeda, hasil perhitungan akhirnya juga akan berbeda. Misalnya,
Misalkan ada dua transaksi, transaksi A dan transaksi B, yang keduanya mencoba memperbarui saldo akun yang sama:
Transaksi A: Tambah saldo akun 10.
Transaksi B: Tambah saldo akun 20.
Saldo awal akun adalah 100.
Jika kita mengeksekusi secara serial, urutan hasil eksekusi adalah pasti:
1. Pertama eksekusi transaksi A, kemudian eksekusi transaksi B:
Saldo akun terlebih dahulu meningkat 10, menjadi 110.
Kemudian meningkat 20, akhirnya menjadi 130.
2. Pertama eksekusi transaksi B, kemudian eksekusi transaksi A:
Saldo akun terlebih dahulu meningkat 20, menjadi 120.
Kemudian meningkat 10, akhirnya menjadi 130.
Dalam kedua urutan ini, saldo akhir adalah 130, karena sistem memastikan konsistensi urutan eksekusi transaksi.
Namun dalam lingkungan eksekusi paralel, transaksi A dan transaksi B dapat membaca saldo awal 100 secara bersamaan dan melakukan perhitungan masing-masing:
1. Transaksi A membaca saldo 100, setelah perhitungan saldo diperbarui menjadi 110.
2. Transaksi B juga membaca saldo 100, setelah perhitungan saldo diperbarui menjadi 120.
Dalam kasus ini, karena transaksi dieksekusi secara bersamaan, saldo akhir hanya diperbarui menjadi 120, bukan 130, karena operasi dari transaksi A dan transaksi B 'menutupi' hasil satu sama lain, menghasilkan konflik status.
Masalah konflik status ini biasanya disebut sebagai 'data overwrite', yaitu ketika transaksi mencoba untuk mengubah data yang sama secara bersamaan, yang mungkin akan saling menutupi hasil perhitungan masing-masing, sehingga status akhir tidak benar. Masalah lain yang mungkin terjadi akibat konflik status adalah ketidakmampuan untuk menjamin urutan eksekusi. Karena banyak transaksi menyelesaikan operasi dalam rentang waktu yang berbeda, urutan eksekusi yang berbeda dapat menghasilkan hasil perhitungan yang berbeda, sehingga membuat hasil menjadi tidak pasti.
Untuk menghindari ketidakpastian semacam ini, sistem eksekusi paralel blockchain biasanya akan memperkenalkan beberapa mekanisme deteksi konflik dan rollback, atau melakukan analisis ketergantungan pada transaksi sebelumnya, untuk memastikan bahwa mereka dapat dieksekusi secara paralel tanpa mempengaruhi konsistensi status akhir.
Paralel optimis dan paralel deterministik
Ada dua pendekatan untuk menangani masalah konflik status yang mungkin ada: paralel deterministik dan paralel optimis. Kedua mode ini memiliki trade-off dalam efisiensi dan kompleksitas desain.
Paralel deterministik memerlukan pernyataan akses status sebelumnya, validator atau sequencer akan memeriksa akses status yang dinyatakan saat mengurutkan transaksi. Jika ada beberapa transaksi yang mencoba menulis ke status yang sama, transaksi tersebut akan ditandai sebagai konflik, untuk menghindari eksekusi secara bersamaan. Rantai yang berbeda memiliki cara spesifik untuk mengimplementasikan pernyataan akses status sebelumnya, tetapi umumnya mencakup beberapa cara berikut:
Melalui kontrak yang mendefinisikan batasan: Pengembang secara langsung menetapkan rentang akses status dalam kontrak pintar. Misalnya, transfer token ERC-20 memerlukan akses ke bidang saldo pengirim dan penerima.
Melalui deklarasi data terstruktur transaksi: Menambahkan bidang khusus dalam transaksi untuk menandai akses status.
Melalui analisis compiler: Compiler dari bahasa tingkat tinggi dapat menganalisis kode kontrak secara statis dan secara otomatis menghasilkan kumpulan akses status.
Melalui deklarasi paksa oleh kerangka: Beberapa kerangka mengharuskan pengembang untuk secara eksplisit menyatakan status yang perlu diakses saat memanggil fungsi.
Paralel optimis akan dengan optimis terlebih dahulu memproses transaksi, dan ketika konflik terjadi, transaksi yang terpengaruh akan dieksekusi ulang sesuai urutan. Untuk menghindari konflik, inti desain paralel optimis adalah dengan melakukan prediksi cepat terhadap status menggunakan data historis, analisis statis, dan sebagainya. Ini berarti sistem mengasumsikan bahwa beberapa operasi atau pembaruan status adalah valid, dengan meminimalkan waktu tunggu untuk semua proses verifikasi, sehingga meningkatkan kinerja dan throughput.
Meski paralel optimis dapat menghindari konflik sebanyak mungkin melalui beberapa prediksi cepat terhadap status, masih ada beberapa tantangan yang tidak dapat dihindari, terutama yang melibatkan eksekusi kontrak atau transaksi lintas rantai. Jika konflik sering terjadi, eksekusi ulang dapat secara signifikan memperlambat kinerja sistem dan meningkatkan konsumsi sumber daya komputasi.
Paralel deterministik menghindari kemungkinan konflik yang dapat muncul dari paralel optimis dengan memeriksa ketergantungan status sebelum transaksi, tetapi karena memerlukan pernyataan yang akurat tentang ketergantungan status sebelum transaksi dikirim, ini meningkatkan tuntutan pada pengembang, sehingga menambah kompleksitas implementasi.
Dilema paralel EVM
Dalam mengatasi konflik status, ada perbedaan antara deterministik dan optimis; dalam proses konkret implementasi paralel, juga perlu mempertimbangkan dari sudut pandang arsitektur basis data rantai. Masalah konflik status dalam paralel sangat sulit dalam EVM yang menggunakan arsitektur pohon Merkle. Pohon Merkle adalah struktur hash bertingkat, di mana setelah setiap transaksi mengubah data status tertentu, nilai hash akar pohon Merkle juga perlu diperbarui. Proses pembaruan ini bersifat rekursif, menghitung dari node daun ke atas sampai ke node akar. Karena hash bersifat tidak dapat dibalik, hanya setelah perubahan data di lapisan bawah selesai, lapisan atas dapat dihitung; sifat ini membuatnya sulit untuk memperbarui secara paralel.
Jika dua transaksi dijalankan secara paralel dan mengakses status yang sama (seperti saldo akun), akan terjadi konflik pada node pohon Merkle. Mengatasi konflik semacam ini biasanya memerlukan mekanisme manajemen transaksi tambahan untuk memastikan bahwa nilai hash akar yang konsisten dapat diperoleh di semua cabang. Ini tidak mudah dilakukan untuk EVM karena memerlukan kompromi antara paralelisasi dan konsistensi status.
Solusi paralel non-EVM
Solana
Berbeda dengan pohon status global Ethereum, Solana menggunakan model akun. Setiap akun adalah ruang penyimpanan independen, disimpan dalam buku besar, sehingga menghindari masalah konflik jalur.
Solana adalah paralel deterministik. Di Solana, setiap transaksi perlu secara jelas menyatakan akun yang akan diakses dan izin yang diperlukan (hanya baca atau baca-tulis) saat diajukan. Desain ini memungkinkan node blockchain untuk menganalisis sumber daya yang perlu diakses oleh setiap transaksi sebelum eksekusi. Karena transaksi telah menyatakan semua ketergantungan akun sebelum mulai dieksekusi, node dapat menentukan transaksi mana yang akan mengakses akun yang sama, transaksi mana yang dapat dieksekusi secara paralel dengan aman, dan dengan demikian mewujudkan penjadwalan pintar untuk menghindari konflik, menjadi dasar untuk penjadwalan paralel.
Karena setiap transaksi telah menyatakan akun dan izin yang perlu diakses sebelum dijalankan, Solana dapat memeriksa apakah ada ketergantungan akun antara transaksi (model Sealevel). Jika tidak ada akun yang dibaca atau ditulis bersama antara transaksi, sistem dapat menempatkan mereka pada prosesor yang berbeda untuk dieksekusi secara paralel.
Aptos
Desain eksekusi paralel Aptos sangat berbeda dari Ethereum, dengan beberapa inovasi kunci dalam arsitektur dan mekanisme, terutama ditunjukkan dalam model akun dan penyimpanan status.
Ethereum perlu sering memperbarui pohon status global (MPT) saat menjalankan transaksi. Semua status akun dan kontrak disimpan dalam pohon status bersama, dan setiap transaksi perlu mengakses dan memperbarui sebagian dari pohon status ini. Sementara itu, Aptos membagi akun menjadi unit status independen, di mana setiap objek adalah pasangan kunci-nilai yang independen, objek-objek tersebut dapat ada secara independen tanpa saling mempengaruhi, hanya akan berhubungan ketika ada hubungan referensi yang jelas. Objek-objek tersebut tidak memiliki jalur pohon yang umum, sehingga tidak ada persaingan penguncian, dan dapat sepenuhnya paralel.
Struktur data dasar Aptos adalah Jellyfish Merkle Tree. Status setiap objek akhirnya disimpan dalam JMT, sebagai pasangan kunci-nilai independen. Berbeda dengan MPT Ethereum, Jellyfish Merkle Tree berbentuk struktur pohon biner penuh, yang menyederhanakan jalur penyimpanan dan jalur kueri node, secara signifikan mengurangi waktu verifikasi. Selain itu, posisi setiap akun dalam pohon adalah tetap, dan node dalam pohon disimpan secara independen, memungkinkan pembaruan dan pencarian beberapa akun untuk dilakukan secara paralel.
Aptos adalah paralel optimis, yang tidak memerlukan penyediaan sebelumnya dari semua ketergantungan akun yang dinyatakan. Untuk itu, Aptos menggunakan Block-STM, yang memanfaatkan urutan transaksi yang telah ditentukan untuk memperkirakan ketergantungan, sehingga mengurangi jumlah penghentian.
EVM paralel
Dibandingkan dengan paralel non-EVM, EVM paralel menghadapi lebih banyak tantangan teknis dalam menangani ketergantungan status, deteksi konflik, manajemen Gas, dan mekanisme rollback. Untuk memahami ini lebih baik, kita dapat merujuk pada beberapa proyek EVM paralel (seperti Sui, Monad, Canto) dan bagaimana mereka mengatasi masalah ini.
Sui
Sui, seperti Aptos, juga menggunakan model objek untuk menangani status, dengan setiap objek (misalnya akun, status kontrak pintar) sebagai sumber daya independen, dan objek-objek ini dibedakan melalui pengenal unik objek. Saat transaksi melibatkan objek yang berbeda, transaksi ini dapat diproses secara paralel karena mereka beroperasi pada status yang berbeda, tanpa menghasilkan konflik langsung.
Meski Sui menggunakan model objek untuk mengelola status, untuk kompatibilitas dengan EVM, arsitektur Sui menjembatani model objek dan model akun EVM melalui lapisan adaptasi tambahan atau mekanisme abstraksi.
Di Sui, penjadwalan transaksi menggunakan strategi paralel optimis, dengan asumsi bahwa tidak ada konflik antara transaksi. Jika konflik terjadi, sistem akan menggunakan mekanisme rollback untuk mengembalikan status.
Sui menggunakan model objek dan teknologi isolasi status, yang dapat secara efektif menghindari masalah ketergantungan status. Setiap objek sebagai sumber daya independen, transaksi yang berbeda dapat dieksekusi secara paralel, sehingga meningkatkan throughput dan efisiensi. Namun, trade-off dari metode ini adalah kompleksitas model objek dan biaya mekanisme rollback. Jika terjadi konflik antara transaksi, beberapa status perlu di-rollback, yang akan menambah beban pada sistem dan dapat mempengaruhi efisiensi pemrosesan paralel. Dibandingkan dengan sistem paralel non-EVM (seperti Solana), Sui memerlukan lebih banyak sumber daya komputasi dan penyimpanan untuk mempertahankan paralelisme yang efisien.
Monad
Seperti Sui, Monad juga menggunakan paralel optimis. Namun, paralel optimis Monad akan memprediksi beberapa transaksi yang memiliki ketergantungan sebelum eksekusi transaksi konkret, prediksi dilakukan terutama melalui analisis kode statis Monad. Prediksi memerlukan akses status, sedangkan cara penyimpanan status dalam basis data Ethereum membuat akses status sangat sulit; untuk membuat proses pembacaan status lebih efisien dalam paralel, Monad juga merekonstruksi basis data.
Pohon status Monad dibagi menjadi partisi, di mana setiap partisi memelihara sub-pohon statusnya sendiri. Saat memperbarui, hanya perlu mengubah bagian terkait, tanpa membangun ulang seluruh pohon status. Dengan tabel indeks status, posisi status dalam partisi dapat ditentukan dengan cepat, mengurangi interaksi antar partisi.
Persyaratan perangkat keras node TPS blockchain Virtual Machine Ciri Solana 65,000+ 12 inti CPU, 256GB RAM, node validator 500GB SSD, node arsip 1TB SSD, dan sebaiknya sisakan 500GB untuk sistem operasi Solana VM Mendukung banyak koneksi, menggunakan Proof of History (PoH), throughput yang sangat tinggi, mekanisme konsensus yang ringan Aptos 160,000+ 32 inti CPU, 64GB+ RAM, 3.0 TB SSD penyimpanan Move VM Berdasarkan bahasa Move, mendukung eksekusi paralel, mengoptimalkan throughput tinggi dan latensi rendah Sui 120,000+ 8 inti CPU, 128GB RAM, 4 TB NVMe SSD penyimpanan Sui VM Eksekusi paralel, berdasarkan model sumber daya, mendukung latensi rendah dan throughput tinggi Monad 10000+ 16 inti CPU, 32GB RAM, 2 TB NVMe SSD penyimpanan EVM (lapisan kompatibilitas) Kinerja paralel tinggi, mengoptimalkan throughput melalui eksekusi asinkron dan desain mesin virtual EVM yang lebih ringan Ethereum (setelah Merge) 30-100+ 4 inti CPU, 32GB RAM, 4TB SSD penyimpanan EVM Platform kontrak pintar tradisional, beralih ke Proof of Stake setelah Merge, masih mendukung paralelisme terbatas.
Ringkasan
Inti dari paralel adalah meningkatkan efisiensi eksekusi lapisan eksekusi dengan cara eksekusi multi-jalur. Untuk mencapai eksekusi multi-jalur, rantai perlu melakukan serangkaian deteksi konflik dan mekanisme rollback untuk memastikan bahwa mereka dapat dieksekusi secara paralel tanpa mempengaruhi konsistensi status akhir, dan melakukan perbaikan tertentu pada basis data.
Tentu saja, peningkatan efisiensi lapisan eksekusi tidak terbatas pada satu cara paralel; optimasi dalam proses eksekusi juga dapat dilakukan dengan mengurangi operasi baca-tulis yang diperlukan oleh satu transaksi terhadap basis data. Namun, meningkatkan kecepatan seluruh rantai melibatkan lebih banyak aspek, termasuk peningkatan efisiensi lapisan konsensus.
Setiap teknologi memiliki kondisi pembatas tertentu yang spesifik. Paralleling hanyalah salah satu cara untuk meningkatkan efisiensi; keputusan akhir tentang apakah akan menggunakan teknologi tersebut juga harus mempertimbangkan apakah ramah bagi pengembang, apakah dapat diselesaikan tanpa mengorbankan desentralisasi, dan sebagainya. Penumpukan teknologi tidak selalu lebih baik; setidaknya, untuk Ethereum, paralel tidak begitu menarik. Dari sudut pandang peningkatan efisiensi, menambahkan paralel bukanlah solusi optimal untuk Ethereum, baik dari sisi kesederhanaan maupun dengan mempertimbangkan peta jalan Ethereum yang saat ini berfokus pada Rollup.
