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. Forward security

The Spiderchain's Forward Security

Similar to how encryption protocols are vulnerable to long term key exposure, the bitcoin secured in a Layer 2 Proof-of-Stake protocol is vulnerable to an attacker gaining majority control of the stake.

In the case of the Botanix EVM where we stake bitcoin on Bitcoin, the protocol needs to be able to defend itself against a malicious actor gaining 2/3rds majority of the staked Bitcoin. This is where the Spiderchain's forward security comes into play. When at a certain point, a malicious actor gains 2/3rds majority of the stake, he will not be able to steal any bitcoin because of the Spiderchain's design. Every bitcoin block, a new multisig is generated between 100 random Orchestrators. So after a while the bitcoin in the Spiderchain is split among numerous different multisig wallets that were previously generated.

  1. Multisig rotation: new bitcoin entering the Spiderchain will be stored in new multisigs controlled by random Orchestrators. The security of that new bitcoin is then dependent on the decentralization and security of the staking pool at that specific moment. This ensures future malicious actors will never be able to have control over the older established multisigs.

  2. Liveness Epochs: Because the bitcoin is stored in FROST multisigs between Orchestrators, after every epoch a new set of keys is generated between the Orchestrators. This allows for the protocol to verify the liveness of each Orchestrator.

  3. LIFO management: In order to protect the bitcoin stored in older established wallets, a LIFO inventory management is chosen.

These techniques contribute to the forward security by reducing the potential damage caused by a malicious attacker gaining majority control over the stake. In systems that prioritize forward security, the compromise of a a 2/3rd majority should not lead to the retroactive compromise of the bitcoin stored. This property is essential for maintaining the security and integrity of the value on the Spiderchain.

PreviousForward security in cryptographyNextInventory management

Last updated 10 months ago

Was this helpful?