Skip to content

Ztarknet/ztarknet

Repository files navigation

Ztarknet logo

Ztarknet 🛡️🐺

Starknet-based L2 for Zcash

Repository · Circle STARK-enabled Zebra fork · Circle STARK draft ZIP · Forum discussion

Status: concept + references for a proof-of-concept (PoC). This repo documents the idea, constraints, and minimum components to explore a Starknet-like rollup that settles to Zcash L1 via a Transparent Zcash Extension (TZE) that verifies Circle STARK proofs.

What is Ztarknet 🛡️🐺?

Ztarknet 🛡️🐺 proposes a Starknet-style L2 that executes Cairo programs, proves the resulting state transitions with Circle STARKs (Stwo), and settles those transitions on Zcash L1 by having full nodes verify the proof natively via a TZE verifier. It reuses an existing Starknet client (e.g., Madara) for sequencing/execution and a Stwo/Cairo prover for proofs. The L1 verification surface is a single TZE type defined by a draft ZIP.

Why Zcash? Zcash already offers strong base-layer privacy. Ztarknet explores programmability and scale via an L2—with validity proofs checked natively on Zcash using the TZE framework (ZIP-222) and the associated digest changes (ZIP-245/244).

Rationale

  • Separation of concerns: keep Zcash L1 minimal, push general execution to an L2 VM (Cairo), and anchor L2 with succinct validity proofs.
  • Clean L1 integration: use a TZE rather than Script changes; TZEs were designed to add new transparent validity conditions in a well-bounded way.
  • Rust-native path: Madara (Rust) and Stwo/Cairo (Rust verifier + CLI) keep the prototype within Zebra’s Rust ecosystem.

Prerequisites and scope

  1. TZE verifier on Zcash — a draft ZIP introduces a Circle‑STARK verifier as a TZE (single type, one mode). Zebra fork with draft plumbing is here.

  2. Sequencer/execution — reuse Madara (Starknet client, Rust) for L2 networking, JSON‑RPC, execution, and local state.

  3. Prover — use Stwo/Cairo to produce Circle‑STARK proofs of Cairo programs (cairo-prove JSON for the MVP).

  4. Data Availability (DA) — PoC will start minimal (publish L2 state roots only). DA must be evaluated separately. Main focus for now is the proof verification.


High‑level architecture

flowchart TB
    subgraph Users["Users"]
        direction TB
        U["Wallets and dApps"]
    end

    subgraph L2["Ztarknet L2 (Starknet compatible)"]
        direction TB
        RPC["JSON-RPC (Madara)"]
        MEM["Mempool"]
        EXE["Cairo VM Execution"]
        ST["State DB and State Root"]
        PROV["Prover Workers (Stwo/Cairo)"]
        AGG["Proof Aggregator (optional)"]
    end

    subgraph L1["Zcash L1"]
        direction TB
        ZN["Full nodes (Zebra)"]
        TZE["TZE: Circle-STARK Verify"]
        CHAIN["Chain / Miner"]
    end

    U -->|send L2 tx| RPC
    RPC --> MEM --> EXE --> ST
    EXE -->|block trace| PROV --> AGG
    AGG -->|Circle-STARK proof and state root| ZN
    ZN --> TZE --> CHAIN
    CHAIN -->|anchor new L2 root as TZE output| ZN
Loading
  • Sequencer: batches L2 txs, executes Cairo contracts, computes next state root.
  • Prover: consumes the execution trace, generates a Circle‑STARK proof.
  • Submitter: builds a Zcash TZE transaction that spends the previous L2 anchor and creates the next anchor, carrying the new root and proof.
  • Zcash nodes run the TZE verifier (per ZIP) as part of tx validation; if valid, the anchor updates on L1.

Starknet’s own docs describe this pattern generically (accounts, block state commitments, proof generation/verification on L1, and DA). Ztarknet mirrors that flow but anchors to Zcash via TZE instead of a Solidity verifier on Ethereum.

Settlement pattern on Zcash L1 (anchor UTXO)

TBD: mostly raw thoughts at the moment, and far from fully fleshed design

Anchor UTXO chain: represent L2 progression as a chain of TZE outputs:

  • Genesis: create Anchor_0 TZE output with precondition committing to root_0.
  • Step k→k+1: submit tx that spends Anchor_k and creates Anchor_{k+1}. The TZE witness carries a proof that executing the Cairo L2 program from root_k with block k+1 txs yields root_{k+1}. The precondition of Anchor_{k+1} commits to root_{k+1}. Zcash nodes verify the proof using the TZE verifier; if valid, Anchor_{k+1} becomes the new on‑chain commitment.

This uses ZIP‑222’s model (precondition/witness per extension type) and integrates with ZIP‑245/244 digests so TZE data is committed correctly in txid/signature trees.

End‑to‑end flow (happy path)

sequenceDiagram
    autonumber
    participant User
    participant Sequencer as Sequencer (Madara)
    participant Prover as Prover (Stwo/Cairo)
    participant Submitter as L1 Submitter
    participant Zcash as Zcash Nodes (Zebra+TZE)

    User->>Sequencer: send L2 tx via JSON RPC
    Sequencer->>Sequencer: order txs, execute Cairo, compute next state root
    Sequencer->>Prover: emit execution trace for the new block
    Prover->>Prover: generate Circle-STARK proof for the transition
    Prover->>Submitter: deliver proof bundle with the new state root
    Submitter->>Zcash: broadcast TZE tx (spend previous anchor, create next anchor)
    Zcash->>Zcash: verify TZE witness with Circle-STARK verifier
    Zcash->>Zcash: on success, include tx in block and anchor the new root
Loading
  • Sequencer/exec can be Madara (Rust Starknet client), which has Starknet‑compatible RPC and computes state commitments.
  • Prover uses Stwo/Cairo; for the PoC we can consume JSON (cairo-prove) directly.
  • Verifier on L1 is the TZE described in the draft ZIP: a single type/mode whose tze_verify invokes the Stwo verifier on the witness bytes and checks the claimed public inputs/commitments.

Components to stand up a PoC

  • L2 node: Madara—run a local testnet sequencer (Starknet‑compatible RPC), produce blocks and state roots.
  • Prover: Stwo/Cairo—generate proofs for small Cairo programs with cairo-prove; start with simple programs (hashing/merkle updates) and progress to a minimal L2 state transition.
  • Submitter tool: small Rust bin to bundle (precondition, witness) and build a TZE tx.
  • Zcash node: Zebra fork with the TZE verifier enabled, gated on a dev/test network activation.

Getting Started

Start Madara Devnet

To start your Madara devnet, run:

docker compose -f docker-compose.devnet.yml up

This will start a local Starknet-compatible devnet that you can use for development and testing.

Explore with Cosmos Explorer

You can use the open source Cosmos Explorer to interact with your devnet:

  1. Clone the Cosmos repository:

    git clone https://github.com/justmert/cosmos.git
    cd cosmos
  2. Set up environment:

    cp .env.example .env
  3. Update the RPC URL in .env to point to your Madara devnet:

    STARKNET_RPC_URL=http://host.docker.internal:9944
    
  4. Start the explorer:

    docker compose up

The explorer will be available at http://localhost:5600 and will connect to your Madara devnet running on port 9944.

Prover

Coming soon!

Resources

License

This project is licensed under MIT.

Releases

No releases published

Packages

No packages published

Contributors 5