Orbis
  • Orbis
  • High-Level Overview
  • Technology
    • zk-SNARKs
    • Halo 2
    • Cardano
      • EUTXO
  • Architecture
    • Process
    • L1 Rollup Protocol: On-Chain Inputs and Outputs
    • L2 Rollup Protocol: On-Rollup Transactions
    • Orbis Specification Language (OSL)
  • Smart Contracts
    • Programming on Orbis
    • Plutus Language Family
  • Design Considerations
    • Reliability
    • Liveness and Safety
    • Decentralization
      • Single node
      • Static master/workers
      • Dynamic master/workers
    • Data Availability
    • Upgradability and Governance
    • Performance
  • Inter-Rollup and Inter-Protocol Bridges
  • HALO Token
    • HALO
    • Tokenomics
  • Official Links
    • Website
    • Twitter
    • Blog
    • Discord
    • Github
    • LinkedIn
Powered by GitBook
On this page
Export as PDF
  1. Design Considerations
  2. Decentralization

Dynamic master/workers

This distributed system has a single master node and multiple worker nodes. To create blocks on the rollup, it must perform a leader election to establish a master node.

In this setting, the system becomes resilient to crash-only failures as long as the cluster can successfully perform a leader election.

Alongside the nodes, the system will run a fully distributed database that will store both transactions and rollup. All nodes will have read-write access to the database.

Creating a block and updating the rollup state will work exactly as in the Static master/workers setup.

PreviousStatic master/workersNextData Availability

Last updated 2 years ago