Understanding ZKsync for Solidity Developers

Historical context: This is a June 2022 overview of the zkSync 2.0 testnet. ZK rollups verify off-chain computation through validity proofs; they are not conventional sidechains, and using a zero-knowledge proof does not make every transaction private.

Have you heard of zkSync and its new zkEVM? The new zkSync EVM enables Zero-knowledge proofs for any smart contract executions.

What does that mean? Well read on later. But what it enables is having a side chain with similar (not not exact) guarantees of the Ethereum mainnet chain. How cool is that? Especially with the increasing gas prices again, it's time to learn what it is, how it works, how to use it and why it's better than a regular sidechain.

The launch of zkEVM represents an essential turning point for crypto. Up until recently it was still considered merely a theoretical possibility that will take years to get real. But over the last year, the pace of the entire zero knowledge proof ecosystem has exceeded even experts’ expectations. And because of the many research breakthroughs by zkSync, Solidity programmers now have access to unmatched scaling, security, and UX benefits of zero knowledge proofs.

But let's start at the beginning...

Zero-knowledge Proofs are complicated, but an easy way to conceptualize them is the following example:

Imagine you are blind and I give you two balls that feel exactly the same way and are the same weight. Now I tell you those two balls have different colors. There's no one else nearby. How can you find out if I'm telling the truth?

You can put one ball in each hand, show them to me. Now you put them behind your back and you either swap the balls between both hands, or you don't. Then you show them to me and ask me: 'Did I swap the balls, yes or no?'. Now if both balls are the same color, I could try to guess it. I'll have a 50% chance of guessing correctly. That's why you do this 15 times in a row. If every hidden swap is chosen independently and uniformly at random, someone who cannot distinguish the balls has a probability of only 2^-15, about 0.00305%, of guessing all 15 answers correctly. That is the example’s false-accept probability, not a posterior probability that the claim is true. If not, I must have randomly guessed correctly 15 times, pretty unlikely. The more often you ask, the more sure you can be.

I have now proven to you that the balls are of different color without ever revealing the actual colors, hence the name 'zero knowledge' proof. You have no idea if the balls are green, black, orange or something else.

There's one problem with the normal Zero-knowledge proofs in the world of blockchains: asking many times in a row and waiting for the answer would require several transactions to go back and forth. That's not very efficient at all. With zk-SNARKs, or non-interactive zero-knowledge proofs, we can do this in one round. Essentially the questions are pre-determined based on a random oracle model. The prover can then send all answers in one single transaction.

The whole concept of zk-SNARKs is a very interesting topic. Vitalik posted a beginner-friendly introduction some days ago here. Well, as beginner-friendly as possible. You'll see what I mean. Or this paper goes into it even more deeply. If you want to go really deep into the math behind it, it will be anything but easy. I certainly haven't figured out everything in the article myself, but here's my high-level understanding if you just want to know the basics:

• zk-SNARKs are based on very heavy computation, like computing a hash 100 million times.
• Verifying a proof itself doesn't require running the heavy computation.
• Actual data is represented by polynomials, .e.g., x² − 4x + 7.
• Using the factor theorem, we can transform certain polynomials into multiples of its lowest degree polynomial.
• Then using polynomial commitments and the Schwartz–Zippel lemma, we can verify a proof for such polynomials by just randomly checking some coordinates.

Now the main issue with this is we have to transform the questions into polynomials. With polynomial commitments we can transform polynomials to simple operations like additions and subtractions. But that still doesn't give us the capability for general computation protocols that are Turing-complete. And this is what we ultimately want if we have to prove any kind of smart contract execution.

zkEVM solved this by using a modified TinyRAM protocol. The idea is to arithmetize generic computations by representing them as operations in an operation circuit in the form of 

• x = (op == ADD ? 1 : 0) * (a + b) + (op == SUB ? 1 : 0) * (a - b) + (op == MUL ? 1 : 0) * (a * b)

Assuming we only support ADD, SUB and MUL operations. This performs all available operations in each step, so it's very computationally intensive. But it allows general computations to be verified by Zeroknowledge proofs. However on its own it's simply too extensive and not helpful. zkEVM built on top two mechanisms to make it more scalable:

1. Using recursive proofs, basically you create a circuit which verifies the proof of a different circuit.
2. Having optimized special circuits for heavy operations like computing the Keccak256 hash.

You can find a detailed explanation of the approach in this video:

This is an intuition for selecting an operation in a circuit. A real proof system must also constrain the selectors, permitted operations and machine state; the expression alone is not a complete proof of correct execution.

A ZK rollup executes transactions off Ethereum and proves that the resulting state transition follows its rules. It groups transactions into batches and verifies proofs for those batches, potentially aggregating proofs recursively, rather than submitting a separate Ethereum verification for every user transaction.

For ZKsync’s concrete organization, see blocks and batches: multiple L2 blocks can belong to an L1 batch. Validity proofs replace the optimistic challenge assumption for execution correctness, but data availability, contract upgrades and other system assumptions still matter.

The original Goerli testnet, Docker compiler VM and v2-docs setup links are historical. For current ZKsync Era network settings, use the official Era reference: mainnet chain ID 324, or Era Sepolia testnet chain ID 300.

Choose the execution path deliberately. Contracts compiled for EraVM and ordinary EVM bytecode run through different tooling and compatibility paths; follow the current compiler and EVM compatibility documentation for that choice. Changing only the old testnet RPC does not migrate this launch-era setup.

The original testnet limitations listed here are obsolete. In particular, msg.value is not universally zero in current EraVM execution. Libraries and value transfers must follow the current execution path’s rules. Consult the EraVM instruction differences and its linked library/EVM-interpreter references instead of assuming the early testnet restrictions still apply.

The launch-era opcode table has been retired because it mixes early testnet restrictions with contradictory and incorrect labels, including two different results for block.gaslimit. It should not guide a current deployment.

Use the maintained opcode and compatibility reference for the execution path you choose. EraVM compilation and the EVM bytecode interpreter have different rules. Pay particular attention to deployment, calls, code introspection, value handling and libraries.

Not long ago in December 2021, Vitalik still wrote:

But it does seem that the speed of development for ZK rollups has been exceeding expectations at this point. Regardless it seems we are headed into a future where Ethereum becomes a data availability layer for these L2 technologies.

Will this combined with sharding be the final scaling solution for Ethereum? What do you think?