What is a ZK proof and what is the use of a ZK proof
PreviousPoA consensus algorithm: how does it compare to PoW, PoS?NextWhat is a stablecoin and what does it do?
Last updated
Last updated
Zero-knowledge (ZK) proofs, like Three Arrows’ Su Zhu and Kyle Davies, were born in the 1980s but only recently became a hot topic.
You've probably heard a lot about them, but what exactly are ZK proofs?
You may know the basics, but are wondering what are the most promising projects using ZK to prove?
Let us now answer these simple and complex questions through the overview, application projects and underlying technology of ZK proofs.
ZK proofs use cryptography to allow someone (the prover) to prove to someone else (the verifier) that a fact is 100% true, but without revealing any additional information beyond a specific statement of truth. You can keep it a secret and make people trust you.
Another more popular definition is: ZK proofs essentially allow someone to prove that they know or possess something without revealing any information about what they know or possess.
Maybe a few examples will help to understand better:
ZK proofs can be used to prove the validity of an Ethereum transaction that sends tokens from account A to account B without revealing the token balance or the amount sent from either account.
The ZK proof first appeared in a 1985 MIT research paper. Like many techniques, ZK proofs first led to a large number of theoretical arguments, and then gradually found practical applications after further development and refinement.
The earliest ZK proofs were interactive. To prove something, you have to play a quiz game with the validator. Like a lie detector test —— the verifier keeps asking a series of questions about the "knowledge" the prover has. By constantly asking questions, the verifier believes that the prover does know this "knowledge". But such an approach does not convince people that both the prover and the verifier are sincere, because the two can collude in advance so that the prover can pass the verification without knowing the answer.
It was later developed to be non-interactive. Non-interactive is that the prover can now generate a thing, a piece of data, to submit to the verifier as his ZK proof without multiple rounds of communication. This ZK proof is less like a game/ceremony/protocol and more like an unforgeable item that can be generated by the prover and submitted to the verifier, avoiding the possibility of collusion between the prover and the verifier.
There are currently two main uses for ZK proofs:
Other projects using ZK proofs to protect privacy are Iron Fish, World coin, and Tornado Cash, which was regulated two days ago.
Scalability: Allows intensive computation to be performed off-chain, making it cheaper, and then creating a concise proof that computation was performed honestly and can be published on-chain.
On-chain and off-chain take their roles, become specialized, and focus on what they do best. We can process a whole bunch of transactions quickly and efficiently using a centralized, high-performance, off-chain system, and then use a decentralized, immutable, trustless blockchain as the ultimate source of truth of who owns what.
ZK proofs are computationally very small relative to the validity proofs of all off-chain transactions and are very fast to verify. This is thanks to an almost magical property: once they have created a proof saying "yes, these billions of computations are 100% correct", the verifier can confirm that the proof is correct without having to do it again themselves Do billions of calculations.
There are a number of ZK rollup projects focused on scalability, and others looking to provide both privacy and scalability, including Aztec and Espresso Systems.
ZK proves to be a general technique. The past few blockchain bull markets have undoubtedly driven investment in ZK R&D, but the first practical application of ZK proofs came before Satoshi Nakamoto released the Bitcoin whitepaper. There are many exciting applications of ZK proofs in the off-chain world - such as identity management, minimum age verification, anonymous credentials, rating and risk assessment of financial assets, and digital voting.
For all the ZK proof hype for on-chain and off-chain applications, it would be a good thing to push the technology forward for new uses. But this expectation is cyclical. When ZK proved to be hot, there was a lot of attention, but when it came to realizing that the technology wasn't 100% perfect either, the mood inevitably turned cold.
It has already been mentioned how ZK-rollups work: instead of running slow and expensive computations on Ethereum, it does the work off-chain (i.e. on a Layer 2 (L2) blockchain): Create a proof that you did all your transactions honestly, then publish the proof on Ethereum.
What does this actually look like to the user?
Suppose L2 uses Ethereum in its L1 settlement layer. It will have one or several smart contracts on L1 Ethereum that do some important work:
Stores all relevant data about what is happening on the L2 chain (account balances, etc.). The contract may not see a real-time view of L2 blocks, as L2 transactions are not considered official until they are submitted to the aggregate on Ethereum;
Check proofs of escrow to make sure they are legitimate code. When the rollup is submitted to Ethereum, the validator smart contract ensures that the proof of the rollup is valid before it is officially released on L1.
Maybe some analogies will give you a better understanding: validators are like bodyguards, making sure that aggregates from L2 are valid before going into Ethereum. Or, a block produced on L2 is like making some rough statement that I have an independent scientific paper, which is then checked by validators and submitted to Ethereum like peer-reviewed and published in a respected journal.
This may not sound like an easy task, but understanding the basics of the ZK rollup architecture is a key foundation for understanding ZK rollup project interactions. A basic user flow might look like this:
(1) Send some ETH to the rollup project's smart contract on Ethereum to store/lock your funds.
(2) After a short delay, the L2 chain will receive the funds you have locked and will unlock the equivalent coins for you to use on L2. This is a very typical bridging experience.
(3) You can freely use your Token on L2. You can exchange, invest, or use to buy NFTs. A rollup is then sent periodically (usually in minutes) to Ethereum, indicating that all of your recent activity on L2 has been completed.
(4) Now you decide that you want to withdraw your funds back to Ethereum because you had fun at the L2 casino, but now you want to cash your chips (coins and tokens on L2) into real money (ETH and L1 tokens). To do this, you send the L2 Token to the burn address on the L2 chain and wait for the rollup that proves the action to be published on Ethereum. Once the release is complete, your funds locked in the Ethereum smart contract are unlocked and returned to your wallet.
This post won’t go into detail about ZK rollups vs Optimistic rollups as there are many articles comparing them, but here’s a one sentence summary: Optimistic rollups take an “innocent until proven guilty” approach to transactions posted to L1 (By default, all transactions are considered valid, but anyone who observes an error rollup can call it back and get a reward), while ZK rollups, as we've already seen, are considered invalid until they enter L1. letter, requiring all off-chain computations to verify themselves using proofs of validity before entering L1.
There are pros and cons to each approach, but a major benefit of ZK rollups is that users can withdraw funds to L1 faster. After withdrawing from Optimistic rollups, one has to wait for the challenge period to expire (approximately 7 days) to unlock the funds as it needs to wait to be verified.
But V God is optimistic about the ZK route for a long time:
Overall, my own view is that in the short term Optimistic rollups may win for general-purpose EVM computations, while ZK rollups may win for simple payments, exchanges, and other application-specific uses, but in the As ZK-SNARK technology improves, mid- to long-term ZK rollups will prevail in all uses.
— Vitalik (January 2021)
Another rollup-like scaling solution is validiums.
Volitions are hybrid scaling solutions that allow users to choose between "zk rollup mode" and "validium mode".
When ZK rollups are published on L1, it includes both proving that all activity on L2 is legitimate, as well as all changes to account balances on L2 since the last rollup. This is critical because when you want to withdraw funds from L2, you need the previous situation to say "this is what I did on L2, which means I should be able to withdraw a specific amount of coins and tokens."
There is also something called validium, which is another rollup-like scaling solution.
Validiums work almost the same way as traditional ZK rollups, and they have the added benefit of being cheaper and more scalable.
The problem is, it's not safe enough.
Validiums published on L1 do not include all data on having funds on L2 - the data on withdrawal of funds to Ethereum is also unknown. Instead, data is stored off-chain. It's not a problem if you trust the person/network/company that stores that data, but it's best to make sure they're absolutely reliable. Because if you store $1 million on L2, and the project party that stores that data gets hacked and loses data, or gets frozen by the government, or punishes you for saying stupid things on Twitter, then you Might lose your money...
Or, to be more precise, it's locked.
There's an opportunity here to spread awareness of the potential risks to validity with a neat "not your keys, not your coins" type mantra, but the best I can think of is "if data is not available, you coin is attackable." Therefore, it is best for projects to track their aggregated data well.
And some projects are using volitions hybrid scaling solutions that allow users to choose between "zk rollup mode" and "validium mode". It's also advertised as a compromise between the two options - projects tout them as a way to "have your cake and eat it" or "the best in the world". So it is important to understand the difference between rollups and validiums. When L2 submits proofs to the L1 chain, they allow users to choose whether the data needed for withdrawals is also published on L1, or whether it is stored elsewhere.
Overall, Validiums are cheaper than ZK-rollups, but put your funds at risk of freezing on L2. Those that use volitions will let you choose between Validiums or ZK-rollups.
There are too many projects using ZK technology to list them all, but here are some of the main categories and projects.
(1) zkEVM
Over the past month, several different projects have made headlines with the launch of so-called zkEVMs. The competition between these protocols was dubbed the "zkEVM war" and the "ZK Rollup Race", and it soon became apparent that each protocol claimed to have beaten the others:
The three main players are Scroll, Matter Labs (creators of zkSync) and Polygon.
zkEVMs are important because they allow ZK rollups to support more applications than currently available. The first wave of ZK rollups allowed to perform basic operations — like sending ETH and transferring tokens — on the super-scalable and cheap L2. But with zkEVM, developers can write arbitrarily complex smart contract code and deploy it on ZK-powered L2. Best of all, they can do this using the same Solidity code they use on Ethereum itself. This means that ZK-rollup L2s can now develop into crazy, complex, composable Wild West chains, full of opportunity but also chaos.
(2) Polygon
Polygon is building a truly staggering number of scaling solutions. Honestly, it's hard to keep track of them. They are described as "Swiss Army Knife scaling", presumably based on this model:
Here is their current product line, four of which mention ZK proofs (including the zkEVM mentioned above):
(3) StarkWare
StarkWare is a company building ZK scaling technology, founded by true ZK magnate Eli Ben-Sasson. Eli co-invented STARKs, an advanced proof of ZK, and is the founding scientist of Zcash. They have two main products:
StarkEx: Allows each application to build its own personal, permissioned ZK system. For example, dYdX (a decentralized smart contract trading platform running on Layer 2) and Immutable (the first NFT trading platform for Layer 2) have used StarkEx for perpetual trading respectively (perpetual trading is similar to stocks, as long as this Only shares are not delisted, you can always hold) and NFTs have established their own application-specific ZK projects. But these applications are siloed - there is no composability between projects, so one StarkEx project cannot "talk" directly to another.
StarkNet: A newer product, similar to a general-purpose blockchain. Any developer can create smart contracts and deploy them on StarkNet - it is permissionless, like StarkEx. Projects are fully composable, and all transactions are aggregated and settled on Ethereum. I suspect you'll be hearing a lot about StarkNet soon, as its token is scheduled to launch in September
Zcash, which has been mentioned a few times before, is the main chain in the privacy coin space. Given its similarities to Bitcoin, whether we will see BTC itself adopt ZK proofs for privacy is yet to be seen? What about Ethereum - could it take a page from the L2 playbook to use ZK proofs for scalability? In short: BTC can't, ETH can.
The early cypherpunks who created Bitcoin were very privacy-conscious. Zooko, the co-founder of Zcash, believes that BTC has lost its way when it comes to privacy, given that most advanced users now accept on-chain forensics allowing transactions to be traced back to real-life identities. The Bitcoin community is known to be reluctant to embrace new features, so there may not be major privacy upgrades in the short term, and Zooko predicts that BTC will eventually come to an end! ! !
Interestingly, after doing some research on the sacred text known as the BitcoinTalk forum, I found that only Satoshi Nakamoto himself mentioned ZK proofs in one of the discussions.
Unfortunately, at the time of the discussion, ZK proofs were not advanced enough to support Zcash (the first blockchain system to use zero-knowledge proofs) level features, which is why Satoshi Nakamoto wrote them off:
This is a very interesting topic. A better, easier and more convenient implementation of Bitcoin will be possible if a solution is found. ...it's hard to think of how to apply zero-knowledge proofs in this case. (August 11, 2010)
When it comes to Bitcoin and ZK proofs together, the timing is not right. At that time, when Bitcoin was young and easy to transform, cryptography was too primitive to be implemented, and now to deal with complex upgrades, Bitcoin has too much inertia to hinder. Maybe this is life. C’est la vie.
However, Ethereum is more advanced when it comes to implementing new technologies. In a recent article on zkEVMs, Buterin mentioned that ZK proofs could make it "easier to verify the Ethereum chain itself," and shouted that Ethereum's Privacy and Scaling Exploration team is working on it. After all, there is no reason for L2s to have a monopoly on ZK technology. But don't get too confident - Ethereum is very slow to grow relative to smaller, more flexible projects.
SNARKs are a type of ZK proofs that first appeared in 2011 and have helped enable many real-world applications. Most ZK projects currently utilize SNARKs.
SNARK stands for "Zero-Knowledge Succinct Non-Interactive Argument of Knowledge", and it's a good technique, but it's more useful to know what they do:
"Succinct" means that the proofs are much smaller than the sum of all the computations they represent. For example, it is possible to take a whole bunch of transactions that need to be recorded individually on the Ethereum blockchain and create a SNARK that only takes a few hundred bytes to prove their validity.
"Non-interactive" means that you can use one computer to generate a proof that acts as an unforgeable proof of something (such as your account balance on the L2 blockchain) that you can submit to another A computer/smart contract will verify it.
ZK: Like all ZK proofs let you prove something while sharing as little information as possible.
Speed: Since these proofs are so small, they can be verified very quickly.
Security: A major disadvantage of SNARKs is that the computer doing the attestation and the computer doing the verification must agree on a set of parameters called the Common Reference String (CRS). To make a CRS, you need to use a source of randomness (entropy), and these random numbers are very powerful. If bad actors find them, they can create arbitrary proofs and trick validators into thinking it's valid. This is why any legitimate project using SNARKs will make sure to destroy these random numbers as soon as they are used.
STARK is the little brother of SNARK, where the letter "N" becomes "T", where "T" is "Transparent", which stands for "transparent". (Zero-Knowledge Succinct Transparent-Interactive Argument ofKnowledge, Chinese meaning: simplified fully transparent zero-knowledge proof)
They each have different advantages and disadvantages. Here are the main differences between the two ZK proofs:
Proof size: STARKs are larger than SNARKs, which also means they are more expensive to verify on Ethereum, since larger proofs = more computations = higher gas fees.
Scalability: STARKs are generally considered more efficient than SNARKs, depending on the implementation. The complexity scale of proving and verifying STARKs grows quasi-linearly relative to the computational complexity of the proof, while the complexity of SNARKs grows linearly. This means that STARKs have a greater advantage over SNARKs when proving larger computations.
Ecosystem and projects: There are far more projects using SNARKs than STARKs because SNARKs have been around longer.
Recursion: SNARKs support recursion - you can create a parent SNARK to attest to multiple child SNARKs - this is the main feature used by many scaling solutions. STARK does not support recursion.
Quantum secure: SNARKs use elliptic curve cryptography, which is not quantum secure. Advances in quantum computing could make SNARK-based systems vulnerable. STARKs are not vulnerable because their encryption scheme relies on hash functions.
Trusted Setup: As mentioned earlier, SNARKs require trusted setup during CRS creation. STARK avoids this inconvenience by leveraging publicly verifiable randomness to generate parameters shared by provers and verifiers.
It is important to note that these features are constantly evolving. New SNARK-based schemes have recently emerged to address the weaknesses of traditional SNARKs.
For anyone concerned with the nitty gritty aspects of the zkEVM product (especially developers), it's worth emphasizing that not all zkEVMs are created equal.
These projects have to make a trade-off between compatibility with Ethereum and performance. The so-called "EVM compatible" means that zkEVM is able to verify programs running in the exact same environment as normal Ethereum.
For example, Scroll is not only compatible with the EVM of high-level abstraction layers like the Solidity programming language, it is also compatible with the EVM at the bytecode level. This is important because it makes the development experience on Scroll almost indistinguishable from developing on Ethereum itself, with the exception of using sophisticated debugger tools that examine individual opcodes. It also allows for the reuse of familiar and battle-tested Ethereum clients such as geth, which means zkEVM can draft upgrades to Ethereum itself with minimal additional work from the project.
These zkEVMs use smart contract code written in Solidity, an approach that allows the code to run more efficiently, but it throws away a lot of Ethereum's existing infrastructure. For example, the geth client is known to have certain limitations, which is why teams like zkSync have replaced it with other software written in Rust.
Compare this to the "EVM-compatible" zkEVM, which is not as strict in its coordination with the EVM. A member of the zkSync team described the two types of zkEVMs this way: If you run Photoshop software on a Windows computer and now want to run it on a Mac, you can either recompile the Photoshop code to optimize it for Mac, or Run a Windows emulator on your Mac and have the emulator run the Windows version of Photoshop. Obviously, the former will be more efficient.
Granted, this view is biased and ignores some of the benefits of higher compatibility, but it's a good analogy. At this point, it's too early to say which approach will ultimately prove a better strategy, but we should be glad that a variety of experiments are now running in parallel.
With all the buzz around ZK proofs and other emerging crypto technologies, it leads me to believe that we may be on the cusp of "crypto, not blockchain", similar to the "blockchain, not bitcoin" of the past few years The story is the same. Even some Bitcoin and Web3/blockchain skeptics point out that the continued development of innovative ZK proof technology is (they believe) a salvation for otherwise worthless alternative chains.
ZK proofs can be used to prove the fact that I own an without revealing which one I own, when I purchased it, or how much I spent.
Privacy: Minimize the amount of data disclosed when conducting activities on the . Zcash is a good example:
Like, Zcash transaction data needs to be published to a public blockchain; but unlike Bitcoin, Zcash offers the option of confidential transactions and financial privacy, utilizing zero-knowledge proofs that allow the sender, receiver, or transaction to be undisclosed Validate the transaction in the case of the amount.
First, you find a ZK rollup project that interests you. Each project has its own independent application and project ecosystem, so find a or NFT protocol that you like.
(4) & ETH
