Like Cardano, Orbis uses the EUTXO (Extended Unspent Transaction Output) accounting model for its transactions, an extension of the standard UTXO model enabling expressive smart contracts while keeping the semantic simplicity of the UTXO model.

In a UTXO model, the coin transfer is recorded in a directed acyclic graph with the nodes representing transactions and the edges representing transaction outputs. Wallets keep track of a list of unspent outputs associated with all addresses owned by the user and calculate the users’ balance.

• A UTXO is the output of a previous transaction.

• UTXO chains don’t have accounts. Instead, coins are stored as a list of UTXOs, and transactions are created by consuming existing UTXOs and producing new ones in their place.

• Balance is the sum of UTXOs controlled by a given address.

• UTXOs resemble cash in that they use ‘change’, and are indivisible (UTXOs are used whole).

The extended UTXO model gives Orbis the ability to run smart contracts safely while maintaining high scalability.

How does Cardano work?

Cardano’s native blockchain is divided into two separate layers to fulfil different tasks and improve overall efficiency. They are:

• Cardano Settlement Layer (CSL): Used for facilitating peer-to-peer transactions of ADA-native tokens

• Cardano Computational Layer (CCL): Used for executing smart contracts

Proof of Stake (PoS)

The Cardano blockchain operates using a proof-of-stake (PoS) consensus mechanism for discovering new blocks and adding transaction data to the blockchain called “Ouroboros.” This PoS system involves ADA holders locking up, aka “staking,” their coins in pools operated by other participants or becoming operators of stake pools themselves.

While anyone can run their own staking pool, it does require a level of technical expertise to do so successfully. Rewards for adding new blocks to the chain are distributed among the stake-pool operator and stakers after every epoch finishes (5 days), proportionate to how many coins are staked in the pool by each person.

The more coins collectively held in a stake pool, the greater the chance it will get randomly selected to become a slot leader and add the next block in the chain. Think of staked coins like lottery tickets. While having more tickets increases your chances of winning it doesn’t guarantee you will. To prevent giant pools from dominating the system, each staking pool is governed by a “saturation parameter” which essentially offers stake pools lower rewards once they reach a certain capacity to incentivize ADA stakers to relocate their coins to smaller pools.

Ouroboros

The Ouroboros consensus system is different from Bitcoin’s proof-of-work (PoW) system, which requires users to compete using specialized computer equipment to discover the next block and has no built-in feature that discourages monopolistic mining operations (other than the fact that bitcoin’s value depends on its being controlled by no one).

In order to create new blocks, Ouroboros uses a time-period system called “epochs” where each epoch lasts five days. Inside each epoch, there are 21,600 smaller units of time called slots, or one slot every 20 seconds. Stake pools are randomly assigned to each slot as a “slot leader” and tasked with creating a new block for that slot.

This is a protocol implemented as a smart contract through which an on-chain UTxO represents the state of a rollup.

Let’s look at the basic operations of the L1 rollup protocol.

1. The on-chain rollup state UTxO can be updated to reflect transactions added to the rollup.

2. Then the on-chain money can be added to the rollup state UTxO to make the funds available to its owner on the rollup.

3. On-rollup money can be removed from the rollup state UTxO and sent to an on-chain address of the owner’s choosing.

The L1 rollup protocol does not define how the rollup data is stored off-chain or how transactions are added to it. But it merely defines the protocol through which changes to the rollup off-chain are reflected on-chain, and money can be added to and subtracted from the rollup.

Contract specification

The L1 protocol respects a well-defined lifecycle for proof-state objects, such that they can be initialized, tracked, altered, and then finally shut down cleanly.

Each proof state can be initialized with an NFT Asset Class to be used as a unique ID (UID) to track the proof state over its entire lifecycle.

Having a well-defined lifecycle for proof-state objects allows the “NoFundsLocked” property to be satisfied so that no funds are ever stuck at a script address.

Validator Mechanics

A given Orbis validator is parameterized with different asset classes for

1. Identification

2. Authentication

3. Assets accepted

Fallback mode

In the event that the prover is offline for a protracted period of time (3 days), the validator will allow for a fallback option that allows users to retrieve their funds from the rollup.

