Intuition about ZK

One sentence for ZK: ZK is a way for a prover to convince a verifier that some statement is true but reveals no additional information except that the statement is true. ZK is designed for anonymity. Imagine that we can prove we have a valid ID without verifiers knowing our real name or ID.

Here is a more vivid example. Alice and Bob are playing Sudoku. Alice would like to show Bob that she found the answer. However, she did not want to reveal any information about the answer since Bob was still working on it. How will you design this proof?

The answer is simple. We write down the Sudoku into cards, facing down. Bob can randomly choose one column, row, or block. Alice takes that column, row, or block of cards and shuffles it. Bob can verify the correctness by checking cards with 1-9. By constantly performing this step, Bob can say that Alice knows the answer, but Bob does not know the answer after the verification.

If you still can’t get the idea, view this video. The UCLA CS professor will explain ZK on five different levels. You will definitely get it.

Common ZK Proof Systems

Before examining the ZK proof systems comprehensively, notice that ZK-SNARK is a name of a class of schemes, and ZK-STARK is the name of a specific scheme.

Let’s start with ZK-SNARK. SNARK stands for Succinct Non-Interactive Arguments of Knowledge. SNARK is unique from other ZK proof systems because of its trust setup phase, what ‘N’ stands for.

• Succinct: The proof size and verification time are smaller than the original computation (statement).
• Non-interactive: The provers and verifiers do not need to communicate back and forth for each round. Instead, the provers and verifiers need to finish the initial setup phase. Even if they miss the setup phase, public verifiers can also join the verification later.
• Arguments: Provers with extremely large computation power can cheat the verifiers by generating wrong proofs. When this happens, the public/private key encryption is also broken.
• Knowledge: The prover needs to know something secret to make the proof.

The problem with ZK-SNARK is the trust setup phase. The trust setup phase generates a reference string. If the reference string is leaked, anyone can make the fake proof. Also, coordinating such a trust setup phase between multiparty is complex. The reference string can only be used in one program (Circuit). Thus it is impossible to have ZK-SNARK with a single trust setup for general computation. Another problem is that the reference string is not upgradable. If we upgrade the program, we need to rerun the trust setup phase.

To solve the problem, there are two approaches:

• Transparent Setup: The trust setup phase sets a CRS (Common Reference String). If the CRS is leaked, the ZK proof systems will not be hurt. Fractal, Halo, SuperSonic and ZK-STARK use this approach. The problem with this approach is that the size of the proofs may be in kBs. This would be too large for the blockchain area.
• Universal Setup: The setup creates a secret reference string, but it is structured. Thus it can be used in not only one program. Marlin, SuperSonic-RSA, and Plonk use this approach.

The following ZK proof systems are commonly used in the industry:

• Groth16: This is used in Zcash. It is fast and has a small proof size and constant verification time, but the trust setup phase needs to run for every program.
• Sonic: Support universal setup. The SRS(Structured reference string) is linear to the size of supported programs. The proofs size is fixed, but the verification is expensive. On the other hand, it makes general computation possible.
• Fractal: Allow recursion. The proof size is big.
• Halo: Support recursion. It is not succinct because verification time is linear. Most ZK application is based on Halo2.
• SuperSonic: The first practical transparent ZK-SNARK.
• Marlin: Structured reference string (SRS); Universal and updatable; Better prover and varication time than Sonic, but slower than Groth16.
• Plonk: Universal setup; Multiparty joins the setup phase sequentially. This makes it easy for many participants to join the trust setup phase; PLONK uses Kate commitments instead of polynomial commitments ( Recall that the first step in ZK-SNARK is to transform computation into a polynomial problem). Plonk is modern and popular today. Lots of ZK proof systems are based on Plonk and they are named Plonkish.

Here is the benchmark based on this research. CRS is common reference string. SRS is structure reference string generated in the trust setup phase. The proof size determines the storage cost in the base layer—the runtime for the prover and verifier influence the computation resource.

