Skip to main content

Open rollup - MVP - Phase 1

  • Team Name: Open rollup
  • Payment Address: 0xC1347410Ee2Fc96C4e5a090FF97E3937A8aE158F (DAI)
  • Level: 2

Project Overview 📄​

Overview​

Description. Open rollup provides a powerful and complete ZK rollup solution for substrate-based chains without contract enabled.

Background. We have developed some blockchain products, and the blockchain scalability problem is a serious problem. We believe that the off-chain zkapp solution is one of the best solutions to this problem.

Proposal. We propose an open zk-rollups hub solution based on Substrate. There is no central operator here. Each zkapp developer can freely register their own zkapp on the chain, implement their own offline logic, and submit their ZK Proofs and state changes for their batch transactions.

Zkapp. Zkapp can be a simple voting app, or a professional layer 2 solution with EVM support like zksync.

Project Details​

The core of Open rollup is open-rollup-pallet, which saves the program-hash, balance, operations (e.g., transfer, swap, move), and account state root hash of each zkapp. In addition it saves each users' balance of each zkapp, one child trie per zkapp. It includes two main components: rollup and verifier. The rollup component includes a zkapp registration, user deposits to a zkapp, exit when a zkapp is inactive which didn't submit a batch within 7 days and the handling of full-exit operations on the zkapp side. Due to resource and time constraints, this proposal currently contains a rollup component, and a miden verifier instead of a zkvm that we want to implement in the future. The verifier will be included in future proposals, and the rollup part will also increase the support of tokens and NFTs. Our initial idea about the verifier is to implement the verifier of Cairo VM in the future, which requires implementing the AIR of zkstark for Cairo VM. Then the developers of zkapp can use Cairo-lang to develop zkapp.

Protocol overview​

