Comparing zkRollups & Introducing TrueZK's Type 1.5 zkRollup
Zero-Knowledge Rollup (ZK Rollup) technology has emerged as a powerful and innovative solution in the blockchain space, offering substantial advancements in scalability, privacy, and security. In recent years, the adoption of blockchain technology has grown exponentially, bringing both exciting opportunities and significant challenges. Scalability has become a bottleneck for many blockchain networks, and privacy concerns have gained more attention than ever. ZK Rollups offer a promising approach to address these issues, making it crucial to evaluate the different options available.
In this article, we provide a detailed analysis of various types of zkRollups, their strengths, weaknesses, and unique features, and how we place ourselves as Type 1.5 zkRollup. It is intended to serve as a valuable resource for blockchain developers, enterprises, and enthusiasts who are considering the adoption of ZK Rollup technology in their projects.
Before we deep dive into how TrueZK was conceptualized, we need to draw a comparison between types of Rollups & we can compare these zkRollups based on several factors that lead us to build TrueNet for TrueZK.
Firstly, At what stage does ZK essentially happen?
Each company turning up a zkRollup has made some tradeoffs, with how they're implementing zk on the entire system, i.e., which portion of the initial system of Ethereum is serving as inputs to the ZKP cryptosystem.
To break it down, there are 3 such kinds:
| Levels | Description |
|---|---|
| Language Level | For language level, the zkRollup system transpiles the entire Solidity/Yul/Vyper code to something the zkrollups VM can understand, hence, they're clearly diverging out of the EVM-friendliness perspective. For example, Starkware transpiles Solidity into Cairo, something that a SNARK-friendly VM can easily work with. Starknet VM in this case |
| Bytecode Level | In this case, the zkRollup system directly interprets the EVM bytecodes directly into something the ZKP system can work with. Though this takes longer proof generation time producing different state roots. For example - converting the Merkle Patricia Trie to something else that the zkrollup system can easily work with, for example, Scroll, Polygon Hermez, and Consensys Linea |
| Consensus Level | This zkRollup system is mostly still under development, but this system targets a FULL EVM EQUIVALENCE, and its consensus layer, as it is used in L1 Ethereum. Most STARK-based prover systems are targeting this goal too, for example, Polygon Miden and Starknet again. |
Understanding types of zkRollup
As most of us know Vitalik breaks down zkRollups into multiple types. Each type tries to prove its EVM Equivalence and Speed/Efficiency.
According to Vitalik, there are 4 types of zkRollups, refer to this diagram.
We took the position of Type 1.5 rollup as in our 1.5 zkRollup approach we focus more on Ethereum compatibility than, optimizing the entire process. However, the major optimization lies within Layer 2 itself. We call ourselves type 1.5 because we change the way blocks are validated on L2, instead of using Merkle Proofs hashing which costs about
384 bytes, we use32 byte recursive Poseidon Hashfunctions.
The type-wise comparison
| Comparison Parameter | Type 1 | Type 2 | Type 2.5 | Type 3 | Type 4 |
|---|---|---|---|---|---|
| EVM-Equivalence | fully and uncompromisingly EVM-equivalent | fully EVM equivalent | EVM-equivalent, except for gas costs | Almost EVM equivalent | High level language equivalent |
| Advantages | the execution layer logic is included, and the beacon chain consensus is untouched, exec trace and smart contract and account logic is added | they make some changes to encoding patterns and internal data structures, which would still result in perfect equivalence at EVM-level | improves prover times significantly by changing gas costs of precompiles like KECCAK | most precompiles are either changed or removed, hence it takes much faster to build, and much faster to prove | by using their own domain-specific languages, every step of the EVM is proved at very fast speeds |
| Disadvantages | there are large parts around the Ethereum protocol that take substantially high amount of time to prove | relies on several zk-unfriendly opcodes, resulting in still slow prover times | changing gas costs will sure shot reduce developer tooling compatibility and shall break a few applications | this will be incompatible with most applications, because many applications use precompiles that have been changed in the zkEVM | type 4 would break in machine level EVM processes, like CREATE2, handwritten bytecodes, which would take enormous amounts of debugging |
Why TrueZK?
TrueZK provides the most seamless approach to incorporate the power of Zero-Knowledge Proofs in any enterprise software, be it, applications or any EVM-compatible L1 blockchain. To help achieve this we have several products up our sleeves as listed below,
TrueNet
TrueNet is one of the flagship products of TrueZK. We thought and came across various ways to be a plug-n-play L2 experience for most EVM compatible chains, following the Go-Ethereum Execution and Consensus Specs.
TrueID
With the TrueID SDK, the users can now avail, 100% Sybil-Resistant (opens in a new tab), zero-knowledge, on-chain identities, using zkSNARKs and incorporating the features of Rate-Limiting Nullifiers (opens in a new tab).
Private Groups
Private Groups would inherently support ERC-4337 (opens in a new tab) (Account Abstraction), for every user, so that they can seamlessly establish, truly private groups, even if they belong to a public EVM Compatible chain.
Each private group shall have its group explorer so that people inside each group can see and identify each other.
Our Approach
To achieve that, we are developing a type 1.5
zkRollup, let us explain why we are a type 1.5 zkRollup and not a type 1 or a type 2 variant. According to Vitalik's types of zkRollups, a type 1 zkrollup is 100% Ethereum-equivalent, this means there aren't any further changes and tweaks to the Execution/Consensus arch of L1 Ethereum.Whereas type 2 zkRollups, focus on changing some encoding patterns and internal algorithms, regarding data storage and transaction execution. However, this architecture too is completely EVM-equivalent, which means, how instructions are handled is still same.
Why compatibility?
As the rollup market is trying to come up with its own ecosystems and is planning to diverge from Ethereum's end goal of decentralization and building together as a community, we plan to stay in the lines of Ethereum's L1 Scalability roadmap. We share most of Ethereum and other EVM compatible chains' infrastructures, and the same time introduce 2 new approaches:
-
Faster block validation on TrueNet L2 variants.
-
Building up an automated pipeline, to scale ANY Ethereum-like/EVM compatible chain, with faster TPS, wrapped with a fully automated Pay-As-You-Go structure. We're calling this zkRollup-As-A-Service (ZaaS).
First Step: TrueProver-1
TrueProver-1 is not a zkEVM design implementation, in our 1.5 zkRollup approach we focus more on Ethereum compatibility, rather than optimizing the entire process. However, the major optimization lies within Layer 2 itself. We call ourselves type 1.5 because we change the way blocks are validated on L2, inspite of using Merkle Proofs which cost about 384 bytes, we use 32 byte recursive Poseidon Hash functions.
Why do we use Poseidon?
- Traditional Hash Functions like
KeccakandSHA256are too expensive (takes almost 1 minute for proofs, in early versions). - Flaws with the proof system: in these collision-resistant hash functions the proof generation time is directly proportional to various factors in the circuit. $$time(proof gen.) \propto circuit(size, width, degree)$$
- Traditional hash functions are mainly optimized on a certain architecture, they're overall not generalized.
- Not enough leaves can be hash in the tree
Merits
With Poseidon, we have:
- We can operate on a bigger finite field (254 bits)
- Can handle a much higher number of constraints, thanks to R1CS
- can generate proofs for more number of leaves, that is $2^30$ leaves.
- Proof verification in < 1 second.
- Upto 15x better hashing performance in comparison to other collision-resistant hash functions.
What if my Pay-as-you-go structure expires or do I want to opt-out?
In that case, there is no problem since we share most of the Ethereum infrastructure, we're essentially an Enshrined Rollup, which basically means all forms of Settlements happen on your Layer 1 chain itself. Hence, once your plan expires, all the transaction batch data shall be posted back to your L1 EVM chain.
Who can use it?
Anyone, with an existing Private/Public EVM compatible chain, who looks forward to scaling the current throughput of their chain.
How we are different (a quest for supporting the Verge)
As mentioned by Vitalik before, the Verge (opens in a new tab) is on its way, which means, the migration of chain data from Merkle Patricia Tries (MPT) to Verkle Tries (VKT), for a faster block validity overall, why? Check out, this chart below!
However, in the current market scenario, NONE of the current zkEVM designs support the Verkle Trie specs to compete over compatibility, at TrueZK we're busy preparing ourselves for something that is going to kick in very soon.
A Deeper dive into the problem
Currently, Ethereum uses the Barreto-Naehrig (BN254) curve, because this is currently the most reliable pairing-friendly crypto primitive available, (check EIP-1829 (opens in a new tab)), and the same design spec is being used to construct zkSNARK circuits too, for example, Poseidon Hash is one very zk-friendly hash function that uses the BN254 curve.
However, in the future, as Verkle Tries come into play with the Verge upgrade, they are being implemented in a curve called Bandersnatch (opens in a new tab), (and sometimes its prime subgroup called Banderwagon (opens in a new tab)). All of these curves are children of the BLS12_381 curve, (EIP-2537 (opens in a new tab)), which is indeed suitable for constructing ZKP circuits over Rust based frameworks like Halo2.
Using Bandersnatch or Banderwagon, we will be implementing Verkle Trie precompiles in our zkEVM design, to accommodate The Verge upgrades, which would result in spectacular optimizations in proving and verification time, even in the most humble computer hardware.
Further Steps:
The next product which is timelined to be released at around later in December this year (Public Testnet), will have a TrueNet variant with a zkEVM design implementation.
TrueProver-3.5: A zkEVM & Verkle Tries(VKT) compatible Proof generation using Bandersnatch or Banderwagon to accommodate the Verge Upgrade
TrueProver-Q - Fully post-quantum zkEVM prover with seamless Ethereum compatibility
TrueID-Q- Post-Quantum Proof-Of-Identity - Powered by Dilithium
Javelin: Upcoming Java Cryptography library to facilitate further Ethereum L1 upgrades, and enable zk in Android & Unreal ecosystems
Framework: In-circuit verkle trie precompiles for zkSNARK frameworks like Circom, Halo2, Leo and Noir.
The final automation layer
We don't want the power zk verifiability to be limited to the hands of Ethereum, hence, we'd be adding automation levels to the existing TrueNet infrastructure which will work for any L1 EVM-compatible chain, and extending further research into Post Quantum implementation.