Gauss Docs
  • 🌐Getting Started
    • Welcome to Gauss
    • Whitepaper
      • Blockchain Providers Need to Do Better
        • Solving a Lack of Token Adoption
          • An Evolving Space With Untapped Potential
        • Security & Reliability
          • Curation & Vetting
            • Important Note For Brands
        • Token Creation
      • WHY BUILD WITH GAUSS?
      • Use Cases
        • Use Cases (Chart)
      • Roadmap
      • Technical Background and Blockchain Development
        • Why Another Blockchain?
        • Gauss 1.0: Built With Efficiency and a Strong Infrastructure to Launch Rapidly
        • Gauss 2.0: Added Functionality For a Better User Experiance
          • Noble Swap 2.0
          • NFTs in Gauss 2.0
          • Token Development Kit (TDK)
          • Gaming DAO
          • Omnipool
      • Token Economics
        • Gang Token Economics: Designed to Ensure Trust and Transparency
        • Token Locking Schedule
        • Reflections: Rewarding the Gauss Community
        • Charitable Allocations: Grants, Scholarships, & Financial Assistance
      • The Gauss Team
      • Important Definitions
      • DISCLAIMER
        • PURCHASER WARNING
        • PROMINENT STATEMENTS
        • FUTURE STATEMENTS
        • VALUE RISKS
        • NOT A SECURITY
    • How To Connect
      • Create Metamask Wallet
    • Links
  • ⚡Launching with Gauss
    • Benefits of Building with Gauss
      • Fostering an Environment for Success
      • Gauss Growth Grant Program
      • Gauss Liquidity Program
      • Ecosystem Integrity Fund
      • Client Referral Program
    • A Guide to Curation
      • Core Principles and Curation Guidelines
      • Curation Stages and Processing Fees
    • Building on Gauss
  • 🖥️Gauss Ecosystem
    • Gauss Chain
      • Polygon-Edge Overview
      • Architecture
      • Consensus
      • Client Modules
        • Blockchain
        • Minimal
        • Networking
        • State
        • TxPool
        • JSON RPC
        • Consensus
        • Storage
        • Types
        • Syncer
        • Sealer
        • Other Modules
      • Polygon-Edge Performance Reports
      • For Developers
        • Operate a Node
          • Local Install
          • Genesis Contract
          • Server Config
          • CLI Commands
          • Key Management
        • Run a Validator
          • Validator FAQ
        • Smart Contract Deployment Permissioning
        • Deploying Contracts
          • Remix
          • Truffle
          • Hardhat
          • Replit
    • Gauss Explorer
      • Features
      • Navigating the Explorer
        • Menus
        • Blocks
        • Transactions
      • Verifying a Smart Contract
        • Hardhat Plugin
        • Sourcify Plugin
        • OpenZeppelin Plugin
      • Interacting With Smart Contracts
      • Exporting Transactions
      • FAQ
      • For Developers
        • Gauss Explorer Dependencies
        • Deployment Guide
          • Smart Contract Verification
          • Cleaning an instance from the previous deployment
          • ENV Variables
          • Testing
        • APIs
          • Requests & Limits
          • GraphQL
          • ETH RPC
    • Noble Swap
      • Liquidity Boost Program
    • Tokens
    • Gauss NFTs
      • Ferro Cards
      • F.E.R.R.E.T. NFTs
    • Contests & Giveaways
    • Gauss Faucet
      • For Developers
    • Address List
  • 💡Additional Resources
    • Partnerships & Affiliates
    • Discord Channel
    • Contact Us
    • Learning Materials
      • Web3 Glossary
    • Media Kit
Powered by GitBook
On this page
  • Overview​
  • LevelDB​
  • Future Plans​
  • 📜 Resources​
  1. Gauss Ecosystem
  2. Gauss Chain
  3. Client Modules

Storage

PreviousConsensusNextTypes

Last updated 2 years ago

Overview

The Polygon Edge currently utilizes LevelDB for data storage, as well as an in-memory data store.

Throughout the Polygon Edge, when modules need to interact with the underlying data store, they don't need to know which DB engine or service they're speaking to.

The DB layer is abstracted away between a module called Storage, which exports interfaces that modules query.

Each DB layer, for now only LevelDB, implements these methods separately, making sure they fit in with their implementation.

blockchain/storage/storage.go

// Storage is a generic blockchain storage
type Storage interface {
    ReadCanonicalHash(n uint64) (types.Hash, bool)
    WriteCanonicalHash(n uint64, hash types.Hash) error

    ReadHeadHash() (types.Hash, bool)
    ReadHeadNumber() (uint64, bool)
    WriteHeadHash(h types.Hash) error
    WriteHeadNumber(uint64) error

    WriteForks(forks []types.Hash) error
    ReadForks() ([]types.Hash, error)

    WriteDiff(hash types.Hash, diff *big.Int) error
    ReadDiff(hash types.Hash) (*big.Int, bool)

    WriteHeader(h *types.Header) error
    ReadHeader(hash types.Hash) (*types.Header, error)

    WriteCanonicalHeader(h *types.Header, diff *big.Int) error

    WriteBody(hash types.Hash, body *types.Body) error
    ReadBody(hash types.Hash) (*types.Body, error)

    WriteSnapshot(hash types.Hash, blob []byte) error
    ReadSnapshot(hash types.Hash) ([]byte, bool)

    WriteReceipts(hash types.Hash, receipts []*types.Receipt) error
    ReadReceipts(hash types.Hash) ([]*types.Receipt, error)

    WriteTxLookup(hash types.Hash, blockHash types.Hash) error
    ReadTxLookup(hash types.Hash) (types.Hash, bool)

    Close() error
}

In order to make querying the LevelDB storage deterministic, and to avoid key storage clashing, the Polygon Edge leverages prefixes and sub-prefixes when storing data

blockchain/storage/keyvalue.go

// Prefixes for the key-value store
var (
    // DIFFICULTY is the difficulty prefix
    DIFFICULTY = []byte("d")

    // HEADER is the header prefix
    HEADER = []byte("h")

    // HEAD is the chain head prefix
    HEAD = []byte("o")

    // FORK is the entry to store forks
    FORK = []byte("f")

    // CANONICAL is the prefix for the canonical chain numbers
    CANONICAL = []byte("c")

    // BODY is the prefix for bodies
    BODY = []byte("b")

    // RECEIPTS is the prefix for receipts
    RECEIPTS = []byte("r")

    // SNAPSHOTS is the prefix for snapshots
    SNAPSHOTS = []byte("s")

    // TX_LOOKUP_PREFIX is the prefix for transaction lookups
    TX_LOOKUP_PREFIX = []byte("l")
)

// Sub-prefixes
var (
    HASH   = []byte("hash")
    NUMBER = []byte("number")
    EMPTY  = []byte("empty")
)

The plans for the near future include adding some of the most popular DB solutions, such as:

  • PostgreSQL

  • MySQL

LevelDB

Prefixes

Future Plans

📜 Resources

🖥️
​
​
​
​
​
LevelDB