Levitation Protocol Summary of Ideas

Draft v1.5

Three challenges Levitation solves

ZK-rollups (ZKRs) are Layer 2 solutions that use cutting edge mathematics of ZK proofs to execute and prove transactions in ZK-EVMs outside of Ethereum mainnet, and then
post transaction data and ZK-proofs to the mainnet for verification. ZKRs inherit the full security guarantees of the mainnet.

The purpose of Levitation protocol is to enable wide spread adoption of ZKRs by addressing the following challenges:

  1. Centralization: ZKRs presently running in production tend to be centralized.

  2. Fragmentation: there is a large number of actively developed ZKR projects. Dapps need a modular interoperability layer, where different ZKRs can run seamlessly.

  3. Isolation: ZKRs do not have access to the state of each other. This makes secure cross-ZKR interactions, such as token transfers, hard to implement.

Levitation solution

Levitation protocol addresses the above challenges by describing an implementation a decentralized sequencer as a set of smart contracts deployed to a high-performance EVM-compatible blockchain.

The sequencer protocol has pluggable modular architecture, enabling existing ZKRs to run seamlessly on chains implementing Levitation protocol.

Here are the three main advantages of Levitation

  1. Decentralization: Existing ZKRs, when executed on Levitation, become decentralized, without requiring any modifications to the underlying software.

  2. Interoperability and Modularity: Levitation turns existing ZKRs into modules that interact with each other seamlessly.

  3. Common security: Multiple ZKRs can run in a common environment of a single Levitation-enabled chain. This enables a common ledger of transactions and eases interaction of rollups.

We target the maximum simplicity and ETH-compatibility of the protocol, so it can run on a wide variety of existing and new ETH-compatible blockchains.

# Levitation Protocol

## Decentralization

- running on blockchain
- implemented as smartcontracts

## Interoperability and Modularity

- Turns existing ZKRs into pluggable modules
- Uses standard Solidity tools and libraries

## Common security
- Can run multiple ZK-rollups on a single Levitation chain
- Provides common transactions ledger and state info

Protocol overview

Existing ZKRs implement six stages:

# ZKR

## Transaction submission

## Pending queue

## Sequence transactions


## Execute and prove

## Relay to mainnet

## Verify ZK-proofs
  1. Submission: users submit transactions
  2. Pending queue: transactions placed into a queue
  3. Sequence transactions: transactions ordered into block candidates
  4. Execute and prove: block candidates are executed and injected with ZK proofs to yield ZK-blocks
  5. Relay to mainnet: ZK-blocks are posted to the verifier contract on the mainnet.
  6. Verify ZK-proofs: ZK-proofs are verified the verifier contract

Levitation protocol creates a universal interoperable layer to take care of steps 1, 2, and 4. Existing ZKRs are then plugged into Levitation-enabled chains to perform Step 4 Execute and prove and Step 6 Verify ZK-proofs.

Before and after comparison

The diagrams below illustrate execution of two ZKRs (ZKR1 and ZKR2) before and after introduction of Levitation.

Before Levitation, each of the ZKRs implements the six stages

graph LR;
    Z1[ZKR1 submit]-->A1[ZKR1 Queue] --> B1[ZKR1 Sequence] --> C1[ZKR1 Execute and Prove]--> D1[ZKR1 Relay]--> E1[ZKR1 Verify];
    Z2[ZKR2 submit]-->A2[ZKR2 Queue] --> B2[ZKR2 Sequence] --> C2[ZKR1 Execute and Prove]--> D2[ZKR2 Relay]--> E2[ZKR2 Verify];

After Levitation, each ZKR needs to implement stage 4 and 6 as a Levitation module, while the remaining stages are implemented by Levitation.

In other words, Levitation handles transaction acceptance, ordering, and network relay, while ZKRs handle ZK-related operations (execution, proving and verification).

graph LR;
    Z1[Levitation Submit]-->|txs| A1[Levitation Queue] -->|txs| B1[Levitation Sequence] -->|candidates| C1[ZKR1 Execute and Prove]-->|blocks| D1[Levitation Relay]--> E1[ZKR1 Verify];
    B1 -->|candidates| C2[ZKR2 Execute and Prove]-->|blocks| D1[Levitation Relay]--> E2[ZKR2 Verify];

Minimalistic design

We target minimalistic protocol design focusing on implementation speed, simplicity and security. A small team of engineers should be able to efficiently implement Levitation using existing opensource libraries and tools.

We also aim to minimize time required to a new ZKR implementation to Levitation.

Security-first Solidity

Security-relevant source code of Levitation is implemented in Solidity and deployed as a set of smart contracts to an EVM-compatible chain.

Using existing Solidity tools and libraries enables fast and secure implementation of the protocol as well efficient third party audits.

Flexible performance vs security

Levitation protocol is designed to run runs on a high-performance, fast-finality, decentralized EVM chain.

When running on a Levitation-enabled chain, Dapps can utilize the Levitation chain itself for fast interactive transactions that do not require security guarantees of the mainnet.

To enable this functionality Levitation introduces programming abstractions of ZKChain and FastChain.

# Levitation

## ZKChain: high security transactions, equivalent to ETH mainnet
## FastChain: fast interactive transactions

Dapps running on a Levitation-enabled chain see Levitation as two chains ZKChain and FastChain, connected by a bridge. Dapps can take advantage of high security of ZKChain and high performance of FastChain.

As an example, a web3 game will use ZKChain to mint NFTs, while implementing interactive gaming dynamics on FastChain.

Transparent MEV protection

Levitation protocol orders transactions on chain before passing them to an ZKR implementation.

This enables a simple and powerful protection mechanism against front running and MEV that does not require modification of ZKR implementation. We call it Transparent Transaction Encryption (TTE).

A user:

  • encrypts a transaction and submits it (Stage 1)
  • Transaction is stored in the pending queue (Stage 2)
  • Levitation creates a candidate block (Stage 3)
  • User decrypts the transaction just before the candidate block is passed to Stage 4
  • Since at this point the transaction is decrypted, Stage 4, 5, and 6 are executed on the plaintext transaction.
graph LR;
    A1[User encrypts and submit tx] --> B1[tx included in candidate block ] --> C1[User decrypts tx before Execute and Prove phase]

Since the transaction is decrypted after it has been included in a block candidate, the user is protected against front running and MEV. In particular, it is too late for other users to insert transactions in front of the user transaction.

High Level Architecture

High Level Architecture for protocol is illustrated below

  • Users submit transactions to ZKQueue contract on Levitation chain
  • ZKQueue contract validates transactions and stores them, ordering them in the order of receipt in a single ledger, splitting them logically into ZKBlockCandidates.
  • ZKProcessor agents pull ZKBlockCandidates from ZKQueue
  • ZKProcessor agents use rollup-specific software (RSS) plugin modules to execute and prove ZKBlockCandidates, creating ZKBlocks.
  • ZKProcessor agents push ZKBlocks to the ZKBlocksStorage contract on the Levitation chain, where they are verified and stored.
  • ZKRelay agents push ZKBlocks to the corresponding Rollup-specific Verifier Bridge contract (RSVBC), that verifies ZKBlocks and bridges tokens from/to ETH mainnet.
Select a repo