zCloak Network Technical Background
zCloak Network provides Zero-Knowledge Proof as a Service . It enables a new computation paradigm called the Cloaking Space, which provides a private and scalable computation environment for Web3.
Background: Blockchain State
The blockchain, in essence, is a replicated state machine. It begins with a genesis state; it changes its state based on user input and a set of rules; then it arrives at a new state. The rule that governs how state changes is usually called a State Transition Function (STF). We can write this process as the following:
STF (current state, input data) -> new state
Note that the STF can be implemented either as on-chain logic (e.g. for token transfer) or as user defined logic (smart contract running on a virtual machine).
To make a change of state, one submits some input data as a transaction to the blockchain network. This transaction will be verified by a group of miners (PoW) or validators (PoS) to determine its validity. They do so by re-executing the STF using the user input data and comparing the results with each other. If the majority of them reach an agreement — i.e. consensus — the chain state will be altered and the transaction will be permanently stored in the blockchain. As such, any newcomers can independently generate the current state of the blockchain by re-executing all the transactions.
The Problem with Re-Execution
The re-execution method has been widely used by almost all the major public blockchain projects. It seems like the most straightforward way to re-create the blockchain world state and to verify the validity of a user-submitted transaction. However, this method suffers several severe disadvantages.
1) Privacy. Users have to submit their input data to the public network for nodes to verify the validity of their transaction. As a result, both the input data and the STF are exposed to the public. This is a huge problem if we were to use blockchain for privacy-sensitive applications such as identity, health-care and finance, etc. There has to be some way to use these private data without sending them to a blockchain node.
2) Scalability. The throughput of a blockchain network is usually measured by the number of transactions per second (TPS). The average TPS of Bitcoin is 5 and Ethereum 15 — far less than required in mainstream commercial applications. This is in part due to the computation overhead caused by the re-execution of each transaction in each node. If the time it takes to verify each transaction becomes shorter, the overall processing capability of the network will improve tremendously.
3) Computation restriction. In recent years, DeFi applications have been booming in Ethereum, for a good reason — the Ethereum smart contract is mostly suitable for processing simple logic/computation due to gas limit. If one tries to perform complex scientific computation in a smart contract, the gas fee will explode. Not to mention to re-execute this computation on each and every node. This definitely limits the functionality of a smart contract in a blockchain. For many real-world use cases and more complicated computations, one needs to find a way to circumvent this limitation.
4) State Explosion. As re-execution is the only way to restore the chain state, the transaction history of a blockchain has to be stored in full across all the nodes. For a slow chain like Ethereum, it already takes hundreds of GB storage for a miner node. For a fast one like Solana, it takes several PB storage for one-year’s transaction history. Gradually, small node runners will be forced to quit the network as they simply cannot afford the cost of storage. As such, big players will take control of the network and decentralization will be hurt as a result. It is thus vital to enable people to join in the network without excessive cost of hardware.
Our Solution: Verification Over Re-Execution
The aforementioned problems all result from the re-execution model used in public blockchains. If only there is a way to verify the validity (integrity) of a computation without re-execution!
Enter Zero-Knowledge Proof (ZKP).
ZKP is a cryptographic technology with two interesting properties — zero knowledge and succinctness. On one hand, you can use it to prove that you know a secret without revealing any knowledge about that secret. On the other hand, you can verify a large and complex computation is done correctly — a.k.a. computational integrity — with a tiny fraction of the efforts needed to actually perform the computation. If you look at the function we gave in the beginning of this article, this means we can prove the integrity of the STF execution without disclosing the input data or the computational process. We can also do long and complex computations off-chain and only leave the succinct proof on-chain for people to verify its integrity. As such, the problems of the re-execution model can be easily solved.
On Zero-Knowledge Proof
Today, there are generally two flavors of ZKP — zk-SNARK and zk-STARK. This article will not get into their technical details but a very good summary has been given by StarkWare. In general, it is known that zk-STARK provides the following advantages over zk-SNARK.
1) zk-STARK has much higher efficiency for proof generation and verification compared to zk-SNARK.
2) zk-STARK uses cryptographic primitives such as collision-resistant hash instead of discrete logarithm and elliptic curves as used in zk-SNARK. As such, STARK is known to be resistant to the upcoming quantum computers whereas SNARK is not.
3) zk-STARK is transparent in that it doesn’t need a trusted setup as required by most zk-SNARKs. This is good news for decentralization and enhanced security.
But zk-STARK has one drawback compared to zk-SNARK — the size of a STARK proof (20–200 KB depending on the complexity of computation) is usually larger than a SNARK proof (around 1KB). This makes it less convenient to store a STARK proof directly on a blockchain. But in zCloak Network, we are not storing the STARK proof on the blockchain anyway — more on this in an article on the zCloak Network architecture — so this limitation has no impact on our project. As such, we are left with all the good parts of zk-STARK.
By use of zk-STARK, we can generate a ZKP for the execution of a STF. Instead of doing re-execution, 3rd parties can simply perform a proof verification to check the integrity of our STF computation. This verification over re-execution method is highly efficient and scalable. It can also hide the input data of the STF, thus preserving user privacy.
Interestingly, this approach is not only effective for solving the privacy and scalability problems in public blockchains but also opens the gate to a whole new generation of computations the world has barely seen before.
Cloaking Space: A New Paradigm of Computation
In the era of big data and cloud computing, people are used to a centralized way of computation. You send your personal data — e.g. your id, income, health record or even facial features — to 3rd party servers. These 3rd parties will run some computation using your data and then provide you with some service based on the result of their computation. From social media to financial service providers, this is the status quo.
Bad news is, in this process, your personal data can get disclosed, misused or sold without your consent or even awareness. This has happened before and is still happening everyday. So we can’t help but to ask: can people use their data for computation/analysis/model-running without sending them to 3rd parties? Ideally, we want our data stored and processed in an environment which is invisible to outsiders — like in a Cloaking Space.
The answer is yes using the ZKP verification approach we discussed above. In the Cloaking Space, you control your own data and you can run all sorts of computation without sending your data away. Note that the data stored in the Cloaking Space is not just some arbitrary data on your device, but they are attested by some credible network/organization to guarantee its authenticity. The type of computation can range from a regular STF of a blockchain, a check of your income for a bank loan to an examination of your facial features to pass an airport checkpoint. In addition to checking your data meet certain criteria, the computation also checks the validity of your data attestations.
Note that in the Cloaking Space, we are working in the opposite direction of big data and cloud computing — we enable Self-Sovereign Data and Cloaked Computation. The bottom line is, your data never have to leave you anymore. And all the information that is exposed to the outside world is 1) the result of your computation and 2) a ZKP that attests to the integrity of your computation.
The idea of a Cloaking Space for user Self-Sovereign Data and Cloaked Computation is novel and useful, but the actual implementation is not so straightforward. Specifically, one needs to consider the difficulty to generate a ZKP for general-purpose computations. It is a well-known fact in the ZKP space that you need to generate a proving circuit (for SNARK) or an AIR (Algebraic Intermediate Representation, for STARK) for each of your algorithm. In our case, this means an AIR needs to be written for every single type of computation the users wish to perform. No doubt, this is a time-consuming process requiring a professional degree of understanding of the ZKP theory and related mathematical tools. If only there is a way to automate this process for the average application developers!
To solve this problem, we have adopted a zk-STARK virtual machine called the Distaff VM in the zCloak Network. The benefit of a virtual machine is that we can use a single AIR to verify its complete instruction set, avoiding the trouble of writing an AIR for each computation the user wishes to perform. In this, Distaff VM is similar to the Cairo VM developed by StarkWare. For any program executed on the Distaff VM, a STARK proof of execution is generated. This proof can then be used by anyone to verify that a program was executed correctly without knowing the inputs to the program or even the program itself. As such, an application developer can focus on their business logic instead of worrying about writing a STARK proof for their algorithm.
The zCloak Network
The zCloak Network will build the necessary ZKP related infrastructures for the Cloaking Space. Main components include a wallet app/extension, a blockchain and a network of incentivized ZKP service providers.
1) zCloak wallet. The Cloaking Space concept will be implemented as a mobile app and a browser extension. Users will store their personal data as Self-Sovereign Data in the wallet. Programs for all sorts of applications can be imported into the wallet and Cloaked Computation can be carried out using the Distaff VM proof generator in the wallet. The computation will end up with a result and a ZKP, which can be safely sent to external parties in exchange for services.
For example, you can import into your wallet a program from a bank for getting a loan. You feed your personal data into the program and the result will be generated along with a proof. You send this result and the proof back to the bank then they will know if you are qualified to get a loan and how much you should get. In this whole process, your data never leave you so no worries about any privacy leakage. Note that the receiving end can be just a smart contract instead of a real-world bank. Many interesting DeFi applications can be unlocked with this approach. To guarantee the authenticity of the input data, we will store the user data as attested credentials or aggregate data directly from other blockchains. We have been working closely with our ecosystem partners such as KILT Protocol and Litentry on the Self-Sovereign Data in a wallet app.
2) zCloak blockchain. The main functionalities of the zCloak blockchain include coordinating the work of ZKP service providers, settling payment for ZKP service fee, setting up smart contracts to react to user computation results, dealing with network governance and working as a port to other public blockchains such as Ethereum, BSC and Solana, etc.
It is expected the zCloak Network will adopt the business model of ZKP as a Service (ZKPaaS). Applications in other blockchains can use the ZKP infrastructures built in the zCloak Network to provide privacy/scalability related functions to their users. This can help the existing blockchain projects to create tons of new use cases.
3) ZKP service network. A decentralized service network will be organized around the zCloak blockchain for the storage and verification of ZKP.
As mentioned above, the size of a STARK proof is larger compared to a SNARK proof — not so efficient to be stored on the blockchain directly. As a STARK proof mainly consists of hashes, it can only be used to verify the integrity of a computation and won’t give away any meaningful user information. Therefore, users can store the STARK proof in a public decentralized storage such as an IPFS network and refer to this proof with its CID on the zCloak blockchain. zCloak Network will provide the basic IPFS infrastructure for the storage of user STARK proofs. In addition, existing public IPFS services such as arweave or Crust can also be leveraged for this purpose.
In reality, the receiving party of the STARK proof may not be equipped with the necessary tools to verify the STARK proof independently. In such cases, a group of STARK proof verifier nodes will be incentivized to provide proof verification service to the users of the zCloak Network. When a user tries to prove something to a receiving party, the proof verifiers will fetch the proof from the public IPFS network, examine the validity of the user proof and flag their results in the zCloak blockchain. A receiving party will be able to judge the validity of a user proof based on its CID and the flags given by the verifier network. A staking/slashing mechanism will be adopted to make sure the verifiers do their verification work honestly and correctly.
In summary, the zCloak Network will provide all the necessary building blocks to realize the Cloaking Space concept — to build a new type of blockchain that is private and scalable powered by a zk-STARK VM for Web 3.0.
