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

Decentralization

For most existing decentralized systems, their decentralization can be only estimated but not computed exactly for a point in time. For example; although the number of nodes in the Bitcoin network at a point in time can be estimated, this estimate does not reveal how many distinct actors control those nodes.

Understood in this way, decentralization appears to be an important characteristic for reliability. The more actors that must be taken out or corrupted to take a system down or corrupt it, the better the system’s reliability.

Orbis Labs is committed to the full decentralization of Orbis. This commitment does not mean that Orbis will be fully decentralized out of the box but that Orbis will eventually be fully decentralized. We plan to deliver the initial centralized version of Orbis incrementally, in which each step introduces a new system version that builds on the previous version.

Distributed System Design

Evaluating transactions and generating relevant zk-SNARK proofs is computationally difficult. Therefore, Orbis will efficiently leverage the computational power of all nodes that are part of the system and the work will be distributed among the cluster of nodes, such that each node will compute a portion of the submitted transactions, and one designated node will gather the results, merge them, to create a new block on the rollup, and eventually post the proof to L1 (Cardano).

PreviousLiveness and SafetyNextSingle node

Last updated 2 years ago