POOLS Chain Documentation
  • Introduction
    • Version
    • Purpose: Blockchain & AI
    • Mission
    • Vision
  • MARKET OVERVIEW
    • Blockchain Market: Current State
    • Blockchain Market: Issues
    • Pools Chain Solutions
  • POOLS CHAIN OVERVIEW
    • Pools chain: Definition & Main functions
    • Features and Utilities
    • Compatible with EVM
    • Abilibitiy of Extension
    • Interoperable
    • Artificial Intelligence
    • Ecosystem
    • Dapps
      • Pools Wallet
      • AIHomes
      • Friendify GPT
      • More Dapps
      • Pools Phone
        • Pools Phone System
        • Pools Phone Authentication
  • Startmobis
  • TECHNICAL ARCHITECTURE
    • Proof-of-Stake (PoS)
    • Node structure
    • Security & Encryption mechanisms
    • Security and Finality
    • Reward
    • Validator Quorum
    • Staking and Governance
    • Staking on POOLS
    • Rewarding
    • Slashing
    • Double Sign
    • Governance Parameters
    • Smart contract language
      • Hardhat: Deploy ERC20 Contract
      • Truffle: Deploy ERC20 Contract
  • Develop smart contracts
  • Integrated smart contracts
  • Smart Contract Verification
    • Overview
    • How to verify your smart contracts on Pools Chain
  • Smart contract
    • Smart Contract Language
      • Hardhat
      • Truffle
    • Smart Contract Development
    • Smart Contract A.I Integration
    • Smart Contract Verification
      • Overview
      • How to verify your smart contracts on Pools Chain
  • TOKENOMIC
    • POOLS Coin: Role & Use case
    • Coin Distribution
    • Incentive Structure
  • ROADMAP & DEVELOPMENT PLAN
    • Pools Chain: Development Milestone
      • A playground for developers
      • Build the Infrastructure
      • Partnership
      • Marketing & PR
    • Future Plans
  • TEAM & PARTNERS
    • Core Team
    • Advisor & Partnership
  • NOTICE & DISCLAIMER
    • Legal Notices & Warnings
    • Regulatory Compliance & Transparency
    • Responsibilities & Rights
      • Pools Chain
      • Users
  • BUILT FOR DEVELOPERS
    • Pools SDK
      • Supported platforms
        • JavaScript
          • React
          • Pure JavaScript
          • Other web frameworks
          • React Native
          • Node.js
          • Electron
        • Mobile
          • Native IOS
    • Contract deploy
    • Blockchain Explorer
  • CONTACT US
    • Summary
    • Contact for further info
Powered by GitBook
On this page
  1. TECHNICAL ARCHITECTURE

Security and Finality

Given there are more than ½*N+1 validators are honest. However, there are still cases where certain amount Byzantine validators may still manage to attack the network, e.g. through the “Clone Attack”. To secure as much as BSC users are encouraged to wait until receiving blocks sealed by more than ⅔*N+1 different validators.

With 21 validators, if the block time is 3 seconds, the ⅔*N+1 different validator seals will need a time period of (⅔*21+1)*3 = 45 seconds. Any critical applications for Bools chain may have to wait for ⅔*N+1 to ensure a relatively secure finality. However, besides such arrangement, Pools chain does introduce Slashing logic to penalize Byzantine validators for double signing or unavailability, which will be covered in the “Staking and Governance” section later. This Slashing logic will expose the malicious validators in a very short time and make the “Clone Attack” very hard or extremely non-beneficial to execute. With this enhancement, ½*N+1 or even fewer blocks are enough as confirmation for most transactions.

PreviousSecurity & Encryption mechanismsNextReward

Last updated 1 year ago