Sumber asli: Gravity

Pengantar

Sejak peluncuran Gravity Alpha mainnet pada Agustus 2024, jaringan ini telah memproses lebih dari 275 juta transaksi, dengan volume transaksi harian mencapai 2,6 juta, dan berhasil mencapai biaya transaksi sebesar 30 juta G. Dengan dirilisnya Litepaper, kami sangat menantikan masa depan rantai EVM berkinerja tinggi ini. Artikel ini akan membahas secara mendalam tentang Litepaper, mengungkap bagaimana Gravity membangun arsitektur blockchain Layer-1 berkinerja tinggi yang luar biasa untuk aplikasi dunia nyata.

Gravity adalah blockchain Layer-1 berkinerja tinggi yang kompatibel dengan EVM yang dibangun oleh Galxe. Pengembangan Gravity berasal dari kebutuhan pengembangan Galxe. Platform Galxe sebagai platform distribusi terbesar di dunia, menghubungkan ekosistem multi-rantai yang besar, menarik lebih dari 25 juta pengguna. Dalam proses perkembangannya yang berkelanjutan, Galxe telah berkembang menjadi aplikasi super terdesentralisasi, mengintegrasikan alat inovatif seperti Quest, Passport, Score, Compass, dan Alva, sambil menyediakan layanan kaya seperti poin loyalitas, NFT acara, hadiah token, verifikasi zk-identity, dan tabungan pintar lintas rantai. Dalam proses perkembangan yang berkelanjutan, volume transaksi tinggi Galxe menjadi faktor pendorong utama untuk pembangunan Gravity — sistem poin loyalitasnya mendukung 51,2 transaksi per detik, sedangkan aktivitas hadiah token mendukung 32,1 transaksi per detik. Ini mendorong kami untuk beralih ke blockchain EVM saat mendesentralisasi backend Galxe, sambil tetap menjaga pengalaman pengguna yang optimal.

Dengan perkembangan penuh rantai Galxe, peningkatan volume transaksi lebih lanjut diperkirakan. Diperkirakan kebutuhan throughput akan mencapai 50 juta gas per detik, sementara memenuhi kebutuhan ekosistem yang lebih luas (seperti penyelesaian lintas rantai, transaksi poin loyalitas, dan pasar NFT) mungkin memerlukan kapasitas pemrosesan 500 juta gas per detik. Untuk itu, tujuan Gravity adalah mendukung throughput 1 gigagas per detik untuk memenuhi kebutuhan ekspansi aplikasi yang padat sumber daya.

Di antara solusi yang ada, banyak platform mencapai skalabilitas melalui Ethereum, tetapi periode tantangan L2 Rollup secara tak terhindarkan menyebabkan penundaan transaksi, yang tidak ramah bagi aplikasi yang membutuhkan konfirmasi transaksi instan seperti Galxe. Meskipun beberapa DApp mencoba mengatasi penundaan ini melalui mode kepercayaan atau pemantauan eksternal, metode ini memperkenalkan kompleksitas dan risiko tambahan yang jelas tidak ideal untuk skenario aplikasi inti.

Dalam konteks ini, Gravity muncul. Gravity berfokus pada EVM paralel, dengan mengembangkan Grevm, sistem eksekusi EVM paralel open-source tercepat saat ini, yang mempersempit kesenjangan kinerja antara L2 dan L1. Selain itu, Gravity memodularisasi arsitektur Aptos, mengintegrasikan komponen terbukti seperti Quorum Store dan mesin konsensus AptosBFT. Dengan memanfaatkan arsitektur matang Aptos, Gravity menghindari kompleksitas dan risiko potensial dari pengembangan dari nol. Akhirnya, Gravity tidak hanya membangun blockchain Layer-1 berkinerja tinggi yang menyediakan pengalaman penuh rantai, tetapi juga meluncurkan SDK blockchain berpipeline pertama, yang sangat menyederhanakan alur interaksi antara pengembang dan pengguna.

Gravity menyediakan skalabilitas, kemampuan desentralisasi, dan kecepatan transaksi yang hampir instan yang belum pernah ada sebelumnya. Teknologinya menggabungkan keuntungan dari L1 dan L2, mencapai 10.000 transaksi per detik dan finalitas sub-detik. Selain itu, dengan mengintegrasikan protokol restaking seperti EigenLayer dan Babylon, Gravity tidak hanya memastikan keamanan yang kuat pada fase awal tetapi juga mengurangi risiko sistemik jangka panjang dari ketergantungan pada satu aset.

Ke depan, Gravity akan melanjutkan sesuai dengan peta jalan berikut:

· Meluncurkan tahap Devnet 1, menguji kinerja waktu nyata;

· Meluncurkan Longevity Testnet, memverifikasi stabilitas jaringan jangka panjang;

· Dari Gravity Alpha mainnet ke Gravity mainnet yang sepenuhnya beroperasi, meletakkan dasar untuk aplikasi teknologi terdesentralisasi berskala besar.

Berikut adalah kompilasi lengkap dari Gravity Litepaper.

Ringkasan