We give a brief overview of the rollup protocols.

  • Zkapp registration. Developers use a program-hash to register a zkapp. The program-hash is derived from the bytecode of the zkapp. If the zkapp is open source, users can verify that the program-hash is indeed corresponding to the zkapp. In addition, the program-hash is also a public output of the verifier, which ensures that the submitted proof is indeed generated by this very zkapp's execution.

  • User deposit. Users who want to participate in a zkapp deposit to this zkapp, and the batch submitted by this zkapp needs to include this deposit.

  • User withdraw. If this zkapp ignores the user's operation in zkapp, the user can submit an withdraw transaction, and this zkapp must include this withdraw operation in the next submission.

  • User full exit. If the zkapp has not been submitted for a period of time, the user can exit the zkapp and withdraw the assets.

  • Zkapp batch submit. The submission includes the batch's commitment, operations, proof, and new and previous account state root hashes. The commitment is the hash of the batch's operations, it's the public output of the zkapp's execution, so the verifier can be convinced that the state transition of the operations is correct. Operations include transfers, swaps, moving to another zkapp, and exit ops, which are used to update user balances for int the zkapp.

  • Zkapp management The registrant of one zkapp can manage the batch submitter and manually set the zkapp to be inactive

  • Zkapps info api. Query the status (assets's balances, last submission time, inactive status) of each zkapp, and the assets's balances of each user in each zkapp

Prove and Verification abstraction​

Open rollup supports arbitrary programs (zkapp) to interact with it, the open rollup pallet runs on-chain (L1), and zkapp runs off-chain (L2). To ensure the correctness of off-chain zkapp execution and state transitions, open rollup abstracts a zkvm that runs off-chain, and an on-chain verifier verifies the batch submitted by zkapp.

  • zkvm run a zkapp program, generate proofs
  • program zkapp program, consisting of zkvm instructions
  • program_hash any zkapp can be reduced to a single 32-byte value, called program-hash, it ensures that the verifier verifies the execution of a specific program
  • zkapp-txs L2 transactions generated by the user's interaction with zkapp and L1 transactions submitted by the user to the Open rollup pallet (deposit/exit/move)
  • operations emitted by zkapp-txs (such as transfer, swap, move) to update state
  • state merkle tree of the account's balances of tokens of a zkapp
  • state root the Merkle root hash of the state of a zkapp
  • batch_commitment the state changes commitment (hash) of the batch, it ensures the submitted operations are the result of the batch's execution

Pseudocode run offchain on zkapp side

let (zk-proof, execute_program_hash, operations, new_state_root, batch_commitment) = zkvm.execute(program, current_state_root, zkapp-txs)
assert program_hash == execute_program_hash
zkapp.submit_to_onchain(program_hash, operations, current_state_root, new_state_root, batch_commitment)

Pseudocode run onchain on pallet side

assert current_state_root == saved_state_roots[program_hash]
let verifier = new MockVerifier()
assert batch_commitment == verifier.compute_batch_commitment(new_state_root, operations)
let public_inputs = (program_hash, batch_commitment)
assert verifier.vefify(zk-proof, public_inputs)
saved_state_roots[program_hash] = new_state_root

note

As the detailed zkvm is determined, this abstraction may change.

Scope of current proposal​

Due to the time and resource constraints of us, we limit the scope of the current proposal to implementing the on-chain rollup part of the pallet involving Currency(Balances pallet)/Assets(Assets pallet)/NFT(Uniques pallet). We are still considering and researching the proof and verification protocol, we can't provide very detailed details yet, we will design it while implementing this proposal.

Ecosystem Fit​

  • Where and how does your project fit into the ecosystem?
  1. Open zk-rollup architecture Developers who want to participate in the Polkadot ecosystem do not need to invest in their own zk-rollup technology alone so that more developers can participate in the development of zkapp.

  2. increase scalability The off-chain zkapps greatly expands the scalability of the Polkadot/Substrate.

  3. Modularity The architecture of Open rollup is suitable for different proof and verify protocols, and can adapt to zkapps of different ZK protocols in the future

  • Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?
  • What need(s) does your project meet?
  1. The application developers that are in search of scaling their blockchain application, for example, the payment application.
  2. The game developers who do not want to interact with the chain frequently only need to submit in batches for a period of time, which saves the cost of using the chain and improves the user experience.
  • Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?

There are many zk-rollup projects, such as zksync, starknet, hermez, plonky2, they are basically in the Ethereum ecosystem. They are all operated by a central operator, and in our protocol, each zkapp is an operator.

Team 👥​

Team members​

  • Chris Cen

Contact​

  • Registered Address: not yet available
  • Registered Legal Entity: not yet available

Team's experience​

Our team has a lot of experience in applied cryptography, blockchain research, and software development. Chris has been a software engineer for many years in the gaming industry and has led the development of various multiplayer online games. Recently he develop a hybrid consensus of Progpow and AuthorityRound https://github.com/chrisicen/openethereum-unity. He is currently devoted to the development of an off-chain ZK scalability solution for blockchain.

Team Code Repos​

Team LinkedIn Profiles (if available)​

not yet available

Development Status 📖​

We've been working on techniques for zk-rollup, and verifiable computation for some time, including projects like zksync, halo2, plonky2, winterfell, hermez, and related papers and articles. We are starting to implement the rollup part.

Development Roadmap 🔩​

Overview​

  • Total Estimated Duration: 7.5 months
  • Full-Time Equivalent (FTE): 1.5 FTE
  • Total Costs: 30,000 USD.

Milestone 1 — Implement Substrate Modules​

  • Estimated duration: 7.5 month
  • FTE: 1.5
  • Costs: 30,000 USD
NumberDeliverableSpecification
0a.LicenseApache 2.0
0b.DocumentationWe will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.
0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
0e.ArticleWe will publish an article/workshop that explains what was done/achieved as part of the grant.
1.Open rollup PalletWe provide the core data types and the functionalities(zkapp registration/user deposit/user exit/user full exit/zkapp batch submit/zkapp management/zkapp info api) which support currencies/tokens/NFTs as specified in Project Details.

- Pallet Data structures
- Zkapps: Map<programHash, zkappParams>, The zkappParams defining a zkapp, i.e., the ZkvmType, the submitter, and the inactive status
- ZkappStates: Map<programHash, childTrieRootHash>, A child Trie holds Users' balances of the Assets in each zkapp

- Pallet Functionality

- fn zkappRegister(programHash: Hash, zkvmType: ZkvmType): Register a zkapp on the pallet
- fn addAssetSuppport(programHash: Hash, asset: Asset): Add support of one asset in the zkapp
- fn changeSubmitter(programHash: Hash, asset: Asset, newSubmitter: AccountId): Change the submitter of the zkapp
- fn setInactive(programHash: Hash): Set the zkapp is inactive, no batch can be submitted in the future, and the users can send an exit transaction to withdraw their assets
- fn submitBatch(programHash: Hash, oldStateRoot: Hash, newStateRoot: Hash, operations: Vec<Operation>, proof: Vec<u8>): Submit a new batch providing the L2 operations (transfer, swap, move, withdraw)
- fn deposit(programHash: Hash, asset: Asset): Deposits a given amount of assets into the zkapp.
- fn withdraw(programHash: Hash, asset: Asset): Withdraws a given amount of assets from the zkapp to the owner
- fn moveAsset(fromProgramHash: Hash, toProgramHash: Hash, asset: Asset): Move a given amount of assets from one zkapp to another zkapp
- fn exit(programHash: Hash): If one zkapp is inactive, the user can exit the zkapp and withdraw the assets
2.Miden verifier in Open rollup PalletWe provide the verifier trait suitable for general apps, and a miden verifier that implements the verifier trait.

Future Plans​

  • A proof and verification protocol for developing Cairo programs using the Rust language.
  • Add recursive zero-knowledge proof protocol

Additional Information ➕​

How did you hear about the Grants Program? Recommendation from a friend in the Bifrost team.