In this special case, users may submit a Fallback redeemer containing a list of UTxOs that they would like to retrieve from L2.

The arithmetic circuit in this case will attempt to verify that:

1. Only burn transactions have taken place in the rollup.

2. Those burn transactions on L2 are signed by the users.

3. The UTxOs burned on L2 correspond to the TxOuts provided in the redeemer on L1.

4. At least 3 days have passed since the last L2 non-burn transaction.

Upgrade and governance process

The validator will also allow the prover to move the UTxO to a new script address through the use of an “Upgrade” redeemer.

The included zk-SNARK will prove that n of m members of the board (the governing body of Orbis) have signed off on the upgrade.

Here, n and m are protocol parameters, and m is the number of board members; both numbers are potentially subject to change. The list of members of the board is part of the contract state and part of the statement to be proven.

The coefficients of the fee calculation can be updated without upgrading the contract as long as n of the members of the board have signed off. In case of voting for an approval for a new board, the included zk-SNARK will prove that n of m members of the board have signed off on the election of the new board and that an approving vote for the new board occurred.

This is the protocol through which prover nodes communicate with one another and with the other components of the system.

Prover nodes are responsible for

1. Responding to queries regarding the rollup.

2. Remembering the state of the rollup.

3. Updating the state of the rollup

4. Executing the L1 rollup protocol.

Because the task of building zk-SNARKs that validate large numbers of on-rollup transactions is computationally difficult, being able to build a distributed computing cluster for executing the L2 protocol is useful. For this reason, among others, the prover node protocol allows for an unlimited number of prover nodes.

Another benefit of allowing for more than one prover node is that the L2 protocol can be decentralized. Full decentralization of the L2 protocol is an eventual goal to which the Orbis team is committed.

Prover API

The prover API contains endpoints necessary to perform operations, including the endpoints for submitting transactions and querying the rollup state.

Transaction-submission API

This API allows Orbis users to interact with their funds on the L2 chain. The endpoints involved are listed below:

1. Submitting a smart contract by the user to L2 via this API

2. Checking whether a smart contract exists

3. Fetching a smart contract

4. Reserving inputs: (Reserving inputs for a transaction by the user is necessary to use inputs in a transaction. This reservation can be performed via this API )

5. Submitting a transaction. (Here The transaction is validated and either accepted or rejected with a reason)

Query-state API

Issuing a rollup metadata fetch request yields the number and hash of the current highest-rollup block. Users can use these to fetch more information about this block.

The endpoints involved are listed below:

1. Fetching rollup metadata - Issuing a rollup metadata fetch request yields the number and hash of the current highest-rollup block.

2. Fetching fee structure - Issuing a fee structure fetch request yields the fee structure parameters as of the given time.

3. Fetching block by hash - The request returns a set of matching blocks, because hash collisions may occur.

4. Fetching block by time

5. Fetching transaction - This endpoint allows for fetching of all details of a transaction ac- cording to its ID.

6. Fetching TxOut - This endpoint can be used to obtain a set of transaction outputs for a given address, which can later be used to construct inputs for a transaction.

Voting and governance

The endpoints involved in voting and governance are listed below:

1. Fetch board - This endpoint returns a list of the current Orbis governance board members.

2. Get voting power - This endpoint returns the current voting power held by a given address.

3. Create a proposal - This endpoint creates a new board election.

4. Fetch active proposals - This endpoint returns a list of active proposals, which have been created but not expired nor executed.

5. Vote - This endpoint adds a vote to an active proposal, or changes the vote of an address which has already voted.

6. Execute election - This endpoint takes the id of an active proposal which has enough votes to pass, and the signatures of the board members, and enacts the change to the governance protocol to govern Orbis under the accepted proposal.

7. Update fee structure - This endpoint updates the fee structure to a new value.

The First Layer 2 ZK-Rollup Scaling Solution Built on Cardano

Visit the official website:

Getting Started

What is Orbis?

What are zero-knowledge proofs?:

Orbis is the first general-purpose layer 2 zk-rollup protocol for Cardano, built to support decentralized finance (DeFi) applications and a thriving blockchain ecosystem. Orbis offers the level of scalability and transaction throughput necessary for a global blockchain-based financial system.

