zkThis, zkThat, zkHere, zkThere. Zero Knowledge is so hot right now. Your favorite thread boi or gurl has done their best to explain what zero knowledge is and why you should care. This is for good reason.
It is showtime for the world of zero knowledge and specifically zkEVMs.
This post is not a "WTF is Zero Knowledge???" article with fancy infographics, charts, or ELI5 videos. There are many great articles that cover this and I will link them below. In this article, we will explore three zkEVMs - Polygon zkEVM, ConsenSys Linea, and Scroll. How do they work, how do they differ, and how are they trying to capture the love of developers?
Let's start our journey!
First Stop: What is a zkEVM?
I know I promised no fancy explanations earlier but I am a nice Dan and we still need to cover some basics.
Why do we have them?
I love the EVM as much as the next guy and I love it so much that I am not afraid to admit it has a bit of an execution problem. Why? In the validation process of transactions, every node on the EVM must re-execute the computation needed for that transaction. This takes time and doesn't scale to the levels we hope all this Web3 stuff will achieve. But what if we can take that computation off-chain and report back when it's done? We can. Enter zkEVMs.
But...How?
The 1980's produced some fantastic music and fashion. It also gave us the idea of zero-knowledge proofs from some big-brained people. To keep things simple here, Zero Knowledge Proofs (ZKPs) allow for someone (the prover) to prove to someone else (the verifer) that what they are saying is true. The catch here is they don't provide the exact information on what they are proving but a way to prove they have the knowledge. See example Below:
In the case of zkEVMs, it is about proving the off-chain computation of the transactions is valid. There are different ways of doing this which we will explore later. There is a great article by the team at Scroll on the parts of Proof Generation for math lovers out there.
Why Should Developers Care?
The goal of any zkEVMs is to be an upgrade to the EVM. They should provide cheaper, faster , safer, and sometimes cuter transactions. For developers, the move to a zkEVM should be as smooth as Brian Armstrong's head
There are different types of zkEVMs as outlined by Vitalik. Each type has its tradeoffs. My opinion is the sweet spot for developers is working with a Type-2 zkEVM . The zkEVMs here fit this type more or less. These allow for any applications and smart contracts to work the same as on the EVM which makes them "EVM-equivalent". This is because at their core they operate like Ethereum but with some tweaks. Think Coke Zero, the same great taste but without the added calories.
Of course, all that I have said is easier written than actually doing it. There are many challenges and each zkEVM has its own way of trying to overcome them. Let's go to the next step and see how these things work!
Second Stop: Architectures
Now that we have covered how the world of zkEVMs shares the same goals, you might be asking yourself how they differ. Looking at their architectures is a great way to understand this.
A node on the Polygon zkEVM can play two different roles: Sequencers and Aggregators. Sequencers act as collectors of transaction requests. They batch them up and send them to the Consensus Contract. Aggregators both check that those transactions are valid and create proofs.
The brains of the Polygon zkEVM operations in the Consensus Contract. The contract is the conductor of the entire transaction process. It receives the transactions from the Sequencers. After this, it hands them off to a trusted Aggregator to generate a proof. Lastly, the Consensus Contract verifies that proof. To make this process efficient, the aggregator that can provide a valid proof the fastest is the one that receives an award.
Instead of roles, Scroll has three different modules that a Scroll Node can run. These are a Sequeuncer, Coordinator, and Relayer. Like Polygon, the Sequence batches the transactions from the Scroll mempool. It also executes these transactions so that a completed block can be passed to the Coordinator.
The Coordinator is like the Consensus Contract on Polygon zkEVM in that it selects a node to generate the proof. A difference on Scroll is that instead of rewarding the fastest node that can generate the proof, a node is randomly selected. This node is called the Roller which is probably the best name here.
Lastly, the Relayers are the guard on the watch tower for this process. They are responsible for tracking the blocks on Scroll and the events from the bridge contract connecting Ethereum and Scroll.
But what about Linea? Unfortunately, at the time of writing, there is not an architecture explanation available in their docs. After requesting this from the team, it seems this is something on their roadmap to provide so stay tuned! There are some good bits in their community call.
Third Stop: Developer Experience
Any good relationship starts by building bridges. Your relationship with a zkEVM is no different. Using a bridge to transfer assets is the first step. Designing a good bridging experience is important for a zkEVM to onboard as many developers as possible.
The most straightforward bridging experience for me was on Linea. Since that fox wallet ConsenSys makes still has a strong grip on the browser wallet market, Linea has a great "foot in the door". The testnet, Linea Goerli, is already configured on all Metamask wallets. This advantage is highly valuable as even the best among us struggle to set up our Metamask sometimes.
Linea uses the Hop Protocol to perform the bridging. This is a smooth process but not as seamless as the wallet configuration of course.
Although Polygon does not have the advantage of being automagically in your wallet, they do have a nice one-click 'Add to zkEVM Network' on their docs. This makes setup much easier. I know the people at Polygon are smart but it really makes me wonder why everyone doesn't have this button on their docs.
Bridging to Polygon zkEVM requires using the Polygon Wallet portal. It is the most feature-heavy of all the bridging options out of the three. This is a good or bad thing. For example, it took me an embarrassingly long time to realize I had not selected the 'Testnest Products" option.
After getting everything setup and some ETH bridged, I was ready to deploy a smart contract! This was a very pleasurable experience as I followed the video guide by the smooooth voice of Tony Olendo. Proof of Work.
I appreciated that Scroll bridge is built directly into their documentation page. No extra services or tools are needed. It was a bit tricky as changing anything on the pages because it prompts Metamask to pop up. This made for changes to what you want to bridge a bit annoying but I know why this is happening.
Scroll also uses Blockscout for their L2 explorer. This was my first time seeing Blockscout. I really like the design. It is easy to find insights about the network and breaks away from the standard Etherscan template used almost everywhere else.
Next For zkEVMS
zkEVMs have chosen to take on the huge task of making Ethereum scalable. This is a major step in the growth and spread of this technology. Each team has realized this challenge and has applied its own unique strategies to onboard as many developers to battle-test their networks as possible. It is great to see them come together and talk about these challenges. Developers and the community
Linea has the brand of ConsenSys behind it. Polygon has some of the biggest brains in the zk space. Scroll has the bravery to take on these big players. Whatever happens, having these options will benefit developers and the community as a whole. I encourage everyone to start building on these networks so we can get the best out of them!
More Resources on zkEVMs
Twitter Thread by Covalent on the data comparing the networks.
Computer Scientist Explains One Concept in 5 Levels of Difficulty
zkEVM Vs EVM: Full Equivalence? by Ignasi Ramos
Thanks for our time together,
Your Guide - DappaDan ❤️
- Loading comments...