Why do we need Zero Knowledge circuitry as part of SabVM?

[razgraf]

Prompted by @IaroslavMazur's the research into Risc Zero, for future context, let's explain: why do we need Zero Knowledge as a feature of the chain itself?

Related:

• https://www.risczero.com/news/op-stack
• Zeth

[PaulRBerg]

I haven't briefed @IaroslavMazur on why we need ZK because this topic is not relevant for him or for anyone of us during the next ~3 months of development.

My conjectures:

• OP Stack does not work with custom EVMs
• If we used a simple optimistic rollup design, we would have to rewrite MIPS and/ or RISC-V (note: Superchain networks like Base have made zero modifications to OP's circuit design)
• ZK tech has become mature enough that writing a ZK circuit for a rollup should take the same amount of effort as refactoring the existing optimistic rollup designs
  • Risc0 has played a pivotal role by enabling type-zero zkEVMs

Obviously, this is all conjectural, and I retain the right to withdraw these conjectures once I pick up the research in 3 months' time.

[PaulRBerg]

Re-opening this discussion because @andreivladbrg's recent foray into deploying Sablier on zkSync has made it clear that ZK rollups are still rough around the edges:

https://sablier.slack.com/archives/CT3NXSNMS/p1713622276417369

I am less convinced now that we should launch SabVM as a ZK rollup. An optimistic rollup sounds like the more appropriate approach - we can let the ZK magicians fill in the gaps and switch to a ZK design later on.

We won't support fraud proofs in either Genesis or Odyssey, but many ORs don't support them.

P.S. it looks like there are benefits to building an EVM product and a rollup in parallel!

[PaulRBerg]

More context from Andrei:

• https://sablier.slack.com/archives/CT3NXSNMS/p1713902333439029
• https://sablier.slack.com/archives/CT3NXSNMS/p1714060202808029

[PaulRBerg]

More context from our all-hands today:

• It's only zkSync that is problematic because they have mucked about with many of EVM's features, such as using different hash functions
• We have previously deployed to Scroll and there we didn't have as many issues

So zkVM need not have such a bad UX.

[PaulRBerg]

@razgraf and I met Justin Thaler at CSX, and we discussed SabVM. His feedback was illuminating.

a16z's Jolt, despite being the fastest ZK VM currently, still requires a 500K overhead. That is, a computer operation that normally takes 0.1 seconds to run would take 50,000 seconds if it has to be proved in ZK.

This is the nail in the coffin for a ZK approach for SabVM. Our graph computations may take so long that ZK proving them would surely be unfeasible for normal blockchain production times (even for a lazy rollup that posts blocks once every so often). See:

• How to prevent Unbounded Computational Growth (UCG)? #57
• Computational Irreducibility and Linear Time Complexity #107