ZK Proofs Explained with a Card Deck

Example 1 :

Imagine I hold 26 cards:
13 red cards and 13 black cards.

You want proof that my claim is true, but I don’t want to reveal the cards themselves.

The Challenge

If I simply show you the cards, my data is exposed.

But what if I can convince you that:

• I truly hold 13 red + 13 black cards
• without showing a single card
• and without revealing their order?

This is exactly what Zero-Knowledge Proofs (ZKPs) do in blockchains.

They allow:

Proving correctness without revealing the underlying data.

In blockchain terms:

• Transaction is valid
• Balance rules are respected
• State updates are correct

—without revealing transaction details.

Mapping the Example to Blockchain

So instead of revealing balances, signatures, or transaction internals, we publish a proof.

Nodes verify the proof, not the data.

Example 2 :

Imagine:

• I hold 26 face-down cards.

• I claim they contain:

  • 13 red

  • 13 black

But I don't want to reveal the cards.

Proof process

• You shuffle the deck so I can't cheat.

• I commit to the deck in hidden envelopes.

• You randomly pick cards and test color balance.

• Repeated checks convince you statistically.

• Yet you never learn card order.

  What just happened?

You verified:

✔ Claim correctness
✔ Without seeing card contents
✔ Without knowing card order

That is Zero-Knowledge Proof.

Blockchain mapping

Pipelines :

1. Transaction Execution Off-chain

   In a ZK system, the transaction is first executed off-chain, usually inside the user’s wallet or a prover service, before anything is sent to the blockchain.

   During this step:

   • The user’s wallet runs the transaction logic locally.

   • It checks balances, signatures, and transaction rules.

   • Private data (balances, inputs, keys) stays on the user side.

After execution, instead of sending full transaction data on-chain, the system generates a Zero-Knowledge proof showing the transaction followed all rules correctly.

Hence,
The heavy computation happens off-chain, while the blockchain only verifies a lightweight proof.

This reduces:

• on-chain computation,

• data storage,

• and transaction costs.

2. Circuit / Constrains validators

   In Zero-Knowledge systems, transaction logic is converted into a mathematical circuit made of rules called constraints.

   These constraints define what must be true for the transaction to be valid.

   For example, constraints may check:

   • Sender has enough balance

   • Signature is valid

   • Transaction amount is positive

   • No double spending occurs

   • New balances are computed correctly

Example logic:

    new_balance = old_balance - amount
    new_balance >= 0
    signature_valid == true

If all constraints are satisfied, the prover can generate a proof.

A ZK circuit is basically transaction logic rewritten as math, so correctness can be proven cryptographically without revealing the actual data.

3. Proofs Generation

   Once all transaction rules (constraints) are satisfied, the next step is Proof Generation.

   In this phase, the prover (usually the user’s wallet or a prover server) uses:

   • private transaction data,

   • circuit constraints,

   • and cryptographic algorithms

to generate a Zero-Knowledge proof.

This proof confirms that:

• the transaction followed all rules,

• computation was executed correctly,

• and no invalid state change occurred.

Importantly, the proof does not reveal private data, only that everything is valid.

4. On-chain Verification

   Instead of re-executing the whole transaction, the blockchain only checks whether the Zero-Knowledge proof is valid.
   Smart contracts or verification nodes run:

    verify(proof, public_inputs)
   

   Verification cost is small and constant.

   A verifier smart contract or protocol runs a verification function that:

   • checks the proof’s cryptographic correctness,

   • confirms all transaction rules were satisfied,

   • and approves the state update if valid.

This process is very fast and requires much less computation compared to executing the full transaction.

5. State Update

   Once the proof is successfully verified on-chain, the blockchain performs a state update.

   This means the network updates its records to reflect the transaction outcome, such as:

   • updating account balances,

   • marking transactions as completed,

   • or updating smart contract state.

At this point, the transaction is finalized and becomes part of the blockchain’s permanent state.

Only after proof verification succeeds does the blockchain update its state, ensuring that only valid transactions modify the network, even though the underlying data remains private.

ZK Architecture

Here’s a clean, architecture flow .

                USER / WALLET
        (holds private data & signs tx)
                          │
                          ▼
              OFF-CHAIN TRANSACTION EXECUTION
          (balances, signatures, contract logic)
                          │
                          ▼
                     ZK PROVER
            (generates cryptographic proof)
                          │
          Proof + Minimal Public Inputs sent
                          │
                          ▼
               BLOCKCHAIN VERIFIER CONTRACT
               (verifies proof correctness)
                          │
                          ▼
                     STATE UPDATE
        (balances & contracts updated on-chain)

• Heavy computation happens off-chain
• Blockchain only verifies correctness
• Privacy and scalability both improve

ZK Rollup

Now let’s go deeper and learn, What is a ZK Rollup?

A ZK Rollup executes many transactions off-chain, then posts:

• compressed state updates

• plus a ZK proof

  to the main chain.

  The chain verifies only the proof.

  ZK Rollup Architecture Flow

