_(2).png?table=block&id=cfe6618d-0c88-41f4-bacf-4d0239ccb43e&cache=v2)
Do not index
Do not index
Sonic stands out with its focus on atomic interoperability and gaming applications. The key differentiator is HyperGrid, a scaling framework that implements a shared sequencer network, orchestrates an interoperability interface, and serves as the consensus layer for the Grids it operates. HyperGrid is designed to inform an opinionated pattern for deploying scalable and configurable SVM rollups we call Grids.
In this article, we will give an overview of how Hypergrid works and what are the different components.
How the HyperGrid Rollup Works?
HyperGrid has two core components:
- Grids – Configurable SVM rollups for optimized performance.
- HyperGrid Shared State Network (HSSN) – A shared validator network for deployed Grids. It provides an interoperability interface for Grids and serves as a consensus layer for Grids that seek to securely roll up state transitions to Solana.
Broadly, there are a few steps for transactions in the HyperGrid:
- Transactions are ingested and executed by the Grid.
- Compression – All state transitions are optimistically rolled up and Merkle compressed. Transactions are compressed and aggregated into a Merkle tree.
- Proof Generation – A proof is generated by each grid instance for each slot. For each block, the corresponding root state hash is committed. A new root represents each block/slot.
- Proof Commitment – Proofs are committed to the HSSN to avoid any state collisions. The HSSN serves as a validation layer for transactions processed by Grids. Light sampling with light fraud proofs is computed here, and the HSSN pushes all proofs to the verifier program on Solana for further validation.
HyperGrid expects a grid instance to post a Merkle proof together with the root state hash to the HSSN. This architecture allows individual grids to implement the Merkle compression and proof generation independently, as long as it satisfies the requirements dictated by the HSSN framework. This flexibility allows different grid teams to implement customizable or even more performant versions of the proofing process.
Let’s now dive deeper into each component.
Compressed Accounts:
Everything on Solana can be considered an account. Accounts are the way the protocol organizes the data on the blockchain i.e. all data is stored in accounts.
Similarly, each transaction within the Sonic rollup is represented as a compressed account. Compressed accounts can be program-owned i.e. PDA (Program Derived Address). It can optionally have a permanent unique address.
Similar to Light Protocol’s implementation, Sonic implements Compressed Accounts. Compressed accounts are similar to regular Solana accounts but each compressed account can be identified by its hash. Further, each writes to a compressed account changes its hash.
RPC nodes index the compression programs, allowing clients to read and construct transactions that interact with the compressed state. Similarly, the compressed accounts must be indexed off-chain for faster referencing during runtime.
Concurrent Merkle Trees:
All compressed accounts are stored in state trees. A state tree is a binary Merkle Tree that organizes data into a tree structure where each parent node is the hash of its two children nodes.
Only the tree's state root (small fingerprint of all compressed accounts) is stored in the on-chain account space. This leads to a single unique root hash that allows for efficient cryptographic verification of the integrity of all the leaves in the tree.
For Sonic, each compressed transaction state will be stored in the Concurrent Merkle tree data structure. Each piece of data that is created or consumed in a transaction represents a single leaf of a state tree. All tree leaves get recursively hashed together so that only the tree's final 32-byte root hash needs to be stored on-chain.
To verify the validity of many pieces of state (Compressed Accounts) inside a single Solana transaction, Sonic shall leverage Zero-knowledge cryptography, enabling it to compress all state proofs into one small validity proof (About 128 bytes).
Atomic SVM chain — Synchronization with the Base Layer
Solana’s main strength lies in composability, where one app can easily compose (integrate) over another app using the same shared ledger. At Sonic, we want to ensure an atomic state synchronization strategy between Solana L1 and HyperGrid.
The demo of read and write can be viewed at – mint.hypergrid.dev. You can find the entire tutorial on how to deploy an NFT contract on Solana Devnet and achieve interoperability with NFTs deployed on Solana Devnet through Grid.
Why HyperGrid Framework for Building Sonic?
We believe HyperGrid Stack provides all the right tools needed for Sonic to empower Web3 gaming on Solana, and the broader SVM Ecosystem - highlighted by following strengths:
- Horizontal Scaling: By utilizing concurrent merklelized state compression and BFT (Byzantine Fault Tolerance) consensus, HyperGrid aims to achieve a controlled aggregated transaction settlement of 12,000,000 TPS to the base layer by optimizing execution for programs deployed to its grids. In essence, games deploying on Sonic can enjoy instant transactions for their game interactions.
- Gaming-Specific SVM Environment: Our team has optimized Sonic SVM for Web3 game development and operation. For example, Sonic’s transactional model is specifically designed to meet the needs of gaming, enabling high-frequency, low-latency interactions that are essential for in-game events, player actions, and state updates. Sonic will also feature an integrated verifiable random function (VRF) for on-chain randomness and NFT support from Metaplex, significantly reducing the minting costs of game-produced NFTs. Sonic offers native composable gaming primitives and extensible data types based on the ECS framework directly on-chain.
- SVM runtime diversity at the Grid level: Game developers can also operate an application-specific SVM runtime for application-specific use cases. This means that game studios can not only take advantage of Sonic’s optimized gaming environment, but also launch their own custom SVM grid. This can enable hyper-optimized game support such as custom vm agnostic game engines, data primitives, and others to facilitate game development and create the best UI/UX for users.
- Atomic Interoperability – Deploy on mainnet, while executing on Grid. Consume state from the base layer, derive new state on your Grid. This allows games that launch on Sonic to launch assets composable with Solana mainnet, while offloading game logic on Sonic grid - which allows for execution of logic without having to compete against other transactions or priority fees.
We look forward to make gaming on Solana great again, with HyperGrid Framework - stay tuned for more exciting updates to come.