Gravity adalah blockchain Layer-1 berkinerja tinggi yang kompatibel dengan EVM yang dibangun oleh Galxe, dirancang untuk aplikasi berskala besar dan ekosistem multi-rantai. Fitur-fiturnya termasuk throughput 1 gigagas per detik, konfirmasi transaksi akhir sub-detik, dan mekanisme konsensus PoS yang bergantung pada protokol restaking. Desain Gravity didasarkan pada dua komponen sumber terbuka inti: (1) Gravity SDK, yang merupakan mesin konsensus PoS berbasis AptosBFT berpipeline dengan restaking; (2) Gravity reth, lapisan eksekusi yang didorong oleh Grevm (Gravity EVM) yang paralel. Alat-alat ini menyediakan kemampuan untuk membangun alternatif Layer-1 dan Layer-2 yang efisien untuk aplikasi Web3, terutama menonjol di rantai EVM. Artikel ini membahas desain teknik dan inovasi Gravity secara mendalam, menunjukkan bagaimana memenuhi kebutuhan kinerja tinggi melalui arsitektur pipeline, algoritma konsensus canggih, teknologi eksekusi paralel, serta mekanisme penyimpanan yang dioptimalkan (melalui peningkatan reth dan perbaikan mesin konsensus Aptos).

Pengantar

Pengembangan Gravity berasal dari tantangan yang dihadapi Galxe dalam operasionalnya. Galxe adalah aplikasi Web3 terkemuka yang menyediakan layanan seperti poin loyalitas, NFT acara, hadiah token, verifikasi identitas nol-pengetahuan, dan tabungan pintar lintas rantai. Dengan cepat berkembang, sistem poin loyalitas Galxe rata-rata memproses 51,2 transaksi per detik, sementara aktivitas hadiah token rata-rata memproses 32,1 transaksi per detik. Dalam proses mendesentralisasi Galxe secara bertahap, mentransfer kasus penggunaan ini ke blockchain EVM sambil memastikan pengalaman pengguna yang mulus menjadi tantangan. Oleh karena itu, penting untuk mengembangkan blockchain EVM berkinerja tinggi yang dapat memenuhi (1) throughput transaksi tinggi dan (2) konfirmasi transaksi yang hampir instan.

Dalam konteks ini, memilih solusi Layer-2 yang ada atau mengembangkan Layer-1 baru adalah titik keputusan yang krusial. Layer-1 mencapai finalitas melalui algoritma konsensus, sementara Layer-2 mengatasi masalah ini melalui protokol Rollup. Keduanya memiliki trade-off: Layer-1 biasanya牺牲 sebagian throughput karena batasan algoritma konsensus, tetapi dapat mencapai konfirmasi transaksi yang lebih cepat. Misalnya, algoritma konsensus berbasis AptosBFT dapat mengonfirmasi transaksi dalam sub-detik, sementara Rollup optimis mungkin memiliki periode tantangan hingga tujuh hari. Meskipun pembuktian nol dapat mempercepat proses ini, konfirmasi akhir masih memerlukan waktu beberapa jam. Mengingat kebutuhan Gravity untuk konfirmasi akhir sub-detik (terutama untuk protokol niat penuh rantai), kami memilih untuk membangun Layer-1.

Meskipun Layer-2 memiliki keuntungan asli dalam berkomunikasi dengan Ethereum, Layer-1 seperti Gravity dapat mencapai interoperabilitas mendalam dengan Ethereum dan blockchain lainnya melalui protokol niat Gravity dan jembatan lintas rantai. Desain ini tidak hanya berkolaborasi tanpa hambatan dengan Ethereum, tetapi juga meningkatkan konektivitas seluruh ekosistem Web3.

Selain itu, protokol restaking secara signifikan mengurangi kesulitan dalam membangun blockchain PoS Layer-1. Gravity mengintegrasikan aset staking dari Ethereum dan Bitcoin serta jaringan validator yang luas melalui protokol seperti EigenLayer dan Babylon. Ini memberikan jaminan ekonomi untuk konsensus PoS, membuat desentralisasi dan keamanan Gravity setara dengan Ethereum.

Secara keseluruhan, Gravity dibangun sebagai blockchain Layer-1 berkinerja tinggi yang kompatibel dengan EVM untuk memenuhi kebutuhan skalabilitas dan kinerja aplikasi Web3 modern. Meskipun tujuan pengembangannya adalah untuk melayani Galxe, kerangka fleksibel yang ditawarkan oleh Gravity SDK dan Grevm (Gravity EVM) sangat cocok untuk membangun Layer-1 atau Layer-2 yang efisien, dengan fungsi serupa Tendermint/Cosmos SDK.

Kami memerlukan throughput 1 gigagas/s

Untuk blockchain, throughput adalah indikator kinerja yang paling penting, biasanya diukur dalam jumlah transaksi per detik (TPS) atau penggunaan gas per detik (gas/s). Sebagai contoh, sistem poin loyalitas Galxe memerlukan setidaknya mencapai 4 juta gas/s untuk beroperasi dengan stabil. Data ini berasal dari konsumsi rata-rata 80.000 gas per transaksi poin loyalitas, sementara dapat memproses sekitar 51,2 transaksi per detik.

Prediksi ini didukung oleh data praktis dari Gravity Alpha Mainnet. Sebagai jaringan Layer 2 dalam pengujian kami, transaksi poin loyalitas Gravity Alpha Mainnet menunjukkan bahwa throughputnya dapat stabil mencapai 4 juta gas/s, memvalidasi akurasi estimasi sebelumnya.

