With this integrated and streamlined solution, Gravity is poised to elevate interactions for users and developers within Web3 while supporting the complexity and scalability needed for mass adoption.

Gravity

Gravity is an omnichain settlement layer built for mass adoption and full-chain abstraction. At its core, Gravity is constructed with advanced technologies like Zero-Knowledge Proofs, staking-powered architecture, and state-of-the-art consensus mechanisms that provide high performance, reinforced security, and transaction cost efficiency. Through its full-chain abstraction, Gravity partitions the technical complexities from end users, prioritizing user-friendliness and a seamless journey without exposing users to the intricacies of on-chain interactions.

To meet the demands of high-throughput applications, Gravity features a cross-chain settlement protocol designed to maximize the capabilities of its high-performance and fast-finality chain. This protocol allows applications to use Gravity as the settlement layer for user intents across any chain. With leading applications like Smart Savings, this feature shifts the development paradigm from private, unauditable backends to offloading mission-critical transactions onto Gravity, functioning as an open, code-is-law database.

Key Features of Gravity

• Cross-Chain Transactions: Gravity allows developers to define and settle transactions across multiple blockchains, making interactions more efficient and secure.

• Efficient Verification: Supporting cost-efficient ZKP verification, Gravity ensures that transactions are both economical and secure.

• Enhanced User Experience: Introducing cryptographic primitives like the secp256r1 curve through precompiled contracts, Gravity enables use cases such as cost-effective passkey authentication for Account Abstraction wallets, enhancing user experience.

• High-Performance Execution: Gravity integrates the fastest execution layer, Reth, and the state-of-the-art consensus algorithm Jolteon. Together, these technologies are set to provide high throughput and near-instant finality.

• Secure and Robust PoS Mechanism: Gravity’s Proof-of-Stake will be powered by the combination of G token native staking and restaking protocols including Babylon and EigenLayer. This design incentivizes and unites a cross-spectrum community to collectively safeguard the Gravity chain.

• EVM Compatibility: Gravity will be fully EVM-compatible, allowing developers to deploy and interact with smart contracts seamlessly.

Use Cases

With Gravity, we’re empowering projects to build a broad spectrum of solutions for Web3 users while tapping into the 20 million users within the Galxe ecosystem.

• Balance Abstraction with Yield: With the emergence of protocols across multiple chains, Web3 users face increasing challenges in managing their assets seamlessly. Gravity addresses this challenge by consolidating balances across all chains and ensuring cross-chain transaction settlements and verification on-chain, providing a streamlined and boundless experience.

• Intent-Based Transactions: Gravity simplifies the intricate process of navigating infrastructure-level transactions between chains. This system permits intent-based transactions, freeing users from the complexities of the underlying technical mechanics. For example, with Gravity, developers can create platforms that allow users to buy ETH on any chain with minimal slippage, without needing to worry about where or how to source the underlying liquidity.

• Gas Abstraction: With the addition of smart contract wallet support, Gravity enhances the user experience by enabling transaction batching and gas sponsorships. This eliminates the need for users to bridge tokens between chains to complete multi-chain transactions, creating a seamless omnichain experience.

• Omnichain Loyalty Points: The existing loyalty points system on Galxe Quest will be migrated to Gravity, shifting all loyalty points on-chain. With native features such as permission control, snapshot taking, and points trading, Gravity functions as the foundational layer for loyalty points marketplaces, powering fully on-chain quests.

Gravity Release

The launch of Gravity will occur in two phases. The Gravity Alpha Mainnet, a Ethereum rollup powered by the Arbitrum Nitro stack, will go live in June 2024, followed by the Gravity Mainnet in Q2 2025. The Alpha Mainnet will demonstrate Galxe’s commitment to high standards by testing cross-chain settlements in a transparent environment. The full Mainnet will feature a restaking-powered PoS Layer 1 blockchain with Reth as its EVM execution engine.

Join Us

The universe cannot exist without gravity; it’s the cosmic glue that holds everything together. Similarly, Gravity is the foundational layer that will empower the Web3 ecosystem to grow and thrive. Join us as we venture into this exciting new phase to transform the future of the Internet.

TL;DR – Highlights of Grevm 2.0

• Grevm 2.0 achieves near-optimal performance in low-contention scenarios, matching Block-STM with 16.57 gigagas/s for Uniswap workloads and outperforming it with 95% less CPU usage in inherently non-parallelizable cases by 20–30%, achieving performance close to sequential execution.

• Breaks Grevm 1.0’s limitations in handling highly dependent transactions, delivering a 5.5× throughput increase to 2.96 gigagas/s in 30%-hot-ratio hybrid workloads by minimizing re-executions through DAG-based scheduling and Task Groups.

• Introduces Parallel State Store, leveraging asynchronous execution result bundling to overlap and amortize 30-60ms of post-execution overhead within parallel execution, effectively hiding these costs within execution time. It also seamlessly handles miner rewards and the self-destruct opcode without the performance penalties of sequential fallbacks.

• In-depth analysis of optimistic parallel execution reveals the underestimated efficiency of Block-STM and the strength of optimistic parallelism, providing new insights into parallel execution.

Abstract

Grevm 2.0 integrates Block-STM with an execution scheduling mechanism based on Task Groups and a Data Dependency Directed Acyclic Graph (DAG), derived from simulated transaction execution results. Unlike Block-STM, which schedules tasks solely based on the lowest index, Grevm 2.0 dynamically schedules execution based on the DAG, prioritizing lower-index transactions with no dependencies for parallel execution while grouping strongly dependent transactions into task groups. Within each task group, transactions execute sequentially within the same thread to minimize re-executions, reduce scheduling overhead, and optimize CPU utilization. This design significantly reduces transaction re-executions in high-conflict scenarios and maximizes parallelism by enabling a parallel execution order that mirrors an optimally reordered sequence—without altering the original transaction order.

Our benchmark results demonstrate that, compared to Grevm 1.0, Grevm 2.0 achieves 5.5× higher throughput for a 30%-hot-ratio hybrid workload (Uniswap, ERC20, and raw transfers), reaching 2.96 gigagas/s. Additionally, while Grevm 2.0 matches Block-STM’s performance for low-conflict workloads, it outperforms Block-STM in extreme cases by maintaining the same performance as sequential execution—avoiding the 20–30% slowdown observed in Block-STM—while using 95% less CPU usage.

From an engineering perspective, Grevm 2.0 introduces parallel state, an asynchronous state storage mechanism that bundles final execution results in parallel. This approach elegantly addresses challenges related to miner rewards and the self-destruct opcode without compromising correctness or imposing a performance penalty when falling back to sequential execution.

In this report, we first present the design of Grevm 2.0 and its benchmark results. Then, we share rarely discussed data highlighting Block-STM's impressive optimistic execution efficiency, which we discovered during our experiments and which shaped our key design choices.

Algorithm Design

Grevm 2.0 consists of three core modules: Dependency Manager (DAG Manager), Execution Scheduler, and Parallel State Storage. It employs a DAG-driven task scheduling mechanism to:

1. Dynamically maintain the data dependency DAG using using a selective update strategy.

2. Group adjacent dependent transactions into task groups.

3. Execute task groups and the lowest-index transactions with no dependencies (i.e., out-degree of 0).

Dependency Manager and Execution Scheduler

The Dependency Manager tracks and resolves transaction dependencies during parallel execution. Like in Grevm 1.0, transactions are represented in a Directed Acyclic Graph (DAG):

Before execution, dependencies are inferred using hints—speculated read/write sets obtained from static analysis or simulation (executing transactions on the last committed state).

The Execution Scheduler manages both transaction execution and validation, following this workflow:

1. Parallel Execution: The scheduler selects and executes transactions with the smallest index from the DAG that have no dependencies (out-degree = 0). For a task group, its index is the smallest among all grouped transactions.

2. Validation: After execution, transactions enter a pending validation phase. The scheduler checks whether the read set of the smallest-index pending transaction has changed:

   • If unchanged, the transaction moves to the unconfirmed state. Consecutive unconfirmed transactions transition into finality, starting from the lowest index.

   • If changed, the transaction is marked as a conflict, reinserted into the DAG, and its dependencies are updated before re-execution.

In the worst-case scenario, where all transactions form a dependency chain, task group execution remains as efficient as serial execution. This design balances optimistic parallelism with efficient CPU utilization, while maintaining the simplicity of Block-STM's scheduling logic—avoiding excessive complexity that could degrade performance for simple, fast-executing transactions, like ERC20 and raw transfers.

Selective Dependency DAG Update Strategy

Grevm 2.0 follows a selective dependency strategy, adding only the most necessary edges to minimize DAG modifications. Dependencies are added in three scenarios:

1. Misestimated Reads: When a transaction reads estimated data that later proves changed, instead of aborting immediately and marking it as dependent, Grevm 2.0 completes execution, analyzes the actual read-write set, and adds only the most significant dependency—specifically, the highest-index transaction it depends on.

Efficient dependency removal is also crucial for balancing scheduling speed and minimizing re-executions. Dependencies can be removed at different stages, each with trade-offs:

• After Execution: Enables faster scheduling of subsequent transactions but increases the risk of re-execution if dependencies were misestimated.

• After Validation: Delays scheduling slightly but reduces unnecessary re-executions.

• After Finality: Eliminates all re-execution risks but introduces the longest scheduling delay.

Grevm 2.0 adopts a hybrid Execution + Finality strategy to achieve an optimal balance:

• Pre-execution dependencies (inferred before execution) are removed immediately after execution to maximize scheduling throughput.

• Dynamically detected dependencies (discovered during execution or validation) are removed only after finality to ensure correctness and minimize re-execution.

This strategy ensures efficient scheduling when dependency hints are accurate while mitigating re-execution overhead when hints are unreliable. Empirical results demonstrate that this hybrid approach effectively balances execution throughput and re-execution probability, delivering robust performance across diverse workload conditions.

Parallel State Storage

The Storage module implements DatabaseRef and provides two key functionalities: Parallel State and Multi-Version Memory (MvMemory). It introduces a Parallel State layer between EvmDB and MvMemory to enhance performance.

This design offers several advantages:

• Amortized Result State Building: Transactions continuously generate Reth-compatible result states, eliminating the ~30ms latency of bundling them after full block execution.

In cases where a transaction executes self-destruct, conflicts arise if later transactions attempt to access that account. The self-destruct operation updates MvMemory's write set and marks the account as self-destructed. If a subsequent transaction retrieves self-destructed account data from MvMemory, it must re-fetch the latest state from Parallel State.

Benchmark

We evaluate the Grevm 2.0 implementation with the same setup as 1.0:

• aws c7g.8xlarge 32 vCPUs @2.6 GHz

• Ubuntu 22.04.5 LTS

• cargo 1.81.0 (2dbb1af80 2024-08-20)

• Grevm git commit hash: ccf5cdc0488e8edf4dc9e86e11b8e3e595c8fd6d

• pevm git commit hash: d48fae90b6ad36ddc5d613ee28ad23214353e81e

To reproduce the benchmark, run

JEMALLOC_SYS_WITH_MALLOC_CONF="thp:always,metadata_thp:always" NUM_EOA=${NUM_EOA} HOT_RATIO=${HOT_RATIO} DB_LATENCY_US=${DB_LATENCY_US} cargo bench --bench gigagas

Replace ${NUM_EOA}, ${HOT_RATIO}, and ${DB_LATENCY_US} with the desired parameters:

• NUM_EOA: Number of accounts.

• HOT_RATIO: Ratio of transactions accessing common ("hot") account.

• DB_LATENCY_US: Simulated database latency in microseconds.

Gigagas Block Test

We conducted the same gigagas block test as 1.0, a benchmark designed to evaluate the efficiency of parallel execution under varying workloads and conditions. Each mock block contains transactions totaling 1 gigagas in gas consumption. The transactions include vanilla Ether transfers, ERC20 token transfers, and Uniswap swaps. Pre-state data is stored entirely in-memory to isolate execution performance from disk I/O variability. To mimic real-world conditions where disk I/O latency can impact performance, we introduced artificial latency using the db_latency parameter.

Conflict-Free Transactions

We first evaluated our implementation using conflict-free workloads to measure optimal performance. In this scenario, transactions consist of independent raw transfers, ERC20 transfers, and Uniswap swaps, each involving separate contracts and accounts to ensure no data dependencies. This setup provides a baseline to assess the maximum achievable performance improvement through parallel execution without the impact of transaction conflicts.

Table 1: Grevm 2.0 Conflict-Free Transaction Execution Speedup (uint = milliseconds)

Compared to Grevm 1.0, Grevm 2.0 does not achieve the same level of speedup when transaction complexity is low. This is expected, as DAG-based scheduling incurs higher overhead than 1.0’s partitioning algorithm. However, as transaction complexity increases, Grevm 2.0’s performance matches and slightly surpasses 1.0. For instance, in the Uniswap swap test with 100µs access latency, Grevm 2.0 achieves a 60.8× speedup, compared to 1.0’s 58.06×. Even in cases where 2.0 is less efficient than 1.0—such as raw and ERC20 transfers—its throughput still significantly exceeds 1 gigagas/s, making this trade-off well-suited for production workloads.

Like Grevm 1.0, Grevm 2.0 benefits from asynchronous I/O, enabled by parallel execution, further amplifying its performance advantage over sequential execution.

Additionally, with parallel state storage, all tests now include overheads that were excluded in 1.0, such as state bundling. This explains why the Grevm 1.0 benchmark results referenced here are end-to-end execution time, as reported in Table 3 of the original paper.

Contention Transactions

We uses the same setup for contention transactions as 1.0, with a hot ratio parameter to simulate contention in transaction workloads. This parameter allows us to model skewed access patterns, where certain accounts or contracts are accessed more frequently than others.

• Number of User Accounts: 100,000 accounts used in the test.

• Hot Ratio: Defines the probability that a transaction will access one of the hot accounts.

  • Hot Ratio = 0%: Simulates a uniform workload where each read/write accesses random accounts.

  • Hot Ratio > 0%: Simulates a skewed workload by designating 10% of the total accounts as hot accounts. Each read/write operation has a probability equal to the hot ratio of accessing a hot account.

We also introduced a a test set called Hybrid, consisting of

• 60% Native Transfers: Simple Ether transfers between accounts.

• 20% ERC20 Transfers: Token transfers within three ERC20 token contracts.

• 20% Uniswap Swaps: Swap transactions within two independent Uniswap pairs.

Table 2: Contention Transactions Execution Test Setup

In Grevm 1.0, the performance of high-contention transactions was constrained by their high interdependence. Grevm 2.0 significantly improves performance in high-conflict scenarios. With a 30% hot ratio, Grevm 2.0 outperforms 1.0 in all test cases except for ERC20 transfers with zero latency, where experimental variance is a factor. The most notable improvement is in the Hybrid test case, where Grevm 2.0 achieves a 29× speedup over sequential execution, which is 5.55× over Grevm 1.0, reaching a throughput of 2.96 gigagas/s.

Table 3: Grevm 2.0 Contention Transactions Execution Speedup (unit = milliseconds, hot ratio = 30%)

Non-Parallelizable Transactions

To compare the performance of Grevm 2.0 and Block-STM in inherently non-parallelizable cases, we conducted a test with transactions that are highly dependent on each other. In this scenario, transactions form a chain where each transaction depends on the previous one, making parallel execution impossible. All tests are running with db_latency = 0. Same as Grevm 1.0, we use pevm as the reference implementation for Block-STM.

Table 4: Grevm 2.0 Non-Parallelizable Transactions Test (unit = milliseconds)

In these tests, Grevm 2.0 experiences only a 5% performance degradation for ERC20 transfers and 3% for Uniswap swaps compared to sequential execution. This result is a significant improvement over Block-STM, which suffers a ~30% slowdown in similar scenarios in our benchmark (see Table 5), aligning with the worst-case benchmark results reported in the Block-STM paper.

A more impressive result is the CPU usage, sampled using pidstat. Grevm 2.0 uses only 128% CPU for ERC20 transfers and 115% CPU for Uniswap swaps, whereas Block-STM consumes 2987% and 2761% CPU, respectively. This represents a 95% reduction in CPU usage compared to Block-STM. These findings highlight Grevm 2.0's efficiency in handling inherently non-parallelizable transactions, enhancing the execution engine's resilience against worst-case transaction dependencies.

Table 5: Block-STM (pevm implementation) Non-Parallelizable Transactions Test (unit = milliseconds)

Comparison, Analysis, and Future Work

Optimistic Parallelism (Block-STM) Is MORE Efficient Than Expected

where block_txs represents the total number of transactions in the block. The following figure illustrates the relationship between conflict rate and dependency distance under fully optimistic execution, based on a 1 Gigagas block containing 47,620 normal transfer transactions:

The analysis reveals that even when dependency_distance = 1, later transactions still have a certain probability of reading the correct data from earlier ones. When dependency_distance ≥ 4, conflict rates drop significantly, showing an approximately inverse relationship with dependency distance.

This insight is highly practical: even in blocks with a high number of interdependent transactions, optimistic execution strategies (such as Block-STM) do not necessarily lead to excessive transaction re-execution. This is because transactions with greater dependency distances are less likely to conflict, minimizing performance degradation caused by re-executions. Moreover, when simple transactions—such as raw transfers and ERC20 transfers—are executed quickly, later transactions are more likely to read correct data from earlier ones. This happens because earlier transactions may have already completed execution, even when later transactions are running in parallel. Furthermore, if transaction reordering is an option, interleaving transactions with gapped dependencies can significantly improve optimistic parallelism by minimizing conflicts caused by short dependency distances.

This principle provides us the theoretical foundation for optimizing parallel execution engines, enabling maximum performance while ensuring correctness. For transactions with short dependency distances (dependency_distance ≤ 3), a more conservative scheduling strategy (e.g., Task Group) can help reduce conflicts. Meanwhile, transactions with larger dependency distances can be processed using fully optimistic execution to maximize parallelism and throughput.

Implications of Dependency Distance on DAG Scheduling

• Execution-phase updates: Lowers retries to about 5.

• Validation-phase updates: Further reduces retries to around 3.

• Finality-phase updates: Limits retries to at most 2.

Both dependency updates and transaction re-executions introduce overhead, requiring a balance where dependency_distance serves as the primary optimization metric.

In high-conflict scenarios, hints accuracy becomes particularly important. When hints are reliable, even execution-phase dependency removals can prevent conflicts, enabling faster scheduling. Conversely, inaccurate hints lead to frequent dependency DAG updates, degrading performance.

Task Group mechanism also mitigates reliance on hints accuracy. To ensure less-conflict execution even when hints are inaccurate, only transactions with dependency_distance = 1 are grouped into task groups, preserving sequential execution and minimizing performance loss.

Overall, Grevm 2.0 offers no major advantage over Block-STM in low-conflict scenarios. However, in high-conflict environments, Grevm 2.0 significantly reduces retries (lowering CPU consumption) and optimizes execution based on dependency_distance when hints are reliable.

Validation Scheduling

In Grevm 2.0, validation scheduling is slower than in Block-STM for two key reasons.

The first is straightforward: Grevm 2.0 does not execute transactions strictly in index order, whereas validation must proceed sequentially. As a result, validation often stalls, waiting for earlier transactions to complete before it can proceed, causing scheduling delays.

The second reason stems from an often-overlooked Block-STM optimization for validation. Block-STM introduces a write_new_locations flag for each transaction, indicating whether transactions have written to a new memory location. If a transaction encounters a conflict, validation_idx advances immediately to tx + 1, meaning validation does not need to wait for the conflicting transaction to be re-executed. After re-execution, if write_new_locations = false, only a single validation task is required, and validation_idx remains unchanged. It only advances when write_new_locations = true. Since this flag is rarely true after a retry, Block-STM efficiently accelerates validation by avoiding unnecessary re-validations for non-conflicting transactions.

Since validation is a prerequisite for finality, and features like remove dynamic dependency, async-commit, miner, and self-destruct all depend on finality, optimizing Grevm 2.0’s validation speed is critical.

A simple approach would be to validate transactions immediately after execution, following Block-STM’s strategy of checking the write_set of earlier transactions. However, this method also requires scanning the read_set of later transactions, which is computationally expensive. Checking the write_set of earlier transactions involves verifying only the latest written location, whereas checking the read_set of later transactions requires scanning all subsequent transactions to confirm they accessed the correct data—an inefficient process.

A more effective solution is to validate a transaction’s write_set and, if its modifications exceed the predicted range of hints, handle those out-of-range transactions using the standard validation process. However, for transactions within the hints range, their read/write sets do not require validation. Thus, optimizing Grevm 2.0’s validation speed relies heavily on hints accuracy. By dynamically refining hints and improving the validation mechanism, the system can significantly enhance performance while maintaining correctness.

Future Work

Based on the above analysis, we propose several directions for future research:

