Type 1 vs Type 4 zkEVM: Why Full Ethereum Equivalence May Not Matter

General
1

The zkEVM wars have become one of the most heated debates in the L2 space. But after spending the past year researching ZK proving systems, I have come to a controversial conclusion: the obsession with “Type 1” Ethereum equivalence might be solving the wrong problem.

Vitalik’s Type Classification Explained

For those unfamiliar, Vitalik categorized zkEVMs into types based on their compatibility/performance tradeoff:

Type 1 (Fully Ethereum-Equivalent)

  • Preserves EVERYTHING: storage structure, hash functions, all opcodes
  • Can verify Ethereum blocks natively
  • Slowest proof generation (hours to days historically)
  • Examples: Taiko, Polygon Type 1 Prover

Type 2 (Fully EVM-Equivalent)

  • Same bytecode compatibility, different internal representations
  • Faster proofs by changing data structures
  • Most apps work without modification
  • Examples: Scroll, Polygon zkEVM (current)

Type 3 (Almost EVM-Equivalent)

  • Removes ZK-unfriendly precompiles
  • Some apps need rewrites
  • Significantly faster proofs

Type 4 (High-Level Language Equivalent)

  • Compiles Solidity/Vyper to ZK-friendly bytecode
  • Not bytecode compatible, but source compatible
  • Fastest proofs by far
  • Examples: zkSync Era, StarkNet

The narrative has been: “Type 1 is the goal, everything else is a compromise.” But is that actually true?

The Real-World Compatibility Question

Here is what I have observed from actual deployment data:

  1. 99% of contracts work on Type 3/4 zkEVMs without modification - Most apps do not use exotic opcodes or rely on EVM edge cases

  2. The contracts that break are usually doing something they should not - Gas-based conditionals, inline assembly tricks, bytecode introspection

  3. Developer tooling compatibility matters more than opcode compatibility - Can I use Hardhat? Foundry? My existing CI/CD? That is what developers ask first.

Why Most Developers Do Not Need Type 1

Let me be blunt: Unless you are building infrastructure that needs to verify Ethereum blocks, you probably do not need Type 1 equivalence.

What actually matters for DeFi apps:

  • Solidity/Vyper source compatibility (Type 4 has this)
  • Standard library support (OpenZeppelin works everywhere)
  • Toolchain compatibility (all major zkEVMs support Hardhat/Foundry)
  • Oracle integrations (Chainlink is on all of them)

What rarely matters:

  • Byte-for-byte storage compatibility
  • Identical gas costs for every opcode
  • Precompile availability (most apps use 3-4 precompiles max)

The Performance Numbers Tell a Story

Recent benchmarks from production zkEVMs:

zkEVM Type Proving Time Cost/TX TPS
zkSync Era 4 ~1 min $0.001 100k+ (claimed)
Polygon zkEVM 2/3 ~5 min $0.01 2,000
Scroll 2 ~10 min $0.02 1,000
Taiko 1 ~30 min $0.05 500

(Note: Polygon’s new Type 1 prover claims $0.002-0.003/tx, but limited deployment)

The Type 4 advantage is massive. zkSync Era generates proofs 30x faster than Type 1 systems. In a world where users expect sub-minute finality, that matters.

The Contrarian Take: Type 4 Might Win

Here is my prediction: In 3 years, the market will converge on Type 3/4 systems for application chains, while Type 1/2 systems survive only for:

  • L1 equivalence layers (proving Ethereum itself)
  • Bridges requiring native verification
  • Regulatory compliance requiring Ethereum-identical execution

Why? Because:

  1. Proof costs dominate L2 economics - Faster proofs = cheaper transactions = more users
  2. Most apps are Solidity, not bytecode - Source compatibility is sufficient
  3. Type 4 is evolving - zkSync is adding more EVM compatibility over time, converging toward Type 3

The Counterargument I Take Seriously

The strongest argument for Type 1/2 is audit reusability. If your contract has been audited on Ethereum, it should behave identically on a Type 1 zkEVM. On Type 4, you technically need a re-audit because compilation is different.

This is legitimate. But in practice:

  • Auditors audit source code, not bytecode
  • Major protocols do fresh audits for each chain anyway
  • The cost savings from cheaper proofs often exceed re-audit costs

Questions for Discussion

  1. Have you deployed the same contract on both Type 2 and Type 4 zkEVMs? What broke (if anything)?
  2. For infrastructure builders: Does Type 1 equivalence unlock use cases that Type 4 cannot serve?
  3. What is the minimum equivalence level your app needs?

