Technical Dive into Polygon’s ZK Solutions
Introduction: How does ZKP help with scaling?
Modern techniques of increasing throughput and lowering cost of transaction execution usually requires the use of an off-chain environment, the drawback of which is ensuring that the executions are done correctly in a trust-less manner. Zero-Knowledge Proofs (ZKP) are a way of ensuring computational integrity — where all computations are valid under no supervision.
Throughput is increased by the bundling and executing of transactions, and all that needs to be done is to post the resultant state changes back to the L1 chain. Verification via proof-generation is done in constant time regardless of the number of transactions in a roll-up batch, resulting in significant decrease in latency.
Execution cost is cheaper due to 2 reasons: amortisation of individual fees over all transactions in a bundle and less consumption of blockspace as only the ZKP and compressed data is stored on the L1 chain.
In this post, we’ll take a look at the developments of ZK-enabled scaling solutions built by Polygon, and hope to enlighten the reader about the key differences between these various developments.
Key Technical Differences Between ZK Roll-ups (WIP)
Polygon Hermez
An important observation was that more than half of all Ethereum transactions are simply token transfers.
The key focus of Hermez was to scale token transfers on Ethereum, which could then be extended to real-world use-cases like payments. This improves the overall experience as users would pay lesser fees on average, and precious blockspace would also be freed-up.
Users would register their L1 addresses into the Hermez to get an internal address, which will be used for token transfers within Hermez. Users can withdraw/deposit L1 tokens into their Hermez addresses, and also transfer tokens between Hermez addresses cheaper and faster.
Block production and proof generation are done by entities known as
coordinators. It also has other functionalities such as:Fetching historical data and state updates from L1
Receive transaction requests from users on Hermez
Build rollup batches using user transactions
Keep track of the merkle root with a ZK proof-of-correctness
Polygon zkEVM
Traditionally, it has been thought that there exist an unavoidable tradeoff between full EVM compatibility and efficient generation of ZKP. However, by re-implementing the entire EVM following the specifications of the original Ethereum yellow paper while including ZK features into the VM, the dilemma has been successfully solved.
The difficulty in implementing a zkEVM stems from the fact that the EVM was not designed to be a ZK-friendly environment. An enitrely new logical EVM processor had to be built to accomodate all the opcodes supported in the original EVM. In addition, all forms of computations have to be transformed into polynomials and off-chain computations have to be connected to their associated ZKP.
The key advantage of having a fully equivalent EVM is that all existing dApps (and smart contracts), developer toolings and wallet from Ethereum would work seamlessly with the zkEVM, while leveraging on the advantages of ZK-enabled scaling solutions.
Polygon Zero
The unique selling point of Polygon Zero is the algorithm it chooses to use in generation of ZK proofs: Plonky2
Plonky2 is a recursive ZK proof generation algorithm that improves the speed of proof generation by generating proofs for transactions in a batch in parallel.
Suppose that we have
Xtransactions in a batch to validate — the naive solution would be to generate a single proof for the entire batch, which is computationally expensive and time-consuming. Instead, we can useYmachines to generateYnumber of proofs (whereY ≤ X), and recursively aggregate these proofs in subsequent layers of proof generation, until a single proof remains.Comparing these 2 ways of proof generation, the naive way would have a runtime of $O(X)$while the runtime of the recursive way would be $O(log_y X)$.
Apart from its improved runtime, Plonky2 is also natively compatible with Ethereum. Hence, its perfect for building a composable VM that’s fully compatible with the EVM, that’s also highly horizontally scalable — improvements to runtime of proof generation scales in proportion as more nodes gets added to the Polygon Zero network.
Polygon Miden
The core component of this ZK Rollup is Miden VM, an open-source STARK-based VM. The most important feature is that a STARK-based proof of execution is automatically generated for any program executed on the VM, which then can be used by anyone to verify that a program was executed correctly without the need for re-executing it or prior knowledge about the inner-workings of the program.
Miden VM is a highly generalisable and flexible, capable of executing arbitrary programs and transactions. Miden VM aims to support multiple blockchain-centric languages (Solidity, Move, Sway) by building language-specific compilers that translates smart contract written in those languages into Miden Assembly — the native language of the Miden VM.
Other features that Miden sought to bring into the Ethereum ecosystem are account abstractions, native multi-asset support, parallel execution of casually-independent transactions and privacy for both transactions and smart contracts.
Miden VM uses STARKs as the proving system, which is commonly compared against SNARKs. Some advantages of doing so are:
No reliance on a a trusted set-up — compared to SNARKs which depends on a impartial 3rd party or a complex setup ceremonies to generate proving and verification keys
Computationally more flexible and scalable
STARKs are quantum-resistant as they rely on collision-resistant hashing, which is future-proof
Concluding Thoughts
Scaling of blockchain performance via ZK technology is still heavily in development, and the emergence of a clear winner remains to be seen. Apart from state-of-the-art ZKP generation and throughput improvements, other external factors such as network effects and user/developer experience play a huge role in determining which solution would come out on top.
As it stands now, polygon zkEVM seems to be in the lead by seemingly solving the dilemma behind ZK-enabled scaling solutions, and also has the first-mover advantage of being the first ZK-enabled and EVM-equivalent VM to go to market.
A notable solution to keep pace with would be the development of Polygon Miden’s Miden VM, which seeks to bring advanced features currently unavailable on Ethereum, which are still heavily under discussion and development.
Appendix
EVM Compatibility vs EVM Equivalence
💡 TLDR: An EVM compatible VM is the quick-and-dirty way to onboard most dApps running on Ethereum on to the L2’s, but it’s inherently un-generalisable and un-sustainable. Achieving EVM equivalence is the best way forward in optimising engineering resources and staying up-to-date with developments with the EVM
The holy grail of L2 roll-ups is to be able to deploy any dApps and tooling running on Ethereum directly with minimal changes to the existing codebase
The fastest way to do so is to build a custom VM that acts as a proxy between the user of the L2 and the EVM. Apart from executing these transactions, the VM also enforces rules and scaling features of the roll-up.
Though quick to go-to-market, this solution inherently introduces technical debt, as teams would have to maintain the custom VM’s codebase to keep up with the developments of the EVM. For instance, not all functionalities of EVM is available for apps deployed on the L2 as the L2’s VM would have to implement 1-to-1 mapping of the
opcodesfor both their VM and the EVM. In addition, L2 teams would have to spend precious engineering resources building out custom tooling to support their VM, since existing EVM tooling is not 100% compatible.The solution here is to re-implement the entire VM following the specifications state in the Ethereum Yellow Paper while introducing L2-scaling features into the VM. This allows the L2 teams to capitalise on existing toolings built out for the original EVM, thus optimising their already-strained engineering resources. Additionally, lesser lines of custom code means lower risk of introducing vulnerabilities into the VM.
Reading List And References
EVM equivalence vs compatibility