Meskipun biaya tinggi untuk operasi di dalam rantai dapat menyebabkan penurunan permintaan yang sedikit, tren ekspansi Galxe menunjukkan bahwa selama periode puncak, permintaan dapat meningkat dua hingga tiga kali lipat dari tingkat saat ini. Selain itu, dengan penambahan skenario aplikasi lain, seperti NFT, hadiah token, dan dukungan untuk pembuktian nol di masa depan, jika Galxe sepenuhnya di rantai, diperkirakan kebutuhan throughput akan mencapai 50 juta gas/s. Dan jika aplikasi di rantai Gravity mengikuti distribusi Pareto (mirip dengan Uniswap yang selalu menggunakan 10% gas di Ethereum), untuk memenuhi kebutuhan ekosistem yang lebih luas, seperti penyelesaian lintas rantai, transaksi poin loyalitas, dan pasar NFT, idealnya harus mendukung throughput 500 juta gas/s. Oleh karena itu, untuk memenuhi potensi kebutuhan ini, blockchain harus memiliki kapasitas pemrosesan 1 gigagas per detik, memastikan bahwa ia dapat beradaptasi dengan kebutuhan ekspansi aplikasi yang padat sumber daya.

Untuk mencapai throughput yang begitu tinggi, kunci utamanya adalah memperkenalkan EVM paralel. Kami mengembangkan Grevm, sistem eksekusi EVM paralel open-source tercepat saat ini, kinerja spesifiknya dapat dilihat di bab selanjutnya.

Waktu konfirmasi sub-detik

Selain throughput, kecepatan konfirmasi transaksi juga sangat penting untuk pengalaman pengguna. Pengguna modern terbiasa dengan respons hampir instan seperti di Web2, dan ini masih merupakan tantangan bagi blockchain. Sebagai contoh, Galxe mirip dengan permainan sepenuhnya di dalam rantai dan memiliki persyaratan latensi rendah. Saat ini, waktu konfirmasi transaksi pada sebagian besar blockchain EVM bervariasi dari beberapa detik hingga beberapa hari, jauh dari memenuhi persyaratan ini. Kami memilih algoritma konsensus AptosBFT untuk mencapai waktu konfirmasi sub-detik.

Meskipun L2 Rollup secara teoritis dapat meningkatkan throughput, periode tantangan mereka dapat menyebabkan penundaan transaksi, yang sangat merugikan aplikasi yang membutuhkan konfirmasi transaksi instan (seperti Galxe). Meskipun beberapa DApp berusaha mengoptimalkan ini melalui mode kepercayaan atau pemantauan eksternal, itu memperkenalkan kompleksitas dan risiko tambahan, yang jelas tidak ideal untuk aplikasi kritis. Gravity SDK memperpendek kesenjangan kinerja antara L2 dan L1 dengan merancang pipeline lima tahap, yang memparallelkan proses konsensus dan eksekusi (desain spesifik akan dibahas lebih lanjut).

Keamanan PoS berbasis restaking

Gravity SDK menyediakan cara yang aman untuk memperluas Ethereum, tidak terbatas pada L2 Rollup, tetapi memilih struktur L1 yang dilindungi oleh restaking, menyeimbangkan kinerja, interoperabilitas, dan keamanan. Modul inti mengintegrasikan protokol restaking seperti EigenLayer dan Babylon, yang menyediakan dukungan kepercayaan ekonomi, menjamin pembangunan konsensus PoS yang kuat.

Dengan dukungan untuk aset staking Ethereum senilai 45 miliar dolar dan 850.000 validator, serta akses ke aset Bitcoin senilai 600 miliar dolar melalui Babylon, Gravity dapat membangun fondasi keamanan yang kuat sejak awal, menghindari masalah umum yang sering terjadi pada peluncuran blockchain baru serta risiko keamanan, sambil secara jangka panjang mengurangi risiko sistemik yang berasal dari ketergantungan pada satu aset.

Arsitektur Gravity Chain

Gravity Chain terdiri dari dua komponen utama: Gravity SDK dan Gravity reth. Gravity SDK adalah kerangka blockchain yang ditingkatkan dari rantai Aptos, yang merupakan blockchain PoS paling maju saat ini berdasarkan keluarga algoritma konsensus HotStuff, dengan arsitektur pipeline yang sangat meningkatkan throughput dan efisiensi sumber daya. Gravity reth adalah lapisan eksekusi berbasis reth, berjalan dalam bentuk reaktor aliran blok (BSR) untuk menerima blok yang diusulkan dari lapisan konsensus. Dengan mengoptimalkan reth, Gravity reth mewujudkan eksekusi paralel, perhitungan komitmen status asinkron batch, dan peningkatan efisiensi penyimpanan. Kedua komponen ini terintegrasi erat melalui antarmuka mesin konsensus Gravity (GCEI) dan adaptor reth, dikelola secara dinamis oleh pengontrol pipeline yang mengatur kemajuan setiap tahap.

Desain ini memisahkan eksekusi blok dari konsensus blok, sehingga lapisan eksekusi bertindak sebagai konsumen dari blok yang diusulkan. Kami melakukan optimasi pada reth, membuatnya sempurna untuk alur proposal blok yang dikelola oleh reaktor aliran blok (BSR).

Proses transaksi di Gravity Chain adalah sebagai berikut:

1. Transaksi diajukan melalui antarmuka JSON RPC Gravity reth, yang sepenuhnya kompatibel dengan Ethereum.

2. Selanjutnya, transaksi memasuki memori pool Gravity SDK dan menyebar di jaringan, validator memproses transaksi secara batch dan menghasilkan sertifikat Quorum Store (QS).

3. Setiap putaran pemimpin mengajukan proposal blok, yang berisi metadata blok dan transaksi yang diurutkan yang dipilih dari memori pool dan QS.

4. Setelah proposal ditandai sebagai terurut, akan masuk ke lapisan eksekusi.

5. Lapisan eksekusi Grevm memproses transaksi secara paralel, menghasilkan hasil eksekusi, dan mengirimkan status baru ke modul manajemen status.

