Everyone reading this must be familiar with the ZK hype around the blockchain industry. Although, it is not a hype anymore. It has literally become a reality after the launch of Polygon's zkEVM. So if you don't know much about it, here's the time to learn.

To start with- let's learn a little about zk and EVM individually and try to understand what these jargon terms really mean. Goal is to simplify it so that even beginners can grasp these terminologies by the end of this blog.

Let's goooo!

What are zero knowledge proofs?

I'm sure you must have read the classic definition of ZK proofs that involves a verifier and the prover (in case you haven't head over to my last year's blog that covers ZK proofs for absolute beginners)

Summarising in simple words-

Zero knowledge proofs (ZKPs) are a method for one party to cryptographically prove to another party that they posses knowledge without actually revealing the underlying information.

In the context of blockchain networks- the only information revealed on-chain by a zero-knowledge proof is that some piece of hidden information is valid and known by the prover.

Here, we are gonna diver deeper into the world of ZK. Let's take a look at what interactive and non-interactive ZKP's are:

• Interactive ZKP: Requires active participation and communication between the prover and verifier.

• Non-Interactive ZKP: Doesn't require real-time interaction; the proof is generated by the prover alone and can be verified independently by the verifier.

Still confused? I asked ChatGPT to generate some examples to help you grasp this better:

Interactive Zero-Knowledge Proof (ZKP): Imagine you and your friend have a secret handshake that only the two of you know. To prove to someone else that you know the secret handshake, you have to perform it with your friend in front of the person. Here's how it works:

1. You and your friend agree on the secret handshake, which represents the function 𝑓f in our scenario.

2. When you want to prove to someone else that you know the secret handshake, you and your friend perform it together in front of that person. This interaction involves both of you actively participating in demonstrating the handshake.

3. The person watching verifies that you and your friend performed the handshake correctly. If it matches the secret handshake you previously shared, they're convinced that you know it.

Here, the proof (the secret handshake) is demonstrated interactively between you, your friend, and the verifier.

Non-Interactive Zero-Knowledge Proof (NIZK): Now, let's say you want to prove to someone that you know a magic word without actually saying it. Here's how you can do it using a non-interactive zero-knowledge proof:

1. You and your friend agree on a magic word without revealing it to anyone else. This magic word represents the function 𝑓f.

2. You write down a series of symbols or clues that only you and your friend understand. These symbols represent the magic word, but they don't reveal the word itself. You then hand these symbols to the person you want to convince.

3. The person receiving the symbols checks them against a reference guide provided by your friend. If the symbols match the magic word without explicitly revealing it, they're convinced that you know the magic word.

Here, the proof (the symbols) is generated by you alone and can be verified without any interaction between you and the verifier.

Can you guess which one of these does Polygon uses for its zkEVM?

If you guess was non-interactive ZKPs, you are correct!

NIZKPs offer advantages in terms of faster verification times as they don't require real time interaction and proof can be generated once and verified by multiple parties without additional interactions.

There are three fundamental characteristics that any ZKP should have:

1. Completeness: If a statement is true, an honest verifier will be convinced by an honest prover that they possess knowledge about the correct input.

2. Soundness: If a statement is false, no dishonest prover can unilaterally convince an honest verifier that they possess knowledge about the correct input.

3. Zero-knowledge: If the statement is true, the verifier learns nothing more from the prover other than the fact that the statement is true.

These core principles ensure that ZKPs are both secure and privacy-preserving. If a proof misses any one of these characteristics, it is simply not a ZK proof.

Implementations of ZKPs:

There are various implementations of ZKPs having its own trade-offs like Bulletproofs, Aurora, Halo and many more but here we will discuss the most widely accepted implementations of ZKPs

1. zk-SNARKs: SNARKs, short for “succinct non-interactive argument of knowledge”, are characterized by their small proof size and ease of verification. They create cryptographic proofs using elliptical curves, which is more gas-efficient compared to the hashing method employed by STARKs.

2. zk-STARKs: STARK stands for “scalable transparent argument of knowledge”. STARK-based proofs involve minimal interaction between the prover and the verifier, resulting in faster performance compared to SNARKs.

Polygon uses zk-SNARKs for its zkEVM.

Huh, we can keep going on and on about ZKPs but now let's take a look at

What an EVM is:

The Ethereum Virtual Machine (EVM) is the backbone of the Ethereum network, defining the rules for computing the network's state from one block to the next. As the core component of Ethereum, the EVM is responsible for executing smart contracts, processing transactions, and updating account balances.

Simply put, the EVM acts like a virtual computer or cloud computing system that powers the Ethereum protocol. It functions much like a traditional computer, running code and storing information. However, unlike a single machine, the EVM operates as a network of thousands of interconnected cloud servers around the globe.

Key Functions of the EVM

1. Managing the State of the Ethereum Blockchain: The EVM maintains the overall state of the Ethereum network, ensuring that all nodes have a consistent view of the blockchain.