There are three main processes involved in a wallet using the Orbis protocol:

1. Moving inputs from the chain to the rollup.

2. Submitting transactions to the rollup.

3. And moving outputs from the rollup to the chain.

Let’s take a look at each of these steps.

Moving inputs from the chain to the rollup

To run transactions on the rollup, users must initially own inputs on Orbis. To do so, they must first send some of their funds from L1 (Cardano) to L2 (Orbis).

Sending funds is a three-step process:

1. Lock L1 funds - Funds are sent to the verifier smart contract address on L1. This process is called “locking” the funds.

2. Mint funds on L2 - The prover mints a new input on Orbis based on the locked funds.

3. Rollup-state update - The prover creates a new block, and updates the roll-up state on L1, moving locked funds to the verifier smart contract state UTxO.

Submitting transactions to the rollup

After users have funds available on the rollup, they can start submitting transactions to Orbis. This process will be somewhat similar to the equivalent process on Cardano.

It involves three steps:

1. Reserving the on-rollup input UTxOs - The purpose of this process is to avoid resource-contention problems that would prevent the transaction from going through. These locks should be temporary and expire automatically after a short time sufficient to complete the transaction.

2. Generation and posting the transaction to the rollup by the wallet - The wallet generates and sends the unsigned transaction to the user’s wallet to be signed. The wallet signs the transaction with the user’s approval. The wallet receives the signed transaction from the wallet and posts the transaction to the rollup by calling the prover API.

3. Processing of transactions and creation of blocks on the rollup - The prover will periodically process submitted transactions (stored in the transaction pool) and create a new block on the rollup. After creating a block on the rollup, the prover will send an update to the verifier smart contract on L1. After receiving and validating that update, the verifier will update the proof in the verifier smart contract state UTxO.

Moving outputs from the rollup

To be able to spend L2 outputs on the mainchain (L1), the user must move them back to L1 through a two-step process:

1. Submitting LeafOutTx to the prover - A LeafOut transaction is sent to the prover to retrieve the funds from L2.

2. Rollup-state update - The prover creates a new block and updates the rollup state on L1, transferring the requested funds from L2 to L1.

Halo 2 is the name of both a leading-edge zk-SNARK theory and its implementation. It was developed by the team behind Electric Coin Co., the inventors of Zcash. Halo 2 is a successor to Halo, and both systems are inspired partly by the zk-SNARK theories PLONK and Sonic, among others.

Orbis Labs chose Halo 2 as the basis for our zk-SNARK implementations due to the following considerations. In no particular order:

• Relatively stable and mature. It is audited, production ready, and used at scale in production.

• Efficient proving algorithm.

• Relatively small proofs which are not very computationally difficult to verify.

• Rich ecosystem of tooling, SDKs, and reusable circuit code.

• Does not require a trusted setup process and has no trust assumptions. Verifiers need not trust provers or any third party.

Blockchain trilemma

The Blockchain Trilemma refers to the conundrum that decentralized networks can only provide two of three benefits simultaneously concerning decentralization, security, and scalability. The blockchain design paradigm is shifting from a traditional monolithic design to modular architecture to break the blockchain trilemma.

Scaling solutions

The L1 Cardano blockchain suffers from performance and throughput issues because of the inherent difficulties in scaling a decentralized consensus protocol. The most practical way to address these issues is to develop general-purpose L2 solutions on top of Cardano. Rollups are general-purpose L2 solutions. There are two types of rollups, optimistic- and zk-rollups. Optimistic rollups assume all transactions to be valid by default, then they roll up transactions into batches & submit them to L1. The transaction can be challenged if fraud is suspected. In the event of a challenge, the optimistic rollup executes a fraud-proof. Like an optimistic rollup, a zk-rollup accumulates a set of transactions off-chain and periodically updates an on-chain rollup contract state to reflect the transactions that have occurred. Unlike an optimistic rollup, zk-rollups do not add a transaction to the rollup until the transaction has been checked and found to be valid. A sidechain, another type of scaling solution, is a blockchain that communicates with the L1 blockchain or “mainchain” via some type of cross-chain data transfer protocol.

