Preface
So far, most of the protocols we have experienced in Web3 have a certain degree of trust assumption. When we hope to further pursue "decentralization", we will inevitably sacrifice some privacy. For example, when the protocol provides MEV-Protection, it is likely to use Private Mempool. Users need to assume that the node providers of this part will work honestly, that is, there is a third-party trust assumption, and in fact this is true for all protocols-there is a certain degree of trust assumption. According to our previous research report, for institutions and large users, privacy protection is one of the important factors for them to consider whether to migrate assets to the chain. This also means that some third-party on-chain data platforms may intensify the targeted attacks of MEV-Searcher and hackers on large users and institutions, so the introduction of on-chain privacy protection is undoubtedly a natural fit for their needs.
Prior to this, we also wrote a research report on Singularity, a project targeting dark pool trading in the privacy track (Extended reading: Detailed explanation of Singularity: Private transactions on a transparent blockchain).
So the question is: What can we do to protect privacy?
The four most commonly heard privacy computing solutions are: Fully Homomorphic Encryption (FHE), Multi-Party Computation (MPC), Trusted Execution Environment (TEE), and Zero Knowledge Proof (ZKP). They actually solve the needs of different scenarios.
First of all, for encrypted data, the ownership of this string of data is determined by who has the decryption/encryption key. Generally speaking, private data can be divided into personal visible and group visible.
Personal Private State: Data that can only be seen and changed by one subject, such as a personal balance.
Shared Private State: Data can be used by multiple entities for calculations while ensuring privacy, such as the balance in a liquidity pool.
For FHE, MPC, and TEE, they can all solve the problem of group visible data. However, FHE requires high computing resources, MPC requires all validators to be online, and TEE must trust the service provider. The current industry exploration of these is only suitable for a few scenarios, such as dark pool trading, private key management, etc. Although the result information output by ZKP is limited (i.e., "yes or no" questions), and most of them are only applicable to personally visible data, its application scenarios are fully explored by current users, such as cross-chain bridges, Layer2, KYC, etc. Even in the future, if FHE and MPC, or even other privacy computing solutions, become popular, ZKP will not be abandoned due to cannibalization effects/market competition, because:
ZKP + FHE: For example, in the ZKVM chain that uses the UTXO model, if you want to verify each transaction, the verifier must download the entire Merkle Tree and decode it one by one before verification. Therefore, the introduction of FHE can calculate the same result without the decoding process.
ZKP + MPC: For example, by using a dark pool with MPC + ZKP, users can further ensure the atomicity of transactions while ensuring their own privacy.
ZKP + TEE: For example, for ZK-SNARK, the generation of the Common Reference String can be performed by the node running TEE to ensure that the intermediate information is not leaked.
We can foresee that ZKP's wide application scenarios will emerge in a spurt, but this demand is still difficult to bear from the current mainstream Layer1. Not only does it have to face high Gas Fees, but it also needs to wait for network verification. Modular ZK As A Service (MZaaS), as a ZKP service provider's design framework, solves the above problems well. MZaaS provides a series of ZKP-related services to reduce the complexity of ZKP generation and improve efficiency. These services can be further divided into the following subcategories:
Proof Marketplace: It is mainly based on the concept of Requester-Prover Separation. It splits the Prover in different scenarios to utilize idle Prover resources to provide an open Proof market. Projects that can be used for reference include Mina, =nil;, and ZKPool.
Verification Layer: Based on the concept of Aggregation, the prover collects multiple proofs and generates a new proof to prove the validity of the initial proof, and reduces the cost of the verification process by providing a verification layer. Reference projects include Aligned Layer, Horizen, Cloaking Layer (zCloak Network), and Nebra.
How to understand ZKP?
Before understanding the ZKP market, we want to have an overall concept of the ZKP life cycle. Basically, the ZKP Proving System follows the following process:
A Prover asserts that he knows some information, expressed in terms of a system of constraints.
Generate circuits based on specified constraint systems
Prover inputs the solution (Witness) that matches the circuit to calculate the ZK Proof
Validator can verify ZKP to determine whether Prover really knows the information
Assume that we now have a Merkle Tree for recording user account balances. Normally, to update the account balance, we need to follow the following process:
Verify sender and receiver records in leaf nodes
Verify the sender's signature
Update the sender and receiver's balances
Update the Merkle Root of the Merkle Tree
But with the support of ZKP, the process proceeds as follows:
The process of verifying the Merkle Tree is completely constructed into a circuit
Take the Merkle Tree before and after the update and the transaction record (someone sent $10 to A) as input and calculate the ZKP
The verifier verifies the ZKP (taking the ZKP, verification key, and public input as input), and if the output is correct, the transaction is considered credible.
In this process, the verifier itself does not need to repeatedly verify the Merkle Tree, but only needs to trust the verification results (provided that the circuit is constructed correctly).
If we further decompose ZKP from a high-level perspective, the process from defining the problem to building the circuit is all done by the front-end (compiled in a high-level language), while the back-end (compiled in a low-level language) is responsible for embedding/combining this circuit with a certain proof system to generate ZKP. Specifically, the circuit is first combined with the Information-Theoretic Protocol, and then compiled into a suitable ZKP System, such as Groth16, using a Cryptographic Compiler.
Soundness is the ability to prove a statement in a system, and complete ...
Interactive Proof (IP): The verifier asks the prover a series of “random” questions. The prover responds. This continues for many rounds until the verifier is convinced that the prover’s statements are correct.
Probabilistic Checkable Proofs (PCP): Proofs are converted into a fixed-size format called a "proof copy". The verifier can randomly query a small amount of data in the copy to verify the proof. In order to prevent the prover from predicting the query value in advance and preparing a forged proof, an oracle can be introduced to generate random values for the verifier to use for random queries. In theory, this method is more effective, but from the perspective of the verifier process, it is relatively inefficient.
Interactive Oracle Proof (IOP): The prover and the verifier interact with each other and have access to random examples. IOP improves the efficiency of interactive proofs by using partial data copies to reduce the complexity of communication and queries. This is also the proof system commonly used in ZKP Systems.
The aforementioned Information-Theoretic Proof System all makes ideal assumptions that are difficult to implement in real life. For example, it may assume that the verifier is trustworthy and access to the proof is restricted. However, the characteristics of Cryptograph make these assumptions feasible in specific environments, such as common mathematical problems:
The Integer Factorization Problem: For example, the security of RSA depends on the factorization of large numbers.
The Discrete Logarithm Problem: Diffie-Hellman Key Exchange relies on the calculation of discrete logarithms of large numbers.
The Elliptic Curve Discrete Logarithm Problem: Elliptic Curve Cryptography (ECC) relies on elliptic curves over finite fields and complex elliptic curve discrete logarithms.
The combination of Information-Theoretic Proof System and Cryptographic Compiler can produce ZKP System, so the characteristics of ZKP will change with different combinations:
Computational methods: There are two main modes of general computing: circuits and Turing machines. Although most mainstream programming languages try to describe the computational path of Turing machines, Turing machines are not the most efficient programming model for cryptographic computing, and all more efficient programming models usually greatly increase the complexity, thus complicating the encryption protocol. Therefore, people use circuits instead of Turing machines because circuits can express many direct statements very easily, but the trade-off is that users need to pre-process the computations being processed.
Computational cost: For different combinations, the cost of verifiers, provers, and communications will be different. For example, in a ZKP system that combines PCP + Collision-Resistant Hash Function (CRFS), the computational cost is as follows:
Quantum resistance: Some encryption algorithms can effectively resist brute force cracking by quantum computers, such as the Collision-Resistant Hash Function used by ZK-STARK. Under current development, quantum computers cannot directly crack it. However, there is still a risk of being cracked. For example, two scholars from Shandong University described how to crack SHA1 and MD5 in a paper published in 2009. Therefore, we still need to have a trust assumption.
Trusted configuration: Trusted configuration usually falls into two categories: Uniform Reference String (URS). The random numbers generated by URS are publicly visible, which means that the "randomness" is fair. Structured Reference String (SRS) is divided into two types, Universal Setup and Specific Setup. The former allows multiple subjects to participate in the generation of random numbers, usually in the form of MPC, while the latter allows participation in the generation of random numbers for a specific scenario.
If in a peer-to-peer scenario, a malicious actor knows the random value, then he can forge the output of the system and generate the correct ZKP.
As can be seen from the above, different combinations can lead to various types of ZKP systems. In general, they can be divided into ZK-SNARK, ZK-STARK and Bulletproof. The following core differences can help us better understand:
Trusted configuration: ZK-SNARKs usually use a trusted configuration, while ZK-STARKs and Bulletproofs do not require such a configuration.
Computing costs:
Proof time: Bulletproof > ZK-SNARKs > ZK-STARKs
Verification time: Bulletproof > ZK-STARKs > ZK-SNARKs
Communication complexity/proof size: ZK-STARKs > Bulletproof > ZK-SNARKs, but when the amount of data increases, the storage space required by ZK-STARKs & Bulletproof will be smaller than that of ZK-SNARKs.
Quantum resistance: ZK-STARKS are usually quantum-resistant, while ZK-SNARKs and Bulletproofs do not need such properties.
Image source: https://github.com/matter-labs/awesome-zero-knowledge-proofs?ref=blog.pantherprotocol.io
Image source: https://medium.com/@emilpepil/history-of-the-formation-of-zkp-151dd7001ffa Zero-Knowledge Proof Market Potential and Scale
Currently, the ZKP track is developing in two main directions: privacy and capacity expansion.
Expansion plan
It mainly refers to the use of ZKP as a solution to improve scalability, including Layer2 availability proof, cross-chain, etc. Currently common solutions include Starknet, ZKsync, Polyhedra, etc. It can usually be divided into two construction systems: Layer1/Layer2 and protocol. In the Layer1/Layer2 construction system, Rollup transactions and applications are executed on ZKEVM and have zero-knowledge proof features. An ideal ZKEVM should be equivalent to EVM, which means it is fully compatible with EVM's existing protocols and development experience. According to Vitalik's blog, the current ZKEVM can be divided into 5 categories:
Type 1: Completely equivalent to Ethereum, its state or transaction tree, hash code, or any other logic in its consensus will not change. Type-1 will be fully compatible with all Ethereum native applications, but will take longer to prove because no pre-compilation is done to speed up proof generation. Currently available projects include Scroll and Taiko.
Type2: Similar in appearance to Ethereum, but slightly modified internally, such as the state tree and block structure, to facilitate development and speed up proof generation. Currently available projects include Polygon Hermez.
Type 2.5: Limiting some ZK functions by increasing the Gas Fee to reduce potential verification time is essentially a temporary solution and does not address the root cause.
Type 3: Some features that are particularly difficult to implement in the ZK-EVM implementation may be removed. In addition, there are sometimes subtle differences in how contract code, memory, or stack are handled, so compatibility with Ethereum will be weaker. This category is more like a product development transition period than a product positioning.
Type 4: Smart contract source code written in a high-level language (such as Solidity) is compiled into a language that is explicitly designed to be friendly to the ZKP system, such as Cairo. Although the proof time can be accelerated, its compatibility is the worst. For example, some DApps developed using Ethereum bytecode may not be able to be migrated. Currently, the projects that can be used for reference are ZKsync and Starknet.
Image source: https://vitalik.eth.limo/general/2022/08/04/zkevm.html
When Ethereum was first designed, it was not envisioned that it would be expanded in the form of ZKEVM in the future, so the development difficulty is undoubtedly very high. Therefore, the choice of ZKsync and Starknet is also to launch a general-purpose ZKEVM to the market as soon as possible. In fact, they should be called ZKVM because their compatibility with Ethereum (for developers) is relatively low, but in return they have higher architectural flexibility and lower ZKP generation costs.
This type of ZKVM can break away from the limitations of the EVM system and become a Layer 1. Developers can write code for a specific virtual machine architecture in a high-level language and then compile it into a ZK circuit, or write code in a domain-specific language (DSL) such as Circom to directly generate a ZK circuit.
Image source: https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d
If we consider the market size of ZK Layer2 alone, according to L2Beat data, the current TVL of ZK Layer2 (including ZK Rollup and Validium) is about $5.015 B, accounting for 10% and 7% of the Layer2 TVL and Ethereum TVL in the total Layer2 respectively. If the market share of OP Rollup is used as a benchmark, ZK Rollup currently has about 10 times the TVL growth space, and it is expected to launch an additional 10-12 new ZK Layer2.
Among them, Linea, Starknet and ZKsync are the top three, accounting for $1.22 B, $1.06 B, and $855 M respectively, and the Three-Firm Concentration Rate is 62%, which means that the current Layer2 competition is monopolized by a few projects. Looking further at the growth of Layer2 TVL, the TVL growth rate mainly appeared on February 20, 2024, due to the inflow and appreciation of Starknet's native tokens. Currently, 75% of Starknet's native tokens are still retained on the chain.
Among them, Linea belongs to Type2 ZKEVM, Starknet and ZKsync are Type4 ZKEVM. And the top three are all ZK Rollup instead of Validium. The former uses Ethereum as DA, and the latter DA will be placed off-chain and managed by DAC. In Validium, Immutable X's TVL reached nearly $200 M, ranking first. It is also worth noting that in OP Rollup, most of the top 10 Layer2s with the highest TVL use OP stack, which means that a certain Stack has a high market share. But in ZK Rollup, the top 10 Layer2s with the highest TVL basically choose to develop their own ZK Stack.
Image source: https://l2beat.com/scaling/summary
Image source: https://l2beat.com/scaling/summary
In addition to the above-mentioned Layer1/Layer2, ZKP also has the protocol layer in the main scenario of capacity expansion, such as cross-chain. The introduction of ZKP in cross-chain mainly serves light node verification and Maker&Sender's cross-chain infrastructure, such as Polyhedra, Orbiter Finance, etc. In the original verification process of the light node, the contract deployed on the target chain needs to continuously obtain the block header of the source chain for subsequent cross-chain information verification, which will inevitably consume Gas. However, if the verification process is placed off-chain and only one Commitment is stored on the chain, then the storage cost will be greatly reduced, and the higher the update frequency of the source chain, the higher the Gas cost. The construction method of Commitment can be carried out with ZKP, which can effectively compress one or more transactions. In the Maker&Sender mode, ZKP is combined with fraud proof to further reduce ZKP generation. In terms of market size, taking Orbiter Finance as an example, although there are currently about $628M in transaction volume and $1.48M in TVL per month, the demand for ZKP will also increase under high turnover.
Privacy Policy
It mainly refers to protocols/networks that use ZKP as their privacy and security solution, including Zcash, Aztec, and Tornado Cash.
Compared to the development direction focused on expansion, there is less development work on privacy-focused solutions. Existing privacy applications are mainly focused on payment privacy and have low programmability. Combining privacy and programmability is a challenging task. There are two ways to build privacy-focused solutions:
Protocols: These protocols mainly use ZKP to create private pools of funds. Users use these private pools as a privacy protection scheme, such as Tornado Cash. For these applications, proofs are performed by users and verification is performed on-chain. Since Layer1 is not designed for cryptographic computations, the verification cost is often high for mainstream users, limiting the adoption of these applications. The intuitive solution is to move private transaction applications to Rollup to reduce Gas Fee. In this case, the private transaction proof needs to be included in the Rollup proof, that is, a recursive proof, which is not currently possible with regular ZK Rollup on Ethereum.
Layer1/Layer2: These Layer1/Layer2 mainly implement privacy protection through ZKP, such as Manta Network and Aztec. Most privacy-focused chains cannot support general computing yet and can only focus on specific scenario use cases. For example, Penumbra and Renegade focus on private transactions. The account models adopted by these Layer1/Layer2 can be divided into: Account-Based and UTXO-Based. Both have their own defects: the former may leak some privacy due to the transaction route and requires serial processing, while the latter requires decryption of each child node to correctly query when verifying and updating the transaction balance.
According to Defillama, the current TVL of the privacy track is about $709 M, and the Three-Firm Concentration Rate accounts for nearly 99%, namely Tornado Cash ($595 M), Railgun ($96.97 M), and Aztec ($9.45 M). Tornado Cash and Railgun are protocols, and Aztec belongs to Layer2.
Image source: https://defillama.com/protocols/Privacy
Among them, Tornado Cash is facing compliance suppression, which also means that many "compliance privacy" requirements will gradually migrate to other protocols and networks, and the Concentration Rate will only gradually decrease. In addition, many third-party data platforms and centralized node providers in the market currently have poor censorship resistance, and some large users and institutions hope to transfer large amounts of funds in a safer and more secretive way. As of June 3, about 37% of the blocks were reviewed by OFAC, which is inevitable for public Mempool.
Image source: https://www.mevwatch.info
This also further extends the compliance requirements, so KYC and other service providers are also very important. However, users often still want to maintain personal privacy to the greatest extent. The potential scenarios of ZKP + KYC will increase with the improvement of privacy transactions. The main service providers in the market are zCloak, zkMe, etc. In the traditional KYC process, when we need to entrust multiple KYC service providers, we need to conduct repeated verification, but in the case of ZKP + KYC, other service providers can try to verify the ZKP to ensure the validity of the identity. In addition, during the KYC process, the service provider needs to record some necessary information, such as sensitive information such as ID cards. If it is carried out by multiple service providers, the risk of information leakage will also increase linearly.
What problems does ZKP face now?
As we mentioned before, ZKP generation requires significant computing resources. Taking the common ZK-Rollup as an example, the ZKP generation time of ZKsync is about 1 hour. If further dismantled, the ZKP generation process of ZK-SNAKS mainly involves Multi-Scalar Multiplication (MSM) and Number Theoretic Transform (NTT). These two processes can account for 80% to 95% of the proof generation time. Although ZK-STARKs uses different algorithms, it also faces the problem of low efficiency.
In addition, in recent years, ZKP systems have provided a wide range of options with different trade-offs, which are constantly expanding. For example, the trade-off for faster proof speed is larger proof size or memory usage. There are many types of proof systems with various customized functions, and they are constantly expanding. But Ethereum is not able to support the evolving proof system. For example, only the BN-254 elliptic curve can be supported at a low cost. But migrating to a more secure curve (such as BLS12-381) is a complicated task, not to mention being compatible with the new ZKP system.
Furthermore, in terms of Layer1 verification of ZKP, the cost of verifying STARK is about 5,000,000 Gas, while the proof based on Plonk is less than 290,000 Gas fee. If the proof system is verified directly in Ethereum, there are currently several limitations. For example, proof systems based on inner product arguments, such as Mina's Kimchi (efficient recursion through Pickles) or Brakedown-based Binius (with square root size proofs), involve large amounts of computation or proof size, so the verification cost will also be very expensive. For this reason, we may need to convert to Ethereum-Friendly ZKP.
How modular ZK services speed up the ZKP process
Therefore, how to improve efficiency has become the next direction to be explored in the development of ZKP. In addition to changes in algorithms/circuits, the current main solutions can be divided into two categories:
Hardware Acceleration: Improve the ZKP generation process by improving the hardware. GPUs usually have limited improvements on ZKP verification time. Another option is to use dedicated hardware, such as FPGA or ASIC, and then extend the Hardware Abstraction Layer. For reference, please refer to AI cloud services. Since the focus of this article is not to discuss hardware acceleration, we will not discuss it in detail.
Modular ZK-As-A-Service (MZaaS): It reduces the complexity of ZKP generation and improves efficiency by providing a series of ZKP-related services. These services can be further divided into the following subcategories:
Proof Marketplace: It is mainly based on the concept of Requester-Prover Separation. It splits the Prover in different scenarios to utilize idle Prover resources to provide an open Proof market. Projects that can be used for reference include Mina, =nil, and ZKPool.
Verification Layer: Based on the concept of Aggregation, the prover collects multiple proofs and generates a new proof to prove the validity of the initial proof, and reduces the cost of the verification process by providing a verification layer. Reference projects include Aligned Layer, Horizen, Cloaking Layer (zCloak Network), and Nebra.
Proof Marketplace
First of all, we can find from the above application scenarios that not all transactions are generated in ZKP application scenarios, so we can classify them into two generation methods (taking cross-chain as an example):
Full ZK: ZKP is generated for each transaction. For example, for each transaction of ZK Bridge, Maker will generate ZKP for verification.
Half ZK: ZKP is generated only when certain conditions are met. For example, Orbiter Finance only needs to generate ZKP when there is erroneous or unreliable transaction information.
Therefore, in the Half ZK scenario, not all Provers are fully utilized. When we split the role of Prover into Requester and Prover, and create a Prover sharing platform/Marketplace, we can improve the utilization of Prover and potentially reduce the time required to generate ZKP in the Full ZK scenario. But the question is, how to select a Prover?
How to choose the specific design of Prover can actually be considered in multiple dimensions: Performance, Cost, and Decentralization. In essence, it is similar to the impossible triangle of the consensus mechanism. For example, multi-node verification is selected to ensure decentralization, but repeated verification will undoubtedly only increase the verification time (performance reduction). Based on the various ZKP economic models explored by Taiko, they summarized the following figure. The author will not go into too much detail here.
Image source: https://www.theblockbeats.info/news/45260 Verification Layer
First of all, we need to clarify the difference between Aggregation and Verification Layer: the former is just to compress ZKP in some way, such as Recursion, Folding; the latter adds a preliminary verification (Soft Finality) process on this basis. The Soft Finality process may rely on external contracts/networks, which requires a certain degree of trust assumption.
In the actual Aggregation process, different projects adopt slightly different architectures, but generally there are four steps (taking ZKTree used by Polymer as an example):
ZKP Composition: Combine arbitrary circuits into a new ZKP, possibly with the help of Recursion and Folding.
ZKP Uniformation: Unify the above process into a new ZKP.
ZKP Recursion: Recurse the newly generated batch of child nodes (unified ZKP) again, and use this batch of ZKP as Proof of Verification to achieve Soft Validity/Finality.
ZKP Transformation: If a specific VM needs to be served, they may have their own degree of adaptability to different ZKP systems, and can be further mapped into ZKPs of different systems to reduce verification costs.
Verification Layer can provide instant verification through Soft Finality and integrate with various systems (not limited to Ethereum). When the demand for security is relatively low, Soft Finality can be used to pursue higher efficiency. And through the Verification Layer, parallel computing can also become a possibility, further getting rid of Ethereum's technical debt. More importantly, it can reduce the cost of verification. According to Nebra's actual test, each proof submitted on the Ethereum chain can save up to 184k gas (about 75%), and each proof submitted off-chain can save up to 207k gas (about 85%). In addition, Aligned Layer also estimates that the verification cost of Groth16 and STARKs will save 29 times and 80 times more than the original verification on Ethereum, and it uses home-grade hardware.
How does Cloaking Layer implement Verification Layer?
Introduction
Cloaking Layer is a new product of zCloak Network, which focuses on providing verification layer services for ZKP. The core idea is to use the ultra-high efficiency and ultra-low cost of Internet Computer (ICP) to directly verify each ZKP using the Canister contract based on WebAssembly (WASM). Then, based on the same trust assumption, the threshold signature technology is used to send the verification results to any target public chain, realizing ZKP verification services covering the entire chain. (Extended reading: Cloaking Layer — a ZK Verification Infra for All Chains)
Main architecture
Image source: https://zcloaknetwork.medium.com/cloaking-layer-a-zk-verification-infra-for-all-chains-1162d3fcc37b
First of all, the core of the Cloaking Layer is ICP Canister, which can run ZKP's verifier directly in the form of WASM to directly verify "SNARK" and "STARK" proofs. ICP Canister can be understood as a smart contract on the EVM chain, which has the characteristics of being tamper-proof after deployment and requiring network-wide consensus for running results. Unlike EVM contracts that need to be written in Solidity, Canister contracts can well support WASM compilation objects. Since most of the current ZKVM systems such as Polygon Miden, RISC0, SP1, Jolt, etc. are written in the Rust programming language and can be easily compiled into WASM, Canister is very suitable for the role of ZKP's verifier.
The ICP public chain consists of multiple subnets, each of which contains a large number of nodes (Replica). After a Canister contract is deployed, a copy will be saved in each subnet node, and it will run independently in each node. Then the subnet compares the running results of all nodes and reaches a consensus to ensure that the running results of Canister are correct. When the Cloaking Layer receives the ZKP, the validator Canister deployed in each node will independently calculate and verify the ZKP. Once the proof result reaches a consensus in the subnet, the subnet will use the threshold ECDSA signature technology to digitally sign the verification result. The signed verification result can be sent to any public chain that supports ECDSA signature verification, such as Bitcoin, Ethereum, and Solana for use.
competition analysis
Key points:
The current market valuations vary widely.
Currently, most solutions are already in Testnet
It is estimated that the verification cost can be reduced by 10 times on average, with the Cloaking Layer having the highest performance.
Most trust assumptions are based on Layer 1
Most projects only conduct “verification and expansion” on Ethereum
evaluate
The biggest difference between Cloaking Layer and other Verification Layer solutions is its trust assumption. Currently, the requirements for applying to become a replica (ICP node) are extremely high. It requires approval from the ICP Foundation and higher node hardware configuration requirements (higher than Layer1 with heavier node configurations such as Solana and Sui). Therefore, there are still certain trust restrictions in the efficiency of threshold ECDSA signatures, and it essentially depends on the network having 2/3 honest nodes. In addition, due to the performance advantages of ICP nodes, Cloaking Layer does not need to use complicated ZKP recursion schemes to achieve ZKP compression, which is also the most direct and convenient way.
Extended discussion
How can we build censorship resistance into the Verification Layer?
The simplest and most effective way is to use the anti-censorship mechanism of Layer1. As long as the Verifier/Unified Prover in the Verification Layer cannot intercept the submitted transaction, the anti-censorship capability of Layer1 can be inherited. In practice, the user/protocol can directly submit ZKP to the smart contract of the Verification Layer in Layer1 (Canister on ICP), and store it in a waiting queue to be packaged by the Verifier/Unified Prover. According to Arbitrum's method, anyone can include the transaction in the transaction history of Layer2 after a period of time when the Sequencer has not responded.
What is the ZKP-EV market?
Through the above thinking, we can provide additional handling fees to give priority to packaging. If the scale is large, it may also develop a ZKP-EV (Extractable Value) market similar to the MEV market.
How to balance Soft Finality and Hard Finality?
All Verification Layers provide Soft Finality, and since the performance of these Verification Layers is higher than that of Ethereum, they are also better than Ethereum in terms of verification speed. However, if the Hard Finality of Layer1 is required, then this time will be longer than the time without the Verification Layer, which is also a disadvantage of maintaining Hard Finality + Aggregated ZKP. Therefore, for protocols that require more cautious Hard Finality, the current Verification Layer may not be a good enough solution. Slashing modules, reputation systems, and insurance mechanisms should be introduced to strike a balance between efficiency and security. Please refer to our previous articles (Extended Reading: TeleportDAO: The Game of Data Verification Security and Efficiency, the Latest Practices in Light Node Design).
What is the revenue source of ZK-As-A-Service?
The current business model of all ZaaS is still relatively vague. In addition to being able to extract part of the commission in the ZKP process, it is to issue coins. However, the cash flow of the business is essentially decoupled from the value of the token, unless it is bound by a strong buyback commitment (such as MakerDAO's MKR). Therefore, although the current market size is expected to be large, the actual performance of the revenue has yet to be verified by the market.
Reference
https://medium.com/casperblockchain/verified-merkle-tree-updates-without-zk-90d8f5100ccd
https://www.zkcamp.xyz/blog/information-theory
https://x.com/iam_preethi/status/1656411033366396929 https://crypto.stackexchange.com/questions/92018/which-is-the-relation-between-zero-knowledge-proofs-of-knowledge-and-circuits https://web.archive.org/web/20090521024709/http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf
https://medium.com/@emilpepil/history-of-the-formation-of-zkp-151dd7001ffa
https://www.paradigm.xyz/2022/04/zk-hardware
https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d
https://vitalik.eth.limo/general/2022/08/04/zkevm.html
https://mirror.xyz/msfew.eth/Yl64OK3lLG48eJpVB3GxqFEhmWOm6yMlAo9sc1VrQP4?ref=blog.pantherprotocol.io
https://x.com/jaosef/status/1730313497513476326
https://l2beat.com/scaling/summary
https://defillama.com/protocols/Privacy
https://docs.zksync.io/zk-stack/concepts/finality.html#finality-on-zksync-era
https://figmentcapital.medium.com/decentralized-proving-proof-markets-and-zk-infrastructure-f4cce2c58596
https://dune.com/nebra/zkp-verify-spending
https://medium.com/@eternal1997L/The reason for the decline of icp - unique technology and a thin ecosystem - 51dd7a9362fb