6. Modul status menghitung akar status dan mengirimkannya ke mesin konsensus untuk mencapai konsensus akar status.

7. Setelah akar status akhirnya dikonfirmasi, modul penyimpanan akan mempersistensikan akar status dan data blok.

Bab selanjutnya akan membahas setiap komponen secara rinci.

Gravity SDK: Praktik inovatif blockchain berpipeline sumber terbuka

Gravity SDK adalah kerangka blockchain sumber terbuka yang modular, dikembangkan berdasarkan blockchain Aptos yang siap produksi. Tujuannya adalah memodularisasi arsitektur Aptos, dengan mengambil inspirasi dari komponen yang telah terbukti seperti Quorum Store dan mesin konsensus AptosBFT, untuk membangun SDK blockchain berpipeline pertama.

Alasan Gravity SDK memilih Aptos sebagai dasar termasuk:

· Arsitektur teknologi tingkat atas: Aptos adalah blockchain PoS canggih berbasis konsensus keluarga HotStuff.

· Kinerja ekstrem: Aptos menyediakan throughput 160.000 transaksi per detik, dan waktu konfirmasi akhir kurang dari 1 detik.

· Keandalan praktis: Aptos telah divalidasi dalam lingkungan produksi, menunjukkan stabilitas dan efisiensi yang luar biasa.

· Hindari mengulangi roda: memanfaatkan arsitektur matang Aptos dapat menghindari kompleksitas dan risiko potensial dari pengembangan dari nol, sementara upaya lain untuk melampaui Aptos sebagian besar bersifat teoritis dan kurang praktik.

· Sinergi: Dengan terus berkembangnya Aptos, Gravity SDK dapat mengintegrasikan fitur-fitur barunya secara mulus, seperti API nomor acak, sementara juga memberi kembali kepada Aptos melalui arsitektur modular dan mekanisme keamanan inovatif.

Blockchain berbasis Gravity SDK terhubung dengan mesin konsensus Gravity melalui antarmuka Gravity Consensus Engine Interface (GCEI) yang berpipeline. Meskipun GCEI kompatibel dengan berbagai lapisan eksekusi, Gravity SDK saat ini terutama mendukung Gravity reth. Rincian lebih lanjut tentang GCEI akan dibahas di bab berikutnya.

Antarmuka Mesin Konsensus Gravity (GCEI)

Protokol GCEI (Gravity Consensus Execution Interface) adalah jembatan komunikasi antara lapisan konsensus dan lapisan eksekusi. Ini menetapkan norma interaksi antara kedua lapisan, memastikan konsensus dan proses eksekusi tetap disinkronkan melalui pengontrol pipeline.

Perbedaan utama antara SDK blockchain tradisional dan Gravity SDK terletak pada mesin konsensusnya yang dipipeline. Lapisan eksekusi harus diimplementasikan sebagai reaktor aliran blok (Block Stream Reactor), yang berarti ia harus mampu terus-menerus mengkonsumsi aliran blok yang diusulkan, dan komitmen status harus dihitung secara asinkron dengan eksekusi transaksi. Selain itu, lapisan eksekusi perlu mampu memberikan sinyal tekanan balik kepada lapisan konsensus untuk menyesuaikan ritme proposal blok secara dinamis.

Selain itu, karena karakteristik pipeline Gravity SDK, lapisan eksekusi harus mampu menangani transaksi yang tidak dapat dieksekusi dalam blok yang diusulkan, karena memori pool tidak dapat memeriksa keabsahan transaksi apa pun secara ketat karena tidak dapat mengakses status dunia terbaru: eksekusi mungkin belum selesai. Sementara itu, hasil eksekusi tidak boleh menghambat pembuatan blok berikutnya, karena setelah Gravity SDK mengparallelkan konsensus blok dengan konsensus status, lapisan eksekusi menjadi reaktor terhadap aliran blok yang diusulkan, dapat dengan bebas mengembalikan hasil eksekusi di tahap berikutnya.

Protokol GCEI mendefinisikan dua set API:

· API lapisan konsensus: API ini diimplementasikan oleh Gravity SDK untuk melayani lapisan eksekusi dalam menanggapi proposal blok mesin konsensus dan menyerahkan komitmen status.

· API lapisan eksekusi: API ini harus diimplementasikan oleh lapisan eksekusi. Mesin konsensus akan menggunakan API ini untuk melakukan verifikasi dengan usaha terbaik sebelum mengajukan transaksi ke blok, mengalirkan blok yang diusulkan, dan memberi tahu lapisan eksekusi tentang komitmen status akhir.

Dari sudut pandang siklus hidup transaksi, protokol GCEI mendefinisikan hal berikut:

1. check_txn (API lapisan eksekusi)

· Input: Menerima satu transaksi (GTxn) sebagai input.

· Output: Mengembalikan alamat pengirim transaksi, nonce, dan batas gas.

Penggunaan: Metode ini digunakan oleh mesin konsensus untuk melakukan verifikasi dengan usaha terbaik sebelum mengusulkan transaksi ke blok. Metode ini dapat dipanggil berkali-kali pada transaksi yang sama, misalnya ketika transaksi masuk ke dalam memori pool, sebelum diusulkan ke blok, dan ketika komitmen status akhirnya ditetapkan.

2. submit_txn (API lapisan konsensus)

Input: Menerima satu transaksi (GTxn) dari lapisan eksekusi.

Output: Mengembalikan Result<()>, menunjukkan apakah transaksi berhasil ditambahkan ke memori pool.