Users submit transactions
            │
            ▼
        Rollup Sequencer
 (orders & batches transactions)
            │
            ▼
   Off-chain Execution Engine
 (computes new state)
            │
            ▼
          ZK Prover
   (creates validity proof)
            │
            ▼
   Proof + New State Root posted
            │
            ▼
        L1 Smart Contract
      verifies validity proof
            │
            ▼
      L1 state finalized

Main Rollup Components

1) Sequencer

• Orders user transactions

• Builds transaction batches

• Improves UX latency

2) Execution Engine

Executes transactions off-chain:

• updates balances

• runs smart contracts

• computes new state root

3) Prover Network

Generates ZK proof showing:

• all transactions followed rules

• state transitions are correct

This is the heavy compute layer.

4) L1 Verifier Contract

Smart contract verifies:

verify(proof, old_root, new_root)

If valid → state update accepted.

Why ZK Rollups Scale

Instead of:

1000 transactions verified on-chain

You get:

1000 transactions
      ↓
1 proof verified on-chain

Result:

• Massive cost reduction

• Faster throughput

• Strong security inherited from L1

Ledger :

Now lets understand how the Ledger records everything On-chain.
Normally, the Ledger records:

• full transaction details,

• sender and receiver,

• balances,

• execution results.

Every node re-executes and stores everything.

In a ZK System

Instead of recording all details, the ledger records:

1. A cryptographic proof

2. Updated state result

3. Minimal public data

What Actually Gets Stored?

Think of it like:

Previous State → Transactions → New State

The chain stores:

Previous State Root
        ↓
ZK Proof confirming correctness
        ↓
New State Root

What is a State Root?

A state root is a cryptographic fingerprint of the entire blockchain state.

It represents:

• all balances,

• contracts,

• storage,

• accounts,

compressed into one hash.

If anything changes, the root changes.

Ledger Entry in ZK Rollups Looks Like

Batch ID: 1024
Old State Root: 0xA45...
New State Root: 0xB91...
Proof: Valid

The chain doesn't store each transaction individually — it stores proof that the update is correct.

Card Deck Analogy Version

Instead of writing down each card:

Ledger records:

“Deck changed from State A to State B, and proof shows rules were followed.”

Lets now understand how zkSync, Polygon zkEVM, and Scroll Pipelines Differ?

All three are ZK rollups, but they differ in execution design and proving approach.

1) zkSync Era — VM-Level Optimization

Pipeline idea:
Optimize execution for ZK proving rather than perfectly copying Ethereum.

Flow:

User Tx
   ↓
Sequencer orders tx
   ↓
zkSync VM executes
   ↓
Proof generated
   ↓
Proof + state root to Ethereum
   ↓
Verification on L1

Key traits:

• Custom VM optimized for ZK

• High performance

• Slight differences from Ethereum internals

Trade-off:
More performance, less strict Ethereum equivalence.

2) Polygon zkEVM — Full EVM Equivalence

Goal: behave exactly like Ethereum.

Flow:

User Tx
   ↓
Sequencer batches tx
   ↓
EVM executes exactly
   ↓
Execution traced
   ↓
ZK proof generated
   ↓
Proof verified on Ethereum

Key traits:

• Exact EVM compatibility

• Existing contracts deploy easily

• Slightly heavier proving

Trade-off:
Maximum compatibility, higher proving complexity.

3) Scroll — Native Ethereum Compatibility Focus

Scroll aims to keep Ethereum execution unchanged and prove it with ZK.

Flow:

User Tx
   ↓
Ethereum-like execution
   ↓
Trace generation
   ↓
Proof aggregation
   ↓
Proof verified on L1

Key traits:

• Strong focus on Ethereum parity

• Research-heavy proving system

• Developer-friendly migration

Trade-off:
Heavy proving workload.

Comparison

Algebraic Flow of ZK Proof from Generation to Ledger Update

Let the initial blockchain state be:

$$S0$$

whose cryptographic commitment (state root) is:

$$R0​=H(S0​)$$

A transaction T is executed via a state transition function:

$$S1​=F(S0​,T)$$

where:

• T = transaction data

• F = execution logic

Example:

balance′=balance−amount

subject to validity constraints:

$$C(S0​,T,S1​)=true$$

A prover then generates a Zero-Knowledge proof:

$$π=Prove(S0​,T,S1​)$$

private inputs + circuit + proving key

proof π

where:

• π= ZK proof

• proof shows constraints satisfied

• transaction data stays hidden.

The blockchain verifier checks:

$$Verify(π,R0​,R1​)=true$$

where:

$$R1​=H(S1​)$$

If verification succeeds, the ledger records the transition:

verify(proof, public_inputs, verification_key)

$$R0​π ​R1​$$

e(A, B) == e(C, D)

Thus, the blockchain stores proof of correct computation and the new state commitment, without revealing the underlying transaction data.

A Developer guide to begin with a zk-project

Project Folder Structure:

zk-project/
│
├── circuits/
│   └── transaction.circom
│
├── build/
│   ├── proving_key.zkey
│   └── verification_key.json
│
├── scripts/
│   ├── generateProof.js
│   └── verifyProof.js
│
├── contracts/
│   └── Verifier.sol
│
└── app/
    └── wallet integration