You can find more benchmarks in the following research:

• Benchmarking Zero-Knowledge proofs with isekai
• Zero-Knowledge Proofs: STARKs vs SNARKs
• Community Proposal: A Benchmarking Framework for (Zero-Knowledge) Proof Systems
• Comparison of Different zk-SNARKs

A quick wrap-up, if you see a new ZK proof systems, what number should you care about?

• Prover time for 1tx and 10 txs
• Verifier time for 1tx and 10 txs
• Proof size for 1tx and 10 txs
• Trusted setup phase
• Reference string size
• CRS(common reference string) support
• Upgradable
• SRS(structured reference string) support
• Recursion support
• Post-quantum secure
• Cryptography assumptions

ZK has been applicable in recent years. The two main theses of ZK is a rollup, which improves computation efficiency and privacy. For the private thesis, it is intuitive since ZK shares no knowledge with the verifier except the statement itself. The rollup thesis heavily relies on two characteristics of ZK: succinct and recursion. Succinct characteristic helps verifiers save many computation resources instead of rerunning the whole program. Recursion characteristic helps to save storage space. With recursion, the blockchain can keep a fixed size. This is also beneficial for decentralization since the tiny blockchain node does not require high-end hardware.

ZK Application Development

To develop a ZK application independently, a developer needs the following research and development skills:

• Algorithm and low-level optimizations of arithmetic skills. Developers need this skill to tackle problems in finite field arithmetic, polynomial commitments, and elliptic curve.
• Cryptography knowledge about ZK proof systems like ZK-SNARKs, Plonkish, and trust setup process. Developers need to choose appropriate ZK proof systems and they may need to customize them.
• Circuit programming skills. Developers need to develop constraints for some cryptography primitives like Merkle Trees, and Hash.
• Application and cryptographic protocols development.

Effective development tools can not only speed up the development process but also reduce the complexity. For example, tools like Circom takes care of the low-level algebra and proof systems. Developers can ignore algebra and ZK proof systems, and focus on circuit programming and application development.

What is Rollup

Mechanism

The concept of rollup is simple. Since on-chain computation is expansive, rollup puts computation off-chain and only stores the result on a chain.

The state root of the Merkle tree is stored at the rollup contract. The root can be used to verify the existence of the leaves. The smart contract knows how to update the state with the info in batches, and the state root switches to the new state root.

ZK rollup uses ZK proof in batches to verify that the new state root is correct. The ZK proof can be used to verify that after executing txs in batches, we can get the new state root provided in batches. Verifiers can verify the correctness of computations without having to execute them, and verifiers will not even learn what was executed. The characteristic of succinctness helps the ZKRU (ZK rollup) scale-up.

Optimistic Rollup is not as perfect as ZKRU. For example, ORU has fewer TPS and has a longer withdrawal period since it relies on fraud proof. Therefore, some ORUs are integrating ZK into their solution. In this way, they can improve TPS and shorter the withdrawal period. For example, they can add ZK to state transition to create a short fraud-proof time.

Roles

There are three roles in rollup:

• User: Users submit txs on Layer2. They deposit assets to Layer2.
• Rollup operator: Rollup operators keep the network running. They generate proof, execute txs, put txs into batches, and challenge fraud proofs.
• Base layer: This layer ensures the security of Layer2 and is where consensus lies. The most common base layer for Layer2 is Ethereum

Economic Structure

The most important things for the economy of Layer2 are costs and revenue.

For Layer2, we can break down the cost into the following:

• Proof Cost (for Layer2)
• State Transition
• Base Layer Tx Cost
• Data cost on the base layer

One main cost for the network is data storage. This chart illustrates how data is stored. First, users send data (txs) to rollup operators. Then rollup operators package lots of data (txs) into batches and publish it to the base layer.

This chart illustrates how much are rollups paying for the base layer and their revenue.