1. More efficient dependency DAG management. Our findings indicate that using a single lock—whether Rust’s standard locks or a high-performance implementation like parking_lot—can reduce scheduler and overall performance by 10-20% (~20ms, depending on transaction count and execution time)., comparing with Block-STM's neat atomic index counter, To address this, we plan to investigate lock-free data structures to enhance the DAG manager’s efficiency.

2. Optimizing validation. Inspired by Block-STM’s write_new_locations flag, we aim to develop more efficient validation algorithms using sophisticated, high-performance data structures to minimize unnecessary re-validations.

3. Empirical hints accuracy analysis. We plan to conduct a comprehensive study on hints accuracy to determine the optimal balance between hints-based scheduling and dynamic dependency updates, based on real-world data from EVM blockchains like Ethereum, BNB chain, and Base.

Authors

The Galactic G isn’t just a role—it’s a badge of honor, earned by the most passionate, dedicated, and unstoppable supporters of Gravity. It symbolizes true community, reserved for those real Gs who consistently show up, stand out, and push Gravity forward. Galactic G holders are the core genius of Gravity—early adopters, update trackers, and ultimate believers.

They don’t just keep the G staked; they keep it alive in their hearts.

Scarce and exclusive, this role brings prestige, perks, and the power to lead the charge as the voice of the community.

If you’ve got the G, you’re not just a supporter—you’re a trailblazer. Stay bold. Stay Galactic.

Communication & Engagement

To become a Galactic G and maintain your status, participation is key. Members aspiring to join this elite group must actively engage in meaningful, organic conversations within the server that inspire and motivate others.

• Discussions can range from humorous to technical but must align with community guidelines.

• Avoid repetitive or generic messages like "gm" or "hello."

• Participate in community events such as Gravity Quizzes, community calls, and more.

Galactic Gs set the standard for vibrant, engaging dialogue that fosters community growth.

Creativity & Art

Unleash your creativity and showcase your talents!

• Share original memes, art, and fun content on the server and social media platforms.

• Design stickers, emojis, GIFs, and other artwork inspired by the Gravity theme.

• Exceptional contributions may be rewarded with special recognition, perks, or roles.

Creativity is boundless—let your imagination lead the way!

Social Media Presence

Galactic G members are Gravity's ambassadors, spreading the word across social media platforms.

• Post about Gravity on platforms like X (Twitter), Medium, or Warp Cast at least twice weekly.

• High-quality posts may be highlighted or reshared by Gravity’s official accounts.

Be the voice that amplifies Gravity’s vision across the galaxy!

Community Missions

Contribute to the collective mission and shine as a Galactic G!

• Participate in general missions, which may include creating memes, artwork, or posts about collaborations.

• Engage in special weekly missions designed to challenge and inspire.

Your involvement directly shapes the community’s energy and momentum.

Pulsar Collaborative Events

Elevate your engagement and join forces with Pulsars!

• Host and organize exclusive events with Pulsar collaborators.

• Access a dedicated channel for Galactic Gs, featuring exclusive chats and missions.

This is your chance to lead, collaborate, and make an impact.

Become a Galactic G and join the ranks of those shaping Gravity’s future. Together, we’ll build something extraordinary.

Network Details

• Chain ID: 7771625

• Reset Schedule: Bi-weekly on Mondays

Developer Resources

Performance Benchmarking

Preliminary benchmarking of the Gravity L1 Devnet, conducted under controlled conditions, indicates the following baseline performance metrics:

• Block Time: 500ms

• ERC20 Transfer Throughput: More than 7,000 TPS

These results represent initial findings, with full network capabilities yet to be fully tested and optimized. Developers can expect at least this level of performance, with potential for further improvements as testing progresses.

Gravity Alpha Mainnet can be added as a custom network to any EVM-compatible wallet (i.e. MetaMask).

Network

Gravity Alpha Mainnet

• Chain ID: 1625, 0x659

• Currency Symbol / Native Token: G

• Block Explorer:

Gravity Alpha Testnet Sepolia

• Chain ID: 13505, 0x34c1

• Currency Symbol / Native Token: G

Chain Parameters

NOTE: The parameters, including gas price and gas fee, will take effect at 12:00 PM on August 20, 2024, PDT. Until that time, the chain will operate using experimental parameters for internal testing purposes. NOTE: We lowered the gas price floor from 3600 gwei to 1800 gwei, effective from 12:00 PM on August 22, 2024, PDT.

Claiming Test Tokens

The Gravity Faucet provides test tokens for both Testnet (L2) and Devnet (L1).

Request Limits

• 1 G token per address every 24 hours

• Separate limits for Testnet and Devnet

Testnet vs Devnet

How to Claim

2. Connect your wallet

3. Select network (Testnet or Devnet)

4. Request tokens

Guide

Prerequisites

1. A local directory for storing node data

2. An Ethereum Sepolia RPC endpoint with unlimited rate limit for eth_getLogs

3. An Ethereum Sepolia beacon chain RPC endpoint

4. Connection to a Celestia lightnode or public testnet RPC endpoint

Node & DAS Server Setup

1. Setup the Celestia DAS Server

   • Configuration for testnet:

   Copy

   docker run -d --rm --name celestia-das-server \
       -p 9876:9876 \
       --entrypoint /bin/celestia-server \
       ghcr.io/celestiaorg/nitro-das-celestia:v0.4.1 \
       --enable-rpc --rpc-addr=0.0.0.0 --rpc-port=9876 \
       --celestia.rpc=<YOUR_CELESTIA_TESTNET_ENDPOINT>\
       --celestia.namespace-id=<TESTNET_NAMESPACE_ID> 

2. Connect to a Celestia testnet RPC endpoint

Download Snapshot (Recommended)

Syncing a node from scratch can be extremely time-consuming and resource-intensive. We strongly recommend downloading our latest snapshot:

Running the node

Save the following script as run-gravity-testnet-node.sh, make it executable with chmod +x run-gravity-node.sh, and update the TODO variables:

#!/bin/bash

# Define dependent variables
LOCAL_DIR="TODO"                      # Replace with your local directory path
ETH_SEPOLIA_RPC="TODO"                 # Replace with your Ethereum Sepolia testnet RPC endpoint
ETH_SEPOLIA_BEACON_RPC="TODO"          # Replace with your Ethereum Sepolia beacon RPC endpoint
CELESTIA_DAS_URL="TODO"                # Replace with your Celestia DAS server URL (e.g., http://localhost:9876)

# Run the Docker container
docker run --rm -it \
    --add-host=host.docker.internal:host-gateway \
    -v "$LOCAL_DIR:/home/user/.arbitrum" \
    -p 0.0.0.0:8547:8547 \
    -p 0.0.0.0:8548:8548 \
    ghcr.io/celestiaorg/nitro:v3.3.2 \
    --parent-chain.connection.url="$ETH_SEPOLIA_RPC" \
    --chain.id=13505 \
    --chain.name=conduit-orbit-deployer \
    --http.api=net,web3,eth \
    --http.corsdomain="*" \
    --http.addr=0.0.0.0 \
    --http.vhosts="*" \
    --persistent.db-engine="pebble" \
    --chain.info-json='[
        {
            "chain-id": 13505,
            "parent-chain-id": 11155111,
            "chain-name": "conduit-orbit-deployer",
            "chain-config": {
                "chainId": 13505,
                "homesteadBlock": 0,
                "daoForkBlock": null,
                "daoForkSupport": true,
                "eip150Block": 0,
                "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
                "eip155Block": 0,
                "eip158Block": 0,
                "byzantiumBlock": 0,
                "constantinopleBlock": 0,
                "petersburgBlock": 0,
                "istanbulBlock": 0,
                "muirGlacierBlock": 0,
                "berlinBlock": 0,
                "londonBlock": 0,
                "clique": {
                    "period": 0,
                    "epoch": 0
                },
                "arbitrum": {
                    "EnableArbOS": true,
                    "AllowDebugPrecompiles": false,
                    "DataAvailabilityCommittee": true,
                    "InitialArbOSVersion": 11,
                    "InitialChainOwner": "0x218a4534C699CE35dc929ff4ca845C05Af9A57a2",
                    "GenesisBlockNum": 0
                }
            },
            "rollup": {
                "bridge": "0x946CF7F3238537e51B017369E523425A18996C23",
                "inbox": "0xe50eBd835F5f17fdEC0A547c37343F080B664357",
                "sequencer-inbox": "0x3eb7334755Fb41dC01400B15C8cC0C64B36E5969",
                "rollup": "0xDE145C4Ef9699D130848167d512dD1D09f173066",
                "validator-utils": "0xb33Dca7b17c72CFC311D68C543cd4178E0d7ce55",
                "validator-wallet-creator": "0x75500812ADC9E51b721BEa31Df322EEc66967DDF",
                "deployed-at": 5979967
            }
        }
    ]' \
    --node.data-availability.enable \
    --node.data-availability.rest-aggregator.enable \
    --node.data-availability.rest-aggregator.urls=https://das-gravity-testnet-sepolia-34ow2embsc.t.conduit.xyz \
    --node.celestia-cfg.enable=true \
    --node.celestia-cfg.url="$CELESTIA_DAS_URL" \
    --execution.forwarding-target=https://rpc-sepolia.gravity.xyz \
    --node.feed.input.url=wss://relay-gravity-testnet-sepolia-34ow2embsc.t.conduit.xyz \
    --parent-chain.blob-client.beacon-url="$ETH_SEPOLIA_BEACON_RPC"

References

For more information, please check out the following guides:

The Gravity Bridge offers cross-chain solutions for seamless asset transfers between different blockchains and the Gravity Alpha Mainnet. You can transfer assets to Gravity Alpha Mainnet through two options: our native bridge, which provides optimized transfers specifically for G, DAI, and WBTC tokens; or through our integration with LI.FI as a routing provider, which supports a wider range of ERC-20 tokens.

1. Native Canonical Bridge: Our purpose-built bridge optimized specifically for G, DAI, and WBTC tokens, providing efficient and secure transfers.

2. LiFi-Powered Multi-Token Bridge: An extended bridging solution supporting a wide range of ERC-20 tokens beyond our core assets, leveraging LiFi's cross-chain infrastructure.

Native Canonical Bridge

The native canonical bridge is designed to connect Gravity Alpha Mainnet with Ethereum. This bridge supports specific tokens:

Important Timeframes:

• Ethereum to Gravity: When bridging tokens from Ethereum Mainnet to Gravity Alpha Mainnet, you will need to wait at least 10 minutes for the bridging process to complete.

• Gravity to Ethereum: When bridging tokens from Gravity Alpha Mainnet to Ethereum Mainnet, after submitting the transaction, you will need to wait 7 days to claim the funds on the Ethereum Mainnet.

