Polygon maintains its crown by bringing in ZKrollup.
Problem with Ethereum Mainnet
Ethereum is the backbone of the web3 ecosystem. It continues to surprise the most brilliant minds in the world with the potential it carries. The potential of diversified applications would make even Einstein scratch his head for a moment.
But yeah, it is not a fairy tale. Every awesome thing has a limitation or restriction. The constant limitation Ethereum has been facing is the “Gas Fees”, or in other terms, Scalability, Ethereum Classic has a limit of performing 15 transactions per second. However, ETH 2.0 will be much faster than this, but we still have a long way to go.
After years of research, prolonged studies and shear dedication web3 community managed to come out with some solutions which help to scale better
- Layer 1 Scaling:- This is the methodology using which we try to make blockchain better by making some changes in the architecture. For example, ETH 2.0 is a Layer 1 scaling solution as it tries to establish PoS for PoW in ETH Classic. This type of Solution is expensive and time taking.
- Roll Ups:- This is a layer 2 solution which is the most promising contender. The users get security backed by the Ethereum blockchain with high throughput.
- Sidechains:- These are EVM compatible and can scale general-purpose applications, but they have drawbacks. As Ethereum does not back its security, Web3 Community has to be constantly aware. This comes under layer 2 scaling.
Starting as an ethereum scaling project Polygon, formerly known as Matic Network, emerged as a shining star in the web3 space. It takes cents to confirm a transaction on a polygon network, whereas the same transaction would take dollars on the Ethereum Mainnet. This was all possible because of the sidechain built on top of the Ethereum mainnet.
Later, Matic Network explored more different ways of scaling the Ethereum blockchain and was renamed “Polygon” to provide different solutions to scale the Ethereum blockchain better.
There are several projects at the time of writing this blog:-
- Polygon PoS
- Polygon Supernets
- Polygon Zero
- Polygon Miden
- Polygon zkEVM
In this blog, we will explore Polygon’s new release zkEVM which is one of the hot projects for scaling Ethereum.
Polygon zkEVM is a product by polygon to scale Ethereum to reduce gas fees and increase the throughput. The “ZK” stands for “zero knowledge”, a type of Roll up. Before we move forward, we need an understanding of RollUps.
What are Roll-ups
Imagine it this way, suppose there is a post letter service from city A to city B, but there is only 1 vehicle, which can take only 100 envelopes once a day. You find it limiting and try to find a way. What you can do is, take 10 letters and write their summary in a single letter and put it in an envelope to post. so doing that we can post 99 + (10) letters. This is essentially what roll-ups are.
That’s how roll-ups essentially work on the Ethereum mainnet. We take a chunk of transactions, collect them in a “roll up”, summarise them and then push it to the mainnet. This increases the throughput. The transaction fee is divided among different parties associated with the transactions in the batch being rolled up. This way, we reduce the gas fees to a good extent.
Roll up Mechanisms
Each roll-up deploys some smart contracts on Layer 1, which are associated with:-
- Processing deposits
- Verifying proofs
The main point of concern here is the verification mechanism. How do we check that the roll-up submitted to layer 1 is not fraudulent? To check this, we have two validation mechanisms:-
- zero knowledge:- This mechanism uses validity proofs and is empowered by cryptography. The batch of transactions that are rolled up includes a cryptographic proof known as “zk-snark”, The proof is quickly verified by the Layer 1 smart contracts when the transaction batch is submitted, and invalid ones are rejected.
- Optimism:- This mechanism works on fraud-proof. This means we have to prove that the batch submitted to layer 1 is not fraudulent. There are 2 parties involved, one which submits the batch to the Layer 1 protocol saying the batch is correct and puts some money at stake if it can be proved wrong, and the other party tries to submit fraud-proof stating that this batch is malicious and with this claim puts some stakes. If someone raises fraud proof, the batch is checked on the Layer 1 protocol, and the party proved wrong is penalised.
The architecture of polygon’s zkEVM:-
By now, you must have a decent understanding of how roll-ups work, zk-roll-up in particular. The main components we find in polygon’s zkEVM are:-
- Consensus Contract (PolygonZkEVM.sol)
This contract is deployed on L1 and plays a crucial role by employing validity proof to ensure the robustness of state transitions. To do this, it has pre-determined rules which are followed to allow state transitions.
To verify the successful completion of state transition, this contract employs zk-SNARK circuits. This system relies on two processes, transactions which are batching and transaction validation, as explained previously.
To carry out transaction batching and transaction validation zkEVM employs two participants:-
- Sequencers:- propose transaction batches to the network.
- Aggregators:- Check the transaction batches’ validity and provide valid proof.
More on Sequencers and aggregators later first, let’s focus on this contract. The contract makes two calls-
- to receive the batches from Sequencers
- to Aggregators requesting the validation of batches
This whole process can be summed up in the following diagram (Here, PoE is our Consensus Contract):-
We were introduced to Sequencer and Aggregator in Consensus Contract, these two are crucial parts of the zkEVM architecture, and zkNode is the software which empowers them to be. zkNode is a client required to implement synchronization and govern Sequencers and Aggregators. So, zkNode software facilitates 4 aspects:-
- Sequencers:- A sequencer is the one who receives L2 transactions from the users and preprocesses them to a new L2 batch, which is then proposed to the Concensous Contract. The sequencer receives the fee submitted by the users for their transactions on L2. To publish this batch to the L1, the Sequencer has to pay L1 fees and also has to pay some MATIC tokens, which work as an incentive to the Aggregators to validate this batch. So, sequencer is profitable if :- txn fees(received by the users in L2 for their transaction) > L1 call (gas fee to publish on L1) + MATIC fee (to incentivise the Aggregators to validate)
- Aggregators:- Aggregators are crucial to verify the batch’s integrity. Aggregators receive all transactional information and then send it to “zkProver”(more on it later), which in turn provides a “zk-Proof” which is a result of complex polynomial computations. The “zk-Proof” is then sent to the Smart Contract to verify that the proof is correct. This batch is then marked correct and ready to be added. The Aggregator is profitable if:- MATIC fee (by Sequencer) > L1 call(gas fee) + Server Cost(to build proof)
- Synchronizer:- The main aspect of the synchronizer is to read events from the Ethereum blockchain and include the new batches to keep the state synced. The information from these events is stored in the database. Synchronizer gets the data from Smart Contracts. All this data is then served to third parties through the JSON-RPC service.
- RPC:- JSON-RPC is a crucial interface which is compatible with Ethereum. When we need a software application to connect to the Ethereum blockchain, it connects to an Ethereum node. That’s how RPC comes into the picture. It enables zkEVM to integrate Metamask and Etherscan and interacts with Pool and State transactions.
This part of the zkEVM architecture is the most technologically oriented and complex. It will surprise you to know that to carry this out. The developers had to develop two new programming languages to implement the needed elements:-
- Zero — Knowledge Assembly:- In simple terms, this language maps instructions from zkProver’s Main State Machine to other State Machines. To learn more about this language, check this.
- Polynomial Identity Language(PIL):- There has been a lot of research to solve the blockchain Trilemma of Privacy, Security and Scalability. Till today there have been several attempts and different theory tries, but the one that is most accepted to date is the “Polynomial Commitment Scheme”. Hence it is only convenient to perform calculations in a polynomial language. Thus, PIL codes form the basis of the verifier code of the zkProver. To know more about it, follow here.
zkProver is backed by many years of research in different departments making its complexity justified. There are majorly some major components of zkProver:-
- The Executor:- This part deals with the execution of the zkEVM from the Main State Machine. This is where the EVM Bytecodes are interpreted using the new “zero-knowledge Assembly Language”(zkASM) discussed before. In this part, we deal with the set up of polynomial constraints that every valid batch of transactions must fulfil and feed the input such as transactions, old/new State, Chain ID etc. Here is the PIL(Polynomial Identity Language) to encode the polynomial constraints. The output of this Step is the “Commitment Polynomials”, which is a result of the execution of all instructions on top of PIL hardware.
- Stark Recursion Component:- This step involves the interaction of three major inputs Committed Polynomials, Constant Polynomials, and a List of instructions. These three inputs blend to generate zk-STARK proofs. These several zk-STARK proofs are collated in bundles of a few zk-STARK proofs and produce a zk-STARK proof of each bundle. Then those proofs are put in a bundle and collated to form one single zk-STARK proof. This is how hundreds of zk-STARK proofs are represented and proved with only one zk-STARK proof.
- CIRCOM Library:- This step involves the interaction with the Verifier data and the single zk-STARK proof created through Stark Recursion Componenet to generate a “witness” this step is necessary for the next step to convert the zk-STARK proof to the zk-SNARK proof.
- Rapid Snark:- This is the last component of the zkProver. This is the stage where the “witness” the output of the CIRCOM Library is fed along with the STARK verifier data to create the zk-SNARK proof.
The zk-STARK proofs are used because of their speed, but they are much larger than zk-SNARK proofs. For that reason, zkProver uses the zk-SNARK created in the final step utilizing the data from zk-STARK proofs. The interaction of these four components can be seen as:-
Looking at the security aspect
Security-wise, the zkEVM project is in its medieval phase, and the polygon team has continuously been involved in internal and external audits. The information about the results of internal audits is mostly classified, but Polygon took help from two external auditors (Hexens and Spearbit). Showcasing the need to get smart contract audits even by the big giants. It is true that “Hacks come unexpected”. Indeed, you can never be so sure and secure. Most of the giants in the web3 ecosystem understand this and are pushing hard to secure themselves.
Now more than ever, we need to secure web3. At this stage, getting a professional code review of smart contracts is vital, saving developers countless work hours. Making sure your Contracts are secure is more crucial than ever. We together can make Web3 a safer space. Do visit QuillAudits to explore different services and solutions.