The common revenue for Layer2 is fees and MEV values. Fees vary based on the network status, and MEV varies based on users’ txs. Also, Layer2 may issue new tokens. Tokens will be the reward for rollup operators.

Common ZK Rollup

This graph shows the status of different Layer2. Arbitrum dominates the whole market.

This graph illustrates different tech used by different chains. Here is a short explanation:

• State Validation
  • Fraud Proofs: Fraud proofs allow whitelisted actors watching the chain to prove that the state is incorrect.
  • ZK proofs (ST): ZK-STARKS are zero-knowledge proofs that ensure state correctness.
  • INT: Interactive proofs (INT) require multiple transactions over time to resolve.
  • SN: Require trust setupExits only: Exits from the network are subject to a period when they can be challenged. The internet network state is left unchecked.
  • 1R: Single round proofs (1R) only require a single transaction to resolve.
• Data availability
  • On chain: All of the data needed for proof construction is published on chain.
  • External DAC: Proof construction relies fully on data that is NOT published on chain. There exists a data availability committee (DAC) that is tasked with protecting and supplying the data.
  • External: Proof construction relies fully on data that is NOT published on chain.
• Upgradability
  • Yes: The code that secures the system can be changed arbitrarily and without notice.
  • 21 day or no delay: There is a 21 days delay unless it is overridden by the 9/15 Security Council multisig.
• Sequencer Failure
  • Transact using L1: The user is able to submit a transaction through L1 and force its inclusion on L2.
  • Force trade/ exit to L1: The user can force the sequencer to include a trade or withdrawal transaction by submitting a request through L1. The user is required to find a counterparty for the trade by out of system means. If the sequencer is down, the user can use the exit hatch to withdraw funds.
  • Force exit to L1: The user can force the sequencer to include their withdrawal transaction by submitting a request through L1. If the sequencer is down, the user can use the exit hatch to withdraw funds.
  • Propose blocks(ZK): The user needs to run their own node and use it to propose new blocks that include otherwise censored transactions. Proposing new blocks requires creating ZK proofs which are very computationally expensive.
  • Exit to L1: The user is only able to submit an L1 withdrawal request . After that, the user exits the system with their funds.
• Validation Failure:
  • Escape hatch(MP): Users are able to trustlessly exit their collateral by submitting a merkle proof of funds. Positions will be closed using the average price from the last batch state update.
  • Propose blocks: The user needs to run their own node and use it to propose new blocks to replace the validator.

Here are the pros and cons listed on Ethhub for ZKRU:

Pros:

• Reduced fees per user transfer.
• Faster than Optimistic Rollup and Plasma.
• Blocks will be computed in a parallel computing model, which encourages decentralization.
• Fewer data contained in each transaction increases the throughput and scalability of layer 2.
• It does not require a fraud game verification like Optimistic Rollup, which can delay withdrawals by up to two weeks.

Cons:

• The difficulty in computing zero-knowledge proof will require data optimization to get maximum throughput.
• The initial setup of ZK rollups promotes a centralized scheme (see Security Considerations).
• The security scheme assumes a level of unverifiable trust.
• Quantum computing poses a threat to hacking the blockchain.

Currently, most available ZK Layer2 only has limited functionality like payment. ZKSync is one payment layer used by Gitcoin. There is also ZK Layer2 with custom VM enabled. These custom VMs are non-EVM compatible, such as (StarkEx + Cairo, zkSync 1.0 + Zinc).

ZKEVM is the next milestone for all ZKRU. There are three levels for ZKEVM solutions:

• Consensus level: At this stage, the ZKEVM is equivalent to EVM on Ethereum. It generates proofs for state roots on Ethereum.
• Bytecode level: The ZK proof systems play a big role in this ZKEVM. In this stage, state roots generated by ZKEVM are not compatible with the Ethereum EVM. This approach is taken by Scroll, Hermez.
• Language level: In this state, there is no real ZKEVM. A transpiler transforms Solidity into ZK-friendly VM that is totally different from EVM. zkSync and Starkware take this approach.