Why do I have to wait 7 days for withdrawing funds to Ethereum mainnet?

This is how all optimistic rollups work. Optimistic rollups use a mechanism called fraud proofs to ensure participants in the network remain honest. There is a "challenge period" for these proofs, where, when one party submits a claim about the state of the chain, another party has approximately 7 days to challenge that claim.

Why do I need G tokens on Ethereum mainnet when I bridge other assets to Gravity Alpha Mainnet?

LiFi Bridge Integration

Using the Bridge Interface

Step 1: Configure Source Token

• Connect your wallet

• Select your source blockchain network

• Choose the token you want to bridge

• Enter the amount you wish to exchange

Step 2: Review Destination Details

• Destination will be default set to G Token on Gravity Alpha Mainnet

• View the estimated amount you'll receive

• Check current exchange rate and price impact

Step 3: Select Bridge Route

• Compare available routes based on:

  • 💰 Expected return amount

  • ⚡ Transaction speed

  • 🏷️ Gas fees

  • ⏱️ Estimated completion time

• Choose between "Best Return" or "Fastest" options

• When you select G, DAI, or WBTC for transfer between Ethereum Mainnet and Gravity Alpha Mainnet, it will automatically use the native bridge route

Step 4: Gas Management

• Check for "Get Gravity gas" notification

• If prompted, enable this option to:

  • Automatically include required G tokens

  • Ensure sufficient gas for bridge completion

  • Cover future transactions on Gravity Alpha Mainnet

Step 5: Configure Settings (Optional)

• Click the ⚙️ icon besides the wallet button

• Adjust route priority if needed

• Select gas price (Slow/Normal/Fast)

• Choose slippage tolerance (Auto/0.5%)

Methods to Bridge Assets

1. ONCHAIN Bridge: Directly bridge tokens from other networks using our cross-chain bridge powered by LIFI protocol.

2. CEX Trading: Purchase through supported centralized exchanges

3. FIAT Purchase: Buy directly using traditional currencies

For quick bridging G token using existing liquidity pools between Gravity Alpha Mainnet <> BNB Chain <> Ethereum <> Base

Option 4: Bridge Programmatically with Arbitrum SDK

​

The Gravity Ecosystem VC Alliance is a $50 million initiative designed to support projects building on the Gravity blockchain. Backed by leading VCs and blockchain investors, it provides developers with the resources and capital needed to leverage Gravity's advanced features, such as high throughput, sub-second finality, and Restaking-Powered PoS security, to create scalable and high-performance decentralized solutions.

Eligibility Criteria

To qualify for the Gravity Ecosystem VC Alliance, projects must meet the following requirements (subject to change):

• Native Integration: Projects must build directly on the Gravity blockchain, leveraging its core features like sub-second finality and omnichain functionality.

• Ecosystem Alignment: Applicants should utilize native Gravity assets and collaborate meaningfully with existing ecosystem partners.

• Priority Focus Areas: DeFi (lending, derivatives, yield aggregators, DEXs, or bridges), payments (financial tools or payment systems), Telegram Mini Apps/Games, loyalty solutions (projects using Gravity’s Loyalty Point-as-a-Service), and onchain quests (fully decentralized gamified systems).

Approved applicants to the Ecosystem VC Alliance will gain direct access to Gravity's network of investors. Each project will receive personalized attention, with investors offering tailored support based on the project's needs and growth potential.

Application Procedure

To apply for the Gravity Ecosystem VC Alliance, follow these steps:

2. Project Screening: Gravity will source and screen projects, sharing the selected opportunities with the Alliance members.

3. Review Process: The Gravity team reviews on a rolling basis and the deadline is on the 15th (GMT+8) of every month. Applications submitted after the most recent deadline will be reviewed for the following one.

4. Sharing with the VC Alliance: The selected projects’ information is shared with the Alliance members within two weeks after the cutoff.

5. Alliance Review: Alliance members will review the projects and respond within 10-15 working days to indicate their interest.

6. Direct Communication: Projects will then engage directly with interested Alliance members to structure the deal.

The Gravity Developer Grant Program is a funding initiative designed to support developers and innovators in building applications within the Gravity ecosystem. By empowering builders, Gravity aims to enable the development of tools like decentralized applications, developer infrastructure, and community-driven projects that address user needs, encourage collaboration, and contribute to the ecosystem’s continuous growth.

Build with Gravity

Gravity invites developers and teams to join our ecosystem, utilizing our high-performance infrastructure to build scalable dApps that can drive real-world adoption. To be eligible for the Developer Grant Program, projects must meet one or more of the following criteria:

• Mainnet Availability: Projects must have a fully functional Mainnet version that is live and accessible to users.

• Clear Development Roadmap: For projects that are not yet live, a detailed go-to-market (GTM) plan is required. The plan should include development timelines, strategies for acquiring users, and clear launch goals.

Pioneering the Next Phase of Web3

The Developer Grant Program is dedicated to accelerating the development of technologies and tools that drive significant impact within the ecosystem. This includes, but is not limited to, the following key areas:

• Ecosystem dApps: Projects that build directly on Gravity.

• Infrastructure Growth: Solutions that reinforce the network, such as:

  • Wallet systems

  • Centralized exchange support for Gravity Alpha Mainnet

  • Data analytics tools and ranking platforms

  • RPC, API, and Indexer services

  • Stablecoins

  • Security and Bounty Programs: Initiatives aimed at securing the network through bug bounty programs and advanced security infrastructure.

Applying for the Developer Grant Program

• Project Background: Explain the context behind your project, including how it was built or your plan for growing your user base.

• Problem and Solution: Describe the problem your project is addressing and the solution you are proposing.

• Impact on the Gravity Ecosystem: Highlight how your project will contribute to and benefit the Gravity ecosystem.

Applications are reviewed on a rolling basis by the Gravity team. If your project aligns with our objectives, our technical team may reach out for a more in-depth discussion or to conduct due diligence. All applicants will receive application results via email. Successful applicants will work with the Gravity legal team to finalize the funding agreement.

Grant Allocation

Beyond funding, we provide extensive ecosystem support to ensure the success of your project. This includes:

• Marketing & Strategy: Access to co-marketing opportunities to boost visibility, premium client strategies, and enhanced services for Galxe quests. We also offer expert guidance for go-to-market planning and advisory.

• Exclusive Network Access: Your project will gain entry to over 6,000 partners within the Galxe ecosystem, opening doors for valuable collaborations and significant growth opportunities.

Abstract

Introduction

The development of Gravity was initially driven by the challenges we encountered with Galxe, a leading Web3 application offering a suite of services such as loyalty points, campaign NFTs, token rewards, zk-identity, and omnichain smart savings. Galxe's rapid growth has resulted in a significant volume of transactions, with its loyalty points system processing over 51.2 transactions per second and token rewards campaigns processing over 32.1 transactions per second on average. As we move towards decentralizing Galxe's backend, transitioning all its use cases to an EVM blockchain while maintaining optimal user experience became challenging. This shift highlights the necessity for a high-performance EVM blockchain capable of supporting (1) high transaction throughput, and (2) near-instantaneous finality.

Considering these performance demands, the decision to either adopt existing L2 solutions or develop a new Layer-1 chain is a critical. The core trade-off lies in the approach to achieving transaction finality: using a consensus algorithm, which defines an L1, or rollup protocols, which categorize as an L2. The trade-off is clear—L1s generally have lower theoretical throughput because of the cost of consensus algorithms. However, this also results in significantly faster time-to-finality compared to L2s. For example, with a consensus algorithm like AptosBFT, finality can be achieved in sub-second, whereas optimistic roll-ups can take up to seven days due to the challenge period. Even with using zero-knowledge proof to speed up this process, the time-to-finality remains in the order of hours. Given Gravity's need for near-instant finality—essential for Galxe user experience and particularly for the Gravity's omnichain intent protocol—we decided to develop an L1.

Moreover, while L2s offer native support for messaging with Ethereum, L1 chains like Gravity can provide comparable, and even more extensive, interoperability through the Gravity Intent Protocol and cross-chain bridges built by players of the Ethereum ecosystem. This approach not only enables seamless communication with Ethereum but also extends interoperability to other blockchain networks, enhancing the overall connectivity of the whole web3 ecosystems.

Furthermore, with the adoption of restaking protocols, bootstrapping a Proof-of-Stake (PoS) L1 blockchain is no longer as challenging as it once was. By integrating restaking protocols like EigenLayer and Babylon, L1s can tap into the vast staked value of Ethereum and Bitcoin, and their extensive validator networks. The economic trust provided by these restaking protocols from the outset serves as a solid foundation for PoS consensus, enabling Gravity to achieve similar levels of decentralization and security to that of Ethereum.

In light of these considerations, we decided to build Gravity, a high-performance EVM-compatible layer-1 blockchain, to meet the scalability and performance demands of modern web3 applications. Although the development of Gravity was initially driven by the needs of Galxe, the Gravity SDK and Grevm (Gravity EVM) are designed to offering a flexible framework for building alternative L1s and faster-finality L2s, just like Tendermint/Cosmos SDK.

Call for 1 gigagas per second throughput

The most critical performance requirement for any blockchain is its throughput, typically measured in transactions per second (TPS) or gas per second (gas/s). Using Galxe's loyalty points system as an example, the system demands a minimum throughput of 4 million gas/s to function effectively. This estimate is based on the average gas usage per loyalty point transaction (80,000 gas) and the observed transaction rate of 51.2 transactions per second, which collectively equates to 4 million gas/s.

This estimate is further validated by real-world data from Gravity Alpha Mainnet, our experimental Layer 2. All loyalty points transactions on Gravity Alpha Mainnet have consistently demonstrated a throughput of approximately 4 million gas/s, confirming the above estimation.

One of the critical parts of achieving such throughput is the parallel EVM. We have developed Grevm, a parallel EVM execution runtime, which is the fastest open-source parallel EVM implementation to date in our benchmark (see more details in the Grevm section below).

Sub-Second Finality

In addition to throughput, the blockchain's finality time is a critical factor in maintaining a positive user experience. Users expect near-instantaneous responses similar to what they experience with centralized backends, just like web2 apps. In this regard, Galxe's requirements are akin to those of fully on-chain games, where low latency is crucial, though not as extreme. Current EVM blockchains, with time-to-finality ranges from several seconds to days, are far from meeting these expectations. We choose AptosBFT as the consensus algorithm choice for achieving such sub-second finality.