Orbis protocol

Orbis is the first zk-rollup L2 solution for Cardano built to support decentralized finance (DeFi) applications and a thriving blockchain ecosystem. Transactions occur off-chain on the Orbis layer 2 and are bundled together into a single zk (zero-knowledge) proof which is submitted on-chain to the Cardano layer 1 and verified. This proof is a zk-SNARK. This proof provides mathematical and unfalsifiable proof that the transactions have happened on Orbis. Similar to Cardano, Orbis is built on an extended UTxO model. Orbis will be developed in a series of iterations, advancing Orbis from a centralized protocol running on a single machine to a distributed protocol with centralized governance, and finally to a decentralized protocol with decentralized governance.

Arithmetized rollup validation with inputs and outputs

Designing and coding arithmetic circuits manually are laborious and error-prone. Therefore, Orbis Labs sought an automated method of creating arithmetic circuits. The goal of this research is to enable the relations to be arithmetized, to be written in a specification language, without any nonessential implementation details, and then transform those specifications into code to build arithmetic circuits.

The only way to validate the specification is to be able to look at it and know intuitively that it does specify the intended relation. For this, the specification must be as obvious and clear as practicable.

Programming languages do not necessarily make good specification languages. For this reason, instead of leveraging an existing zk-SNARK programming language, Orbis Labs opted to create a new specification language for expressing the Orbis rollup validity relations. This specification language must satisfy two design constraints:

1. It must allow the Orbis rollup validity relations to be fluently expressed without nonessential information.

2. A provably correct and reasonably efficient method must exist for translating the specification into a Halo 2 circuit.

For these purposes, Orbis Labs created the Orbis Specification Language (OSL).

Orbis Specification Language (OSL)

Orbis Specification Language (OSL) is similar to languages like Haskell and Coq, which can express statements in a math-like, machine-readable notation. The difference is that OSL is engineered to be amenable to translation into a form which can be used to make zk-SNARK proofs. OSL takes away the zk-SNARK engineer's burden of making a non-obvious translation of a statement into a form which can be proven by a zk-SNARK.

Our published paper is shown below:

Orbis Labs is investigating two approaches for scaling the proof system by using recursion.

In the first approach, proofs are passed as parameters in the OSL spec, which asserts that the proofs are verifiable. This approach is more straightforward to understand, but it has the disadvantage of adding incidental complexity to the spec, and the use of recursive proofs would not be expressed as part of the spec.

The next potential approach incorporates recursive proofs into the Σ¹₁ arithmetization scheme. The concept is that we would like to prove a statement for which the corresponding circuit would have a potentially infinite number of rows. A feature which Halo 2 does not support.

“zk-SNARK” stands for “zero-knowledge succinct non-interactive argument of knowledge.” zk-SNARKs are a type of zero-knowledge proof.

What is a zero-knowledge proof?

It is a cryptographic technique, where one party (The Prover) can prove that a specific statement is true to the other party (The Verifier) without disclosing any additional information.

A zk-SNARK is a type of zero-knowledge proof that has 3 core characteristics.

• “Succinctness”, which means the proof is not lengthy. This property reduces the costs of storing and transmitting proofs

• “Non-interactive”, meaning that a zk-SNARK consists of a single message as opposed to an interaction.

• “Zero-knowledge”, meaning that the proof does not reveal any information beyond the statement that it proves to be true.

Leading-edge zk-SNARK theories also provide the benefit of inexpensive proof checking. Even when the proof is expensive to generate, the proof’s size and the complexity of checking the proof do not increase.

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).

Out of the box, Orbis will support writing on-rollup smart contract scripts in Haskell using PlutusTx, Plutarch, and in Pluto. All these script languages will have a shared compilation pipeline that compiles to TinyRAM via UPLC.

PlutusTx and Plutarch are domain-specific languages embedded in Haskell (Haskell-EDSLs). Pluto is a language built from scratch and not embedded in another language. Pluto and Plutarch were created to address several performance issues involving the Haskell-to-Plutus code generation in PlutusTx. PlutusTx has several performance problems regarding the size of the generated code and the time and space required to execute the resulting code. In comparison, Pluto and Plutarch have shown improvements by orders of magnitude in all these metrics in porting programs from PlutusTx to Pluto or Plutarch.

