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.

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:
Ikhtisar Sistem Paralel Kripto- Pendekatan Akses Memori & Status- Peluang Desain Paralel## Sistem Paralel Non-KriptoMengambil 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.
Pemrosesan Paralel: Pemrosesan paralel secara mendasar telah mengubah citra medis, menghasilkan peningkatan signifikan dalam kecepatan dan resolusi di berbagai modalitas seperti MRI, CT, sinar-X, dan tomografi optik. Nvidia berada di garis depan dari kemajuan ini, menyediakan radiolog dengan kemampuan kecerdasan buatan yang ditingkatkan melalui paket alat pemrosesan paralelnya, yang memungkinkan sistem citra untuk menangani beban data dan komputasi yang lebih besar dengan lebih efektif.- Astronomi: Beberapa fenomena baru, seperti pemahaman lubang hitam, hanya bisa terjadi menggunakan superkomputer paralel.- Mesin Game Unity: Mesin Unity menggunakan kemampuan GPU - yang dibangun untuk beban kerja grafis besar - untuk membantu kinerja dan kecepatan. Mesin ini dilengkapi dengan fitur pemrosesan multithreaded dan paralel, menghasilkan pengalaman bermain game yang mulus dan menciptakan lingkungan game yang kompleks dan detail.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.
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.
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
Diagram hirarki memori ilustratifDengan 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
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.