While L2 rollup can theoretically achieve higher throughput by eliminating the need for consensus, they typically introduce significant delays in finalizing transactions due to the challenge period. This latency is problematic for applications requiring near-instantaneous finality, like Galxe. Some DApps, such as cross-chain bridges, attempt to mitigate this by using "trust" modes, implementing external monitoring systems—like running a sequencer replica to check invariance—and bypassing the challenge period. However, these approaches introduce additional risks and complexities, which is not ideal for security-critical applications. To narrow the throughput gap between L2 rollup and L1, after introducing consensus, the Gravity SDK implemented a 5-stage pipeline, which parallelizes consensus for the next block and execution for the current block (see more details in the pipelining section).

Restaking PoS security

Scaling Ethereum securely is not limited to L2 rollup. The Gravity SDK deliberately opts for a restaking-secured L1 architecture to balance security, throughput, time-to-finality and interoperability. Central to this strategy is a restaking module that integrates multiple restaking protocols, such as EigenLayer and Babylon, which provide the economic trust necessary to bootstrap and sustainably power a robust Proof-of-Stake (PoS) consensus.

By leveraging economic trust that is programmable on well-established networks, Gravity and chains built on Gravity SDK tap into: (1) Ethereum's $45 billion in staked value and 850,000 validators through building an Actively Validated Service (AVS) on Ethereum, based on EigenLayer, and (2) Bitcoin's $600 billion assets via Babylon's integration, using cryptographic primitives like extractable one-time signature (EOTS). This provides a secure foundation for PoS consensus from the outset, by extending security from well-established networks like Ethereum and Bitcoin, effectively addressing the typical challenges of bootstrapping new PoS blockchains, long-range attacks, and potential risks associated with any single assets like long-term sustainability.

Gravity Chain Architecture

Gravity Chain is built on two major components: Gravity SDK and Gravity reth. Gravity SDK is a blockchain framework refined from the Aptos chain, the state-of-the-art PoS blockchain of the PBFT-family consensus, featuring a pipelined architecture that maximizes throughput and resource utilization. Gravity reth is a pipelined execution layer based on reth, running as a Block Stream Reactor (BSR), consuming the proposed blocks from the consensus layer. By innovating with reth, it is optimized for parallel execution, batched and asynchronous paralleled state commitment computation, and storage optimization. Two components are glued together via Gravity Consensus Engine Interface (GCEI) using a reth adaptor, seamlessly managed by a pipeline controller, which will dynamically adjust the pace of each stage based on the multiple backpressure signals from execution and consensus layer.

In this design, the block execution is decoupled from the block consensus, making execution layer a consumer of the proposed blocks. We optimize reth to make it fit into this pipelined block proposal process, managed by the Block Stream Reactor (BSR).

The flow of a transaction in Gravity Chain is as follows:

1. A transaction will first reach Gravity reth JSON RPC, a fully Ethereum-compatible JSON-RPC endpoint.

2. The transaction is then forwarded to Gravity SDK mempool, propagating across the network. Validators will try to batch transactions and form Quorum Store (QS) certificates.

3. The Leader of the round will propose a new block proposal, containing block metadata and ordered transactions picked mempool and quorum store.

4. Once the block proposal status become ordered, it will be passed to the execution layer.

5. On the execution layer side, Grevm will execute the transactions in parallel and generate execution results. The new state will be pass to state commitment and multi-version state manager.

6. The state commitment box will compute the state root and pass it to state consensus engine, which will try to reach a consensus on the state root.

7. Once the state root is finalized, it will notify execution storage to persistent the state root and the block data.

We will dive into the details of each component in the following sections.

Gravity SDK: The First Open Source Pipeline Blockchain SDK

Gravity SDK is an open-source, modular blockchain framework that builds upon the world's most production-ready blockchain, Aptos. It is designed to modularize the existing architecture of the Aptos blockchain, borrowing battle-tested components such as the mempool with Quorum Store, the AptosBFT consensus engine to create a the world's first pipelined blockchain SDK.

The decision to base Gravity SDK on Aptos stems from several key factors:

• Performance Optimized for Extreme Demands: Aptos has been meticulously optimized for performance, achieving an impressive throughput of roughly 160,000 transactions per second with a finality time of under one second.

• Battle-Tested Reliability: Aptos has already proven its reliability and robustness through real-world deployment in production environments, demonstrating its ability to handle demanding workloads with ease.

• Avoiding Reinvention: Building on Aptos allows us to leverage its mature and well-tested foundation, avoiding the unnecessary complexities and risks associated with starting from scratch. Other attempts to outperform Aptos by reinventing the wheel lack both theoretical grounding and convincing innovations.

• Synergetic Evolution Aptos is a continuously evolving project, introducing features like the randomness API and other cutting-edge capabilities. By integrating closely with Aptos, Gravity SDK ensures that these innovations can be seamlessly incorporated, creating a synergistic relationship between Aptos and chains built on Gravity SDK, e.g. Gravity Chain. On the other hand, Gravity SDK also contributes back to Aptos, by modularizing the structure and introducing restaking-powered PoS security modules.

Blockchains built on Gravity SDK uses the Gravity Consensus Engine Interface (GCEI) to interact with the pipelined consensus engine. This interface is designed to be compatible with any execution layer, although Gravity SDK offers primary support around Gravity reth. We will dive into more details GCEI in the following section.

Gravity Consent Engine Interface (GCEI)

The GCEI (Gravity Consensus Execution Interface) protocol is the communication bridge between the consensus and execution layer. It standardizes the interaction between the two layers, ensuring that consensus and execution processes are properly synchronized by the pipeline controller.

The major difference between the traditional blockchain SDK and Gravity SDK is its pipelined consensus engine. The execution layer must be implemented as a Block Stream Reactor, which means that the it must be able to continuously consume the proposed block stream, and the state commitment must be computed asynchronously from the transaction execution. Moreover, the execution layer must be able to provide backpressure signals to the consensus layer, which will dynamically adjust the pace of block proposing.

Besides, due to the pipelined nature of the Gravity SDK, the execution layer must be able to handle the un-executable transactions in the proposed block, as the mempool does not have the ability to strictly check the validity of any transaction due to lack of access to the newest world state: the execution might have not been finished yet. Also, the execution result, should not block further block generation, as after the Gravity SDK paralleled the block consensus and state consensus, the execution layer becomes a reactor to the proposed block stream, having the freedom to return the execution result in a later 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 react to the blocks proposed by the consensus engine, and submit the state commitment.

• Execution Layer APIs: These APIs must be implemented by the execution layer. Consensus engine will use these APIs to do best-effort validation of a transaction before proposing it in a block, stream proposed blocks, and notify the execution layer of the finalized state commitment.

In the perspective of the lifecycle of a transaction, the GCEI protocol defines the following:

1. check_txn (Execution Layer API)

   • Input: Takes a transaction (GTxn) as input

   • Output: Returns the sender address, nonce, and gas limit of the transaction.

   • Usage: This method is used by the consensus engine to run best-effort validation of a transaction before proposing it in a block. The method can be called multiple times for the same transaction, e.g., when the transaction enters the mempool, before it is proposed in a block, and when a state commitment is finalized.

2. submit_txn (Consensus Layer API)

   • Input: Accept a transaction (GTxn) from execution layer.

   • Output: Returns Result<()>, indicating whether the transaction was successfully added to the mempool.

   • Usage: Execution layer can use this method to submit a transaction to the mempool. The consensus engine will then gossip the transaction across the network, and form Quorum Store if a batch of transactions is received.

3. recv_ordered_block (Execution Layer API)

   • Input: Accepts an ordered_block (of type BlockBatch), which contains ordered transactions and block metadata.

   • Output: Returns Result<()>, indicating whether the block received and accepted by the execution layer.

   • Usage: Once a block is proposed by the consensus engine, it is sent to the execution layer for transaction execution. This method allows the execution layer to receive and process the ordered block.

4. update_state_commitment (Consensus Layer API)

   • Input: State commitment of a block number (StateCommitment).

   • Output: Returns Result<()>, indicating whether the state commitment was successfully accepted by local consensus engine.

   • Usage: Once state commitment is computed by the execution layer, it is sent to the consensus layer for finalization, i.e., reaching a 2f+1 light consensus with other validator. If the statement commitment consensus became falling far from proposed blocks, the pipeline controller will adjust the pace of block proposing.

5. commit_block_hash (Execution Layer API)

   • Input: Takes a vector of block_ids, representing blocks that are to be committed.

   • Output: Returns Result<()>, indicating the success or failure of the operation.

   • Usage: When the state commitment is finalized, consensus layer will notify the execution layer to commit the block hash to the blockchain storage.

Blockchain Pipeline

Gravity SDK utilizes a 5-stage pipelined architecture to maximize hardware resource utilization, for higher throughput and lower latency. The pipeline interleaves the execution of tasks across different blocks, and the pipeline manager ensures that the blockchain is moving at a steady pace using feedback mechanisms. The first three stages are part of the consensus layer, while the last two stages are part of the execution layer.

Stages are as explained as follows:

• Stage 2: Block Metadata Ordering: This stage establishes a consistent and agreed-upon order of transactions and block metadata within the network. The consensus mechanism (AptosBFT) follows the 2-chain rule to provide a Byzantine fault-tolerant block. The block will then be streamed to the execution stage, ready for parallel processing.

• Stage 3 (BSR): Parallel Transaction Execution: This stage is actually part of the execution layer, where transactions are executed in parallel. The execution results are then passed to the state commitment stage.

• Stage 4: State Commitment: This stage finalizes the state changes resulting from transaction execution and prepares for block finalization. The state commitment is computed asynchronously from the transaction execution, ensuring that the execution of the next block is not blocked by the state commitment of the current block.

• Stage 5: State Persistence: This stage persists the committed state changes to the blockchain's storage. The finalized State Root and associated data are stored in the Gravity Store, which uses a highly optimized storage engine designed for fast access and reliability. It also notifies the mempool and quorum store to clear transactions that can no longer be included in future blocks.

Staking & Restaking Module

Bootstrapping a secure Proof-of-Stake (PoS) Layer 1 blockchain is a complex challenge, particularly when relying solely on staking chain-specific tokens. Such an approach may not provide sufficient economic security to protect the network, especially during the initial phases when the token value may be volatile and validator participation might be limited. To address this issue, the Gravity SDK introduces a flexible staking and restaking Module designed to enhance network security through both native and external staking mechanisms.

In addition to supporting restaking assets, the module also accommodates staking of custom ERC20 tokens on supported chains, such as G token on Ethereum. Validators can stake allowed tokens to participate in consensus, contributing to the network's security. The voting power of each validator is calculated based on their total staked value, which includes both custom token stakes and assets from restaking protocols. This calculation adheres to chain-specific configurations, ensuring that each chain can define its staking and restaking parameters according to its unique requirements.

