Original source: Gravity
introduction
Since the launch of the Gravity Alpha mainnet in August 2024, the network has processed more than 275 million transactions, with an average daily transaction volume of 2.6 million transactions and successfully achieved 30 million G transaction fees. With the release of Litepaper, we are full of expectations for the future blueprint of this high-performance EVM chain. This article will analyze Litepaper in depth and reveal how Gravity builds an excellent high-performance Layer-1 blockchain architecture for real-world applications.
Gravity is a high-performance, EVM-compatible Layer-1 blockchain built by Galxe. Gravity was developed out of the need for development at Galxe. As the world’s largest on-chain distribution platform, the Galxe platform connects a vast multi-chain ecosystem and attracts over 25 million users. In its ongoing development, Galxe has evolved into a decentralized super-app that integrates innovative tools such as Quest, Passport, Score, Compass, and Alva, while providing a rich set of services such as loyalty points, event NFTs, token rewards, zk-authentication, and cross-chain smart savings. In the process of continued development, Galxe’s high transaction volume has become an important factor driving the construction of Gravity - its loyalty points system supports 51.2 transactions per second, and its token rewards activities support 32.1 transactions per second. This prompted us to move to the EVM blockchain while maintaining the best user experience when decentralizing the Galxe backend.
As Galxe moves towards full on-chain development, further growth in transaction volume is foreseeable. Throughput requirements are expected to reach 50 million gas per second, while processing capacity of 500 million gas per second may be required to meet broader ecological needs such as cross-chain settlement, loyalty points trading, and NFT markets. To this end, Gravity aims to support a throughput of 1 gigagas per second to meet the scaling needs of resource-intensive applications.
Among existing solutions, many platforms achieve scalability through Ethereum, but the challenge period of L2 Rollup inevitably leads to transaction delays, which is not friendly to applications such as Galxe that require instant transaction confirmation. Although some DApps try to compensate for delays through trust models or external monitoring, these methods introduce additional complexity and risks, which are obviously not ideal for core application scenarios.
In this context, Gravity came into being. With parallel EVM as its core, Gravity narrowed the performance gap between L2 and L1 by developing Grevm, the fastest open source parallel EVM execution system. In addition, Gravity modularized the architecture of Aptos and integrated proven components such as Quorum Store and AptosBFT consensus engine. By leveraging the mature architecture of AptosBFT, Gravity avoided the complexity and potential risks of developing from scratch. In the end, Gravity not only built a high-performance L1 blockchain that provides a full-chain experience, but also launched the first pipeline blockchain SDK, which greatly simplified the interaction process between developers and users.
Gravity provides unprecedented scalability, decentralization, and near-instant transaction speeds. Its technology combines the advantages of L1 and L2, achieving 10,000 transactions per second and sub-second finality. At the same time, by integrating re-staking protocols such as EigenLayer and Babylon, Gravity not only ensures strong security during the launch phase, but also reduces the systemic risk of long-term reliance on a single asset.
In the future, Gravity will advance according to the following roadmap:
Launched Devnet Phase 1 to test real-time performance.
Launch Longevity Testnet to verify the long-term stability of the network;
Transition from the Gravity Alpha mainnet to the fully operational Gravity mainnet, laying the foundation for large-scale application of decentralized technologies.
The following is a compilation of the full text from Gravity Litepaper.
summary
Gravity is a high-performance, EVM-compatible Layer-1 blockchain built by Galxe, designed for large-scale applications and multi-chain ecosystems. Its features include 1 gigabyte per second throughput, sub-second transaction finality, and a PoS consensus mechanism based on the re-staking protocol. Gravity's design relies on two core open source components: (1) Gravity SDK, which is a pipelined AptosBFT PoS consensus engine based on re-staking; and (2) Gravity reth, an execution layer driven by the parallel EVM Grevm (Gravity EVM). These tools provide Web3 applications with the ability to build alternative Layer-1 and efficient Layer-2, especially on EVM chains. This article deeply explores Gravity's engineering design and technical innovations, showing how it meets high performance requirements through pipeline architecture, advanced consensus algorithms, parallel execution techniques, and optimized storage mechanisms (through enhanced reth and improved Aptos consensus engine).
introduction
Gravity was developed out of operational challenges faced by Galxe, a leading Web3 application that provides users with loyalty points, campaign NFTs, token rewards, zero-knowledge identity verification, and multi-chain smart savings. As Galxe rapidly grew, its loyalty points system averaged 51.2 transactions per second, while its token rewards campaign averaged 32.1 transactions per second. As Galxe gradually decentralizes, migrating these use cases to the EVM blockchain while ensuring a smooth user experience has become a challenge. Therefore, it is critical to develop a high-performance EVM blockchain that can meet (1) high transaction throughput and (2) nearly instant transaction confirmation.
In this context, choosing an existing Layer-2 solution or developing a new Layer-1 is a key decision point. Layer-1 achieves finality with the help of consensus algorithms, while Layer-2 solves this problem with the help of Rollup protocols. There is a trade-off between the two: Layer-1 usually sacrifices some throughput due to the limitations of the consensus algorithm, but can achieve faster transaction finality. For example, the consensus algorithm based on AptosBFT can confirm transactions in sub-seconds, while optimistic Rollup may take up to seven days due to the challenge period. Although zero-knowledge proofs can speed up this process, final confirmation still takes hours. Given Gravity's need for sub-second final confirmation (especially its full-chain intention protocol), we chose to build Layer-1.
Although Layer-2 has a native advantage in communicating with Ethereum, Layer-1 like Gravity can achieve deep interoperability with Ethereum and other blockchains through the Gravity Intent Protocol and cross-chain bridges. This design not only works seamlessly with Ethereum, but also enhances the connectivity of the entire Web3 ecosystem.
In addition, the restaking protocol significantly reduces the difficulty of building a PoS Layer-1 blockchain. Leveraging protocols like EigenLayer and Babylon, Gravity integrates Ethereum and Bitcoin’s staked assets with their extensive validator networks. This provides economic security for the PoS consensus, making Gravity's decentralization and security comparable to Ethereum.
In summary, Gravity is built as a high-performance, EVM-compatible Layer-1 blockchain to meet the scalability and performance requirements of modern Web3 applications. Although it was originally developed to serve Galxe, the flexible framework provided by Gravity SDK and Grevm (Gravity EVM) is suitable for building any Layer-1 and efficient Layer-2, with functions similar to Tendermint/Cosmos SDK.
We need 1 gigagas/s throughput
For blockchain, throughput is the most critical performance indicator, usually measured in transactions per second (TPS) or gas usage per second (gas/s). Taking Galxe's loyalty point system as an example, it requires at least 4 million gas/s to run stably. This data is calculated from the average consumption of 80,000 gas per loyalty point transaction and the ability to process approximately 51.2 transactions per second.
This prediction is supported by the practical data of Gravity Alpha Mainnet. As the Layer 2 network under our test, the loyalty point transaction of Gravity Alpha Mainnet shows that its throughput can stably reach 4 million gas/s, verifying the accuracy of the above estimation.
While the high cost of on-chain operations may lead to a small drop in demand, Galxe's expansion trends show that demand could rise to two to three times the current level during peak hours. In addition, with the addition of other application scenarios such as NFTs, token rewards, and future zero-knowledge proof-supported full-chain tasks, if Galxe is fully on-chain, the throughput demand is expected to reach 50 million gas/s. Assuming that the gas usage of applications on the Gravity chain follows a Pareto distribution (similar to Uniswap, which has always consumed 10% of Ethereum's gas), in order to meet the needs of a wider ecosystem, such as cross-chain settlement, loyalty point transactions, and NFT markets, a throughput of 500 million gas/s should ideally be supported. Therefore, to meet these potential needs, the blockchain must have a processing capacity of 1 gigagas per second to ensure that it can adapt to the expansion of resource-intensive applications.
To achieve such high throughput, the key is to introduce parallel EVM. We developed Grevm, which is currently the fastest open source parallel EVM execution system. The specific performance can be seen in the following chapters.
Sub-second confirmation time
In addition to throughput, the speed of transaction confirmation is also crucial to user experience. Modern users are accustomed to almost instant responses similar to Web2, which is still a challenge for blockchain. Take Galxe as an example. It is similar to fully on-chain games and has certain requirements for low latency. Currently, the transaction confirmation time of most EVM blockchains ranges from seconds to days, which is far from meeting this requirement. We chose the AptosBFT consensus algorithm to achieve sub-second confirmation time.
Although L2 Rollup can theoretically increase throughput, their challenge period will cause transaction delays, which is very unfavorable for applications that require instant transaction confirmation (such as Galxe). Although some DApps try to optimize this through trust models or external monitoring, it introduces additional complexity and risks, which is not ideal for critical applications. Gravity SDK shortens the performance gap between L2 and L1 by designing a five-stage pipeline to parallelize the consensus and execution processes (see below for detailed design).
PoS Security Based on Restaking
Gravity SDK provides a way to safely scale Ethereum, not limited to L2 Rollup, but chooses L1 architecture protected by re-staking, balancing performance, interoperability and security. The core module integrates re-staking protocols such as EigenLayer and Babylon, provides economic trust support, and provides guarantees for building a robust proof-of-stake consensus.
With Ethereum’s $45 billion in staked assets and 850,000 validators, and Bitcoin’s $600 billion in assets connected via Babylon, Gravity can build a solid security foundation from the start, avoiding the startup problems and security risks common to new blockchains, while reducing the systemic risks of a single asset in the long term.
Gravity Chain Architecture
Gravity Chain consists of two main components: Gravity SDK and Gravity reth. Gravity SDK is a blockchain framework improved from Aptos Chain. Aptos is currently the most advanced PoS blockchain based on the HotStuff consensus algorithm family. Its pipeline architecture greatly improves throughput and resource efficiency. Gravity reth is an execution layer based on reth, running in the form of a block stream reactor (BSR) to receive proposed blocks from the consensus layer. By optimizing reth, Gravity reth achieves parallel execution, batch asynchronous state submission calculation, and storage efficiency improvement. These two components are closely integrated through the Gravity Consensus Engine Interface (GCEI) and the reth adapter, and the progress of each stage is dynamically managed by the pipeline controller.
This design separates block execution from block consensus, making the execution layer a consumer of block proposals. We optimize reth to make it a perfect fit for the pipelined block proposal process managed by the Block Stream Reactor (BSR).
The transaction process of Gravity Chain is as follows:
1. Transactions are submitted through the Gravity reth JSON RPC interface, which is fully compatible with Ethereum.
2. The transaction then enters the Gravity SDK’s memory pool and propagates across the network, where the validator batches the transaction and generates a Quorum Store (QS) certificate.
3. The leader of each round proposes a block proposal, which contains block metadata and ordered transactions selected from the memory pool and QS.
4. Once the proposal is marked as ordered, it will enter the execution layer.
5. Grevm of the execution layer processes transactions in parallel, generates execution results, and passes the new status to the state management module.
6. The state module calculates the state root and passes it to the consensus engine to reach a state root consensus.
7. After the state root is finally confirmed, the storage module persists the state root and block data.
The following sections describe each component in detail.
Gravity SDK: Innovative Practice of Open Source Pipeline Blockchain
Gravity SDK is a modular open source blockchain framework developed on the production-ready Aptos blockchain. Its goal is to modularize the architecture of Aptos, drawing on proven components such as Quorum Store and AptosBFT consensus engine to create the first pipeline blockchain SDK.
The reasons why Gravity SDK chose Aptos as its foundation include:
Top-notch technical architecture: Aptos is an advanced PoS blockchain based on the HotStuff family consensus.
Extreme performance: Aptos provides a throughput of 160,000 transactions per second, with a final confirmation time of less than 1 second.
· Practical reliability: Aptos has been verified in production environments and has demonstrated excellent stability and efficiency.
Avoid reinventing the wheel: Aptos’ mature architecture can avoid the complexity and potential risks of developing from scratch, while other attempts to surpass Aptos are mostly insufficient in theory and practice.
Synergistic gains: As Aptos continues to grow, Gravity SDK can seamlessly integrate its new features, such as the random number API, while also feeding back to Aptos through modular architecture and innovative security mechanisms.
The blockchain based on Gravity SDK is connected to the pipeline consensus engine through the Gravity Consensus Engine Interface (GCEI). Although GCEI is compatible with multiple execution layers, Gravity SDK currently mainly supports Gravity reth. The details of GCEI will be discussed in subsequent chapters.
Gravity Consensus Engine Interface (GCEI)
The GCEI (Gravity Consensus Execution Interface) protocol is a communication bridge between the consensus layer and the execution layer. It standardizes the interaction between the two layers and ensures that the consensus and execution processes are synchronized through the pipeline controller.
The main difference between traditional blockchain SDKs and Gravity SDK is its pipelined consensus engine. The execution layer must be implemented as a Block Stream Reactor, which means it needs to be able to continuously consume the proposed block stream, and the state commitment must be calculated asynchronously with the transaction execution. In addition, the execution layer needs to be able to provide backpressure signals to the consensus layer in order to dynamically adjust the rhythm of block proposals.
In addition, due to the pipeline nature of the Gravity SDK, the execution layer must be able to handle unexecutable transactions in the proposed block, because the memory pool cannot strictly check the validity of any transaction due to the lack of access to the latest world state: the execution may not be completed. At the same time, the execution result should not block the generation of subsequent blocks, because after the Gravity SDK parallelizes the block consensus and the state consensus, the execution layer becomes a reactor for the proposed block stream and can freely return the execution result in the subsequent stage.
The GCEI protocol specification defines two sets of APIs:
Consensus layer APIs: These APIs are implemented by the Gravity SDK and are used by the execution layer to respond to blocks proposed by the consensus engine and submit state commitments.
Execution layer APIs: These APIs must be implemented by the execution layer. The consensus engine will use these APIs to perform best efforts to validate transactions before proposing them to blocks, stream proposed blocks, and notify the execution layer of the final state commitment.
From the perspective of the transaction lifecycle, the GCEI protocol defines the following:
1. check_txn (execution layer API)
Input: Receives a transaction (GTxn) as input.
Output: Returns the sender address, nonce, and gas limit of the transaction.
Purpose: This method is used by the consensus engine to run a best effort validation before proposing a transaction to a block. This method can be called multiple times for the same transaction, for example when the transaction enters the memory pool, before being proposed to a block, and when the state commitment is finalized.
2. submit_txn (consensus layer API)
Input: Receive a transaction (GTxn) from the execution layer.
Output: Returns Result<()>, indicating whether the transaction is successfully added to the memory pool.
Purpose: The execution layer can use this method to submit transactions to the memory pool. The consensus engine will then propagate the transaction through the network and form a Quorum Store after receiving a batch of transactions.
3. recv_ordered_block (execution layer API)
Input: Receives an ordered_block (of type BlockBatch), which contains ordered transactions and block metadata.
Output: Returns Result<()>, indicating whether the execution layer successfully received and accepted the block.
Purpose: Once the consensus engine proposes a block, it is sent to the execution layer for transaction execution. This method allows the execution layer to receive and process proposed blocks.
4. update_state_commitment (consensus layer API)
Input: State Commitment of a block number.
Output: Returns Result<()>, indicating whether the state commitment is successfully accepted by the local consensus engine.
Purpose: After the execution layer calculates the state commitment, it sends it to the consensus layer for finalization, that is, reaching a lightweight consensus of 2f+1 with other validators. If the gap between the state commitment consensus and the progress of the proposed block is too large, the pipeline controller will adjust the rhythm of the block proposal.
5. commit_block_hash (execution layer API)
Input: Receives a set of block_ids vectors, representing the blocks that need to be submitted.
Output: Returns Result<()>, indicating whether the operation is successful or not.
Purpose: When the state commitment is finalized, the consensus layer notifies the execution layer to commit the block hash to the blockchain storage.
Blockchain pipeline
Gravity SDK uses a five-stage pipeline architecture to maximize hardware resource utilization, resulting in higher throughput and lower latency. The pipeline interleaves tasks between different blocks, and the pipeline manager uses a feedback mechanism to ensure that the blockchain moves forward steadily. The first three stages belong to the consensus layer, while the last two stages belong to the execution layer.
The stages are explained below:
Phase 1: Transaction Propagation: This phase efficiently propagates transactions between validators, ensuring timely and reliable inclusion of transactions during block construction. The design decouples transaction propagation from consensus mechanisms, following the ideas of Narwhal & Tusk and Aptos, where validators continuously share batches of transactions and run concurrently using all network resources. When a batch of transactions is signed with 2f+1 weights (forming PoAv, or proof of availability), it is ensured that the batch of transactions is stored by at least f+1 honest validators, so that all honest validators can retrieve these transactions for execution.
Phase 2: Block Metadata Ordering: This phase establishes a consistent and recognized order of transaction and block metadata within the network. The consensus mechanism (AptosBFT) follows the 2-chain rule to provide Byzantine fault-tolerant blocks. Blocks then flow into the execution phase, ready for parallel processing.
Phase 3 (BSR): Parallel Transaction Execution: This phase is part of the execution layer, where transactions are executed in parallel. The execution results will be passed to the state commitment phase.
Phase 4: State Commitment: This phase completes the state changes caused by transaction execution and prepares for block finalization. State commitment is calculated asynchronously with transaction execution to ensure that the execution of the next block is not hindered by the state commitment of the current block.
Phase 5: State persistence: This phase persists the committed state changes to the blockchain storage. The final state root and related data are stored in the Gravity Store, which uses a highly optimized storage engine designed to be fast and reliable. At the same time, the memory pool and Quorum Store are notified to clear transactions that can no longer be included in the future.
Staking and Restaking Modules
Building a secure Proof of Stake (PoS) Layer 1 blockchain is a complex task, especially when relying solely on specific tokens on the chain for staking. This approach may face problems of insufficient economic security in the early stages, such as token value fluctuations or limited validator participation. To address this issue, Gravity SDK provides a flexible Staking and Restaking module designed to improve the security of the network through local and external staking mechanisms.
One of the key strategies of Gravity SDK is the introduction of Restaking protocols such as EigenLayer and Babylon. These protocols allow validators to re-stake assets from other mature networks such as Ethereum and Bitcoin, thereby leveraging their existing security guarantees. By allowing validators to pledge assets from these chains, Gravity SDK is able to improve the economic security of the network without relying entirely on native tokens. This approach not only enhances the robustness of the chain, but also promotes the diversity of the validator ecosystem. The Staking module is designed with modularity at its core, and its Restaking component is highly flexible and can easily adapt to new Restaking protocols as the blockchain ecosystem evolves.
This module not only supports Restaking assets, but also supports staking custom ERC20 Tokens on supported chains, such as G Token on Ethereum. Validators can participate in consensus by staking these allowed tokens and contribute to the security of the network. The voting power of a validator is calculated based on its total staked value, including custom tokens and assets in the Restaking protocol. This calculation is performed based on the specific configuration of the chain, ensuring that each chain can flexibly set staking and re-staking rules according to its own needs.
The Epoch Manager in the consensus engine works directly with the Staking module to calculate the weight of the next round of validator sets. It ensures that the consensus process accurately reflects the latest staking dynamics by obtaining the staking value from the execution layer. In this architecture, cross-chain assets (such as staked assets from Ethereum) must first be bridged to the execution layer before they can be used to calculate the total staked value of the validator. The implementation of the bridging mechanism is the responsibility of the execution layer, which allows for more flexible handling of cross-chain communication. Possible solutions include PoS bridges, zero-knowledge proofs of chain state, and embedded self-starting cross-chain messaging.
More technical details, API design, and a complete description of the Staking and Restaking mechanisms will be introduced in subsequent documents.
Gravity Reth: Blockstream Reactor EVM Execution Layer
Integrating the Ethereum Virtual Machine (EVM) execution layer in the Gravity SDK architecture presents unique challenges, especially when fully leveraging the capabilities of its pipelined consensus engine. In order to achieve seamless integration and fully leverage the potential of the architecture, we needed to make several key optimizations to the open source Ethereum client reth. These optimizations fundamentally transform reth into Gravity reth, a pipeline-optimized EVM execution layer tailored for pipelined consensus engines.
Traditional blockchain architecture processes blocks sequentially, ensuring that each block is fully verified and executed before proposing the next block. However, Gravity SDK uses a pipeline consensus mechanism that separates the various stages of block processing to improve performance. This paradigm shift introduces complexity:
Unexpected transactions: In a pipelined chain, the memory pool cannot access the latest world state because the execution of previous blocks may not have been completed. Therefore, transactions included in the proposed block may not be executed at the time of proposal, because their validity cannot be strictly verified without the latest state.
Non-blocking execution results: To prevent pipeline stalls, execution results should not prevent subsequent block generation. The execution layer must be able to process proposed blocks asynchronously and return execution results at a later stage without blocking the consensus process. For EVM, this means redefining blockhash and eliminating the reliance on the stateRoot field in the block header.
To address these issues, we introduced four key optimizations:
Block Stream Reactor (BSR): BSR is designed to adapt reth to the pipelined block proposal process of Gravity SDK. It enables the execution layer to continuously consume the proposed block stream, acting as a reactor for asynchronously processing blocks. BSR establishes a dynamic feedback loop with the consensus engine, combined with appropriate backpressure signals. These signals adjust the speed of block proposals and state submissions in real time based on the throughput and latency of the execution layer. If the execution layer lags due to complex transactions or resource constraints, the backpressure mechanism will reduce the block proposal rate to ensure system stability.
Decoupling state submission from transaction execution: The second optimization involves separating state submission calculation from transaction execution. By decoupling these processes, we have achieved asynchronous state submission calculation, so that the execution of subsequent blocks does not need to wait for the state submission of the current block to be completed. We redefined blockhash to remove the reliance on the stateRoot field in the block header, ensuring that the state root calculation does not prevent the generation of subsequent blocks.
Storage layer optimization: In a pipeline architecture, efficient caching and persistence of multi-version state values and state commits are critical. The third optimization focuses on enhancing the storage layer to meet these requirements without introducing bottlenecks. By optimizing the storage mechanism, we ensure that state data can be written quickly and retrieved with high concurrency. This includes building a multi-version storage engine and supporting asynchronous I/O from the database to the storage API.
· Parallel EVM: The last optimization involves parallelizing transaction execution within the EVM. We developed Grevm, a parallel EVM runtime that significantly accelerates transaction processing by executing transactions concurrently. Grevm leverages data dependency hints obtained from transaction simulations to optimize parallel execution, reducing transaction re-executions and increasing throughput.
Grevm (Gravity EVM) - Parallel EVM execution
Grevm is an open source project, hosted on GitHub (if it isn't already, it will be in the future). See its README for more information.
Grevm (Gravity EVM) is an open source parallel EVM runtime based on revm. Grevm's algorithm is inspired by BlockSTM and enhanced by introducing transaction data dependency graphs obtained from simulation results. This mechanism makes parallel execution scheduling more efficient and minimizes transaction re-execution.
In our benchmarks, Grevm is currently the fastest open source parallel EVM implementation. For conflict-free transactions, Grevm is 4.13 times faster than sequential execution, running at 26.50 gigagas/s. If simulating real-world 100 μs I/O latency, it is 50.84 times faster than sequential execution, with a throughput of 6.80 gigagas/s. This performance leap is due to the integration of parallelized execution with asynchronous I/O operations - parallelization allows I/O operations to be efficiently overlapped, thereby further accelerating them.
The core idea of Grevm is to exploit data dependencies between transactions to optimize parallel execution through speculative transaction read/write sets. Although all tips are not completely accurate, these simulation-based tips are generally practical enough. For example, on the Ethereum mainnet, based on historical gas usage, about 30% of transactions are simple ether transfers, and another 25%-30% are ERC20 token transfers, which usually only involve reading and writing a limited number of accounts and storage slots. For these transactions, the simulation results have consistent accuracy.
Based on these insights, we developed a three-phase parallel execution framework for Grevm as a follow-up to the Block-STM model, incorporating data dependency hints obtained from transaction simulations:
Phase 1: Hint Generation and State Preloading - Simulate transactions to collect dependency hints and warm up the memory cache. This phase can be performed at different points in time, depending on the design of the blockchain. For example, when a new transaction arrives in the memory pool, a simulation can be run immediately to prepare dependency hints in advance.
Phase 2: Dependency Analysis - Transform the dependency hints collected during the simulation phase into a directed acyclic graph (DAG) that represents the dependencies between transactions. This DAG is used to plan the transaction scheduling in subsequent parallel execution.
Phase 3: Parallel execution with conflict resolution - Execute transactions in parallel using a modified version of the BlockSTM algorithm based on dependency DAG. The scheduler no longer selects transactions strictly according to the sequence number of transactions in the block (such as 1, 2, 3, ..., n), but instead prioritizes transactions according to the DAG to minimize conflicts and reduce the need for re-execution.
Asynchronous batch status submission
The generation of state commits remains a key bottleneck in the blockchain pipeline, stemming from the inherently sequential nature of Merkleization. Each subtree computation must be completed before the final state commit can be generated, which results in significant delays. Although existing solutions (such as reth's account-level parallelization) introduce a certain degree of parallelism, there is still a lot of room for optimization. In the context of Gravity reth's Block Stream Reactor (BSR) execution layer, state submission consensus is decoupled from transaction execution, and delayed and batched state submission calculations can be performed asynchronously without blocking execution.
To address these issues, the proposed framework introduces the following key innovations:
Asynchronous batch hash calculation: Taking advantage of the decoupling of state submission consensus and transaction execution, this framework implements asynchronous calculation of state submission. State root updates are performed in batches (e.g., calculated every 10 blocks) to reduce the frequency of state root calculations. This batch processing approach enables efficient hash computation by aggregating shared dirty nodes, thereby minimizing the overhead of frequent updates and reducing overall computational cost. For small blocks, batch processing can significantly increase parallelism; for large blocks, it can reduce the overall computational cost.
Fully parallelized: The framework extends parallelization to the entire state tree, not just a single account tree. For nodes marked as "dirty", the framework uses a parallel state calculation algorithm that divides the tree into independent subtrees and processes them concurrently. The results are aggregated at the top level to efficiently calculate the final root. This approach ensures that large blocks with a large number of transactions and state changes can fully utilize multithreading, thereby maximizing throughput.
Alternative Fast State Root: To accommodate Ethereum's block headers and BLOCKHASH opcodes (which require access to the state root of the most recent 256 blocks), we redefined the state root. Instead of relying on the final state commit (which is not available during transaction execution), we compute the state root as a combination of the block changeset and the hash of the previous state root. This approach makes the state root computation faster without waiting for a full state commit to complete.
Gravity Store
In order to meet the needs of high-performance blockchain for large-scale data management, Gravity Store was born as an optimized multi-version storage layer. It is based on the design of reth, which has reduced the state expansion problem by separating state submission storage from state data storage, while reducing the overhead of data reading and writing. However, the execution layer of Gravity reth needs to further support parallel processing and asynchronous state submission, which puts forward more technical requirements.
To address these challenges, Gravity Store proposes an efficient multi-version tree structure, tailored for our BSR (Block Stream Reactor) architecture. This tree structure supports managing multi-version state updates. Unlike the traditional practice of updating the hash value immediately after modification, Gravity Store marks the modified nodes as "dirty nodes", thereby achieving delayed processing and batch execution of hash calculations. This design allows for the rapid creation of new versions, efficient query of specified version data, and the cleaning of old versions below the specified height, greatly improving the performance of blockchain state management.
We are also working on developing an independent storage engine, Gravity DB, which is designed to provide an optimized storage layer for blockchain applications and support fully asynchronous I/O operations. The design of this engine is inspired by LETUS, a high-performance log-structured general-purpose database engine for blockchains. Our lead developer Richard, one of the main authors of LETUS, will detail its design in an upcoming blog post.
in conclusion
Gravity Chain is a high-performance EVM-compatible first-layer blockchain designed to meet the scalability and performance requirements of modern web3 applications. Combining the Gravity SDK, the pipelined AptosBFT PoS consensus engine, and the Block Stream Reactor execution layer Gravity reth driven by Grevm, Gravity achieves a transaction throughput of 1 gigagas per second, sub-second transaction confirmation time, and PoS security based on the re-staking mechanism. The design of these technical components provides a solid foundation for web3 applications to create customized alternative L1 blockchains or more efficient L2 solutions, and is particularly suitable for optimizing the use cases of EVM chains.
This article is from a contribution and does not represent the views of BlockBeats
