Privacy vs. Performance: How CZ and Vitalik Are Redefining Web3's Future

Yagya Khandelwal

In the world of Web-3, two foundational questions are emerging: Can we make decentralized trading safer for larger players? And can we scale ETH completely without breaking it?

Two big players — CZ( Changpeng Zhao), the co-founder of Binance and Vitalik, co-founder of Ethereum have proposed bold solutions to these problems. CZ wants to build a dark pool for perpetual contracts DEX( Decentralized Exchange) to bring privacy to on-chain trading. Vitaliks wants to replace Ethereum’s execution engine with RISC V, a standardized and ZK(Zero-knowledge) friendly instruction set in simple words, imagine ZK as instruction that lets you prove to someone that a statement is true without revealing the actual information behind that statement.

These Proposals both tackle a very very different problem but they reflect a common theme: Web 3 needs to evolve beyond its transparency first and complexity-heavy roots.

Part 1: CZ’s Dark Pool DEX

Most DEXs today are completely transparent which means every trade, deposit, or pending order is visible to everyone. This openness is the foundation of blockchains but it also exposes traders to vulnerability.

The problem: Too much transparency

Due to too much of transparency on the chain leads to 3 main problems :

1) Front running - it happens when bots scan pending transactions and jump ahead and execute similar trades to profit and this is very common on platforms like UNISWAP and SUSHISWAP

Example - A user submits a large order to buy a token and a bot sees it in the mempool ( The mempool is a waiting area for valid but unconfirmed transactions. These are transactions that have been broadcast to the network but have not yet been included in a block by miners or validators), places the transaction before that and increase the price and later sells that token right after user execute transaction at higher price, The user ends up paying more than expected known as slippage — a textbook “sandwich attach”

2) MEV(Maximal extractable value) allow validators to manipulate transaction order for profit. This introduces unfairness and inefficiencies in to system.

3) Liquidation hunting - occurs in leverage derivative trading.If a trader’s liquidation point is visible, bots or adversaries can push the market in that direction. There have been several cases and real-world claims of liquidation targeting platforms like hyper liquid, where $100M in bitcoin positions were wiped out after traders allegedly ganged up to trigger liquidation andafterbuyinguy at cheaper prices.

CZs solution: A dark pool perpetual DEX

Dark pools in traditional finance are private exchanges that allow institutions to place large orders without revealing their intents and CZ proposes bringing that idea to DEFI using —

• Hidden order books: Prevent others from seeing live buy/sell intent.

• Zero-knowledge proofs (ZKPs): Verify trade validity without exposing data.

• Delayed deposit and position visibility: Mask smart contract interactions until execution.

How it would work:

1. Traders encrypt their orders and submit them

2. A matching engine pairs these orders in private

3. A ZK proof verified the trade was fair

4. Only aggregate results are published, not individual trades

Benefits:

1. Protects against MEV and front-running.

2. Prevents targeted liquidations.

3. It will enable and encourage institution-grade trading

Risk and trade-offs:

1. Hiding info will reduce market transparency

2. It will lead to increased manipulative behaviours and would be difficult to track manipulative behaviour due to less transparency.y

3. The complexity of cryptographic infra could slow adoption

Still, the idea reflects a broader shift toward privacy-enhancing DeFi, a space where institutional capital might feel more at home.

Part 2: Vitalik's RISC-V Proposal – Ethereum’s Scalability Engine Upgrade

Etehrium’s flexibility comes from the EVM( Ethereum virtual machine), the runtime environment for smart contracts Think of it like a computer where all contracts of ETh are executed. But the problem is EVM wasn’t designed with scalability or ZK proofs in mind.

The problem: The EVM’s limitations

• ZK inefficiencies: Generating ZK proof for EVM operations can be up to 800x slower than native computation

• EVM built-in complexity: EVM uses 256-bit operations and custom opcodes, making it hard to optimize. What exactly do 256-bit operations mean? It is a 256 binary digits (0s and 1s) where each transaction is coded into a 256-digit code to ensure consistency. The EVM uses 256-bit operations to handle cryptographic functions and ensure consistency across all calculations.

• Tooling Gap - developers can’t leverage mainstream compilers or performance profiles in it.

Vitali's Proposal: Move to RISC V is an open source, reduced instruction set computing architecture It’s widely used in academia and chip design

Vitalik proposes replacing EVM with a RISC V-based execution model to :

• Simplify Ethereum’s base layer

• improve ZK compatibility

• Enable faster execution and cheap proof generation

Why RISC V?

• ZK native architecture Easier to prove computations using ZK-SNARKs/ STARKs

• Modularity: Allows for custom blockchain-specific extensions

• Standardization - RISC V is well-documented and broadly adopted

Example - Today, a zk-rollup like zkSync has to simulate EVM logic inside a ZK circuit. With RISC-V, the rollup could compile directly to a ZK-friendly format—saving time, gas, and compute power.

Benefits:

• ZK-proofs up the speed 100x faster

• Simpler execution layer, easier to maintain.

• Enables multi-language support (C, Rust, etc.) via LLVM encourages wider adoption

• Backwards-compatible via EVM interpreters. (A blockchain (or zk-rollup) that is not natively based on EVM can still run Ethereum smart contracts by using an interpreter that understands EVM bytecode.)

Risks:

• High migration complexities

• Dualsupportt for EVM + RISC V will increase complexity and attach surface

Conclusion:

CZ and Vitalik are tackling the twin challenges of Web3: the need for privacy and the need for performance. One aims to protect traders, the other, to empower developers and scale users.

They represent a shift in Web3’s priorities from raw transparency and complexity towards verifiable privacy, modular execution and real-world readiness.

These ideas aren’t just fixing the pain points but they’re about layering a new foundation, one that could scale to billions of users without sacrificing decentralization.