Keeta Network
  • Introduction
    • Start Developing
    • Create Your First Account
    • Send a Transaction
  • Architecture
    • Data Structure
    • Consensus
      • Voting Power
      • Votes
      • Vote Stapling
  • Components
    • Ledger
      • Get Ledger History
    • Blocks
      • Create a Block
      • Operations
        • Send
        • Receive
        • setInfo
        • modifyTokenSupply
        • modifyTokenBalance
        • updatePermissions
    • Nodes
      • Ledger Pruning
    • Accounts
      • Permissions
      • Storage Accounts
        • Create a Storage Account
        • Single-Token Storage Account
    • Key Pairs
      • Storing Key Pairs
    • Certificates
      • Creating and Attaching Certificates
  • Security
    • Digital Signatures
    • Post Quantum Readiness
    • Data Integrity
    • Protection From Common Attacks
  • Scalability
    • Benchmarks and Performance Metrics
    • Seperating Nodes from Hardware
    • Eliminating Mempools
  • Features
    • Identity Profiles
      • Utilizing Identity Profiles
    • Native Tokenization
      • Token Creation
        • Mint Tokens
        • Burn Tokens
        • Set Permissions
      • Built-in Rules Engine
    • Anchors
      • Creating an Anchor
  • Applications
    • Public Network
    • Private Sub Network
  • Industry Comparison
    • Keeta Network's Advantage
    • Resolving the Blockchain Trilemma
  • Guides
    • Tokenizing Real-World Assets
  • Other Documentation
    • Official Links
    • Tokenomics
    • Roadmap
Powered by GitBook
On this page
  1. Architecture

Consensus

PreviousData StructureNextVoting Power
CtrlK

At its core, the Keeta Network utilizes a Delegated Proof of Stake (dPoS) voting protocol, which allows for quick consensus while ensuring decentralization. Keeta's block validation process follows a structured five-step sequence that ensures security and efficiency.

The process begins when a client initiates a vote on a new block(s), sending their request to multiple network representatives. These representatives respond with temporary votes, providing initial validation of the proposed blocks. The client then requests verification of all temporary votes, creating a cross-validation layer. Following this, representatives submit their permanent votes, confirming their final decision on block validity. In the final step, the client broadcasts both the validated blocks and their associated votes to the network, where they are permanently added to the blockchain.

Each transaction must receive a sufficient number of votes before being broadcasted to the network.