Penulis: Tia, Techub News
Blockchain mengorbankan efisiensi karena desain desentralisasinya, sehingga meningkatkan kecepatan eksekusi selalu menjadi salah satu masalah yang mendesak untuk diselesaikan. 'Lapisan eksekusi' blockchain adalah bagian kunci yang menangani setiap transaksi dan menambahkannya ke dalam rantai. Untuk mempercepat kapasitas pemrosesan, peningkatan di lapisan eksekusi menjadi salah satu strategi inti, dan eksekusi paralel adalah terobosan penting dalam hal ini.
Blockchain tradisional biasanya menggunakan metode serial untuk memproses transaksi satu per satu, yang sangat membatasi kecepatan transaksi, terutama dalam jaringan yang padat transaksi dapat menyebabkan kemacetan. Namun, dengan eksekusi paralel, beberapa transaksi dapat diproses secara bersamaan, sehingga secara signifikan meningkatkan efisiensi eksekusi dan mengurangi tekanan pada blockchain.
Untuk lebih memahami apa itu paralel, kita akan mulai dengan menjelaskan eksekusi dan menggunakan Ethereum dalam mode PBS pasca Merge sebagai contoh untuk menjelaskan apa itu eksekusi, sekaligus menunjukkan posisi eksekusi dalam seluruh siklus hidup transaksi.
Rincian eksekusi transaksi
Transaksi memasuki mempool dan disaring serta diurutkan: ini adalah tahap pra-pemrosesan setelah transaksi diajukan, mencakup interaksi antara Mempool, Pencari, dan Pembangun, menyelesaikan penyaringan dan pengurutan transaksi.
Pembuat membangun blok (tetapi tidak mengeksekusi): Pembuat menyusun transaksi yang menguntungkan menjadi satu blok untuk menyelesaikan pengemasan dan pengurutan transaksi.
Proposer memvalidasi dan menyerahkan blok: Setelah blok dibangun selesai, Pembuat akan mengirimkan proposal blok kepada Proposer. Proposer memvalidasi struktur blok dan konten transaksi, kemudian secara resmi mengajukan blok ke jaringan untuk memulai eksekusi.
Mengeksekusi transaksi: Setelah blok diserahkan, node menjalankan transaksi dalam blok satu per satu. Ini adalah tahap kunci pembaruan status, di mana setiap transaksi akan memicu pemanggilan kontrak pintar, perubahan saldo akun, atau perubahan status.
Saksi bersaksi: Validator bersaksi atas hasil eksekusi blok dan akar status, dan menjadikannya sebagai konfirmasi akhir. Ini memastikan bahwa blok tersebut keaslian dan validitasnya di lapisan eksekusi, serta mencegah ketidakcocokan.
Sinkronisasi status: Setiap node akan menyinkronkan hasil eksekusi blok (seperti saldo akun, pembaruan status kontrak, dll.) ke status lokal mereka sendiri. Setelah mengeksekusi setiap transaksi, node menghitung dan menyimpan akar status baru, yang akan digunakan sebagai status awal dalam blok berikutnya.
Tentu saja, ini hanya sinkronisasi status transaksi dalam unit blok. Untuk menjaga status terbaru di blockchain, 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 di setiap Slot menjadi satu tanda tangan lengkap dan menyampaikannya kepada propositor Slot berikutnya, dan validator perlu mengonfirmasi status semua blok dalam Epoch tersebut berdasarkan jumlah suara setelah satu Epoch berlalu, membentuk titik pemeriksaan konsensus sementara. Setelah dua Epoch berturut-turut mendapatkan dukungan saksi dari mayoritas validator, blok dan transaksi baru akan mencapai finalitas.
Dari seluruh siklus hidup transaksi, eksekusi terjadi setelah Proposer memvalidasi struktur blok dan konten transaksi yang dikirim oleh Pembuat. Proses eksekusi yang sebenarnya membutuhkan pemrosesan transaksi satu per satu, dan memperbarui status akun atau kontrak yang sesuai. Setelah semua transaksi dieksekusi, Proposer akan menghitung akar status baru (akar Merkle), yang merupakan ringkasan dari hasil eksekusi semua transaksi dalam blok saat ini dan status global akhir. Dengan kata lain, keseluruhan proses eksekusi blok mencakup serangkaian perhitungan yang perlu diselesaikan untuk mengubah Ethereum dari status sebelumnya ke status berikutnya, dari eksekusi setiap transaksi hingga perhitungan akar Merkle.
Eksekusi berurutan
Berlawanan dengan paralel, eksekusi berurutan adalah cara eksekusi yang lebih umum di 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 hash node akar pohon status yang disebut akar Merkle status. Setelah menyelesaikan akar Merkle status, akar Merkle transaksi, dan akar Merkle bukti, blok header akan dihitung hash-nya, menghasilkan hash blok tersebut.
Di antara ini, urutan eksekusi transaksi sangat penting. Karena pohon Merkle adalah pohon biner dari nilai hash, nilai akar Merkle yang dihasilkan dalam urutan yang berbeda akan berbeda.
Eksekusi paralel
Dalam lingkungan eksekusi paralel, node akan mencoba untuk memproses transaksi dalam blok secara paralel. Ini bukan dieksekusi satu per satu secara berurutan, tetapi transaksi dialokasikan ke 'jalur eksekusi' yang berbeda sehingga mereka dapat dieksekusi secara bersamaan. Dengan eksekusi paralel, sistem dapat memproses transaksi dalam blok dengan lebih efisien, meningkatkan throughput.
Setelah semua eksekusi transaksi selesai, node akan mengumpulkan hasil eksekusi (yaitu pembaruan status yang dipengaruhi oleh transaksi) untuk membentuk status blok baru. Status ini akan ditambahkan ke blockchain, mewakili status global terbaru di blockchain.
Konflik status
Karena paralel akan memproses transaksi di jalur yang berbeda secara simultan, salah satu tantangan besar paralel adalah konflik status. Artinya, mungkin ada beberapa transaksi yang berusaha membaca atau menulis data (status) yang sama di blockchain pada waktu yang sama. Jika situasi ini tidak ditangani dengan baik, akan menghasilkan hasil eksekusi yang tidak pasti. Karena urutan pembaruan status berbeda, hasil perhitungan akhir juga akan berbeda. Sebagai contoh,
Misalkan ada dua transaksi, transaksi A dan transaksi B, yang keduanya mencoba memperbarui saldo akun yang sama:
Transaksi A: Menambah saldo akun 10.
Transaksi B: Menambah saldo akun 20.
Saldo awal akun adalah 100.
Jika kita mengeksekusi secara serial, hasil dari urutan eksekusi adalah pasti:
1. Eksekusi transaksi A terlebih dahulu, kemudian transaksi B:
Saldo akun meningkat 10 terlebih dahulu, menjadi 110.
Menambah 20 lagi, akhirnya menjadi 130.
2. Eksekusi transaksi B terlebih dahulu, kemudian transaksi A:
Saldo akun meningkat 20 terlebih dahulu, menjadi 120.
Menambah 10 lagi, akhirnya menjadi 130.
Dalam kedua urutan ini, saldo akhir adalah 130, karena sistem memastikan konsistensi urutan eksekusi transaksi.
Tetapi dalam lingkungan eksekusi paralel, transaksi A dan transaksi B mungkin secara bersamaan membaca saldo awal 100 dan melakukan perhitungan masing-masing:
Transaksi A membaca saldo 100, setelah perhitungan memperbarui saldo menjadi 110.
Transaksi B juga membaca saldo 100, setelah perhitungan memperbarui saldo menjadi 120.
Dalam kasus ini, karena transaksi dieksekusi secara bersamaan, saldo akhir hanya diperbarui menjadi 120, bukan 130, karena operasi transaksi A dan transaksi B 'menutupi' hasil satu sama lain, menghasilkan konflik status.
Masalah konflik status seperti ini biasanya disebut 'penutupan data', yaitu ketika transaksi mencoba mengubah data yang sama secara bersamaan, mereka mungkin saling menutupi hasil perhitungan satu sama lain, menghasilkan status akhir yang tidak benar. Masalah lain yang mungkin ditimbulkan oleh konflik status adalah ketidakmampuan untuk menjamin urutan eksekusi. Karena beberapa transaksi menyelesaikan operasi pada waktu yang berbeda, akan menyebabkan urutan eksekusi yang berbeda. Urutan yang berbeda mungkin menghasilkan hasil perhitungan yang berbeda, sehingga membuat hasil tidak pasti.
Untuk menghindari ketidakpastian ini, sistem eksekusi paralel blockchain biasanya memperkenalkan beberapa mekanisme deteksi konflik dan rollback, atau menganalisis ketergantungan transaksi sebelumnya untuk memastikan mereka dieksekusi secara paralel tanpa mempengaruhi konsistensi status akhir.
Paralel optimis vs. paralel deterministik
Ada dua pendekatan untuk menangani kemungkinan masalah konflik status: paralel deterministik dan paralel optimis. Kedua mode ini memiliki trade-off dalam efisiensi dan kompleksitas desain.
Paralel deterministik memerlukan deklarasi 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 bersamaan. Implementasi spesifik dari setiap rantai dalam mendeklarasikan akses status sebelumnya bervariasi, tetapi umumnya mencakup beberapa cara berikut:
Melalui batasan spesifikasi kontrak: 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 kompiler: kompiler bahasa tingkat tinggi dapat menganalisis kode kontrak secara statis, secara otomatis menghasilkan kumpulan akses status.
Melalui deklarasi yang dipaksakan oleh kerangka: beberapa kerangka mengharuskan pengembang untuk secara eksplisit menyebutkan status yang perlu diakses saat memanggil fungsi.
Paralel optimis akan dengan optimis memproses transaksi terlebih dahulu, dan jika konflik terjadi, transaksi yang terpengaruh akan dieksekusi ulang secara berurutan. Untuk menghindari konflik, inti dari desain paralel optimis adalah melalui data historis, analisis statis, dll., untuk melakukan prediksi dan asumsi cepat tentang status. Ini berarti sistem berasumsi bahwa beberapa operasi atau pembaruan status adalah valid tanpa verifikasi lengkap, berusaha menghindari menunggu semua proses verifikasi, untuk meningkatkan kinerja dan throughput.
Meskipun paralel optimis dapat menghindari konflik sebanyak mungkin melalui beberapa prediksi dan asumsi cepat tentang 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 situasi konflik yang mungkin muncul dari paralel optimis dengan memeriksa ketergantungan status sebelum transaksi, tetapi karena perlu mendeklarasikan ketergantungan status dengan akurat sebelum transaksi diajukan, ini meningkatkan persyaratan untuk pengembang dan menambah kompleksitas implementasi.
Dilema EVM paralel
Menangani konflik status tidak hanya terbagi antara deterministik dan optimis, dalam proses implementasi paralel, juga perlu mempertimbangkan dari perspektif arsitektur basis data rantai. Masalah konflik status dalam EVM di bawah struktur pohon Merkle sangat sulit. Pohon Merkle adalah struktur hash bertingkat, setelah setiap transaksi melakukan modifikasi pada data status tertentu, nilai hash akar Merkle juga perlu diperbarui. Proses pembaruan ini bersifat rekursif, dihitung dari node daun ke atas hingga node akar. Karena hash tidak dapat dibalik, hanya setelah perubahan data di tingkat bawah selesai, perhitungan untuk tingkat atas dapat dilakukan, fitur ini membuatnya sangat sulit untuk diperbarui secara paralel.
Jika dua transaksi dieksekusi secara paralel dan mengakses status yang sama (seperti saldo akun), konflik node pohon Merkle dapat terjadi. Menyelesaikan konflik ini biasanya memerlukan mekanisme manajemen transaksi tambahan, memastikan bahwa nilai hash akar yang konsisten dapat diperoleh di semua cabang. Ini tidak mudah dicapai untuk EVM, karena perlu membuat kompromi antara paralelisasi dan konsistensi status.
Solusi paralel non-EVM
Solana
Berbeda dengan pohon status global Ethereum, Solana mengadopsi model akun. Setiap akun adalah ruang penyimpanan independen yang disimpan dalam buku besar, sehingga menghindari masalah konflik jalur.
Solana adalah paralel deterministik. Di Solana, setiap transaksi perlu secara jelas mendeklarasikan akun yang akan diakses dan izin akses yang diperlukan (hanya baca atau baca-tulis) saat diajukan. Desain ini memungkinkan node blockchain menganalisis sumber daya yang perlu diakses oleh setiap transaksi sebelum eksekusi. Karena transaksi telah mendeklarasikan semua ketergantungan akun sebelum eksekusi, node dapat menentukan transaksi mana yang akan mengakses akun yang sama, dan transaksi mana yang dapat dieksekusi secara paralel dengan aman, sehingga mencapai penjadwalan cerdas dan menghindari konflik, yang menjadi dasar penjadwalan paralel.
Karena setiap transaksi telah mendeklarasikan akun dan izin yang perlu diakses sebelum dieksekusi, Solana dapat memeriksa apakah ada ketergantungan antar akun di antara transaksi (model Sealevel). Jika transaksi tidak memiliki akun baca-tulis yang sama, sistem dapat mengalokasikannya ke 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 dalam model akun dan penyimpanan status.
Ethereum sering kali perlu memperbarui pohon status global (MPT) saat mengeksekusi transaksi. Semua akun dan status kontrak disimpan dalam satu pohon status yang dibagikan, dan setiap transaksi perlu mengakses dan memperbarui sebagian dari pohon status ini. Sementara itu, Aptos membagi akun menjadi unit status mandiri, di mana setiap objek adalah pasangan kunci-nilai independen, objek dapat ada secara independen tanpa saling mempengaruhi, dan hanya akan terhubung jika ada hubungan referensi yang jelas. Tidak ada jalur pohon umum di antara objek, sehingga tidak akan ada persaingan kunci 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, bentuk ini menyederhanakan jalur penyimpanan dan jalur pencarian 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 dilakukan secara paralel.
Aptos adalah paralel optimis, yang tidak memerlukan deklarasi semua ketergantungan akun sebelumnya. Untuk itu, Aptos menggunakan Block-STM, yang memanfaatkan urutan transaksi yang ditetapkan untuk memperkirakan ketergantungan dan mengurangi jumlah pembatalan.
EVM paralel
Dibandingkan dengan paralel non-EVM, EVM paralel menghadapi kesulitan teknis yang lebih besar dalam menangani ketergantungan status, deteksi konflik, manajemen Gas, dan mekanisme rollback. Untuk lebih memahami hal ini, kita dapat merujuk pada beberapa proyek EVM paralel (seperti Sui, Monad, Canto) dan bagaimana mereka menyelesaikan masalah ini.
Sui
Sui dan Aptos, sama-sama menggunakan model objek untuk menangani status, dengan setiap objek (misalnya akun, status kontrak pintar) sebagai sumber daya independen. Objek-objek ini dibedakan melalui pengidentifikasi unik objek. Ketika transaksi melibatkan objek yang berbeda, transaksi tersebut dapat diproses secara paralel karena mereka beroperasi pada status yang berbeda dan tidak akan menghasilkan konflik langsung.
Meskipun Sui menggunakan model objek untuk mengelola status, untuk kompatibilitas EVM, arsitektur Sui menjembatani model objek dan model akun EVM melalui lapisan adaptasi atau mekanisme abstraksi tambahan.
Di Sui, penjadwalan transaksi menggunakan strategi paralel optimis, mengasumsikan tidak ada konflik antar 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 berfungsi sebagai sumber daya independen, dan 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 antar transaksi, perlu untuk melakukan rollback pada sebagian status, yang akan menambah beban pada sistem dan mungkin mempengaruhi efisiensi pemrosesan paralel. Dibandingkan dengan sistem paralel non-EVM (seperti Solana), Sui memerlukan lebih banyak sumber daya komputasi dan penyimpanan untuk mempertahankan efisiensi paralel.
Monad
Seperti Sui, Monad juga menggunakan paralel optimis. Namun, paralel optimis Monad masih akan memprediksi beberapa transaksi yang memiliki ketergantungan sebelum eksekusi transaksi yang sebenarnya, dengan prediksi dilakukan terutama melalui analis kode statis Monad. Prediksi memerlukan akses ke status, dan cara penyimpanan status di database Ethereum membuat akses status menjadi sangat sulit. Untuk membuat paralel lebih efisien dalam proses pembacaan status, Monad juga telah merombak database.
Pohon status Monad dibagi berdasarkan partisi, setiap partisi memelihara subpohon statusnya sendiri. Saat memperbarui, hanya perlu mengubah bagian yang relevan tanpa membangun kembali seluruh pohon status. Dengan tabel indeks status, dapat dengan cepat menentukan status dalam partisi, mengurangi interaksi antar partisi.
Ringkasan
Inti dari paralel adalah meningkatkan efisiensi eksekusi lapisan eksekusi dengan cara eksekusi multi-jalur, dan untuk mencapai eksekusi multi-jalur, rantai perlu melakukan serangkaian hal seperti deteksi konflik dan mekanisme rollback untuk memastikan mereka dieksekusi secara paralel tanpa mempengaruhi konsistensi status akhir, serta melakukan perbaikan tertentu pada basis data.
Tentu saja, peningkatan efisiensi lapisan eksekusi tidak terbatas pada satu cara paralel. Optimasi di tahap eksekusi juga dapat dilakukan dengan mengurangi operasi baca-tulis yang diperlukan oleh satu transaksi pada basis data. Sementara itu, peningkatan kecepatan keseluruhan rantai mencakup cakupan yang lebih luas, termasuk peningkatan efisiensi lapisan konsensus.
Setiap teknologi memiliki kondisi pembatas tertentu. Paralel hanyalah salah satu cara untuk meningkatkan efisiensi, keputusan akhir untuk menggunakan teknologi ini masih perlu mempertimbangkan apakah ramah bagi pengembang dan apakah dapat dilakukan tanpa mengorbankan desentralisasi, dll. Penumpukan teknologi tidak selalu lebih baik, setidaknya untuk Ethereum, paralel tidak begitu menarik, jika hanya dari sudut peningkatan efisiensi, menambahkan paralel bukanlah solusi optimal bagi Ethereum, baik dari segi kesederhanaan maupun dari peta jalan Ethereum yang saat ini berfokus pada Rollup.