Orbis Labs will provide SDKs that allow the off-rollup portions of a dapp that interact with the on-rollup contract to be written in various languages. Orbis will include SDKs for writing the off-rollup portions of a dapp in Haskell, TypeScript/JavaScript, and Python. Over time, off-chain dapp code development SDKs for more languages will be added.

In discussing the correctness of a distributed system, two properties are usually referred to as safety and liveness.

A safety property of a distributed system means that nothing “bad” ever happens during the execution of a concurrent program. This means the system never enters a state that is considered incorrect by the protocol that it follows.

Liveness, defined informally, is a property that asserts that “good” things eventually happen during the system execution. Meaning, that the system continues operating according to its protocol.

The liveness analysis of Orbis will operate under the assumption of a partially synchronous network, which guarantees that the messages are delivered within some finite time-bound. But in the full asynchronous model, liveness cannot be guaranteed.

We plan for Orbis to be a system that is safe throughout its entire execution, even in a fully asynchronous model.

If congestion exists on L1 (Cardano), Orbis will not be able to push zk-SNARK updates to the verifier smart contract, but it will be able to periodically forge new blocks and eventually push an update to L1 after the congestion is no longer present.

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.

Programming on Orbis

Orbis aims to provide a developer experience largely compatible with the Cardano developer experience for writing L1 dapps. Dapp development on Cardano is based on the extended UTxO (eUTxO) model. The eUTxO model allows for architecting dapps that can scale to massive levels of throughput. Orbis will be built on an eUTxO data model that is isomorphic primarily to the data model on which Cardano is built. The core abstract data models are the same, but several differences exist.

Orbis features transaction types that are not present on Cardano and handle sending funds to Orbis from Cardano and back. Staking primitives appear in the Cardano eUTxO model but not the Orbis eUTxO model.

Another significant difference between the eUTxO model implementations of Cardano and Orbis is the representation of scripts. In Cardano, scripts are represented on-chain as Untyped Plutus Core (UPLC) bytecode. In Orbis, scripts are represented on-rollup as TinyRAM object code. By representing on-rollup scripts as TinyRAM object code instead of UPLC bytecode, Orbis will allow more efficient compilers targeting Orbis scripts. The core reason for selecting TinyRAM object code as the scripting language is that TinyRAM is amenable to efficient arithmetization. Another benefit of using TinyRAM object code as the scripting language is that TinyRAM is a suitable compilation target for all general-purpose programming languages.

In this setup, the system runs on a single machine controlled by Orbis Labs.

This system is fully centralized. Because Orbis Labs will control this single node, it becomes a single point of failure. It is neither crash-only nor resistant to Byzantine failure.

This system should be considered a milestone that enables testing of all user-facing features like sending funds, submitting transactions, inspecting the rollup, retrieving funds, and syncing the rollup with layer 1.

This distributed system has a single master node and multiple worker nodes. This configuration is static. This means it is fixed upon initialization and cannot change during runtime. The master node divides work among the worker nodes. After receiving partial results, the master node combines them and updates layer 1.

Although the system becomes distributed, it is still fully centralized. Because Orbis Labs control all nodes, the failure of either the master node or all worker nodes shuts down the entire system in this setting. Nevertheless, the system can fully recover from failures of individual worker nodes. The system remains live and operational as long as at least one worker node and master node are running.

The system will run a fully distributed database that stores the transaction pool and the rollup. The master node will be the only machine with read-write access to the database, whereas worker nodes will have read-only access.

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.

Orbis will essentially consist of an L1 smart contract and an associated contract state UTxO; a network of prover nodes; a rollup data structure; the prover node software; and the associated SDKs. Each component may need to be updated to perform an upgrade.

A smart contract cannot be updated after it is deployed on Cardano. The only way to upgrade a smart contract is by deploying a new script.

To enable a transparent upgrade process for the layer 1 rollup smart contract, the L1 rollup contract must contain a governance protocol.

