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

Reliability

A zk-rollup in its intended use is a critical piece of financial infrastructure, thus implying stringent requirements in terms of reliability.

Reliability is a multi-dimensional concept that can be subdivided into two axes: liveness and fidelity.

Liveness means that the system is functioning and responsive to requests and fidelity means that the system is functioning in the intended manner, conforming to the rules or contracts defining its intended behaviour.

Together, these two axes capture the concept of reliability, with which the system ensures each of the following outcomes:

  • Nobody can double spend.

  • Nobody can spend money that is not theirs.

  • Valid transactions submitted to the rollup are processed and included in the rollup in a short amount of time.

  • The prover node network responds in a timely manner to queries for rollup data.

  • The prover node network responds accurately to queries for rollup data.

  • The complete rollup data structure is retained.

PreviousPlutus Language FamilyNextLiveness and Safety

Last updated 2 years ago