Skip to content

Orbis

Jump to bottom
Sebastian Nagel edited this page Mar 8, 2022 · 4 revisions

Orbis is a Zero-Knowledge (ZK) rollup layer 2 protocol for Cardano

Introductory blog post: https://blog.orbisprotocol.com/p/enter-orbis?s=r

Requested funding in Catalyst Fund8: https://cardano.ideascale.com/c/idea/396617

Two documents had been shared with us so far (both dated March 4 2022)

  • Orbis System Architecture: overview of the Orbis protocol and its defining features for a technical audience
  • Orbis Technical Whitepaper: very detailed discussion of zkSNARKs, still incomplete (not public yet)

Notes on "Orbis System Architecture"

Overview:

  • uses zkSNARKS
  • trustless & open
  • based on CRDT?
  • prover has a node-like interface
  • verifier is an on-chain contract

zkSNARKS allow constant O(1) verification of potentially infinitely many off-chain transactions.

Mentions CRDT and that some data structures can be made conflict-free by carefully choosing mutations (e.g. removals from a queue) to be timely. (Not sure why this is included though)

Orbis provides an off-chain context in which smart contract validator code can run. (what does that mean?)

Uses Halo 2 for zkSNARK implementation: "has small proof sizes, of several kilobytes or less"

DApps need to know about the rollup. (Probably the same holds also for Hydra, unless the whole DApp runs "in a Head").

Posting transactions to a roallup requires to put a lock on the inputs to avoid contention problems. In turn requires collateral, which is slashed if the input goes unused.

Adding UTXOs requires two transactions on-chain? Seems like the rollup state is also governed by a UTXO which will be used to "consume" the input UTXO in a so-called "input transaction".

Removing UTXOs is also two-steps, comprised by a "removal" and "output transaction". The output transaction is very similar to the incremental de-commit transaction of a Hydra Head.

Concurrent construction of proofs is possible given the transactions are independent.

Full decentralization with no single point of failure (updating rollup contracts?) is not scope of the initial release. Authorization via stored public key hashes and authorization tokens are discussed.

Interesting discussion of centralizing access to avoid contention/conflicts between provers vs. denial of service. Keep-alive on contract state + backup mechanism of removing funds to mitigate (somewhat). Also, mentions this would only work for pub key addresses and not funds addressed to scripts? Why not? In a decentralized setting, they recommend slashing when provers not honor a CRDT-based off-chain queue ... but then argue it won't be implemented because it would need to be enforced by the contract. They deem it "acceptable risk" as they will be the only authorized (centralized) prover on release.

Questions

  • Where's the catch?
    • a very/too high constant of O(1)?
  • Why is not the whole Ethereum ecosystem running on zk rollups if this solution is superior?
  • When are transactions final in this system?
    • triggered by reading "can scale to any required level of throughput."
    • how often will the proofs be posted on-chain
    • in the fees section it is briefly mentioned that collected fees need to include this on-chain posting cost
  • Is holding funds hostage a form of custody? Not fully trustless after all?
  • Why no script address support for backup mechanism?
    • would be incompatibility with any form of script-based wallets
  • How hard is it to verify correct implementation of zkSNARKs? i.e. if once audited, how expensive would a re-audit be if a new prover/verifier implementation was made?
  • What about on-chain limitations, in particular transaction size? Is there a way to split a rollup (i.e. sub-proofs)?
  • The solution described in the system architecture sounds very much custodial; what guarantees or control do users have on their funds once they lock into a roll-up?
  • Part of the technical documents re-define the "Plutus stack" and how Orbis will defer from Plutus (TinyRAM vs UPLC, Pluto, Plutarch...) though, this seems quite orthogonal to Orbis and rollups in general. What's up about that?

Fun facts:

  • The word "rollup" occurrs 109 / 120 times in each of the documents
  • Quote: It is important to keep two terms distinct here: verifier and validator. [...] “Verifier” refers to the smart contract validator which validates transactions over the rollup smart contract. The verifier is a validator, but other validators are not verifiers.
Clone this wiki locally