The initial release of Orbis will feature a governance protocol that is based on voting, which is not fully decentralized. The governing body or the “board” of Orbis V1 will be a group of individuals identified by their public keys. Orbis Labs will determine the initial composition of the board.

In the centralized versions of Orbis, the prover could potentially manipulate elections not by creating fake votes but by excluding real votes. This is a special case in the centralized versions of Orbis in which the prover could censor transactions. This loophole will be solved in the first decentralized version of Orbis.

The first fully decentralized version of Orbis will feature a decentralized governance protocol. Meaning, that it allows for the participation of an unlimited number of actors in the system. The design of the decentralized governance protocol will be announced in a future revision of the whitepaper.

The most relevant performance measures for user experience with Orbis are throughput and latency.

Latency is the amount of time between a user initiating action and the action is completed. Whereas, throughput is the number of user interactions that can be processed in a given time period.

The latency of a concurrent process is greater than or equal to the sum of the durations of the longest chain of steps in the process. For example; adding funds to or removing funds from the rollup is limited by the throughput and latency of the blockchain (Cardano). However, latency on Orbis itself for transactions would not be limited by Cardano and would be shorter.

When it comes to the throughput, the Orbis architecture should be able to scale to any level that the market would support. This will be achieved in a series of iterations in which different limiting factors are incrementally improved to achieve the level of scale that the market demands.

In contrast to the EVM, the eUTXO model of Cardano allows for a local state for the smart contracts and parallel execution of transactions. Because of this zk-rollups on Cardano can achieve a better throughput than Ethereum Virtual Machine (EVM)-based zk-rollups.

Proof-carrying data refers to the process of providing a zk-SNARK as input to an arithmetic circuit in order to produce another zk-SNARK which validates the input zk-SNARK.

Proof-carrying data and recursive proofs, as well as zk-SNARKs more generally, are useful concepts for creating interoperability between different trustless protocols.

One design principle of Orbis is that all the world’s demand for zk-rollups could be met by one rollup. In reality, more than one zk-rollup will exist and an open decentralized financial ecosystem cannot become a reality without protocols for interoperability between decentralized protocols.

The concept similar to sending a UTxO between heterogeneous Orbis rollups can be applied to create bridges between zk-rollup protocols based on different zk-SNARK theories.

Applying the concepts requires only that

1. A zk-SNARK can be created proving the creation of a UTxO burning transaction in the source protocol.

2. A zk-SNARK can be validated as part of the conditions for validating a UTxO factory transaction in the destination protocol.

The concept of inter-protocol bridges opens the door to a concept of layer 3 rollups, which are rollups that use an L2 rollup in place of an L1 blockchain as the basis for the settlement and commitment protocol. Layer 3 rollups may be useful for specialized applications. This concept could be further extended to layer 4 rollups and beyond.

Data availability relates to the problem of how nodes in a network can be certain that a new block has been produced and that all the data in that block have been published to the entire network. This plays a major role in the consensus and liveness of the system. Data availability allows block producers to be held accountable for the data they post to the network and for creating new blocks and updating the consensus.

Validiums

Both rollups and validiums are L2 protocols that post validity proofs to the mainchain to be verified by an on-chain verifier contract.

The difference is that rollups for data availability solutions have all data stored on-chain, and those for validiums have data stored off-chain. Which introduces additional security and trust assumptions to the system architecture outside the L1 mainchain protocol.

Orbis will be launching first as a validium with an off-chain data storage solution and then transitioning toward a rollup with minimal trust assumptions after data availability on Cardano has evolved.

The on-rollup block header data alongside the on-rollup UTxO balances and their corresponding authorized signing keys will be posted and stored on-chain in the rollup UTxO, which is the verifier contract. The current rollup state and on-rollup transaction history will be stored off-chain in a fully distributed database.

The HALO token is the native token for Orbis.

It is designed to ensure that owners can participate in governance and will support decentralization of Orbis.

HALO is a fixed supply token whose inflation will be directed towards network supporters and participants.

The HALO token is used for:

• Transaction fees

• Rewarding/incentivizing network operators

• Network governance rights

Token Distribution

Pricing and Valuation

Vesting Schedule