Penggunaan: Lapisan eksekusi dapat menggunakan metode ini untuk mengajukan transaksi ke dalam memori pool. Mesin konsensus kemudian akan menyebarkan transaksi tersebut melalui jaringan, dan setelah menerima satu batch transaksi, membentuk Quorum Store.

3. recv_ordered_block (API lapisan eksekusi)

Input: Menerima satu ordered_block (tipe BlockBatch), yang berisi transaksi yang diurutkan dan metadata blok.

Output: Mengembalikan Result<()>, menunjukkan apakah lapisan eksekusi berhasil menerima dan menerima blok tersebut.

Penggunaan: Setelah mesin konsensus mengusulkan sebuah blok, blok tersebut akan dikirim ke lapisan eksekusi untuk dieksekusi. Metode ini memungkinkan lapisan eksekusi untuk menerima dan memproses blok yang diusulkan.

4. update_state_commitment (API lapisan konsensus)

Input: Komitmen status untuk nomor blok tertentu (StateCommitment).

Output: Mengembalikan Result<()>, menunjukkan apakah komitmen status diterima dengan sukses oleh mesin konsensus lokal.

Penggunaan: Setelah lapisan eksekusi menghitung komitmen status, ia mengirimkannya ke lapisan konsensus untuk finalisasi, yaitu mencapai konsensus ringan 2f+1 dengan validator lain. Jika konsensus komitmen status terlalu jauh dari kemajuan blok yang diusulkan, pengontrol pipeline akan menyesuaikan ritme proposal blok.

5. commit_block_hash (API lapisan eksekusi)

Input: Menerima vektor block_ids yang menunjukkan blok yang perlu diserahkan.

Output: Mengembalikan Result<()>, menunjukkan apakah operasi berhasil.

Penggunaan: Ketika komitmen status akhirnya ditetapkan, lapisan konsensus akan memberi tahu lapisan eksekusi untuk menyerahkan hash blok ke dalam penyimpanan blockchain.

Pipeline blockchain

Gravity SDK memanfaatkan arsitektur pipeline lima tahap untuk memaksimalkan pemanfaatan sumber daya perangkat keras, sehingga mencapai throughput yang lebih tinggi dan latensi yang lebih rendah. Pipeline menjalankan tugas secara berselang-seling antar blok, manajer pipeline menggunakan mekanisme umpan balik untuk memastikan blockchain bergerak maju dengan stabil. Tiga tahap pertama termasuk dalam lapisan konsensus, sedangkan dua tahap terakhir termasuk dalam lapisan eksekusi.

Setiap tahap dijelaskan sebagai berikut:

· Tahap 1: Penyebaran transaksi: Tahap ini secara efisien menyebarkan transaksi di antara validator, memastikan transaksi disertakan dengan tepat dan andal selama pembangunan blok. Desainnya memisahkan penyebaran transaksi dari mekanisme konsensus, mengikuti pemikiran Narwhal & Tusk dan Aptos, yaitu validator terus-menerus berbagi batch transaksi, memanfaatkan semua sumber daya jaringan untuk berjalan secara paralel. Ketika satu batch transaksi mendapatkan tanda tangan berat 2f+1 (membentuk PoAv, yaitu bukti keberterimaan), memastikan bahwa batch transaksi tersebut disimpan oleh setidaknya f+1 validator yang jujur, sehingga semua validator yang jujur dapat mengambil transaksi ini untuk dieksekusi.

· Tahap 2: Pengurutan metadata blok: Tahap ini membangun urutan transaksi dan metadata blok yang konsisten dan diakui di dalam jaringan. Mekanisme konsensus (AptosBFT) mengikuti aturan dua rantai (2-chain rule) untuk menyediakan blok toleransi Byzantine. Blok kemudian akan mengalir ke tahap eksekusi, bersiap untuk pemrosesan paralel.

· Tahap 3 (BSR): Eksekusi transaksi paralel: Tahap ini merupakan bagian dari lapisan eksekusi, di mana transaksi dieksekusi secara paralel. Hasil eksekusi kemudian akan diteruskan ke tahap komitmen status.

· Tahap 4: Komitmen status: Tahap ini menyelesaikan perubahan status yang disebabkan oleh eksekusi transaksi dan mempersiapkan blok untuk finalisasi. Komitmen status dihitung secara asinkron dengan eksekusi transaksi, memastikan bahwa eksekusi blok berikutnya tidak terhambat oleh komitmen status blok saat ini.

· Tahap 5: Persistensi status: Tahap ini mempersistensikan perubahan status yang telah dikomit ke dalam penyimpanan blockchain. Akar status akhir dan data terkait disimpan di Gravity Store, yang menggunakan mesin penyimpanan yang sangat dioptimalkan, dirancang untuk akses cepat dan handal. Sementara itu, memori pool dan Quorum Store diberitahu untuk membersihkan transaksi yang tidak dapat disertakan di masa depan.

Modul Staking dan Restaking

Membangun blockchain Layer 1 berbasis bukti kepemilikan (PoS) yang aman adalah tugas yang kompleks, terutama dalam situasi di mana hanya mengandalkan token tertentu di dalam rantai untuk staking. Metode ini mungkin menghadapi masalah keamanan ekonomi yang tidak mencukupi pada tahap awal, seperti fluktuasi nilai token atau keterbatasan partisipasi validator. Untuk mengatasi masalah ini, Gravity SDK menyediakan modul Staking dan Restaking yang fleksibel, dirancang untuk meningkatkan keamanan jaringan melalui mekanisme staking lokal dan eksternal.