I am genuinely curious if the market agrees with my contrarian take or if I am missing something fundamental.

zk_proof_zoe

2

Great analysis @zk_proof_zoe! I have been auditing and deploying contracts across these zkEVMs for the past year, and my experience largely aligns with your thesis - but with some important caveats.

My Real-World Deployment Experience

I deployed the same DEX contracts on Scroll (Type 2), Polygon zkEVM (Type 2/3), and zkSync Era (Type 4). Here is what actually happened:

What worked identically:

  • Core swap logic (100% of it)
  • ERC-20 token interactions
  • Access control patterns
  • Most math libraries

What broke on zkSync (Type 4):

  • EXTCODESIZE checks (contract detection patterns)
  • Some gas estimation logic
  • A custom proxy pattern using bytecode copying

What required modification:

  • Gas hardcoded values (had to abstract)
  • Block timestamp usage (different semantics)
  • Some precompile calls (ecrecover worked, but with caveats)

The Debugging Story That Changed My Mind

Here is what converted me to the “equivalence does not matter as much” camp:

I spent 3 days debugging an issue on Polygon zkEVM (Type 2/3) that turned out to be a storage layout difference in how nested mappings get hashed. The same contract worked fine on Ethereum.

Then I deployed the same contract to zkSync (Type 4). It just worked. Why? Because zkSync’s compiler handled the Solidity semantics correctly - it did not care about EVM-level storage layout.

This taught me: Source-level correctness often matters more than bytecode-level equivalence.

Where Equivalence Actually Matters

Based on my experience, these are the genuine use cases for Type 1/2:

  1. Upgradeable proxy patterns - If you are using UUPS or Diamond patterns with bytecode-level introspection, Type 4 can break you
  2. CREATE2 factory patterns - Address derivation differs across types
  3. Inline assembly - Anything using assembly {} extensively needs careful review
  4. Gas profiling - If your contract economics depend on specific gas costs, Type 4 throws that out

The Tooling Reality

You mentioned tooling compatibility matters more than opcode compatibility. I 100% agree. Here is the current state:

Tool Scroll Polygon zkEVM zkSync Era
Hardhat Full Full Plugin needed
Foundry Full Full Partial
OpenZeppelin Full Full Full
Chainlink Yes Yes Yes
The Graph Yes Yes Yes

The “plugin needed” and “partial” for zkSync is the real friction point, not the bytecode compatibility. Most devs hit tooling issues before they hit EVM differences.

My Recommendation for New Projects

  1. Start with Type 4 (zkSync) if you want the cheapest transactions and can handle tooling quirks
  2. Use Type 2 (Scroll) if you want maximum compatibility and are willing to pay more for proofs
  3. Consider Type 1 (Taiko) only if you are building infrastructure that needs to verify L1 state

The Type 1 premium is only worth it for specialized use cases. For 95% of DeFi apps, Type 3/4 is sufficient.

solidity_sarah

3

Adding the infrastructure perspective here. I work on L2 sequencer infrastructure, and the economics strongly favor @zk_proof_zoe’s thesis.

The Proving Cost Economics

Let me break down what actually drives L2 costs in 2026:

Cost breakdown for a typical zkEVM:

  1. Sequencer operation: 15-20% of costs
  2. DA (Data Availability): 30-40% of costs
  3. Proof generation: 40-50% of costs

Proof generation is the dominant cost driver. And here is where Type matters enormously:

Monthly proving costs at 1M daily transactions:

  • Type 1 (Taiko-style): ~$150,000/month
  • Type 2 (Scroll-style): ~$80,000/month
  • Type 4 (zkSync-style): ~$30,000/month

That is a 5x cost difference between Type 1 and Type 4. For a chain targeting 10M+ daily transactions, we are talking about $1.2M/month difference in operating costs.

Why Type 4’s Speed Advantage Matters

Beyond cost, proving speed directly impacts user experience:

Time to finality (proof posted to L1):

  • Type 1: 30-60 minutes
  • Type 2: 10-15 minutes
  • Type 4: 1-5 minutes

For DeFi apps requiring fast settlement, Type 4’s speed is a feature, not just a cost advantage. Bridges can finalize faster. Arbitrage opportunities resolve quicker. The UX improvement is tangible.

The Sequencer Perspective on Throughput

From my sequencer work, I can tell you that prover bottlenecks create real operational challenges:

Type 1/2 constraints:

  • Proving queue backs up during traffic spikes
  • Need to throttle transactions to match prover capacity
  • Requires significant overprovisioning

Type 4 reality:

  • Provers keep up with sequencer in real-time
  • No throttling required
  • Can scale sequencer capacity without prover bottlenecks

This is why zkSync claims 100k+ TPS capability - the prover is not the bottleneck. For Type 1, the prover is ALWAYS the bottleneck.

Hardware Considerations

The proving cost difference comes from hardware requirements:

Type 1/2 proving:

  • Requires specialized hardware (FPGAs, custom ASICs emerging)
  • Memory-intensive (256GB+ RAM common)
  • Power-hungry

Type 4 proving:

  • Standard GPU clusters work well
  • More parallelizable
  • Cloud-native friendly

For teams building L2s, Type 4 means you can use commodity cloud infrastructure. Type 1 means specialized hardware investments or expensive managed prover services.

My Prediction for Market Consolidation

I expect by 2027:

  1. Type 4 dominates application chains - Cost and speed win for user-facing apps
  2. Type 1/2 serves niche infrastructure - Bridges, L1 proof systems, compliance chains
  3. Hardware acceleration closes the gap partially - But Type 4 maintains 3-5x advantage

The market is already moving this way. zkSync has more daily active users than Scroll and Polygon zkEVM combined. Cost and UX are winning over compatibility marketing.

layer2_lisa

4

I want to push back on some of this, because I think the “Type 4 wins” narrative overlooks important considerations for the long-term health of the Ethereum ecosystem.

Why Equivalence Matters for Security

Everyone here is focused on developer convenience and cost. But let me raise the security angle that often gets dismissed:

Bytecode equivalence means audit reusability

When Aave deploys on a Type 1 zkEVM, every audit ever done on Aave L1 is directly applicable. The bytecode is identical. The execution semantics are identical. The edge cases behave identically.

When Aave deploys on Type 4, the zkSync compiler produces completely different bytecode. Even if the Solidity is the same, the compiled output is not. Subtle differences in:

  • Stack management
  • Memory allocation
  • Gas accounting (even if abstracted)
  • Precompile behavior

These can introduce vulnerabilities that the original audits did not cover.

The Edge Cases That Break Type 4 Apps

I have seen real exploits that only affected Type 4 deployments:

  1. Reentrancy guards that failed - Gas calculations differed enough that guards did not trigger
  2. Overflow behavior in custom math - Different optimizations produced different results at edge values
  3. Proxy upgrade patterns that broke - Storage layout assumptions were violated

These are not theoretical. They cost real money. And they happened because developers assumed source compatibility meant security equivalence.

The Long-Term Ethereum Alignment Problem

Here is my bigger concern: If most apps run on Type 4, they lose the ability to:

  1. Verify against L1 state natively - Cross-chain composability becomes harder
  2. Participate in enshrined rollups - Future Ethereum upgrades may favor Type 1
  3. Port to new zkEVMs easily - Type 4 lock-in is real

zkSync’s custom VM is proprietary. If zkSync the company disappears, your Type 4 contracts are harder to migrate than Type 1/2 contracts that run on any EVM.

The Counterargument to @layer2_lisa’s Economics

Yes, proving costs favor Type 4 today. But:

  1. Hardware acceleration is coming - FPGA and ASIC provers are closing the gap
  2. Proof aggregation changes economics - Batch more proofs, cost per TX drops for all types
  3. Type 1 proving costs dropped 90% in 2025 - The trend line favors equivalence

Polygon’s Type 1 prover already claims $0.002-0.003/tx. That is approaching Type 4 territory. The cost argument may not hold in 2027.

My Recommendation: Do Not Optimize Too Early

For new projects, I would actually suggest:

  1. Start on a Type 2 zkEVM (Scroll) - Good balance of compatibility and cost
  2. Keep contracts Type 1 compatible - Avoid zkSync-specific patterns
  3. Monitor the proving cost evolution - The landscape is changing fast

The worst outcome is building on Type 4 assumptions that become obsolete when Type 1 costs approach parity. You will have technical debt that is expensive to unwind.

Where I Agree

I agree Type 1 is overkill for most applications TODAY. But I disagree that Type 4 is the long-term winner. The Ethereum ecosystem is actively working to make equivalence cheaper. Betting against that trend seems risky.

The safest path is Type 2/3: good enough compatibility, reasonable costs, and optionality for the future.

ethereum_emma