ZK Project Flow :

User Input
     ↓
Circuit Logic (Circom/Noir)
     ↓
Trusted Setup
     ↓
Prover generates proof
     ↓
Proof sent to smart contract
     ↓
On-chain verification
     ↓
State update

Minimal Developer Workflow Should Consists :

1. Write circuit logic

2. Run trusted setup

3. Generate proving & verification keys

4. Generate proof off-chain

5. Send proof to verifier contract

6. Contract verifies and updates state

Conclusion :

Zero-Knowledge Proofs introduce a powerful shift in how blockchains operate — replacing the need to reveal and re-execute every transaction with the ability to prove correctness without exposing underlying data. By moving heavy computation off-chain and verifying only compact proofs on-chain, ZK systems enable scalable, efficient, and privacy-preserving networks.

As adoption grows through rollups, private payments, and state compression, ZK technology is becoming a core layer of modern blockchain infrastructure. In the near future, users may not even notice these proofs working behind the scenes — they will simply experience faster, cheaper, and more secure transactions.

In essence, Zero-Knowledge systems show that blockchains don’t need more data to build trust — they just need better proofs.

"Building web apps is like constructing cities — React gives you the bricks, while Next.js gives you the blueprint."

Welcome to your go-to guide on React vs Next.js! Whether you’re a beginner just stepping into frontend development or an advanced developer looking to scale your app, this guide will help you understand when and why to use each.

🌱 What is React?

React is a JavaScript library developed by Meta (Facebook) for building user interfaces — primarily single-page applications (SPAs).

🧠 Core Concept

React focuses on the view layer (UI) of your app.

You write small, reusable components that render HTML using JSX.

function Welcome() {
  return <h1>Hello, React World! 👋</h1>;
}

✅ React Pros:

• Component-based structure 🧩

• Virtual DOM for faster rendering ⚡

• Strong community and ecosystem 🌍

❌ React Cons:

• No built-in routing

• SEO challenges due to client-side rendering

• Needs configuration for optimization and SSR (Server-Side Rendering)

⚡ What is Next.js?

Next.js is a React framework built by Vercel. It extends React by adding server-side rendering, static site generation, API routes, and more.

Think of it as React + Superpowers 💪.

🧱 Example

export default function HomePage() {
  return <h1>Welcome to Next.js! 🌐</h1>;
}

✅ Next.js Pros:

• SEO friendly 🧭

• File-based routing system 📂

• Server-Side Rendering (SSR) & Static Site Generation (SSG)

• Built-in image optimization 🖼️

• Supports API routes 🚀

❌ Next.js Cons:

• Slightly larger learning curve 📚

• Heavier build size than pure React ⚙️

🧩 Key Differences: React vs Next.js

🧭 Rendering Strategies

Next.js provides multiple rendering modes:

• CSR (Client-Side Rendering): Rendered in the browser (like React)

• SSR (Server-Side Rendering): Pages pre-rendered on each request

• SSG (Static Site Generation): Pages generated at build time

• ISR (Incremental Static Regeneration): Hybrid — static pages updated periodically

🪄 When to Use React

• Small SPAs or internal dashboards 🧮

• Projects with minimal SEO requirements 🕶️

• You prefer full control over build setup 🎛️

🌍 When to Use Next.js

• SEO-heavy websites (blogs, e-commerce) 🛍️

• Scalable apps needing SSR/SSG ⚡

• You want optimized performance and ready-to-use routing 🚦

🧰 Developer Experience

React requires additional tools for production:

• react-router for navigation

• vite or webpack for bundling

• axios or fetch for API calls

Next.js gives you everything out-of-the-box:

• Routing ✅

• Image optimization ✅

• API routes ✅

• SSR/SSG ✅

🔍 Real-World Analogy

🧠 Advanced Insights

⚙️ Data Fetching

• React: Fetch data with useEffect or external libraries.

• Next.js: Fetch with getStaticProps, getServerSideProps, or getStaticPaths.

🪶 Image Optimization

• Next.js automatically optimizes images via <Image /> component.

🔐 Authentication & API

• Next.js supports API Routes — you can build your backend inside the same project.

🧭 The Developer’s Journey

If you’re a beginner: Start with React. Learn components, props, and hooks.

If you’re ready to build full-stack apps: Move to Next.js. It’s built on top of React, so the learning curve is smooth.

🌈 Final Verdict

"React teaches you how to build; Next.js teaches you how to deploy what you build."

🧩 Summary Chart

graph TD;
  A[React Library] --> B[Client-side Rendering];
  A --> C[Needs Router, Bundler];
  D[Next.js Framework] --> E[Server-side Rendering];
  D --> F[Static Site Generation];
  D --> G[API Routes & SEO];

📚 Recommended Resources

• 📘 React Official Docs

• 📙 Next.js Official Docs

• 📗 Vercel Deployment Guide

💡 Conclusion

If React is your foundation, then Next.js is your skyscraper — taller, stronger, and more impressive. Start small, dream big, and build the web of tomorrow 🌐✨.