In the Ethereum roadmap, Ethereum will integrate a consensus level ZKEVM.

Justin Drake from EF expects to see a bytecode level ZKEVM, like Hermez or Scroll to deploy in 2022, but with some limitations:

• Small gas limits compare to the current gas limit on Ethereum.
• Centralized provers due to computation difficulty. Users may start to run their provers in 2023 with GPUs and SNARK proving ASIC by 2024. The development of the hardware will change from CPU, GPU, FPGA to ASIC.
• Due to development complexity, there will exist bugs.

To further reduce the cost, some ZKRUs are implementing Volition, changing their base layer. They plan to store the data off-chain or on their chains.

There are 16 ZKRU in the market and 7 of them have released the token. The total market cap is $15B, around 0.67% of the total crypto market.

Polygon

Polygon currently works on 4 ZK products:

• Miden: Experiment general computation ZKRU with 1k+ tx/sec; 15min withdraws; 5 secs block time; Privacy enabled.
• Nightfall: Nightfall is an ORU with ZK enabled to provide private transactions. Around 9000 gas/tx and 110 TPS. It is designed for Ernst & Young.
• Hermez: EVM compatible ZKRU; 2k TPS. The network is currently live. The average txs per batch is 1. The daily tx number is nearly zero (data from explorer).
• Zero: General Computation ZKRU with recursion enabled; 0.17s to generate proof; 45kb proof size; one account only occupies 5 bits.

zkSync

zkSync started in Dec 2019. zkSync is a ZKRU built by Matter Labs. It is based on Plonk and the trusted. Currently, it supports payment function and limited smart contract function with customized programming language Zinc.

zkSync 2.0 testnet is live in Feb featured ZKEVM. Matter Labs makes most OPCODE into circuits to achieve EVM compatibility. For now, it does not support ADDMOD, SMOD, MULMOD, EXP, CREATE2, and KECCAK256. In this approach, Solidity will be the first-class citizens.

The gas in zkSync 2.0 will fluctuate based on the current Layer1 gas price (data storage on Layer1 cost) and ZK proof generation costs.

To further improve the TPS and lower the cost, zkSync will launch ZKPorter. Users can choose to store their account data on ZKPorter, which can cost much less than the base layer. If an account is stored on ZK Porter, all its tx can only be stored on ZKPorter. They can not be stored on Ethereum. ZKPorter will be secured by zkSync token holders.

Starkware

Starkware was started in May 2018 by core team members of Zcash.

Starkware has two solutions: StarkEx, StarkNet.

StarkEx is a SaaS that designs ZKRU for projects like dYdX, DeverseFi, Immutable, Sorare. dYdX is quite successful. Here are some metrics about dYdX. It has around 4k weekly active traders.

StarkNet is the permissionless version. StarkNet is not EVM compatible. It uses Cairo to write smart contracts.

Starkware is also working on ZKEVM. However, they have a different approach. They use Warp to transpile smart contracts written by solidity to Cairo on StarkNet. This approach is not as good as zkSync.

StarkNet alpha with EVM compatible launched in Nov 2021. Currently, the daily transaction number is 1033 (data from Explorer).

Similarly, Starkware is also working on off-chain storage. Users can choose to process their tx on Ethereum or off-chain.

Loopring

Loopring is a ZKRU DEX featuring low fees for spot trading with 2k TPS.

Loopring released its tokens LRC in 2018. Currently, the market cap of Loopring is $1.3m. Loopring has total 65k users, 167 unique users increment everyday, and 10896 txs everyday (data from explorer).

dYdX is a strong competitor of Loopring. In the future, when ZKEVM becomes popular, there would be more competitors joining this market, because development on ZKEVM is faster than developing a new Layer2 DEX.

Current State

Blockchain space has entered the multichain era. Different chains have different concentrations and have their features, not only look good on paper. We see lots of new chains featured with high TPS in the past. Now, these chains have a strong ecosystem and featured apps. Making a new chain with high TPS is easier than before because of the development tools. Thus now we emphasize more on featured apps, not paper numbers.

