Sonic | Official Documentation
Official WebsiteExplorerFaucet
  • Welcome to Sonic
  • Users
    • Getting Started
      • Setting up your wallet
      • Bridging funds to Sonic
      • Join Sonic community!
  • Developers
    • Why Choose Sonic?
    • Getting Started
      • Setup local development for Sonic SVM
      • Build & Deploy Your First Program
    • Developer Tooling
      • Explorer
      • Faucet
      • Wallet Extensions
  • Additional Tools & Examples
  • Additional Resources
  • Architecture
    • Overview
    • Sonic SVM Whitepaper
    • Vision & Architecture
    • Clusters
    • HyperGrid Framework
      • HyperGrid Infrastructure
        • Architectural Overview
        • Grids and Network Relationships
          • Grids
      • Interoperability with Solana
        • Data Synchronization Between HyperGrid and Solana Base Layer
      • HyperGrid Shared State Network (HSSN)
      • HSSN Explorer Overview
      • HSSN Gas Fee Mechanism
      • Operator Guides
        • Deploying a New Grid
        • Deploying a Sonic RPC Node
        • Deploying an HSSN Validator
        • Mainnet
          • Deploying an HSSN Validator
      • Verifiable Compute & Zero-Knowledge Proofing on HyperGrid
    • Sorada
      • Introduction
      • Architecture
      • How to Deploy Sorada
      • Resources
    • Rush ECS Framework
      • Introduction
      • Features
      • Quickstart
      • Reference
      • Demo
  • RESOURCES
    • Audit Reports
    • We're Hiring!
Powered by GitBook
On this page
  • Blockchain's Data Layer Problem
  • Performance
  • Scalability
  • How Blockchain Indexing solves this problem
  • Case Study – Sonic SVM's 85% Archival Reads
  • What is Sorada?
Edit on GitHub
  1. Architecture
  2. Sorada

Introduction

A comprehensive introduction to Sorada, Sonic SVM's archival RPC data indexing and read-optimization solution

PreviousSoradaNextArchitecture

Last updated 6 months ago

Blockchain's Data Layer Problem

Blockchain networks aggregate data through blocks, transactions, and metadata.

Querying APIs are openly available and well-documented for fetching these data directly from the network.

This may work for small decentralized applications (DApps) with minimal historical data needs, but for bigger historical data requirements the baseline APIs fail to meet 2 main business requirements:

  • Performance

  • Scalability

Performance

Companies have barely any control over the response times and the data operation optimizations of the baseline querying API endpoints provided by the network.

This is critical for business requirements because performance greatly impacts .

Scalability

Similar to performance, companies cannot optimally adapt to the demands of their users with elastic provisioning due to the limitation of the baseline Querying API endpoints provided by the network.

This is another critical business requirement because scalability goes beyond performance and impacts the financial feasibility of operating.

How Blockchain Indexing solves this problem

Blockchain Indexing is the process of querying historical data directly from the network and storing them in in-house provisioned infrastructure.

A typical and simplified Blockchain Indexing pipeline would have the following flow:

  1. Use network API to fetch blocks and transactions.

  2. Store blocks and transactions to internal storage infrastructure.

  3. Use internally provisioned data query endpoints for products as opposed to querying directly from the network

This way, the Company has internal control over the Performance and Scalability of its historical data needs.

Case Study – Sonic SVM's 85% Archival Reads

These read requests span across getTransaction, getBlock, getSignaturesForAddress.

While this is a solid metric of demand for Sonic, the engineering team started experiencing bottlenecks around Bandwidth and Storage costs for requests directly funneled towards the Hypergrid infrastructure.

These bottlenecks were solved by decoupling typical archival read requests away from Sonic's main Hypergrid infrastructure and into Sorada.

What is Sorada?

Sorada is Sonic's Data Solution with the main objective of decoupling Archival Read Requests away from Network Write Requests.

By decoupling archival read requests away from the main Sonic validator and into a separate data-optimized infrastructure, Bandwidth and Storage bottlenecks were mitigated.

Sorada enables SVM validators to release more compute resources to transaction processing, while optimizing read performance of archival requests by 30 – 40x.

According to Sonic's internal Infrastructure monitoring, Sonic experienced around 85% Archival Read Requests vs 15% Write Requests.

website speed, search engine optimization (SEO), and conversion rate
Hypergrid