The epoch manager within the consensus engine interacts directly with the staking module to calculate the weight of the next validator set. By reading the staked values from the execution layer, it ensures that the consensus process accurately reflects the most recent staking activities. In this design, cross-chain values, such as the amount of staked assets from Ethereum, must be first bridged to the execution layer, before they are then used to calculate the total staked value of each validator. We leave this bridging mechanism to the execution layer, as it is more flexible for the execution layer to handle cross-chain communication in their preferred ways. PoS-bridge, zero-knowledge proof of chain state, and embedded self-bootstrapping cross-chain messaging are all possible solutions.

Further technical specifications, API design and comprehensive details of the staking and restaking mechanisms will be provided in forthcoming documentation releases.

Gravity Reth: A Block Stream Reactor EVM Execution Layer

Integrating an Ethereum Virtual Machine (EVM) execution layer into the Gravity SDK architecture presents a unique set of challenges, particularly when aiming to fully exploit the capabilities of its pipelined consensus engine. To achieve seamless integration and unlock the full potential of this architecture, we must perform several key optimizations on reth, the open source Ethereum client. These optimizations fundamentally transform reth into Gravity reth, a pipeline-optimized EVM execution layer tailored for pipelined consensus engines.

Traditional blockchain architectures process blocks sequentially, ensuring that each block is fully validated and executed before the next is proposed. However, the Gravity SDK employs a pipelined consensus mechanism that decouples various stages of block processing to enhance performance. This paradigm shift introduces complexities:

1. Unexpected Transactions: In a pipelined chain, the mempool lacks access to the most recent world state because the execution of prior blocks may not have completed. Consequently, transactions included in proposed blocks might be un-executable at the time of proposal, as their validity cannot be strictly verified without the latest state.

2. Non-Blocking Execution Results: To prevent pipeline stall, the execution results should not stop subsequent block generation. The execution layer must be capable of processing proposed blocks asynchronously, returning execution outcomes at a later stage without stalling the consensus process. For EVM, this means that we need an alternative definition of blockhash, removing the dependency on the stateRoot field of the block header.

To address these challenges, we introduce four pivotal optimizations:

• Block Stream Reactor (BSR): The BSR is designed to adapt reth to the pipelined block proposal process of the Gravity SDK. It enables the execution layer to continuously consume a stream of proposed blocks, functioning as a reactor that processes blocks asynchronously. The BSR establishes a dynamic feedback loop with the consensus engine, incorporating proper backpressure signals. These signals adjust the pace of block proposals and state commitments in real-time based on the execution layer's throughput and latency. If the execution layer lags due to complex transactions or resource constraints, the backpressure mechanism throttles the block proposal rate, ensuring system stability.

• Decoupling State Commitment from Transaction Execution: The second optimization involves separating the computation of state commitments from transaction execution. By decoupling these processes, we enable asynchronous state commitment computation, allowing the execution of subsequent blocks to proceed without waiting for the finalization of the current block's state commitment. We changed the definition of blockhash to remove the dependency on the stateRoot field of the block header, ensuring that state root computation do not block further block generation.

• Optimization of the Storage Layer: Efficient caching and persistence of multi-version state values and state commitments is critical in a pipelined architecture. The third optimization focuses on enhancing the storage layer to handle these requirements without introducing bottlenecks. By fine-tuning the storage mechanisms, we ensure that state data can be written rapidly and retrieved highly concurrently. This involves building a multi-version storage engine and support asynchronous I/O from the database to storage API.

• Parallel EVM: The final optimization involves parallelizing the execution of transactions within the EVM. We have developed Grevm, a parallel EVM runtime that significantly accelerates transaction processing by executing transactions concurrently. . Grevm leverages data dependency hints derived from transaction simulations to optimize parallel execution, minimizing transaction re-executions and enhancing throughput.

Grevm (Gravity EVM) - Parallel EVM Execution

In our benchmark, Grevm stands as the fastest open-source parallel EVM implementation to date. For conflict-free transactions, Grevm is 4.13× faster than sequential execution, running at 26.50 gigagas/s. If we simulate real-world I/O latency of 100 μs, it is 50.84× faster than sequential execution, with 6.80 gigagas/s throughput. This leap in performance is attributed to both the parallelized execution and the integration of asynchronous I/O operations—enabled by the parallelism—which further amplifies the speedup by efficiently overlapping I/O operations.

The seminal idea behind Grevm is to leverage the data dependency between transactions, using speculated transactions read/write set, to optimize parallel execution. While not all hints are perfectly precise, these simulation-based hints are generally accurate enough for practical purposes. For instance, on the Ethereum mainnet, by historical gas usages, approximately 30% of transactions are simple Ether transfers, and another 25%-30% are ERC20 token transfers, which typically involve reading and writing to a limited number of accounts and storage slots. In such transactions, simulation results are consistently accurate.

Building upon these insights, we have developed a three-phase parallel execution framework for Grevm, a follow-up work of Block-STM model by incorporating data dependency hints from transaction simulations:

• Phase 1: Hint Generation & State Preloading—Simulate transactions to gather dependency hints and warm-up memory cache. This phase can be performed at various points in time, depending on the design of the blockchain. For example, when new transactions arrive in the mempool, simulations can be run immediately to prepare dependency hints in advance.

• Phase 2: Dependency Analysis—Transform the dependency hints gathered during the simulation phase into a DAG that models the dependencies between transactions. This DAG serves as a roadmap for scheduling transactions in the subsequent parallel execution.

• Phase 3: Concurrent Execution with Conflict Resolution—Execute transactions in parallel using a modified BlockSTM algorithm that leverages the dependency DAG generated in Phase 2. Instead of the scheduler selecting transactions strictly based on their sequence numbers in the block (e.g., 1, 2, 3, ..., n), it now prioritizes transactions according to the DAG to minimize conflicts and reduce the need for re-executions.

Asynchronous Batched State Commitment

To address these challenges, the proposed framework introduces the following key innovations:

Asynchronous Batched Hash Computation: Leveraging the decoupling of state commitment consensus from transaction execution, the framework enables asynchronous computation of state commitments. State root updates are batched—e.g., computed every 10 blocks—to reduce the frequency of state root calculations. This batching approach minimizes the overhead of frequent updates and reduces overall computational costs by aggregating shared dirty nodes for efficient hash computation. For small blocks, batching can significantly increase its parallelism, and for large blocks, it can reduce the overall computational cost.

Full Parallelization: The framework extends parallelization beyond individual account trees the whole state tree. For nodes marked as "dirty," the framework employs a Parallel State Calculation algorithm, which partitions the tree into independent subtrees. These subtrees are processed concurrently. The results are aggregated at the top level to compute the final root efficiently. This approach ensures that large blocks, with numerous transactions and state changes, can fully utilize multi-threading, maximizing throughput.

Alternative Fast State Root: To accommodate Ethereum's block header and BLOCKHASH opcode, which require access to the last 256 block state roots, we redefined the state root. Instead of relying on finalized state commitments—which are unavailable during transaction execution—we calculate the state root as the hash of the block's change sets combined with the previous state root. This approach enables faster state root computation without waiting for full state commitment finalization.

Gravity Store

High-performance blockchains require a more efficient storage layer to manage the vast amount of data generated by transaction execution and state commitment. The Gravity Store, a fine-tuned multi-version storage layer, builds on the foundation provided by reth, which already separates the state commitment store from the state storage store to mitigate state bloating and lower read/write amplification. However, additional demands arise to support parallel execution and asynchronous state commitment in the Gravity reth execution layer.

To address these requirements, the Gravity Store introduces a highly efficient multi-version tree to facilitate the unique needs of our BSR architecture. It is used to manage state updates across multiple versions. Instead of recalculating hashes immediately after modifications, altered nodes are marked as dirty, allowing for deferred and batched hash computation against specific tree versions. This structure supports efficient operations like creating new versions, querying values from specific versions, and deleting versions below a certain height, thereby offering significant performance benefits for managing blockchain state.

Conclusion

Gravity Chain is a high-performance EVM-compatible layer-1 blockchain designed to meet the scalability and performance demands of modern web3 applications. By combining the Gravity SDK, a pipelined AptosBFT PoS consensus engine, and Gravity reth, a Block Stream Reactor execution layer powered by Grevm, Gravity offers 1 gigagas per second throughput, sub-second finality, and restaking-powered PoS security. These components are designed to empower web3 applications to launch their own alternative L1s and faster-finality L2s, specifically optimized for EVM chains.

Guide

Prerequisites

1. A local directory for storing node data

2. An Ethereum mainnet RPC endpoint with unlimited rate limit for eth_getLogs

3. An Ethereum beacon chain RPC endpoint

4. Connection to a Celestia lightnode or public RPC endpoint

DAS Server Setup

1. Setup the Celestia DAS Server

   • Configuration for mainnet:
2. Connect to a Celestia RPC endpoint

   • Or setup your own Celestia lightnode

Download Snapshot (Recommended)

Syncing a node from scratch can be extremely time-consuming and resource-intensive. We strongly recommend downloading our latest snapshot:

2. Extract the snapshot to your local directory before running the node.

In our experiment, syncing from scratch without using snapshots will take 12-15 days for Gravity Alpha Mainnet. The experiment was done in March 2025, when the block height of Gravity Alpha Mainnet is around 51,413,000.

Running the Node

Save the following script as run-gravity-node.sh, make it executable with chmod +x run-gravity-node.sh, and update the TODO variables:

Additional Information

• The chain info is obtained from Conduit:

• Relay endpoint is provided by Conduit as wss://relay-gravity-mainnet-0.t.conduit.xyz

• Gravity Alpha Mainnet uses Anytrust DA, with aggregator URL: https://das-gravity-mainnet-0.t.conduit.xyz

• Celestia namespace for Gravity mainnet: 0000047d50b18e30e965

References

For more information, please check out the following guides:

Introducing Grevm

In our benchmark, Grevm stands as the fastest open-source parallel EVM implementation to date. For fully parallelizable transactions, Grevm is 4.13× faster than sequential execution, running at 26.50 gigagas/s. If we simulate real-world I/O latency of 100 μs, it is 50.84× faster than sequential execution, with 6.80 gigagas/s throughput. This leap in performance is attributed to both the parallelized execution and the integration of asynchronous I/O operations—enabled by the parallelism—which further amplifies the speedup by efficiently overlapping I/O operations.