Moonbeam is such a good example. It has some kind of similar base layer Polkadot and high TPS. This looks similar to most Layer2. Before launch, moonbeam collaborated with lots of projects, like sushi. It launches with a complete ecosystem like top-tier DEX, Lending, and bridges but lacks concentration and featured apps.

Thus layer2 needs to have features to compete with other chains with high TPS. There would be several potential opportunities in layer2 ecosystems:

1. Apps that utilize high throughput and lower fees of Layer2. One example is dYdX. As a DEX, it offers CEX like experience.
2. Since all Layer2 use the same base layer, it would be safer to construct cross-layer2 apps. For example, aggregate the fragmented liquidity between layer2. Starkware proposes dAMM to solve this. dAMM allows layer1 LPs to expose to layer2 traders.
3. Development kit to help developers quickly construct app-specific layer2. This may look like Cosmos SDK and Substrate from Polkadot. The idea is that if an app grows bigger, it will consume more resources on the base layer. To reduce computation cost, it either builds its chain, moves to layer2, or builds its layer2. We see Axie Infinity face the same problem. At that time, building its chain was the only solution. However, a separated chain is isolated and cannot benefit from the base layer ecosystem. Migrating to layer2 looks good, but it is not flexible. The app faces the same constraint as in the base layer. Thus the most promising solution is having its layer2. If the cross-layer2 is convenient and integrated well with the base layer, the app does not lose anything from moving away from the base layer.
4. Better integration with the base layer. Users don’t feel any difference between layer2 and the base layer. This includes asset bridges and protocol communication.
5. Different kinds of VM. More powerful ZKEVM or ZKWASM.
6. Layer2 on other chains. Different chains have different concentrations. A ZKRU is also promising to them. ZK Link team has implemented Groth16 in Solana. Solana focuses on onboarding traditional finance institutions. These institutions need ZK to protect their customer's privacy.
7. ZK bridge. Almost all the bridges are not trustless. We at least need to trust someone, like an oracle, to network participants. Although network participants have deposits, it is hard to calculate the slashing condition. The ideal trustless bridge is the ZK bridge. The light client captures the block and generates the proof. In this way, we don’t need to trust what the oracle says. We can verify the proof with a small cost due to SNARKs. The current problem is how to build a block verifier in the ZK circuit. Also, the extensibility sucks. The light client is coupled with blockchain consensus. Thus developers need to build different circuits for different chains.
8. Commercialize ZK algorithm. There are many commercialized algorithms for professional problems, like advanced solvers for linear programming and GPT-3 from Microsoft. However, if ZK is highly professional and only selected developers can do this, there is room for a commercialized algorithm. Currently, most ZK practitioners are highly educated and hold a Ph.D. degree in CS, Math, or Cryptography.
9. Chips and cloud computation. If more users move to ZKRU, there would be a growing demand for computation power. Node operators need more computation power to compete for packaging transactions, which is profitable. In the Ethereum roadmap, Ethereum will integrate ZKEVM, which means Ethereum miners also need to compute ZK proofs. Dedicated chips can give node operators more computation power and lower power consumption. Cloud computations can give more users to access ZKRU node operations. This growing demand for dedicated chips and cloud computation may look similar to what we see in the Ethereum mining industry. Miners first use CPU and GPU. Then they change to dedicated FPGA and ASIC. Cloud mining has existed in Ethereum and Bitcoin mining industry for a long time. Another example is AI chips. Now every iPhone has dedicated AI chips. If ZK is the new standard tech for privacy, there will be SNARK ASICs for every iPhone.
10. Recursion enabled ZKRU. Blockchain needs to balance security, decentralization, and TPS. Size plays a big role here. In traditional blockchains, bigger size means centralization, because the node requires advanced hardware. However, smaller size means lower TPS. It is hard to balance TPS and decentralization. Now recursion will change this. Recursion can minimize the blockchain size without harming TPS.