Salah satu strategi kunci dari Gravity SDK adalah memperkenalkan protokol Restaking seperti EigenLayer dan Babylon. Protokol ini memungkinkan validator untuk melakukan staking ulang aset dari jaringan yang sudah mapan (seperti Ethereum dan Bitcoin), memanfaatkan jaminan keamanan yang ada. Dengan memungkinkan validator untuk mempertaruhkan aset dari rantai tersebut, Gravity SDK mampu meningkatkan keamanan ekonomi jaringan tanpa harus sepenuhnya bergantung pada token lokal. Metode ini tidak hanya memperkuat ketahanan rantai, tetapi juga mendorong keberagaman ekosistem validator. Desain modul Staking berfokus pada modularitas, dengan komponen Restaking yang sangat fleksibel, mampu dengan mudah beradaptasi dengan protokol Restaking baru seiring perkembangan ekosistem blockchain.

Modul ini tidak hanya mendukung aset Restaking, tetapi juga mendukung staking token ERC20 kustom di rantai yang didukung, seperti G Token di Ethereum. Validator dapat berpartisipasi dalam konsensus dengan melakukan staking pada token yang diizinkan ini, berkontribusi pada keamanan jaringan. Hak suara validator dihitung berdasarkan total nilai staking mereka, termasuk token kustom dan aset dalam protokol restaking. Perhitungan ini dilakukan berdasarkan konfigurasi spesifik rantai, memastikan setiap rantai dapat mengatur aturan staking dan restaking sesuai dengan kebutuhan mereka.

Pengelola Epoch di mesin konsensus bekerja sama langsung dengan modul Staking untuk menghitung bobot kumpulan validator untuk putaran berikutnya. Ia memastikan bahwa proses konsensus dapat mencerminkan dinamika staking terbaru secara akurat dengan mengambil nilai staking dari lapisan eksekusi. Dalam arsitektur ini, aset lintas rantai (seperti aset staking dari Ethereum) harus terlebih dahulu dijembatani ke lapisan eksekusi sebelum dapat digunakan untuk menghitung total nilai staking validator. Implementasi mekanisme jembatan ini menjadi tanggung jawab lapisan eksekusi, sehingga bisa menangani komunikasi lintas rantai dengan lebih fleksibel. Solusi yang mungkin termasuk jembatan PoS, pembuktian nol untuk status rantai, dan pengiriman pesan lintas rantai yang terintegrasi sendiri.

Rincian teknis lebih lanjut, desain API, dan penjelasan lengkap tentang mekanisme Staking dan Restaking akan dibahas di dokumen selanjutnya.

Gravity Reth: Lapisan eksekusi reaktor aliran blok EVM

Mengintegrasikan lapisan eksekusi mesin virtual Ethereum (EVM) dalam arsitektur Gravity SDK menghadirkan tantangan unik, terutama dalam memanfaatkan sepenuhnya kemampuan mesin konsensus berpipeline. Untuk mencapai integrasi yang mulus dan memaksimalkan potensi arsitektur ini, kami perlu melakukan beberapa optimasi kunci pada klien Ethereum open-source reth. Optimasi ini secara fundamental mengubah reth menjadi Gravity reth, lapisan eksekusi EVM yang dioptimalkan untuk konsensus berpipeline.

Arsitektur blockchain tradisional memproses blok secara berurutan, memastikan setiap blok sepenuhnya diverifikasi dan dieksekusi sebelum mengusulkan blok berikutnya. Namun, Gravity SDK mengadopsi mekanisme konsensus berpipeline, memisahkan setiap tahap pemrosesan blok untuk meningkatkan kinerja. Perubahan paradigma ini membawa kompleksitas:

Transaksi yang tidak terduga: Dalam rantai pipeline, memori pool tidak dapat mengakses status dunia terbaru karena eksekusi blok sebelumnya mungkin belum selesai. Oleh karena itu, transaksi yang termasuk dalam blok yang diusulkan mungkin tidak dapat dieksekusi saat diusulkan, karena keabsahannya tidak dapat diverifikasi secara ketat tanpa status terbaru.

Hasil eksekusi non-blok: Untuk mencegah pipeline terhenti, hasil eksekusi tidak boleh menghalangi pembuatan blok berikutnya. Lapisan eksekusi harus mampu menangani blok yang diusulkan secara asinkron dan mengembalikan hasil eksekusi di tahap berikutnya tanpa mengganggu proses konsensus. Untuk EVM, ini berarti perlu mendefinisikan ulang blockhash, menghilangkan ketergantungan pada field stateRoot di dalam header blok.

Untuk mengatasi masalah ini, kami memperkenalkan empat optimasi kunci:

· Reaktor aliran blok (Block Stream Reactor, BSR): BSR dirancang untuk menyelaraskan reth dengan alur proposal blok pipeline Gravity SDK. Ini memungkinkan lapisan eksekusi untuk terus menerus mengonsumsi aliran blok yang diusulkan, sebagai reaktor untuk memproses blok secara asinkron. BSR membangun siklus umpan balik dinamis dengan mesin konsensus, menggabungkan sinyal tekanan balik yang sesuai. Sinyal ini menyesuaikan kecepatan proposal blok dan komitmen status secara real-time berdasarkan throughput dan latensi lapisan eksekusi. Jika terjadi keterlambatan di lapisan eksekusi akibat transaksi kompleks atau batas sumber daya, mekanisme tekanan balik akan mengurangi laju proposal blok untuk menjaga stabilitas sistem.