This marks our first step toward the broader vision of Gravity Chain and Gravity SDK—an open-source, high-performance Layer 1 blockchain toolkit. Grevm is a critical component of this vision, serving as the execution runtime that enables Gravity Chain to achieve a throughput of 1 gigagas per second, essential for supporting the next generation of Web3 applications. Together, they provide a modern toolkit for launching restaking-secured, high-performance EVM Layer 1 solutions, effectively scaling Ethereum.

Grevm 1.0 is still a PoC implementation, where its known limitations are discussed in the following sections. We are currently working on the next version of Grevm 2.0, which will be release soon in December 2024.

Technical Design

Figure 1: Ideal Parallel Execution

Before diving into the specifics of our algorithm, it's instructive to consider what an ideal parallel execution would look like. Figure 1 illustrates this perfect scenario, where transactions are processed in parallel without conflicts, effectively maximizing throughput and resource utilization.

Consider a sequence of transactions ordered as Tx₁, Tx₂, ..., Txₙ. The ideal process involves:

1. Precise Analysis of Transaction Dependencies:

   • Transaction dependencies are accurately analyzed and represented using a Directed Acyclic Graph (DAG), which captures the data (read-after-write) dependencies between transactions.

   • Specifically, a transaction Txⱼ depends on Txᵢ (where j > i) if and only if Txⱼ reads from a storage slot that Txᵢ writes to. This indicates a true read-after-write dependency.

   • Example: If Tx₃ reads ERC20 balance of Alice that Tx₂ would modify, Tx₃ must wait for Tx₂ to complete, ensuring data consistency.

2. Optimal Distribution of Transactions Across Threads:

   • The scheduler optimally distribute transactions across multiple threads, balancing the computational (CPU-intensive) and input/output (I/O-intensive) workloads.

3. Parallel Execution on Software Transactional Memory (STM) System:

   • A high-performance STM provides multi-version state access to each thread

   • During execution, each transaction can read the writes of all preceding transactions but not those of subsequent ones, effectively avoiding write-after-read hazards.

   • Write-After-Write Conflict Resolution:

     • If multiple transactions write to the same storage slot, the STM resolves the conflict by using the value from the transaction with the highest sequence number (i.e., the latest transaction in the sequence).

     • This ensures that the final state reflects the correct order of transactions as intended in the original sequence.

However, achieving this ideal in live block execution contexts—such as running a validator node or performing block synchronization—is challenging due to several factors:

• Unpredictability of Transaction Interactions: The precise data dependencies and resource requirements of each transaction are difficult to determine without sequentially executing them, due to the dynamic nature of high-contention transactions, e.g., DEX swaps.

• Real-Time Analysis Overhead: Performing exact dependency analysis in real-time introduces significant computational overhead, potentially negating the benefits of parallel execution.

Recognizing these limitations, our approach leverages transaction simulation results obtained by running each transaction against the most recent available state view before execution. These simulations provide estimates of which storage slots a transaction will read or write, which serves as input to build the data dependency DAG. These hints can be computed before parallel execution, avoiding introducing additional computational overhead during execution.

Screenshot 1: Ideal Parallel Execution

While not all hints are perfectly precise, these simulation-based hints are generally accurate enough for practical purposes. For instance, on the Ethereum mainnet, by historical gas usages, approximately 30% of transactions are simple Ether transfers, and another 25%-30% are ERC20 token transfers, which typically involve reading and writing to a limited number of accounts and storage slots. In such transactions, simulation results are consistently accurate.

Building upon these insights, we have developed a three-phase parallel execution framework for Grevm, a follow-up work of Block-STM model by incorporating data dependency hints from transaction simulations:

• Phase 1: Hint Generation & State Preloading—Simulate transactions to gather dependency hints and warm-up memory cache. This phase can be performed at various points in time, depending on the design of the blockchain. For example, when new transactions arrive in the mempool, simulations can be run immediately to prepare dependency hints in advance.

• Phase 2: Dependency Analysis—Transform the dependency hints gathered during the simulation phase into a DAG that models the dependencies between transactions. This DAG serves as a roadmap for scheduling transactions in the subsequent parallel execution.

• Phase 3: Concurrent Execution with Conflict Resolution—Execute transactions in parallel using a modified BlockSTM algorithm that leverages the dependency DAG generated in Phase 2. Instead of the scheduler selecting transactions strictly based on their sequence numbers in the block (e.g., 1, 2, 3, ..., n), it now prioritizes transactions according to the DAG to minimize conflicts and reduce the need for re-executions.

Implementation and Evaluation

Grevm 1.0: A Proof-of-Concept Implementation

Figure 2: Grevm 1.0 PoC Implementation

This initial implementation focuses on testing our hypotheses while minimizing engineering complexity. Despite its known limitations, Grevm 1.0 has demonstrated significant performance improvements in parallel transaction execution.

The three phases of our framework are executed iteratively across multiple rounds (see Figure 2). This iterative approach simplifies the engineering effort and allows for flexible experimentation. For each round, the above three phrases is implemented as the following:

1. Hint Generation

   • First Round: We simulate each transaction against the last known state to gather initial dependency hints, specifically the read and write sets.

   • Subsequent Rounds: Instead of re-simulating, we use the read and write sets obtained from the previous round's execution.

2. Dependency Analysis

   • Dependency Graph Construction: We construct a dependency graph based on the read and write sets of transactions based on hints.

   • Partitioning Transactions: We break the DAG into Weakly Connected Components (WCCs). Each WCC represents a group of transactions that are interdependent and must be considered together to avoid conflicts.

   • Greedy Partitioning Algorithm: We assign these WCCs to partitions using a greedy algorithm

     • The number of partitions is set to 2 × number of CPU cores + 1 to maximize parallelism.

     • Each transaction is assigned a weight based on the estimated gas usage.

     • We aim to distribute the total weight evenly across partitions.

3. Concurrent Execution

   • Execution: Each partition is executed independently and in parallel using its own executor. Within each partition, transactions are executed sequentially to respect intra-partition dependencies. After all partitions complete execution, we attempt to merge the changesets from each partition into a single state.

   • Validation: We validate transactions by comparing their read sets against the writes from other partitions. Transactions are classified into three states:

     • Finalized: No conflicts detected, and transaction IDs are sequentially continuous from the last finalized transaction.

     • Unconfirmed: No conflicts detected, but transaction IDs are not sequentially continuous.

     • Conflict: Conflicts are detected; these transactions require re-execution.

   • Merge: If all transactions are finalized, exit. Otherwise, we merge all finalized transaction into a new state, and go back to step 1 with the remaining unconfirmed and conflict transactions, with their read/write set as the updated speculation.

The above phases are repeated for up to three rounds. If convergence (i.e., all transactions being finalized) is not achieved after three rounds, we fallback to sequential execution for the remaining transactions.

Despite its advantages, our simplified implementation has known limitations. By partitioning based on Weakly Connected Components (WCCs), we treat all data dependencies within a WCC as transitive across all included transactions, which is overly restrictive. For example, with a hot ratio of 30%—meaning 30% of transactions access a set of common storage slots—about half of the transactions may be grouped into a single WCC. This significantly limits parallelism, often reducing it to two or fewer concurrent partitions, underutilizing available resources. Additionally, if dependency hints are highly inaccurate, the system may fail to resolve conflicts after three rounds of parallel execution and revert to sequential execution, resulting in worse performance compared to algorithms like BlockSTM, which experience only about a 30% slowdown in their worst-case scenarios in their benchmark.

Evaluation

We evaluate the 1.0 implementation with the following setup:

• gcloud n2d-standard-32 32 vCPUs @2450MHz

• Ubuntu 20.04.6 LTS

• cargo 1.81.0 (2dbb1af80 2024-08-20)

• Grevm git commit hash: ef3f2cb7b43a37f0acd69798d99678a1f1784f62

• pevm git commit hash: d48fae90b6ad36ddc5d613ee28ad23214353e81e

To reproduce the benchmark, run

Replace ${NUM_EOA}, ${HOT_RATIO}, and ${DB_LATENCY_US} with the desired parameters:

• NUM_EOA: Number of accounts.

• HOT_RATIO: Ratio of transactions accessing common ("hot") account.

• DB_LATENCY_US: Simulated database latency in microseconds.

Gigagas Block Test

We conducted the gigagas block test, a benchmark designed to evaluate the efficiency of parallel execution under varying workloads and conditions. We reused some portions of the benchmarking code from pevm. Each mock block contains transactions totaling 1 gigagas in gas consumption. Note that we use the actual gas consumption of transactions to calculate the total gas, which accounts for the gas refunds. The transactions include vanilla Ether transfers, ERC20 token transfers, and Uniswap swaps. Pre-state data is stored entirely in-memory to isolate execution performance from disk I/O variability. To mimic real-world conditions where disk I/O latency can impact performance, we introduced artificial latency using the db_latency parameter.

Conflict-Free Transactions

We first evaluated our implementation using conflict-free workloads to measure optimal performance. In this scenario, transactions consist of independent raw transfers, ERC20 transfers, and Uniswap swaps, each involving separate contracts and accounts to ensure no data dependencies. This setup provides a baseline to assess the maximum achievable performance improvement through parallel execution without the impact of transaction conflicts.

Table 1: Grevm 1.0 Conflict-Free Transaction Execution Speedup

Under conflict-free conditions, parallel execution with Grevm 1.0 showed significant speedup compared to sequential execution, especially when simulated I/O latency was introduced. For raw transfer, we observed a 4.13x speed up and when DB access latency is 100us, we achieved a 50.84x speedup. Similar results can be found for ERC20 transfers and uniswap swaps.

Figure 3: IO Latency v.s. Speedup, Hot Ratio = 0%

The introduction of I/O latency amplified the performance advantages of parallel execution. While sequential execution suffers from increased latency due to its linear processing nature, parallel execution mitigates this effect by overlapping I/O operations across multiple threads. See Figure 3.

Table 2: pevm Benchmark Result of Conflict-Free Transaction Execution

We noticed that some transactions in our benchmark may refund gas, e.g. when ERC20 balances become zero. The refunded gas are not accounted for in the total gas in our case, which may lead to a slight discrepancy in the throughput calculation with pevm. We will conduct a more detailed analysis in the future.

For a fair comparison, The above test result of Table 1 excludes certain overheads

• State Bundling: The time spent creating bundle states from cache states is not included, as this is a necessary step for interfacing with the reth API but is not present in other implementations' benchmarks.

• Initial Hint Parsing and Partitioning: When integrated with pipelined blockchain, the time taken for the initial simulation and transaction partitioning is also excluded, because they will be ready before the start of execution.

But even with the above overheads, the total speedup is still considerably significant, especially when DB latency is non-zero, see Table 3.

