Sequentia docs
  • 💡INTRODUCTION
    • Introduction
  • 🖱️TESTNET
    • What to know before starting
    • Download and Installation
    • Demo the "No Coin" feature
      • 1. Set up your wallet
      • 2. Transfer TEST paying fees in TEST
      • 3. Create a new asset
      • 4. Pay transaction fees in the newly issued asset
      • 5. Replace By Fee (RBF) with different assets
  • 📖WHITE PAPER
    • 1. The Mission
    • 2. Sequentia Overview
    • 3. Blockchain Architecture
      • 3.1. Orange pilled
      • 3.2. Open fee market
      • 3.3. Market-driven governance
      • 3.4. Bitcoin anchoring
      • 3.5. Immediate transaction finality
      • 3.6. Full node sovereignty
      • ­­­­­­­­3.7. Cross-chain consistency
      • 3.8. Escaping stall
      • 3.9. No inflation
      • 3.10. Cheap to handle
      • 3.11. Bitcoin checkpoints
    • 4. Asset tokenization
      • 4.1. Why tokenization: security tokens and stablecoins
      • 4.2. The RAS standard
      • 4.3. Lightning Network payments
      • 4.4. Peer-to-peer batching
      • 4.5. Access-Control-List
      • 4.6. Programmable Accounts
    • 5. Decentralized Exchange
      • 5.1. Atomic swap
      • 5.2. Lightning Network swap
      • 5.3. Standardized order package
      • 5.4. Distributed Hash Table (DHT)
      • 5.5. Market incentives
      • 5.6. Watchtower and Book aggregator
    • Disclaimer
  • 🔗Links
    • Sequentia Theoretical Paper
    • Sequentia Lightpaper
    • Sequentia website
    • Join on socials
Powered by GitBook
On this page
Export as PDF
  1. WHITE PAPER
  2. 3. Blockchain Architecture

3.6. Full node sovereignty

Every node on the network can be a Sequentia validator, and block proposers cannot enforce changes to Consensus rules on full validator nodes.

Anybody can run a Sequentia validator node, independently of the amount of SEQ at stake, exactly like a Bitcoin full node can function without holding any bitcoin and still process, validate, and accept transactions broadcast by the network. Also, stakers selected by the algorithm to act as block proposers cannot arbitrarily force, even if they form a majority, a Consensus rule change, just like bitcoin miners cannot force other nodes to upgrade their software.

In case a malicious majority attempts to change Consensus rules, accepting and countersigning blocks that are invalid for a minority of stakers, the enforce consensus rule applies:

If there exists a block b0 that breaks the consensus rules but is certified, meeting the quorum of countersignatures, then a valid block b1 at the same height of b0 can be certified with a new quorum representing the majority of the blocksigners that have not countersigned b0. If that quorum cannot be met and the hard-forked chain stalls, the escaping stall clause can be applied.

Previous3.5. Immediate transaction finalityNext­­­­­­­­3.7. Cross-chain consistency

Last updated 1 year ago

📖