· Pemisahan komitmen status dan eksekusi transaksi: Optimasi kedua melibatkan pemisahan perhitungan komitmen status dari eksekusi transaksi. Dengan memisahkan proses ini, kami mewujudkan asinkronisasi perhitungan komitmen status, sehingga eksekusi blok berikutnya tidak perlu menunggu penyelesaian komitmen status blok saat ini. Kami mendefinisikan ulang blockhash, menghilangkan ketergantungan pada field stateRoot di dalam header blok, memastikan bahwa perhitungan akar status tidak menghalangi pembuatan blok berikutnya.

· Optimasi lapisan penyimpanan: Dalam arsitektur pipeline, caching yang efisien dan pelestarian nilai status multi-versi serta komitmen status sangat penting. Optimasi ketiga berfokus pada meningkatkan lapisan penyimpanan untuk memenuhi kebutuhan ini tanpa memperkenalkan hambatan. Dengan mengoptimalkan mekanisme penyimpanan, kami memastikan bahwa data status dapat ditulis dengan cepat dan diambil dengan konkuren tinggi. Ini mencakup pembangunan mesin penyimpanan multi-versi dan mendukung I/O asinkron dari database ke API penyimpanan.

· EVM paralel: Optimasi terakhir melibatkan eksekusi transaksi dalam EVM secara paralel. Kami mengembangkan Grevm, runtime EVM paralel, yang secara signifikan mempercepat pemrosesan transaksi melalui eksekusi transaksi secara bersamaan. Grevm menggunakan petunjuk ketergantungan data yang diperoleh dari simulasi transaksi untuk mengoptimalkan eksekusi paralel, mengurangi pengulangan eksekusi transaksi dan meningkatkan throughput.

Grevm (Gravity EVM) - Eksekusi EVM paralel

Grevm adalah proyek open-source yang dihosting di GitHub (jika belum open-source, akan dibuka di masa depan). Silakan lihat README-nya untuk informasi lebih lanjut.

Grevm (Gravity EVM) adalah runtime EVM paralel open-source yang dibangun di atas revm. Algoritma Grevm terinspirasi oleh BlockSTM dan ditingkatkan dengan memperkenalkan grafik ketergantungan data transaksi yang diperoleh dari simulasi. Mekanisme ini memungkinkan penjadwalan eksekusi paralel menjadi lebih efisien, meminimalkan pengulangan eksekusi transaksi.

Dalam pengujian kinerja kami, Grevm adalah implementasi EVM paralel open-source tercepat saat ini. Untuk transaksi tanpa konflik, Grevm lebih cepat 4,13 kali dari eksekusi berurutan, dengan kecepatan mencapai 26,50 gigagas/s. Jika mensimulasikan latensi I/O 100 μs di dunia nyata, kecepatannya adalah 50,84 kali eksekusi berurutan, dengan throughput sebesar 6,80 gigagas/s. Lonjakan kinerja ini disebabkan oleh integrasi eksekusi paralel dengan operasi I/O asinkron — paralelisme memungkinkan operasi I/O untuk saling tumpang tindih dengan efisien, sehingga mempercepat lebih lanjut.

Inti dari Grevm adalah memanfaatkan ketergantungan data antar transaksi, melalui kumpulan baca/tulis transaksi yang diperkirakan untuk mengoptimalkan eksekusi paralel. Meskipun tidak semua petunjuk sepenuhnya akurat, petunjuk berdasarkan simulasi ini biasanya cukup praktis. Sebagai contoh, di jaringan utama Ethereum, berdasarkan penggunaan gas sejarah, sekitar 30% transaksi adalah transfer Ether yang sederhana, sementara 25%-30% adalah transfer token ERC20, yang biasanya hanya melibatkan pembacaan dan penulisan sejumlah akun dan slot penyimpanan yang terbatas. Untuk transaksi ini, hasil simulasi memiliki akurasi yang konsisten.

Berdasarkan wawasan ini, kami mengembangkan kerangka eksekusi paralel tiga tahap untuk Grevm, sebagai kelanjutan dari model Block-STM, dan menggabungkan petunjuk ketergantungan data yang diperoleh dari simulasi transaksi:

· Tahap 1: Generasi petunjuk dan pemuatan awal status — mensimulasikan transaksi untuk mengumpulkan petunjuk ketergantungan dan memanaskan cache memori. Tahap ini dapat dilakukan pada titik waktu yang berbeda, tergantung pada desain blockchain. Misalnya, ketika transaksi baru tiba di memori pool, simulasi dapat segera dijalankan untuk menyiapkan petunjuk ketergantungan sebelumnya.

· Tahap 2: Analisis ketergantungan - Mengubah petunjuk ketergantungan yang dikumpulkan selama fase simulasi menjadi grafik terarah asiklik (DAG) yang menunjukkan ketergantungan antar transaksi. DAG ini akan digunakan untuk merencanakan penjadwalan transaksi pada eksekusi paralel selanjutnya.

· Tahap 3: Eksekusi paralel di bawah penyelesaian konflik - menggunakan algoritma BlockSTM yang dimodifikasi berbasis ketergantungan DAG untuk mengeksekusi transaksi secara paralel. Penjadwalan tidak lagi memilih transaksi dengan ketat berdasarkan nomor urut transaksi dalam blok (seperti 1, 2, 3, ..., n), tetapi memberikan prioritas berdasarkan urutan DAG untuk meminimalkan konflik dan mengurangi kebutuhan untuk eksekusi ulang.

Komitmen status batch asinkron