Privacy

ZK has already been used in lots of privacy projects. For example, Tornado cash, Zcash, dark forest.

There are three stages for privacy projects:

1. Transaction privacy: Users can hide their txs
2. General computation privacy: Currently all the computation process on Ethereum is public. Anyone can see the inputs, outputs, and state transition.
3. Function privacy: Sometimes functions’ names leak info. For example, mint() often means mint tokens.

The total market cap of the private sector is around $10B, around 0.45% of the total crypto market. The daily trading volume is around $1B.

Tornado Cash

Tornado Cash is a smart contract-based privacy transaction tool. It is used to hide the cash flow. It now supports Ethereum, BSC, Polygon, Optimism, Arbitrum, Gnosis, and Avalanche.

It achieves privacy for the sake of usability. Deposit, wait and withdraw, the user can get the clean money.

ZK is used in users’ deposit and withdrawal processes.

Zcash

Zcash is a blockchain that use zk-SNARK to achieve private transactions. Unlike Tornado Cash, Zcash customize the blockchain to achieve privacy transaction.

Zecrey

Zecrey is a privacy payment application supporting Ethereum, Polygon, BSC, Near, and Avalanche. It is on the first level of privacy, transaction privacy. Zecrey offers a browser wallet to help users privately transfer and swap tokens. To swap and transfer privately, users need to deposit tokens into Zecrey layer2, powered by Plonk. Everything that happens in layer2 can be private. Zecrey layer2 also supports cross-chain swap.

Currently, Zecrey has around 10 txs everyday (data from explorer)

Suterusu

Suterusu is a private payment application supporint Ethereum, BSC, Fantom, and Polygon. It uses layer2 to protect users’ transaction privacy. It also has a cross-chain bridge, which transfers $SUTER between ETH and BSC.

Suterusu has total 15k users and 24k deposits. The user increment stagnates. Its market cap is around $10m.

Dark Forest

Dark Forest is an MMO. Players need to send energy to other planets to occupy them. The location of planets is kept secret. Players need to find these planets themselves (hash collision). The ZK is used to prove locations related operations:

• Planet Initialization
• Planet resources movement

In v0.6 round 1, 1700 players joined the game, and 700 got the next round. During this round, players made 2 million txs, spending around 1.5 trillion gas. Suppose it is on Ethereum, with an 80 gas fee. So the total gas will cost 120 ETH.

Stealth Airdrop

The stealth airdrop allows users to get airdrop anonymously. The user first uses their airdrop wallet to generate proof. Then they can use other wallets to get the airdrop token with the proof.

A16z also implements something similar a16z/zkp-merkle-airdrop-contracts (github.com).

This example shows the application of ZK in voting.

zkProof of Buffiness

This project is on ETHDanver. Users can generate ZK proof to show that they have a buffiness without revealing anything about themselves other than the user’s Buffiness.

This is an application of ZK in Identity.

Wrap up

1. Small privacy market. Privacy projects started very early. Zcash started in 2016. However, the whole privacy market only takes 0.45% of the total crypto market.
2. Benefit from higher privacy standards. Users are pursuing stronger privacy protections without sacrificing usability. Especially in the mobile phone industry, Google and Apple are pushing stricter privacy standards. EU proposes regulations to protect consumers’ privacy. Infrastructure companies like let’s encrypt which offer SSL certificates benefit from this. In the future, ZK may be adopted by these giant companies and there would be huge opportunities for ZK infrastructures.
3. A must for onboard institutions. Big institutions have the responsibility to protect customers’ privacy and some blockchains are trying to onboard these big institutions. ZK will be a must for this scenario.
4. Benefit DAO governance and Identity. Anonymity is an important aspect of democratic governance. ZK can empower privacy preserved governance and let participants make their own decisions without distracting by others’ decisions. Identity can also benefit from privacy. Users can reveal their identity without showing their actual address.
5. Ignore ZK, focus on product usability. ZK can better protect privacy, but a product is not all about ZK. ZK is more tech focus and we need to emphasize the usability of the product. Normally more privacy means bad usability, but usability is the most crucial compatibility. Thus focus more on usability, market, and the team.

