Botanix
Visit websiteTry Testnet
  • Welcome!
  • Get to know the Technology
    • Introduction to Botanix Labs
    • Risk warning
    • Terminology
    • Basic knowledge
      • Proof-of-Stake
      • Ethereum Virtual Machine (EVM)
      • UTXO vs Account Based Model
    • Introductory concepts
      • The Botanix EVM
      • The Spiderchain
      • Orchestrator node
      • Deposit & Withdraw
      • Transaction fees
    • Advanced concepts
      • Bitcoin security inheritance
      • Bridging
      • Consensus
      • Finality
        • Finality in a Proof-of-Work (PoW)
        • Finality in a Proof-of-Stake (PoS)
        • Finality on Botanix EVM
      • Forward security
        • Forward security in cryptography
        • The Spiderchain's Forward Security
        • Inventory management
      • FROST
      • Reth
      • Orchestrators
      • Staking
    • Roadmap to Spiderchain
      • Single Node (Testnet)
      • Botanix Federation
        • Consensus - CometBFT
          • Byzantine Fault Tolerance (BFT)
        • Node types
        • Multisig details - FROST
        • Peg-in / Peg-out
      • Botanix Federation with Staking
      • Slashing
      • Spiderchain DynaFed
      • Permissionless staking
      • Fully Decentralized Layer 2
    • Deeper dive: Whitepaper
  • How to use the Botanix EVM
    • Getting started with the Botanix EVM (testnet)
    • Risk warning
    • Step 1 - Set up your wallet
    • Step 2 - Get test funds
    • Step 3 - Send a transaction
    • Step 4 - Use dApps
    • Step 5 - Deploy your first contract / Launch your own token
    • Step 6 - Withdraw
    • FAQ - Testnet V1
  • Build dApps
    • Introduction
    • Risk warning
    • Tools
      • Useful links
      • Development Frameworks
      • Web3 libraries and tools
      • Oracle Tools
      • Block explorer
        • Routescan
      • Indexers
        • The Graph
        • SubQuery
      • WalletConnect
      • Account Abstraction with BTC Connect
      • Muticall3
    • Build on the Botanix EVM
      • Basic Botanix EVM Information
      • Gas fees
      • Develop a new dApp
      • Migrate existing dApps
      • Quickstart - Build a dApp with Botanix (Solidity, Hardhat)
  • Run a node
    • Introduction
    • Run an RPC Node
  • Glossary
Powered by GitBook
On this page

Was this helpful?

  1. Get to know the Technology
  2. Advanced concepts
  3. Finality

Finality in a Proof-of-Work (PoW)

PreviousFinalityNextFinality in a Proof-of-Stake (PoS)

Last updated 1 year ago

Was this helpful?

In a proof-of-Work (PoW) system, finality is typically achieved through the use of confirmations, which refer to the number of blocks that have been added to the chain after a particular block. The more confirmations a block has, the more secure it is considered to be. From the :

"The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power."

A chain can split into two different forks when two different miners mine a block at the same time. When that happens, it is quite difficult to determine which fork is the valid chain. Once one of the chains validates a block before the other chain completes it becomes the longest chain. The longest chain is the one with the longest most valid blocks attached.

The longest chain becomes officially the accepted chain and the transactions mined on the shorter chain are rejected. However, it is possible the transactions rejected on the shorter chain have been included in other blocks on the longest chain.

Bitcoin whitepaper