Citrea
WebsiteBlogJoin The Community
  • 👋Welcome
    • Getting started
  • ⛓️Technical Specs
    • TL;DR
    • Technical Introduction
    • Characteristics
      • Execution Environment
      • Block Production
        • Pre-Confirmations
        • Decentralized Sequencer Network
      • Proof Generation
      • Nodes
      • Bitcoin Settlement: Trust-minimized BTC Bridge
        • BitVM
        • Optimistic Verification
    • Security Properties
      • Validity
      • Data Availability
      • Re-org Resistance
      • Censorship Resistance and Force Transactions
        • Escape Hatch
  • 👤User Guide
    • Run Citrea Full Node
      • Bitcoin Testnet4
        • Testnet4 Docker Setup
        • Build Testnet4 from Source
      • Citrea Full Node
        • Citrea Binary Executable
        • Build Citrea from Source
    • Use Citrea Testnet Faucet
    • Installing an EVM Wallet
    • Taproot Recovery Address
  • 📖Developer Documentation
    • Kickstart
    • Deployment Guide
      • Deploy a Smart Contract Using Remix
      • Deploy a Token
      • Configure Hardhat
    • System Contracts
      • Bitcoin Light Client
      • Bridge
      • Fee Vaults
    • Chain Information
    • RPC Documentation
    • Deploy a Bitcoin Appchain (L3)
  • 🔎Future Research
    • Decentralized Sequencer Network
    • Lightning Integration
    • Multi Prover
    • Multi VM Approach
    • Trustless Atomic Swaps
    • Trustless Settlement
    • Volition Model
  • 🌐Community
    • Citrea Meetups
      • Meetup Guide
      • Resources
      • Code of Conduct
Powered by GitBook
On this page

Was this helpful?

  1. Technical Specs
  2. Security Properties

Re-org Resistance

Citrea blocks are proposed by a block producer and acknowledged by nodes, which both need to have access to the Bitcoin network directly. Nodes see and verify Citrea blocks through the Bitcoin network.

Every block header produced on Citrea has a field for the last finalized Bitcoin blockhash, which is configured and baked into the state transition function. As every participant in the network has the same finalized block after some confirmation, they can validate or invalidate the Citrea block by looking at Bitcoin blockhash in its header. An adversary who wants to re-org Citrea after some confirmation must re-org the Bitcoin network as well to make nodes validate the new fork. After a Citrea block header is pushed in a batch, it is impossible to re-org the block without re-orging Bitcoin, which is almost impossible after 6 blocks.

PreviousData AvailabilityNextCensorship Resistance and Force Transactions

Last updated 7 months ago

Was this helpful?

⛓️