Generasi komitmen status tetap menjadi kendala kunci dalam pipeline blockchain, berasal dari sifat urutan yang melekat pada Merkle. Setiap perhitungan sub-pohon harus diselesaikan sebelum menghasilkan komitmen status akhir, yang dapat menyebabkan penundaan signifikan. Meskipun solusi yang ada (seperti pemrosesan paralel tingkat akun pada reth) memperkenalkan derajat paralelisme tertentu, masih ada banyak ruang untuk optimasi. Dalam konteks lapisan eksekusi reaktor aliran blok (BSR) Gravity reth, pemisahan konsensus komitmen status dan eksekusi transaksi memungkinkan perhitungan komitmen status yang tertunda dan batch yang asinkron tanpa menghalangi eksekusi.

Untuk mengatasi masalah ini, kerangka yang diusulkan memperkenalkan inovasi kunci berikut:

Perhitungan hash batch asinkron: Dengan memisahkan konsensus komitmen status dan eksekusi transaksi, kerangka ini mewujudkan perhitungan asinkron untuk komitmen status. Pembaruan akar status dilakukan per batch (misalnya, setiap 10 blok) untuk mengurangi frekuensi perhitungan akar status. Metode pemrosesan batch ini memungkinkan perhitungan hash yang efisien dengan menggabungkan node kotor yang dibagikan, sehingga meminimalkan overhead dari pembaruan yang sering dan mengurangi total biaya komputasi. Untuk blok kecil, pemrosesan batch dapat secara signifikan meningkatkan paralelisme; untuk blok besar, ini dapat mengurangi total biaya komputasi.

Sepenuhnya paralel: Kerangka ini memperluas paralelisme ke seluruh pohon status, bukan hanya ke pohon akun tunggal. Untuk node yang ditandai sebagai 'kotor', kerangka ini menggunakan algoritma komputasi status paralel, membagi pohon menjadi sub-pohon independen dan memproses sub-pohon tersebut secara bersamaan. Hasilnya kemudian digabungkan di tingkat atas untuk menghitung akar akhir dengan efisien. Metode ini memastikan bahwa blok besar dengan banyak transaksi dan perubahan status dapat memanfaatkan multithreading secara maksimal, sehingga memaksimalkan throughput.

Alternatif akar status cepat: Untuk menyesuaikan dengan header blok Ethereum dan opcode BLOCKHASH (yang memerlukan akses ke akar status 256 blok terakhir), kami mendefinisikan ulang akar status. Alih-alih bergantung pada komitmen status akhir (yang tidak tersedia selama eksekusi transaksi), kami menghitung akar status sebagai kombinasi dari kumpulan perubahan blok dan nilai hash akar status sebelumnya. Metode ini membuat perhitungan akar status lebih cepat, tanpa menunggu penyelesaian penuh dari komitmen status.

Gravity Store

Untuk memenuhi kebutuhan manajemen data besar dari blockchain berkinerja tinggi, Gravity Store muncul sebagai lapisan penyimpanan multi-versi yang dioptimalkan. Itu didasarkan pada desain reth, yang telah mengurangi masalah pembengkakan status dengan memisahkan penyimpanan data komitmen status dan penyimpanan data status, sambil mengurangi overhead pembacaan dan penulisan data. Namun, lapisan eksekusi Gravity reth perlu lebih lanjut mendukung pemrosesan paralel dan pengiriman status asinkron, yang mengajukan lebih banyak kebutuhan teknis.

Untuk mengatasi tantangan ini, Gravity Store mengusulkan struktur pohon multi-versi yang efisien, yang dirancang khusus untuk arsitektur BSR (Block Stream Reactor) kami. Struktur pohon ini mendukung pengelolaan pembaruan status multi-versi. Berbeda dari pendekatan tradisional yang segera memperbarui nilai hash setelah modifikasi, Gravity Store menandai node yang dimodifikasi sebagai 'node kotor', sehingga memungkinkan penanganan perhitungan hash yang tertunda dan eksekusi batch. Desain ini memungkinkan pembuatan versi baru dengan cepat, kueri efisien terhadap data versi tertentu, dan pembersihan versi lama di bawah ketinggian tertentu, secara signifikan meningkatkan kinerja manajemen status blockchain.

Kami juga sedang meneliti pengembangan independen mesin penyimpanan Gravity DB, yang dirancang untuk memberikan lapisan penyimpanan yang dioptimalkan untuk aplikasi blockchain dan mendukung operasi I/O sepenuhnya asinkron. Desain mesin ini terinspirasi oleh LETUS, sebuah mesin database log terstruktur berkinerja tinggi yang ditujukan untuk blockchain. Pengembang utama kami, Richard, sebagai salah satu penulis utama LETUS, akan menjelaskan desainnya dalam artikel blog yang akan segera diterbitkan.

Kesimpulan

Gravity Chain adalah blockchain Layer-1 yang kompatibel dengan EVM berkinerja tinggi, dirancang untuk memenuhi kebutuhan skalabilitas dan kinerja aplikasi web3 modern. Menggabungkan Gravity SDK, mesin konsensus PoS AptosBFT yang dipipeline, serta lapisan eksekusi Gravity reth yang didorong oleh Grevm, Gravity mencapai throughput 1 gigagas per detik, waktu konfirmasi transaksi sub-detik, dan keamanan PoS berbasis mekanisme restaking. Desain komponen teknologi ini memberikan dasar yang kuat untuk menciptakan blockchain L1 alternatif yang disesuaikan atau solusi L2 yang lebih efisien untuk aplikasi web3, khususnya dalam konteks penggunaan rantai EVM yang dioptimalkan.

Artikel ini berasal dari kontribusi, tidak mewakili pandangan BlockBeats.