Other interesting project

ZKRepel

ZKRepel appeared in GR13 and got $5k. This is an online playground for ZK circuits. Developers can quickly write and test circuits in ZKRepel without setting local development environments. It is similar to Remix.

We see a paradigm shift from local development to cloud-based development. There are famous products like Codesandbox, Codepen, Codespaces. With these products, developers can continuously work anywhere anytime and set up a new development environment quickly. Development environment as infrastructure is a big trend today. This is proposed by Github, and Github practiced it with Codespaces.

There are no clear statistics about ZK developers. However, from the data on Github, it is over 500x less than solidity developers.

Find more ZK project

There are VCs or grants there focusing on ZK projects:

• ZKTech Gitcoin Grants: The first round matched $100k among 19 projects.
• 0xPARC Grants: Supporting application level innovation on Ethereum and other decentralized platforms.
• zkDAO: Newly launched $200M backed by zkSync and BitDAO to support zkSync ecosystem. 7.5% of $200M will be used in grants.
• Polygon ZK Fund
• Aztec Grants: Current focus on bridges, tooling, and analytics.
• Harmony ZK Fund: $10M fund for ZK and privacy research.
• ZK Validator: Fund focusing on ZK. Featured investments are Aztec, Penumbra, Ironfish, Anoma, zkSync, Aleo, Diversfi
• ZPrice from Aleo

Conclusion

ZK is a really promising technology that can bring impossible things to possible. In recent years, there have been lots of breakthroughs happening here. These breakthroughs like stronger performance, upgradability and no need for trust setup push ZK to the applied stage. So if we are going to look at a ZK project, we need to care about these theoretical numbers:

• Prover time
• Verifier time
• Proof size
• Trusted setup phase
• Reference String Size
• CRS(common reference string) support
• Upgradable SRS(structured reference string) support
• Recursion Support
• Post-quantum Secure
• Cryptography assumptions

ZKEVM is the next milestone for ZKRU. There are three stages for ZKEVM:

• Consensus level
• Bytecode level
• Language level

ZK just enters the applied stage. The ecosystem is still empty. Not every characteristic of ZK is well used and applied to new products. People can still get inspiration from this cutting-edge theory. The following direction can best be beneficial from ZK tech:

• Apps that need high TPS and lower fee
• Cross Layer2 communication protocol/apps
• Aggregate fragment liquidity in Layer2
• Development kit/framework
• Cloud-based development tools
• Cross Layer2 Layer1 apps with unique features
• Different zkVM
• ZK Bridge
• Applied ZK on other chains
• Layer2 with recursion enabled
• ZK in DAO and community governance
• Commercialize ZK algorithm
• Chips and cloud computation
• Recursion in ZKRU

There are two main theses for applying ZK: Rollup and Privacy. Rollup is more promising than privacy. Privacy does not make sense because it is designed to be transparent. The privacy culture is somewhere against the transparent spirit. Also, privacy may have compliance problems. In Web2 era, we do not see the prosperity of privacy apps. In the same category, the top product does not heavily focus on privacy, although more and more institutions have improved their privacy protections. Privacy does have a tradeoff. Most of the time is availability, which is the key to users.

When looking at ZK applications, the following points are important:

• ZK is a fancy term. Without ZK, is the real product still competitive and has good UX.
• ZK is complex and does an extra burden on the development speed.
• ZK benefits DAO governance and identity
• ZK will help institutions onboard the blockchain

Learn more

If you would like to learn more about building a ZK project, check out this tutorial and Awesome-zk. Also, keep an eye on this.

I worked as a tech associate for Fundamental Lab. You can find me on Twitter here and Fundamental Lab here.

Reference