TLDR: Bagian penelitian ini memberikan gambaran tentang arsitektur desain paralel untuk blockchain, menggunakan tiga contoh yang relevan: Solana, Sei, dan Monad. Ini menyoroti perbedaan antara paralelisasi optimis dan deterministik dan menguji nuansa akses keadaan dan memori di sepanjang rantai-rantai ini.
Pada tahun 1837, ilmuwan komputer dan matematikawan Charles Babbage merancang Mesin Analitis,” yang meletakkan dasar teoritis untuk komputasi paralel. Hari ini, paralelisasi adalah tema kunci dalam dunia kripto karena blockchain berusaha mendorong batas-batas pemrosesan, efisiensi, dan throughput.
The Parallel Universe
Komputasi paralel memungkinkan banyak perhitungan atau proses untuk dijalankan secara bersamaan, berbeda dengan perhitungan yang dijalankan secara serial atau satu demi satu. Komputasi paralel mengacu pada memecah masalah yang lebih besar menjadi bagian-bagian yang lebih kecil dan independen yang dapat dijalankan oleh beberapa prosesor yang berkomunikasi melalui memori bersama. Sistem paralel memiliki sejumlah keunggulan, seperti peningkatan efisiensi dan kecepatan, skalabilitas, peningkatan keandalan dan toleransi kesalahan, pemanfaatan sumber daya yang lebih baik, dan kemampuan untuk menangani set data yang sangat besar.
Namun, sangat penting untuk mengakui bahwa efektivitas paralelisasi bergantung pada spesifik dari arsitektur dan implementasi yang mendasarinya. Dua bottleneck inti untuk blockchain adalah fungsi kriptografis (fungsi hash, tanda tangan, kurva eliptis, dll.) dan akses memori/keadaan. Dengan blockchain, salah satu komponen kunci dari merancang sistem paralel yang efisien terletak pada nuansa akses keadaan. Akses keadaan merujuk pada kemampuan transaksi untuk membaca dan menulis ke keadaan blockchain, termasuk penyimpanan, kontrak pintar, dan saldo akun. Agar blockchain yang diparalelisasi menjadi efektif dan performa, akses keadaan harus dioptimalkan.
Saati ini, ada dua aliran pemikiran tentang mengoptimalkan akses keadaan untuk blockchain yang diperparalelkan: paralelisme deterministik vs. paralelisme optimis. Paralelisme deterministik memerlukan kode untuk secara eksplisit mendeklarasikan di awal bagian-bagian dari keadaan blockchain yang akan diakses dan dimodifikasi. Ini memungkinkan sistem untuk menentukan transaksi mana yang dapat diproses secara paralel tanpa konflik sebelumnya. Paralelisme deterministik memungkinkan untuk prediktabilitas dan efisiensi (terutama ketika transaksi sebagian besar independen). Namun, ini membuat lebih kompleksitas bagi para pengembang.
Paralelisasi optimis tidak memerlukan kode untuk mendeklarasikan akses statusnya di muka dan memproses transaksi secara paralel seolah-olah tidak akan ada konflik. Jika konflik memang muncul, paralelisasi optimis akan either dijalankan ulang, diproses ulang, atau menjalankan transaksi yang bertentangan secara serial. Sementara paralelisasi optimis memberikan lebih fleksibilitas bagi para pengembang, re-eksekusi diperlukan untuk konflik, mengakibatkan metode ini paling efisien ketika transaksi tidak bertentangan. Tidak ada jawaban yang benar mengenai mana dari kedua pendekatan ini yang lebih baik. Mereka hanya dua pendekatan (dan layak) yang berbeda dalam paralelisasi.
Pada Bagian I dari seri ini, kami akan pertama-tama menjelajahi beberapa dasar sistem parallel non-kripto, diikuti oleh ruang desain untuk eksekusi parallel untuk blockchain, dengan fokus pada tiga area inti:
Mengambil apa yang baru saja kita baca di atas tentang apa yang memungkinkan komputasi paralel dan keuntungan dari sistem paralel, mudah untuk memahami mengapa adopsi komputasi paralel telah berkembang dalam beberapa tahun terakhir. Peningkatan adopsi komputasi paralel telah memungkinkan banyak terobosan hanya dalam beberapa dekade terakhir.
Mari kita periksa tiga blockchain yang telah mengimplementasikan lingkungan eksekusi paralel. Pertama, kita akan membongkar Solana, diikuti oleh dua rantai berbasis EVM, Monad dan Sei.
Pada tingkat yang tinggi, filsafat desain Solana adalah bahwa inovasi blockchain harus berkembang seiring dengan kemajuan perangkat keras. Ketika perangkat keras meningkat seiring waktu melalui Hukum Moore, Solana dirancang untuk mendapatkan manfaat dari peningkatan kinerja dan skalabilitas. Pendiri Solana Anatoly Yakovenkoawalnya dirancangArsitektur paralelisasi Solanalebih dari lima tahun yang lalu, dan hari ini, paralelisme sebagai prinsip desain blockchain sedang menyebar dengan cepat.
Solana menggunakan paralelisasi yang deterministik, yang berasal dari pengalaman masa lalu Anatoly saat bekerja dengan sistem tertanam, di mana biasanya Anda mendeklarasikan semua keadaan di muka. Hal ini memungkinkan CPU untuk mengetahui semua ketergantungan, yang memungkinkannya untuk melakukan pra-fetch pada bagian-bagian memori yang diperlukan. Hasilnya adalah eksekusi sistem yang dioptimalkan, namun lagi-lagi, ini memerlukan pengembang untuk melakukan pekerjaan ekstra di depan. Di Solana, semua ketergantungan memori untuk sebuah program diperlukan dan dinyatakan dalam transaksi yang dibangun (yaitu, Daftar Akses), memungkinkan runtime untuk menjadwalkan dan mengeksekusi beberapa transaksi secara paralel secara efisien.
Komponen utama berikutnya dari arsitektur Solana adalah Sealevel VM, yang merupakan runtime kontrak cerdas paralel Solana. Sealevel secara alami mendukung pemrosesan kontrak dan transaksi ganda secara paralel berdasarkan jumlah inti yang dimiliki validator. Validator dalam blockchain adalah peserta jaringan yang bertanggung jawab untuk memverifikasi dan memvalidasi transaksi, mengajukan blok baru, dan mempertahankan integritas serta keamanan blockchain. Karena transaksi menyatakan akun mana yang perlu dibaca dan dikunci tulisnya terlebih dahulu, penjadwal Solana dapat menentukan transaksi mana yang dapat dieksekusi secara bersamaan. Karena itu, dalam hal validasi, “Block Producer” atau Pemimpin dapat menyortir ribuan transaksi tertunda dan menjadwalkan transaksi yang tidak tumpang tindih secara paralel.
Elemen desain akhir untuk Solana adalah “pipelining.” Pipelining terjadi ketika data perlu diproses dalam serangkaian langkah, dan perangkat keras yang berbeda bertanggung jawab untuk masing-masing. Ide kunci di sini adalah mengambil data yang perlu dijalankan secara serial dan memparallelkannya menggunakan pipelining. Pipelines ini dapat dijalankan secara paralel, dan setiap tahap pipeline dapat memproses batch transaksi yang berbeda.
Optimisasi-optimisasi ini memungkinkan Sealevel untuk mengatur dan mengeksekusi transaksi-transaksi independen secara simultan, memanfaatkan kemampuan perangkat keras untuk memproses beberapa titik data sekaligus dengan satu program. Sealevel menyortir instruksi-instruksi berdasarkan programID dan menjalankan instruksi yang sama pada semua akun terkait secara paralel.
Dengan inovasi-inovasi ini dalam pikiran, kita dapat melihat bahwa Solana sengaja dirancang untuk mendukung paralelisasi.
Sei adalah blockchain Layer 1 sumber terbuka yang bersifat umum dan dikhususkan untuk pertukaran aset digital. Sei V2 memanfaatkan paralelisasi optimis dan, sebagai hasilnya, lebih ramah pengembang dibandingkan dengan pendahulunya yang deterministik. Dalam paralelisasi optimis, kontrak pintar dapat dieksekusi lebih lancar dan secara bersamaan tanpa memerlukan pengembang untuk mendeklarasikan sumber daya mereka di muka. Ini berarti bahwa rantai secara optimis menjalankan semua transaksi secara paralel. Namun, ketika terjadi konflik (yaitu, beberapa transaksi mengakses status yang sama), blockchain akan melacak komponen penyimpanan tertentu yang dipengaruhi oleh setiap transaksi yang bertentangan.
Blockchain Sei mendekati eksekusi transaksi menggunakan “Optimistic Concurrency Control (OCC).” Pengolahan transaksi bersamaan terjadi ketika beberapa transaksi secara bersamaan aktif dalam suatu sistem. Ada dua fase dalam pendekatan transaksi ini: eksekusi dan validasi.
Dalam tahap eksekusi, transaksi diproses secara optimis, dengan semua bacaan/tulisan disimpan sementara di dalam penyimpanan khusus transaksi. Setelah itu, setiap transaksi akan memasuki tahap validasi, di mana informasi dalam operasi penyimpanan sementara diperiksa terhadap setiap perubahan status yang dilakukan oleh transaksi sebelumnya. Jika suatu transaksi independen, transaksi tersebut berjalan secara paralel. Jika suatu transaksi membaca data yang dimodifikasi oleh transaksi lain, hal ini akan menciptakan konflik. Sistem paralel Sei akan mengidentifikasi setiap konflik dengan membandingkan himpunan bacaan transaksi versus perubahan status terbaru dalam penyimpanan multi-versi (ini diindeks berdasarkan urutan transaksi). Sei akan mengeksekusi dan memvalidasi kembali kasus-kasus di mana konflik muncul. Ini adalah proses iteratif yang melibatkan eksekusi, validasi, dan pengulangan untuk memperbaiki konflik. Grafik di bawah ini menggambarkan pendekatan Sei terhadap transaksi ketika terjadi konflik.
Sumber: https://blog.sei.io/sei-v2-the-first-parallelized-evm/
Implementasi Sei menghasilkan biaya gas yang lebih murah dan ruang desain yang lebih luas bagi pengembang EVM. Secara historis, lingkungan EVM telah terbatas pada <50 TPS, yang memaksa pengembang untuk membuat aplikasi yang mengikuti pola anti. Sei V2 memungkinkan pengembang untuk mendekati sektor-sektor yang biasanya memerlukan kinerja tinggi dan biaya rendah, seperti DeFi, DePIN, dan Gaming.
Monad sedang membangun Layer 1 EVM paralel dengan kompatibilitas bytecode penuh. Yang membuat Monad unik bukan hanya mesin paralelisasinya tetapi juga apa yang mereka bangun di bawahnya untuk mengoptimalkannya. Monad mengambil pendekatan unik terhadap desain keseluruhannya dengan memasukkan beberapa fitur kunci, termasuk pipelining, I/O asinkron, memisahkan konsensus dan eksekusi, dan MonadDB.
Salah satu inovasi kunci dalam desain Monad adalah pipeliningdengan sedikit pergeseran. Pergeseran memungkinkan lebih banyak proses untuk diparellelkan dengan menjalankan beberapa contoh secara bersamaan. Oleh karena itu, pipelining digunakan untuk mengoptimalkan sejumlah fungsi, seperti pipelining akses keadaan, pipelining eksekusi transaksi, pipelining dalam konsensus dan eksekusi, dan pipelining dalam mekanisme konsensus itu sendiri.
Selanjutnya, kami akan mengklik dua kali ke dalam bagian paralelisasi Monad. Dalam Monad, transaksi diurutkan secara linear dalam blok, tetapi tujuannya adalah untuk mencapai keadaan akhir ini lebih cepat dengan memanfaatkan eksekusi paralel. Monad menggunakan algoritma paralelisasi optimis untuk desain mesin eksekusinya. Mesin Monad memproses transaksi secara bersamaan dan kemudian melakukan analisis untuk memastikan bahwa hasilnya akan identik jika transaksi dieksekusi satu per satu. Jika ada konflik, Anda perlu mengeksekusi ulang. Eksekusi paralel di sini adalah algoritma yang relatif sederhana, tetapi menggabungkannya dengan inovasi kunci lain dari Monad adalah yang membuat pendekatan ini baru. Satu hal yang perlu dicatat di sini adalah bahwa bahkan jika terjadi re-eksekusi, biasanya murah karena input yang diperlukan untuk transaksi yang tidak valid hampir selalu tetap berada di cache, sehingga akan menjadi pencarian cache yang sederhana. Re-eksekusi dijamin berhasil karena Anda sudah mengeksekusi transaksi sebelumnya dalam blok.
Monad juga meningkatkan kinerja dengan memisahkan eksekusi dan konsensus, mirip dengan Solana dan Sei, selain eksekusi tertunda. Ide di sini adalah bahwa jika Anda mengendurkan kondisi untuk menyelesaikan eksekusi pada saat konsensus selesai, Anda dapat menjalankan keduanya secara paralel, menghasilkan waktu tambahan untuk keduanya. Tentu saja, Monad menggunakan algoritma deterministik untuk menangani kondisi ini untuk memastikan salah satunya tidak terlalu jauh di depan tanpa kemungkinan mengejar.
Seperti yang saya sebutkan di awal pos ini, akses keadaan adalah salah satu bottleneck kinerja khas bagi blockchain. Pilihan desain seputar akses keadaan dan memori pada akhirnya dapat menentukan apakah implementasi sistem paralel tertentu akan meningkatkan kinerja dalam praktek. Di sini, kita akan membongkar dan membandingkan pendekatan-pendekatan berbeda yang diambil oleh Solana, Sei, dan Monad.
Akses Status Solana: AkunDB / Cloudbreak
Solana menggunakan penskalaan horizontal untuk mendistribusikan dan mengelola data status di sejumlah perangkat SSD. Banyak blockchain saat ini menggunakan basis data generik (misalnya, LevelDB) dengan batasan dalam menangani sejumlah besar pembacaan dan penulisan data status yang bersamaan. Untuk menghindari hal ini, Solana membangun akunDB kustomnya sendiri memanfaatkanCloudbreak.
Cloudbreak dirancang untuk akses paralel melintasi operasi I/O daripada hanya mengandalkan RAM, yang secara inheren cepat. Operasi I/O (Input/Output) merujuk pada membaca data dari atau menulis data ke sumber eksternal, seperti disk, jaringan, atau perangkat periferal. Awalnya, Cloudbreak menggunakan indeks in-RAM untuk memetakan kunci publik ke akun yang memegang saldo dan data. Namun, saat ini menulis makalah ini dan versi 1.9, indeks telah dipindahkan dari RAM ke SSD. Pergeseran ini memungkinkan Cloudbreak untuk secara bersamaan menangani 32 operasi I/O dalam antrian, meningkatkan throughput di beberapa SSD. Akibatnya, data blockchain seperti akun dan transaksi dapat diakses secara efisien, seolah-olah mereka berada di RAM menggunakan file yang dipetakan ke memori. Grafik di bawah ini mewakili hierarki memori yang menggambarkan. Meskipun RAM lebih cepat, kapasitasnya lebih sedikit dari pada SSD dan umumnya lebih mahal:
Diagram hirarki memori ilustratif
Dengan penskalaan secara horizontal dan mendistribusikan data keadaan di sejumlah perangkat, Cloudbreak mengurangi laten dan meningkatkan efisiensi, desentralisasi, dan ketahanan jaringan dalam ekosistem Solana.
Akses Keadaan Sei: SeiDB
Sei telah mendesain ulang penyimpanannya, SeiDB, untuk mengatasi beberapa isu: amplifikasi tulisan (berapa banyak metadata yang diperlukan untuk menjaga struktur data, semakin kecil = lebih baik), pembengkakan status, operasi lambat, dan penurunan kinerja dari waktu ke waktu. Redesain baru sekarang dibagi menjadi dua komponen: toko status dan komitmen status. Merekam dan memverifikasi setiap perubahan data ditangani oleh komitmen status, sementara database yang mencatat semua data pada setiap titik ditangani oleh penyimpanan status (SS).
Pada Sei V2, Komitmen Negara menggunakan memori-mapped Arsitektur pohon IAVL (MemIAVL)Pohon IAVL yang dipetakan memori menyimpan lebih sedikit metadata, yang mengurangi penyimpanan status dan waktu sinkronisasi status dan membuat menjalankan node penuh jauh lebih mudah. Pohon IAVL yang dipetakan memori direpresentasikan sebagai tiga file di disk (kv, cabang, daun); oleh karena itu, lebih sedikit metadata yang perlu dilacak, yang membantu mengurangi penyimpanan status lebih dari 50%. Struktur MemIAVL baru membantu mengurangi faktor penguatan tulisan karena mengurangi metadata yang dibutuhkan untuk memelihara struktur data.
SeiDB yang diperbarui memungkinkan dukungan backend database yang fleksibel untuk lapisan penyimpanan state. Sei percaya bahwa operator node yang berbeda akan memiliki persyaratan yang beragam dan kebutuhan penyimpanan yang berbeda. Oleh karena itu, SS telah dirancang untuk menampung backend yang berbeda, memberikan kebebasan dan fleksibilitas kepada operator, yaitu PebbleDB, RocksDB, SQLite, dll.
Akses Negara: MonadDB
Ada beberapa nuansa penting dalam akses keadaan Monad. Pertama, sebagian besar klien Ethereum memanfaatkan dua jenis basis data: basis data B-Tree (yaitu, LMDB) atau basis data log-structured merge tree (LSM) (yaitu, RocksDB, LevelDB). Kedua basis data ini adalah struktur data generik yang tidak dirancang secara eksplisit untuk blockchain. Selain itu, basis data ini tidak memanfaatkan kemajuan terbaru dalam teknologi Linux, terutama mengenai operasi asinkron dan optimisasi I/O. Terakhir, Ethereum sendiri mengelola keadaan menggunakanPatricia Merkle Trie, yang mengkhususkan diri dalam kriptografi, verifikasi, dan bukti. Masalah utamanya adalah bahwa klien harus mengintegrasikan Trie Patricia Merkle khusus ini ke dalam basis data yang lebih generik (yaitu, B-Tree / LSM), dengan kerugian kinerja yang signifikan seperti akses disk yang berlebihan.
Semua hal di atas membantu menyiapkan panggung mengapa Monad memutuskan untuk membuat database MonadDB buatan sendiri, yang dirancang khusus untuk menangani data blockchain dan akses keadaan secara lebih efisien. Beberapa fitur kunci MonadDB termasuk basis data akses paralel, basis data khusus yang dioptimalkan untuk Data Merkle Trie, akses keadaan efisien melalui penggunaan RAM standar, dan desentralisasi serta skalabilitas.
MonadDB secara eksplisit dirancang untuk blockchain, membuatnya lebih performa daripada menggunakan basis data generik. MonadDB khusus dan disesuaikan untuk mengelola data tipe Merkle trie dengan efisien, memungkinkan akses paralel ke beberapa simpul trie pada saat yang sama. Meskipun biaya membaca tunggal di MonadDB versus beberapa basis data generik di atas sama, properti kunci di sini adalah bahwa MonadDB dapat menjalankan banyak pembacaan secara paralel, menghasilkan peningkatan kecepatan yang besar.
MonadDB memungkinkan akses keadaan simultan ke database akses paralel. Karena Monad membangun database ini dari awal, ia mampu memanfaatkan teknologi kernel Linux terbaru dan kekuatan penuh SSD untuk I/O asinkron. Dengan async I/O, jika suatu transaksi memerlukan membaca keadaan dari disk, ini tidak boleh menghentikan operasi menunggu penyelesaian. Sebaliknya, itu harus memulai pembacaan dan secara bersamaan melanjutkan pemrosesan transaksi lainnya. Inilah bagaimana async I/O secara signifikan mempercepat pemrosesan untuk MonadDB. Monad mampu mengekstrak kinerja yang lebih baik dari perangkat keras dengan mengoptimalkan penggunaan SSD dan mengurangi ketergantungan pada RAM yang berlebihan. Ini memiliki manfaat tambahan untuk sejalan dengan desentralisasi dan skalabilitas.
Ringkasan Perbandingan Solana vs. Sei vs. Monad
Secara kesimpulan, menjelajahi paralelisasi dalam blockchain melalui lensa Solana, Sei, dan Monad memberikan pemahaman komprehensif tentang bagaimana arsitektur dan pendekatan yang berbeda dapat meningkatkan kinerja dan skalabilitas. Paralelisasi deterministik Solana, dengan penekanan pada mendeklarasikan akses keadaan di muka, menawarkan prediktabilitas dan efisiensi, menjadikannya pilihan yang kuat untuk aplikasi yang membutuhkan throughput tinggi. Di sisi lain, pendekatan paralelisasi optimis Sei memprioritaskan fleksibilitas pengembang dan cocok untuk lingkungan di mana konflik transaksi jarang terjadi. Dengan perpaduan unik paralelisasi optimis dan MonadDB yang dibangun khusus, Monad menyajikan solusi inovatif yang memanfaatkan kemajuan teknologi terbaru untuk mengoptimalkan akses keadaan dan kinerja.
Setiap blockchain menawarkan pendekatan yang berbeda dalam mengatasi tantangan paralelisasi, dengan serangkaian kompromi tersendiri. Desain Solana ditujukan untuk memaksimalkan pemanfaatan perangkat keras dan throughput, sementara Sei fokus pada mempermudah proses pengembangan, dan Monad menekankan solusi database yang dibuat khusus untuk data blockchain. Perbedaan ini menyoroti keragaman dalam ekosistem blockchain dan pentingnya memilih platform yang tepat berdasarkan kebutuhan spesifik aplikasi.
Saat ruang blockchain terus berkembang, kemajuan dalam teknik paralelisasi yang ditunjukkan oleh Solana, Monad, dan Sei tanpa ragu akan menginspirasi inovasi lebih lanjut. Perjalanan menuju blockchain yang lebih efisien, dapat diskalakan, dan ramah pengembang masih berlangsung, dan pelajaran yang dipetik dari platform-platform ini akan memainkan peran penting dalam membentuk masa depan teknologi blockchain.
Pada Bagian II dari seri ini, kita akan membahas implikasi ekonomi dan kompromi yang terkait dengan sistem desain paralel ini.
TLDR: Bagian penelitian ini memberikan gambaran tentang arsitektur desain paralel untuk blockchain, menggunakan tiga contoh yang relevan: Solana, Sei, dan Monad. Ini menyoroti perbedaan antara paralelisasi optimis dan deterministik dan menguji nuansa akses keadaan dan memori di sepanjang rantai-rantai ini.
Pada tahun 1837, ilmuwan komputer dan matematikawan Charles Babbage merancang Mesin Analitis,” yang meletakkan dasar teoritis untuk komputasi paralel. Hari ini, paralelisasi adalah tema kunci dalam dunia kripto karena blockchain berusaha mendorong batas-batas pemrosesan, efisiensi, dan throughput.
The Parallel Universe
Komputasi paralel memungkinkan banyak perhitungan atau proses untuk dijalankan secara bersamaan, berbeda dengan perhitungan yang dijalankan secara serial atau satu demi satu. Komputasi paralel mengacu pada memecah masalah yang lebih besar menjadi bagian-bagian yang lebih kecil dan independen yang dapat dijalankan oleh beberapa prosesor yang berkomunikasi melalui memori bersama. Sistem paralel memiliki sejumlah keunggulan, seperti peningkatan efisiensi dan kecepatan, skalabilitas, peningkatan keandalan dan toleransi kesalahan, pemanfaatan sumber daya yang lebih baik, dan kemampuan untuk menangani set data yang sangat besar.
Namun, sangat penting untuk mengakui bahwa efektivitas paralelisasi bergantung pada spesifik dari arsitektur dan implementasi yang mendasarinya. Dua bottleneck inti untuk blockchain adalah fungsi kriptografis (fungsi hash, tanda tangan, kurva eliptis, dll.) dan akses memori/keadaan. Dengan blockchain, salah satu komponen kunci dari merancang sistem paralel yang efisien terletak pada nuansa akses keadaan. Akses keadaan merujuk pada kemampuan transaksi untuk membaca dan menulis ke keadaan blockchain, termasuk penyimpanan, kontrak pintar, dan saldo akun. Agar blockchain yang diparalelisasi menjadi efektif dan performa, akses keadaan harus dioptimalkan.
Saati ini, ada dua aliran pemikiran tentang mengoptimalkan akses keadaan untuk blockchain yang diperparalelkan: paralelisme deterministik vs. paralelisme optimis. Paralelisme deterministik memerlukan kode untuk secara eksplisit mendeklarasikan di awal bagian-bagian dari keadaan blockchain yang akan diakses dan dimodifikasi. Ini memungkinkan sistem untuk menentukan transaksi mana yang dapat diproses secara paralel tanpa konflik sebelumnya. Paralelisme deterministik memungkinkan untuk prediktabilitas dan efisiensi (terutama ketika transaksi sebagian besar independen). Namun, ini membuat lebih kompleksitas bagi para pengembang.
Paralelisasi optimis tidak memerlukan kode untuk mendeklarasikan akses statusnya di muka dan memproses transaksi secara paralel seolah-olah tidak akan ada konflik. Jika konflik memang muncul, paralelisasi optimis akan either dijalankan ulang, diproses ulang, atau menjalankan transaksi yang bertentangan secara serial. Sementara paralelisasi optimis memberikan lebih fleksibilitas bagi para pengembang, re-eksekusi diperlukan untuk konflik, mengakibatkan metode ini paling efisien ketika transaksi tidak bertentangan. Tidak ada jawaban yang benar mengenai mana dari kedua pendekatan ini yang lebih baik. Mereka hanya dua pendekatan (dan layak) yang berbeda dalam paralelisasi.
Pada Bagian I dari seri ini, kami akan pertama-tama menjelajahi beberapa dasar sistem parallel non-kripto, diikuti oleh ruang desain untuk eksekusi parallel untuk blockchain, dengan fokus pada tiga area inti:
Mengambil apa yang baru saja kita baca di atas tentang apa yang memungkinkan komputasi paralel dan keuntungan dari sistem paralel, mudah untuk memahami mengapa adopsi komputasi paralel telah berkembang dalam beberapa tahun terakhir. Peningkatan adopsi komputasi paralel telah memungkinkan banyak terobosan hanya dalam beberapa dekade terakhir.
Mari kita periksa tiga blockchain yang telah mengimplementasikan lingkungan eksekusi paralel. Pertama, kita akan membongkar Solana, diikuti oleh dua rantai berbasis EVM, Monad dan Sei.
Pada tingkat yang tinggi, filsafat desain Solana adalah bahwa inovasi blockchain harus berkembang seiring dengan kemajuan perangkat keras. Ketika perangkat keras meningkat seiring waktu melalui Hukum Moore, Solana dirancang untuk mendapatkan manfaat dari peningkatan kinerja dan skalabilitas. Pendiri Solana Anatoly Yakovenkoawalnya dirancangArsitektur paralelisasi Solanalebih dari lima tahun yang lalu, dan hari ini, paralelisme sebagai prinsip desain blockchain sedang menyebar dengan cepat.
Solana menggunakan paralelisasi yang deterministik, yang berasal dari pengalaman masa lalu Anatoly saat bekerja dengan sistem tertanam, di mana biasanya Anda mendeklarasikan semua keadaan di muka. Hal ini memungkinkan CPU untuk mengetahui semua ketergantungan, yang memungkinkannya untuk melakukan pra-fetch pada bagian-bagian memori yang diperlukan. Hasilnya adalah eksekusi sistem yang dioptimalkan, namun lagi-lagi, ini memerlukan pengembang untuk melakukan pekerjaan ekstra di depan. Di Solana, semua ketergantungan memori untuk sebuah program diperlukan dan dinyatakan dalam transaksi yang dibangun (yaitu, Daftar Akses), memungkinkan runtime untuk menjadwalkan dan mengeksekusi beberapa transaksi secara paralel secara efisien.
Komponen utama berikutnya dari arsitektur Solana adalah Sealevel VM, yang merupakan runtime kontrak cerdas paralel Solana. Sealevel secara alami mendukung pemrosesan kontrak dan transaksi ganda secara paralel berdasarkan jumlah inti yang dimiliki validator. Validator dalam blockchain adalah peserta jaringan yang bertanggung jawab untuk memverifikasi dan memvalidasi transaksi, mengajukan blok baru, dan mempertahankan integritas serta keamanan blockchain. Karena transaksi menyatakan akun mana yang perlu dibaca dan dikunci tulisnya terlebih dahulu, penjadwal Solana dapat menentukan transaksi mana yang dapat dieksekusi secara bersamaan. Karena itu, dalam hal validasi, “Block Producer” atau Pemimpin dapat menyortir ribuan transaksi tertunda dan menjadwalkan transaksi yang tidak tumpang tindih secara paralel.
Elemen desain akhir untuk Solana adalah “pipelining.” Pipelining terjadi ketika data perlu diproses dalam serangkaian langkah, dan perangkat keras yang berbeda bertanggung jawab untuk masing-masing. Ide kunci di sini adalah mengambil data yang perlu dijalankan secara serial dan memparallelkannya menggunakan pipelining. Pipelines ini dapat dijalankan secara paralel, dan setiap tahap pipeline dapat memproses batch transaksi yang berbeda.
Optimisasi-optimisasi ini memungkinkan Sealevel untuk mengatur dan mengeksekusi transaksi-transaksi independen secara simultan, memanfaatkan kemampuan perangkat keras untuk memproses beberapa titik data sekaligus dengan satu program. Sealevel menyortir instruksi-instruksi berdasarkan programID dan menjalankan instruksi yang sama pada semua akun terkait secara paralel.
Dengan inovasi-inovasi ini dalam pikiran, kita dapat melihat bahwa Solana sengaja dirancang untuk mendukung paralelisasi.
Sei adalah blockchain Layer 1 sumber terbuka yang bersifat umum dan dikhususkan untuk pertukaran aset digital. Sei V2 memanfaatkan paralelisasi optimis dan, sebagai hasilnya, lebih ramah pengembang dibandingkan dengan pendahulunya yang deterministik. Dalam paralelisasi optimis, kontrak pintar dapat dieksekusi lebih lancar dan secara bersamaan tanpa memerlukan pengembang untuk mendeklarasikan sumber daya mereka di muka. Ini berarti bahwa rantai secara optimis menjalankan semua transaksi secara paralel. Namun, ketika terjadi konflik (yaitu, beberapa transaksi mengakses status yang sama), blockchain akan melacak komponen penyimpanan tertentu yang dipengaruhi oleh setiap transaksi yang bertentangan.
Blockchain Sei mendekati eksekusi transaksi menggunakan “Optimistic Concurrency Control (OCC).” Pengolahan transaksi bersamaan terjadi ketika beberapa transaksi secara bersamaan aktif dalam suatu sistem. Ada dua fase dalam pendekatan transaksi ini: eksekusi dan validasi.
Dalam tahap eksekusi, transaksi diproses secara optimis, dengan semua bacaan/tulisan disimpan sementara di dalam penyimpanan khusus transaksi. Setelah itu, setiap transaksi akan memasuki tahap validasi, di mana informasi dalam operasi penyimpanan sementara diperiksa terhadap setiap perubahan status yang dilakukan oleh transaksi sebelumnya. Jika suatu transaksi independen, transaksi tersebut berjalan secara paralel. Jika suatu transaksi membaca data yang dimodifikasi oleh transaksi lain, hal ini akan menciptakan konflik. Sistem paralel Sei akan mengidentifikasi setiap konflik dengan membandingkan himpunan bacaan transaksi versus perubahan status terbaru dalam penyimpanan multi-versi (ini diindeks berdasarkan urutan transaksi). Sei akan mengeksekusi dan memvalidasi kembali kasus-kasus di mana konflik muncul. Ini adalah proses iteratif yang melibatkan eksekusi, validasi, dan pengulangan untuk memperbaiki konflik. Grafik di bawah ini menggambarkan pendekatan Sei terhadap transaksi ketika terjadi konflik.
Sumber: https://blog.sei.io/sei-v2-the-first-parallelized-evm/
Implementasi Sei menghasilkan biaya gas yang lebih murah dan ruang desain yang lebih luas bagi pengembang EVM. Secara historis, lingkungan EVM telah terbatas pada <50 TPS, yang memaksa pengembang untuk membuat aplikasi yang mengikuti pola anti. Sei V2 memungkinkan pengembang untuk mendekati sektor-sektor yang biasanya memerlukan kinerja tinggi dan biaya rendah, seperti DeFi, DePIN, dan Gaming.
Monad sedang membangun Layer 1 EVM paralel dengan kompatibilitas bytecode penuh. Yang membuat Monad unik bukan hanya mesin paralelisasinya tetapi juga apa yang mereka bangun di bawahnya untuk mengoptimalkannya. Monad mengambil pendekatan unik terhadap desain keseluruhannya dengan memasukkan beberapa fitur kunci, termasuk pipelining, I/O asinkron, memisahkan konsensus dan eksekusi, dan MonadDB.
Salah satu inovasi kunci dalam desain Monad adalah pipeliningdengan sedikit pergeseran. Pergeseran memungkinkan lebih banyak proses untuk diparellelkan dengan menjalankan beberapa contoh secara bersamaan. Oleh karena itu, pipelining digunakan untuk mengoptimalkan sejumlah fungsi, seperti pipelining akses keadaan, pipelining eksekusi transaksi, pipelining dalam konsensus dan eksekusi, dan pipelining dalam mekanisme konsensus itu sendiri.
Selanjutnya, kami akan mengklik dua kali ke dalam bagian paralelisasi Monad. Dalam Monad, transaksi diurutkan secara linear dalam blok, tetapi tujuannya adalah untuk mencapai keadaan akhir ini lebih cepat dengan memanfaatkan eksekusi paralel. Monad menggunakan algoritma paralelisasi optimis untuk desain mesin eksekusinya. Mesin Monad memproses transaksi secara bersamaan dan kemudian melakukan analisis untuk memastikan bahwa hasilnya akan identik jika transaksi dieksekusi satu per satu. Jika ada konflik, Anda perlu mengeksekusi ulang. Eksekusi paralel di sini adalah algoritma yang relatif sederhana, tetapi menggabungkannya dengan inovasi kunci lain dari Monad adalah yang membuat pendekatan ini baru. Satu hal yang perlu dicatat di sini adalah bahwa bahkan jika terjadi re-eksekusi, biasanya murah karena input yang diperlukan untuk transaksi yang tidak valid hampir selalu tetap berada di cache, sehingga akan menjadi pencarian cache yang sederhana. Re-eksekusi dijamin berhasil karena Anda sudah mengeksekusi transaksi sebelumnya dalam blok.
Monad juga meningkatkan kinerja dengan memisahkan eksekusi dan konsensus, mirip dengan Solana dan Sei, selain eksekusi tertunda. Ide di sini adalah bahwa jika Anda mengendurkan kondisi untuk menyelesaikan eksekusi pada saat konsensus selesai, Anda dapat menjalankan keduanya secara paralel, menghasilkan waktu tambahan untuk keduanya. Tentu saja, Monad menggunakan algoritma deterministik untuk menangani kondisi ini untuk memastikan salah satunya tidak terlalu jauh di depan tanpa kemungkinan mengejar.
Seperti yang saya sebutkan di awal pos ini, akses keadaan adalah salah satu bottleneck kinerja khas bagi blockchain. Pilihan desain seputar akses keadaan dan memori pada akhirnya dapat menentukan apakah implementasi sistem paralel tertentu akan meningkatkan kinerja dalam praktek. Di sini, kita akan membongkar dan membandingkan pendekatan-pendekatan berbeda yang diambil oleh Solana, Sei, dan Monad.
Akses Status Solana: AkunDB / Cloudbreak
Solana menggunakan penskalaan horizontal untuk mendistribusikan dan mengelola data status di sejumlah perangkat SSD. Banyak blockchain saat ini menggunakan basis data generik (misalnya, LevelDB) dengan batasan dalam menangani sejumlah besar pembacaan dan penulisan data status yang bersamaan. Untuk menghindari hal ini, Solana membangun akunDB kustomnya sendiri memanfaatkanCloudbreak.
Cloudbreak dirancang untuk akses paralel melintasi operasi I/O daripada hanya mengandalkan RAM, yang secara inheren cepat. Operasi I/O (Input/Output) merujuk pada membaca data dari atau menulis data ke sumber eksternal, seperti disk, jaringan, atau perangkat periferal. Awalnya, Cloudbreak menggunakan indeks in-RAM untuk memetakan kunci publik ke akun yang memegang saldo dan data. Namun, saat ini menulis makalah ini dan versi 1.9, indeks telah dipindahkan dari RAM ke SSD. Pergeseran ini memungkinkan Cloudbreak untuk secara bersamaan menangani 32 operasi I/O dalam antrian, meningkatkan throughput di beberapa SSD. Akibatnya, data blockchain seperti akun dan transaksi dapat diakses secara efisien, seolah-olah mereka berada di RAM menggunakan file yang dipetakan ke memori. Grafik di bawah ini mewakili hierarki memori yang menggambarkan. Meskipun RAM lebih cepat, kapasitasnya lebih sedikit dari pada SSD dan umumnya lebih mahal:
Diagram hirarki memori ilustratif
Dengan penskalaan secara horizontal dan mendistribusikan data keadaan di sejumlah perangkat, Cloudbreak mengurangi laten dan meningkatkan efisiensi, desentralisasi, dan ketahanan jaringan dalam ekosistem Solana.
Akses Keadaan Sei: SeiDB
Sei telah mendesain ulang penyimpanannya, SeiDB, untuk mengatasi beberapa isu: amplifikasi tulisan (berapa banyak metadata yang diperlukan untuk menjaga struktur data, semakin kecil = lebih baik), pembengkakan status, operasi lambat, dan penurunan kinerja dari waktu ke waktu. Redesain baru sekarang dibagi menjadi dua komponen: toko status dan komitmen status. Merekam dan memverifikasi setiap perubahan data ditangani oleh komitmen status, sementara database yang mencatat semua data pada setiap titik ditangani oleh penyimpanan status (SS).
Pada Sei V2, Komitmen Negara menggunakan memori-mapped Arsitektur pohon IAVL (MemIAVL)Pohon IAVL yang dipetakan memori menyimpan lebih sedikit metadata, yang mengurangi penyimpanan status dan waktu sinkronisasi status dan membuat menjalankan node penuh jauh lebih mudah. Pohon IAVL yang dipetakan memori direpresentasikan sebagai tiga file di disk (kv, cabang, daun); oleh karena itu, lebih sedikit metadata yang perlu dilacak, yang membantu mengurangi penyimpanan status lebih dari 50%. Struktur MemIAVL baru membantu mengurangi faktor penguatan tulisan karena mengurangi metadata yang dibutuhkan untuk memelihara struktur data.
SeiDB yang diperbarui memungkinkan dukungan backend database yang fleksibel untuk lapisan penyimpanan state. Sei percaya bahwa operator node yang berbeda akan memiliki persyaratan yang beragam dan kebutuhan penyimpanan yang berbeda. Oleh karena itu, SS telah dirancang untuk menampung backend yang berbeda, memberikan kebebasan dan fleksibilitas kepada operator, yaitu PebbleDB, RocksDB, SQLite, dll.
Akses Negara: MonadDB
Ada beberapa nuansa penting dalam akses keadaan Monad. Pertama, sebagian besar klien Ethereum memanfaatkan dua jenis basis data: basis data B-Tree (yaitu, LMDB) atau basis data log-structured merge tree (LSM) (yaitu, RocksDB, LevelDB). Kedua basis data ini adalah struktur data generik yang tidak dirancang secara eksplisit untuk blockchain. Selain itu, basis data ini tidak memanfaatkan kemajuan terbaru dalam teknologi Linux, terutama mengenai operasi asinkron dan optimisasi I/O. Terakhir, Ethereum sendiri mengelola keadaan menggunakanPatricia Merkle Trie, yang mengkhususkan diri dalam kriptografi, verifikasi, dan bukti. Masalah utamanya adalah bahwa klien harus mengintegrasikan Trie Patricia Merkle khusus ini ke dalam basis data yang lebih generik (yaitu, B-Tree / LSM), dengan kerugian kinerja yang signifikan seperti akses disk yang berlebihan.
Semua hal di atas membantu menyiapkan panggung mengapa Monad memutuskan untuk membuat database MonadDB buatan sendiri, yang dirancang khusus untuk menangani data blockchain dan akses keadaan secara lebih efisien. Beberapa fitur kunci MonadDB termasuk basis data akses paralel, basis data khusus yang dioptimalkan untuk Data Merkle Trie, akses keadaan efisien melalui penggunaan RAM standar, dan desentralisasi serta skalabilitas.
MonadDB secara eksplisit dirancang untuk blockchain, membuatnya lebih performa daripada menggunakan basis data generik. MonadDB khusus dan disesuaikan untuk mengelola data tipe Merkle trie dengan efisien, memungkinkan akses paralel ke beberapa simpul trie pada saat yang sama. Meskipun biaya membaca tunggal di MonadDB versus beberapa basis data generik di atas sama, properti kunci di sini adalah bahwa MonadDB dapat menjalankan banyak pembacaan secara paralel, menghasilkan peningkatan kecepatan yang besar.
MonadDB memungkinkan akses keadaan simultan ke database akses paralel. Karena Monad membangun database ini dari awal, ia mampu memanfaatkan teknologi kernel Linux terbaru dan kekuatan penuh SSD untuk I/O asinkron. Dengan async I/O, jika suatu transaksi memerlukan membaca keadaan dari disk, ini tidak boleh menghentikan operasi menunggu penyelesaian. Sebaliknya, itu harus memulai pembacaan dan secara bersamaan melanjutkan pemrosesan transaksi lainnya. Inilah bagaimana async I/O secara signifikan mempercepat pemrosesan untuk MonadDB. Monad mampu mengekstrak kinerja yang lebih baik dari perangkat keras dengan mengoptimalkan penggunaan SSD dan mengurangi ketergantungan pada RAM yang berlebihan. Ini memiliki manfaat tambahan untuk sejalan dengan desentralisasi dan skalabilitas.
Ringkasan Perbandingan Solana vs. Sei vs. Monad
Secara kesimpulan, menjelajahi paralelisasi dalam blockchain melalui lensa Solana, Sei, dan Monad memberikan pemahaman komprehensif tentang bagaimana arsitektur dan pendekatan yang berbeda dapat meningkatkan kinerja dan skalabilitas. Paralelisasi deterministik Solana, dengan penekanan pada mendeklarasikan akses keadaan di muka, menawarkan prediktabilitas dan efisiensi, menjadikannya pilihan yang kuat untuk aplikasi yang membutuhkan throughput tinggi. Di sisi lain, pendekatan paralelisasi optimis Sei memprioritaskan fleksibilitas pengembang dan cocok untuk lingkungan di mana konflik transaksi jarang terjadi. Dengan perpaduan unik paralelisasi optimis dan MonadDB yang dibangun khusus, Monad menyajikan solusi inovatif yang memanfaatkan kemajuan teknologi terbaru untuk mengoptimalkan akses keadaan dan kinerja.
Setiap blockchain menawarkan pendekatan yang berbeda dalam mengatasi tantangan paralelisasi, dengan serangkaian kompromi tersendiri. Desain Solana ditujukan untuk memaksimalkan pemanfaatan perangkat keras dan throughput, sementara Sei fokus pada mempermudah proses pengembangan, dan Monad menekankan solusi database yang dibuat khusus untuk data blockchain. Perbedaan ini menyoroti keragaman dalam ekosistem blockchain dan pentingnya memilih platform yang tepat berdasarkan kebutuhan spesifik aplikasi.
Saat ruang blockchain terus berkembang, kemajuan dalam teknik paralelisasi yang ditunjukkan oleh Solana, Monad, dan Sei tanpa ragu akan menginspirasi inovasi lebih lanjut. Perjalanan menuju blockchain yang lebih efisien, dapat diskalakan, dan ramah pengembang masih berlangsung, dan pelajaran yang dipetik dari platform-platform ini akan memainkan peran penting dalam membentuk masa depan teknologi blockchain.
Pada Bagian II dari seri ini, kita akan membahas implikasi ekonomi dan kompromi yang terkait dengan sistem desain paralel ini.