Table 3: Grevm 1.0 Conflict-Free Transaction E2E Total Speedup

Contention Transactions

In this gigagas block test, we introduce the concept of a hot ratio to simulate contention in transaction workloads. This parameter allows us to model skewed access patterns, where certain accounts or contracts are accessed more frequently than others.

• Number of User Accounts: 100,000 accounts used in the test.

• Hot Ratio: Defines the probability that a transaction will access one of the hot accounts.

  • Hot Ratio = 0%: Simulates a uniform workload where each read/write accesses random accounts.

  • Hot Ratio > 0%: Simulates a skewed workload by designating 10% of the total accounts as hot accounts. Each read/write operation has a probability equal to the hot ratio of accessing a hot account.

We also introduced a a test set called Hybrid, consisting of

• 60% Native Transfers: Simple Ether transfers between accounts.

• 20% ERC20 Transfers: Token transfers within three ERC20 token contracts.

• 20% Uniswap Swaps: Swap transactions within two independent Uniswap pairs.

Table 4: Contention Transactions Execution Test Setup

Table 5: Grevm 1.0 Contention Transactions Execution Speedup (hot ratio = 0%)

Table 6: Grevm 1.0 Contention Transactions Execution Speedup (hot ratio = 10%)

Table 7: Grevm 1.0 Contention Transactions Execution Speedup (hot ratio = 30%)

Figure 4: Hot Ratio v.s. Speedup

Figure 5: Hot Ratio v.s. Speedup, Latency=100us

When the hot ratio is 0%, representing a uniform workload, Grevm 1.0 maintains high levels of parallelism and shows significant performance improvements over sequential execution.

As the hot ratio increases (e.g., hot ratio ≥ 30%), we observe a noticeable decrease in parallel execution performance. It is an expected behavior as it is related to a known issue of 1.0 implementation, that it only parallelizes execution between WCC of transaction dependencies. All transactions within a WCC are executed sequentially within the same partition, even if many transactions are actually independent. With a hot ratio of 30%, there's a 51% chance that a transaction will involve a hot account, calculated by 1−(1−0.3)^2=0.51 . With 10% of accounts (10,000) designated as hot accounts, which is much less than the number of transactions (47620), this results in over half of the transactions being interconnected through shared hot accounts, forming a large partition. Consequently, the execution becomes bottlenecked by an abnormally long tail in one partition, significantly reducing overall parallelism and performance.

This issue will be addressed in the upcoming Grevm 2.0, allowing independent transactions within a WCC to be executed concurrently.

Future work

More Detailed Analysis

With the implementation of Grevm 1.0, we can conduct more detailed analyses to further evaluate our future design.

• Memory Footprint and DoS Vulnerability: Evaluate the memory usage to identify any potential vulnerabilities to Denial-of-Service attacks due to excessive memory consumption.

• Re-execution Counts and CPU Utilization: Compare the number of re-executions and overall CPU usage with other implementations. Grevm is expected to use fewer CPU cycles because of reduced re-executions.

• Dependency Hint Accuracy: Collect statistics on dependency hint errors, analyzing false positives and false negatives to understand their impact of parallelism and the number of executions.

Grevm 2.0

Figure 5: Grevm 2.0

Grevm 2.0 will address the limitations of version 1.0 by introducing:

• Finer-Grained Transaction-Level Concurrency: This enhancement allows transactions with shared dependencies to execute in parallel once those dependencies are finalized. It overcomes the limitation where such transactions were previously executed serially, significantly improving parallelism and resource utilization, especially in high-contention workloads.

• Fully Asynchronous I/O: Grevm 2.0 will implement true asynchronous I/O throughout the system—from the underlying database to the multi-version state memory. This eliminates redundant coroutine context switches associated with non-I/O operations in the current implementation, enhancing execution efficiency and reducing latency.

Authors

Core Contracts

L2 Contracts

L3 Contracts

Core Contracts

L2 Contracts

L3 Contracts

Developer Utilities

CreateX & Create2

CreateX and Create2 are smart contract factories designed to facilitate deterministic deployments across EVM-compatible blockchains. They enable developers to predictably deploy contracts to the same address across different networks, which is essential for multi-chain applications and counterfactual interactions.

• Deployment Addresses on Gravity:

  • CreateX: 0xba5Ed099633D3B313e4D5F7bdc1305d3c28ba5Ed

  • Create2 Factory: 0x4e59b44847b379578588920cA78FbF26c0B4956C

These factories support various deployment opcodes, including CREATE, CREATE2, and CREATE3, allowing for flexible and secure contract deployments.

Multicall3

Multicall3 is a smart contract that enables batching multiple read-only function calls into a single call. This is particularly useful for applications that need to aggregate data from various contracts.

• Deployment Address on Gravity: 0xca11bde05977b3631167028862be2a173976ca11

• Functionality: Batch multiple read-only function calls into a single call to reduce RPC requests.

Succinct SP1

Succinct SP1 is a high-performance, open-source zero-knowledge virtual machine (zkVM) that verifies the execution of arbitrary Rust programs or any LLVM-compiled language. It enables developers to generate zero-knowledge proofs (ZKPs) for smart contract execution, enhancing scalability and privacy.

• SP1 Verifier Gateway Address: 0x3B6041173B80E77f038f3F2C0f9744f04837185e

• Supported Verifier Routes:

  • Groth16 v3.0.0: 0x95F70a7DE0AeDdb1166343524934D2aaE5609a53

  • Plonk v3.0.0: 0xd2832Cf1fC8bA210FfABF62Db9A8781153131d16

• Functionality: The SP1VerifierGateway automatically routes SP1 proofs to the appropriate verifier for on-chain verification.

Thirdweb

thirdweb is a comprehensive Web3 development platform that empowers developers to build, deploy, and manage decentralized applications (dApps) across over 2,000 EVM-compatible blockchains. It offers a suite of tools, including SDKs, smart contract templates, and infrastructure services, designed to simplify the development process and accelerate time-to-market for Web3 applications.

Supported Tools:

• Contracts

• Connect SDK

• RPC Edge

• Engine

• Universal Bridge

• Nebula

Zerion API

Zerion API offers a comprehensive solution for building feature-rich Web3 applications, wallets, and protocols. It provides access to wallets, assets, and chain data across all major blockchains including Gravity.

Overview

Blockchain explorers serve as essential tools for navigating and analyzing blockchain networks. They allow users to search for transactions, view wallet balances, inspect smart contracts, and access various on-chain data.

Explorers

Blockscout

Blockscout is an open-source blockchain explorer tailored for EVM-compatible chains. It offers features like transaction tracking, smart contract interaction, and API support. Blockscout provides a user-friendly interface for developers and users alike.

Supported Networks

OKLink

OKLink is a comprehensive multi-chain explorer and Web3 analytics platform. It supports over 60 blockchains, offering real-time data, contract verification, and extensive API services. OKLink is designed for both casual users and developers seeking in-depth blockchain insights.

Supported Networks

NFTScan

NFTScan is a leading multi-chain NFT data infrastructure platform that supports over 25 blockchain networks, including Gravity. It offers comprehensive NFT data indexing, real-time analytics, and developer-friendly APIs. Users can explore NFT collections, track transactions, and access detailed asset information.

Supported Networks

Wallets

The following wallets have already supported Gravity Alpha Mainnet or allow users to add Gravity Alpha Mainnet manually.

Exchanges

The following exchanges have supported Gravity Alpha Mainnet.

• OKX

• BitMart

• MEXC

• Bitget

• KuCoin

• Bithumb

There are four major ways to verify contracts on OKLink:

1. Explorer Interface

2. Contract Verification APIs

3. Verify Using Foundry

Prerequisite: Get an OKLink API Key

Run forge verify-contract

To verify a contract, you need to provide:

• The deployed contract address

• The contract path and name (e.g., src/MyToken.sol:MyToken)

• The OKLink verify-url for your target chain

• Your OKLink API key

Command format:

bashCopyEditforge verify-contract <contract_address> \
  src/MyToken.sol:MyToken \
  --verifier oklink \
  --verifier-url https://www.oklink.com/api/v5/explorer/contract/verify-source-code-plugin/gravity \
  --api-key <Your_OKLink_API_Key> \
  --watch

Check Verification Status

It is recommended to use the --watch flag to continuously poll for verification status.

If you didn’t use --watch, you can manually check the result using:

bashCopyEditforge verify-check <contract_address> --verifier oklink

4. Verify Using Hardhat

Method 1 (Recommended): Using @okxweb3/hardhat-explorer-verify Plugin

This method uses an official Hardhat plugin provided by OKX. It provides a CLI command (npx hardhat okverify) to automate contract verification.

1. Install the Plugin

bashCopyEditnpm install @okxweb3/hardhat-explorer-verify

2. Configure hardhat.config.ts

Here is a sample configuration for Gravity Chain:

tsCopyEditimport { HardhatUserConfig } from "hardhat/config";
import "@nomicfoundation/hardhat-toolbox";
import "@okxweb3/hardhat-explorer-verify";

const config: HardhatUserConfig = {
  solidity: "0.8.24",
  sourcify: {
    enabled: true,
  },
  networks: {
    gravity: {
      url: "https://rpc.gravity.xyz",
      accounts: ["<Your Private Key>"],
    },
  },
  okxweb3explorer: {
    apiKey: "<Your OKLink API Key>",
    customChains: [
      {
        network: "gravity",
        chainId: 1625,
        urls: {
          apiURL:
            "https://www.oklink.com/api/v5/explorer/contract/verify-source-code-plugin/gravity",
          browserURL: "https://www.oklink.com",
        },
      },
    ],
  },
};

export default config;

3. Verify the Contract

After deployment, verify with:

bashCopyEditnpx hardhat okverify --network gravity <ContractAddress>

4. Verifying Proxy Contracts

For contracts deployed via TransparentUpgradeableProxy, use:

bashCopyEditnpx hardhat okverify --network gravity --contract contracts/MyContract.sol:MyContract --proxy <ProxyAddress>

If you're using the 897 proxy standard, omit --proxy and just run the command as normal

Method 2: Manually Configuring etherscan.customChains for OKLink

You can also verify contracts using Hardhat's native Etherscan integration by overriding the default verification endpoint.

Configuration Example:

jsCopyEditmodule.exports = {
  etherscan: {
    apiKey: "<Your OKLink API Key>",
    customChains: [
      {
        network: "gravity",
        chainId: 1625,
        urls: {
          apiURL:
            "https://www.oklink.com/api/v5/explorer/contract/verify-source-code-plugin/gravity",
          browserURL: "https://www.oklink.com",
        },
      },
    ],
  },
};