2. Executing Smart Contracts: It runs the code of smart contracts, which are self-executing contracts with the terms directly written into code.

3. Storing Data: The EVM handles data storage required by the network and the applications running on it.

4. Calculating Gas Fees: It computes the gas fees necessary for transactions and contract executions, ensuring that resources are allocated efficiently and network security is maintained.

Keeping things short about EVM, let's finally look at Polygon's zkEVM.

But just in case, you're curious to explore more about how EVM works, take a look at my dive deeper blog about EVM here.

Let's look at Polygon's zkEVM now

Polygon zkEVM was built to address the scalability issues that Ethereum faces in blockchain trilemma while maintaining a strong sense of decentralisation and security that Ethereum has by utilising that as the base layer for all of the transactions to kind of live on.

Well, you must be wondering...do we really need it?

Let me tell you- I just paid $18 in gas fees for doing a $20 transaction on Ethereum mainnet, so yeah we need Ethereum to scale and Polygon's zkEVM is doing just that.

What is a zkEVM?

• ZK- it utilises zero-knowledge proofs somewhere in the system

• EVM- it is EVM compatible

Under the hood, Polygon's zkEVM inherits the security and decentralisation of Ethereum is because it posts all of information back and uses these zero-knowledge proofs which is just cryptographically proving the computational integrity of the batches of transactions.

EVM compatibility means you can access all of the Ethereum's community. So essentially, all of the development process is the same, you can just change the name of the blockchain you're deploying to. That's it.

By this time, you should understand that Polygon is a Layer 2 solution built to scale Ethereum, after all.

To make it fuss free- assume I am talking about Polygon's zkEVM whenever I am using the term Layer 2 and Ethereum whenever I am using the term Layer 1.

How does Polygon zkEVM work?

From an end user perspective, if you want to do a transaction on Polygon zkEVM, the process looks exactly the same and it is very easy to do so but there are multiple things happening behind the scenes and I want to break it down into these simple steps:

1. Submitting Transactions

There are many ways you could submit a transaction on Ethereum- through wallets, dApps and more. This is the exact same on Polygon's zkEVM. You can use the exact same tools and developer experience is identical to Ethereum thanks to being EVM compatible.

The main benefits while submiting transactions on Polygon's zkEVM is the low (tiniest) gas fees and speed as transactions gets submitted almost instantly, which means that all these 5 steps happens super quickly.

2. Executing Transactions

A transaction will only get executed if and only if it is considered valid. Assuming your transaction was valid, the sequencer will broadcast the information of the executed transactions to all of the nodes on the zkEVM network and then these nodes provides the information about the transaction (eg: NFT minted successfully, transaction id, etc) back to the application.

3. Bridging and withdrawals

To execute a transaction in Polygon's zkEVM (Layer 2), the user would need to bridge funds across from Ethereum (Layer 1) to Polygon's zkEVM (Layer 2) .

But in order to withdraw funds from Polygon's zkEVM (Layer 2) and get it back to Ethereum (Layer 1) need to go through a process where we send all the information back to Ethereum and Ethereum receives these information/transactions and then proves it using ZK proofs. Once it has been verified and proven to be correct, only then the user can withdraw funds out of the Layer 2 and back onto Layer 1.

Polygon's zkEVM is a zk rollup and not an optimistic rollup which makes sure that the withdrawal period is quicker.

4. Batching Transactions

The sequencer is batching the transactions (executed on Layer 2) and sending it to Layer 1.

We are actually sending batched transactions to a smart contract called Polygon zkEVM on Ethereum (Layer 1).

The reason batching is done is to lower the gas fees as it costs us gas fees to call the Polygon zkEVM smart contract on Ethereum. So we try to batch as many transactions together as possible.

//this is an example of how transactions are batched
struct BatchData {
    bytes transactions;
    bytes32 globalExitRoot;
    uint64 timestamp;
    uint minForcedTimestamp;
}

5. Sequencing Batches

Now that the batching of transactions is completed, we need to send it to Ethereum.

We simply need to call a function sequence batches on Polygon zkEVM smart contract stored on Ethereum.

We are literally calling a function! See it was not at all complicated, right?

6. Aggregating Batches

Ok, so we got all the batched transactions from Layer 2 but now we need to prove them using ZK proofs.

The role of an Aggregator is to prove that transactions are valid and post this proof to Ethereum smart contract.

So, the aggregator takes the batches, send them to a zkProver. Then zkProver will generate the zkProof or a validity proof that the aggregator is going to receive in return for those batches.

That's mostly it! That is how Polygon's zkEVM works.

Ah, if you are still here, many thanks! And congratulations, you now have a fair understanding of how Polygon zkEVM works.

You can literally start building on Polygon's zkEVM is not much efforts if you have ever built a dApp on Ethereum, it is almost the same thing (except better!)