Use of zk-SNARKs inside Blockchain Infrastructure
There are many positive aspects of the current Internet, also known as Web 2.0. It is scalable, fast and, to some degree, secure. It is also user-friendly, i.e. anyone, regardless of age, can access it without hindrance — the only thing a person needs is an Internet connection. But with all the advantages, one major disadvantage is not discussed enough — centralization. Why is centralisation such a big problem?
Authorities rule
Every piece of information transmitted from our computers over the Internet, every bank account with our balance being just a number field in a database that can be deleted, every legal document which can be invalidated by a single person who is not competent enough and made a mistake. One may object that this cannot happen in the real world because we are protected by law and guided by trust. Indeed, this is true. But the law is not an axiom; it can be interpreted, and trust can be broken. This means we have limited power over our digital assets and the data stored on foreign databases, with no ability to eliminate human error.
One more issue regarding the standard Web 2.0 approach to the internet is exploitation. The data is usually stored in one place, risking a loss in an unexpected event, such as a fire at cloud provider servers or data leaks due to access by many employees. There are multiple examples of data leaks in 2022 in various domains. Web 3.0, as the internet’s next iteration, could present a potential solution to these problems. The new concept of ownership and identity is being introduced as we can finally own digital assets, proofs, and data that nobody can take from us thanks to cryptography. Web 3.0 leverages the naturally immutable blockchain technology and simultaneously stores data on multiple nodes. If one or more nodes are destroyed, another one can likely provide the data. Despite these advantages, the blockchain also contains a few drawbacks. Some will be solved as the technology matures (scalability, user experience), and some can be solved with new technology (privacy). I would like to focus on privacy element of blockchain. Every piece of data which goes in and out of the blockchain is public. But what if I want to forward sensitive information? I argue that the use of zero-knowledge proof can overcome this limitation.
Note: This project discusses the use of Zero Knowledge Proof for public EVM-compatible blockchains without native support for data hiding. If there is a need for absolute privacy and control, Hyperledger Fabric is a suitable solution among many others.
What is a zero knowledge proof?
Well, basically it’s a tool to prove some information without disclosing that information. In the context of smart contracts, I want to prove to the smart contract that I know, say, a preimage of a hashed string (i.e. password). A zero-knowledge protocol must satisfy the following criteria:
- Completeness: if the statement is true then a prover can convince a verifier
- Soundness: a cheating prover can not convince the verifier of a false statement
- Zero-knowledge: the interaction only reveals if a statement is true and nothing else
Applications
Since the blockchain is public by its nature, every input, output and state is publicly visible. This is unwanted when we need to send private information to a smart contract that executes logic based on this information. A solution to this problem would be using zero-knowledge proof, implemented in various domains.
Healthcare
There were at least ten major cases of data leaks in hospitals in 2022. The data is generally stored on conventional databases, which offer a high degree of security, yet are not infallible. With blockchain and zero-knowledge proofs, we can overcome this risk. Suppose we have a blockchain healthcare system and a blockchain identity assigned to every patient. Every patient could prove that they suffer from a severe illness and request free treatment from the hospital without disclosing identity. Another example of such usage is to prove one’s disease and then receive a monthly payment as financial support in times of need.
Social
Zero-knowledge proof can also be used in the social domain. Since this technology scores well in preserving privacy, it can be leveraged to build private voting systems based on blockchain. A great example of such usage would be in a Decentralised Autonomous Organisation. This translates as a blockchain system guided by smart contracts where individual users can vote on changes done to that system using tokens (configuration of rewards from features, trading fee on marketplaces, protocol changes etc.). Maintaining the privacy of votes would be a great benefit when wallet addresses are known and tied to a real person — this happens quite frequently if KYC is demanded to use the blockchain services of a provider. Another example would be to prove to the blockchain that a person is in a difficult life situation and, if some conditions are met, this person can apply for financial support. Blockchain is phenomenal because every transaction takes only a couple of seconds at most (except Bitcoin) — meaning the tokens with a financial value can be transferred instantly. This could be of considerable significance in charity and philanthropy.
Entertainment
Since zero-knowledge proof is a tool to prove some information without disclosing it to the verifier, there are unlimited opportunities to use this technology in games. One example would be sudoku-type games (puzzles, crossword, battleship etc.) or quiz games. The player will prove to the verifier that the player knows the answer to the problem (correct answer, position of enemy boat etc.) and the verifier verifies the proof. If the proof is correct, the verifier will send a reward to the player in the form of NFT, cryptocurrency or updating the state of the game. Significant benefit of this approach is that the answers remain hidden, and the reward is processed immediately, which can motivate the players.
Schooling
Blockchain and zero-knowledge proofs can be effectively used in university governing software. Applicants can become students at the university if they pass the requirements set by the university. Such requirements can be a SCIO score over 90 percentile or a successful entrance exam. This information will be imputed on blockchain as a proof by the relevant authorities; the registration smart contract will then verify these proofs. If the verification is successful, the applicant becomes a student. Once the student is registered, they can receive a scholarship for their achievements, use discounts for other services which will verify that this person is indeed a student at the university etc.
There have been recent cases of student discrimination at Czech universities. This represents another positive aspect of such a system based on blockchain. This system can be built so that all student information is public but anonymous (hashed). This would protect students against discrimination based on their individual characteristics.
Now let us get to the practical part.
In this example, I focus on Non-interactive zero-knowledge proofs since we cannot communicate with blockchain repetitively within the same session (at least in a meaningful way). There are currently two main types of Non-interactive zero-knowledge proof protocols: zk-SNARK and zk-STARK.
ZK-SNARK was introduced in 2012, so there has already been some widespread adoption with projects such as ZCash blockchain and many more. ZK-STARK has been around since 2018, so it is relatively new. I have chosen ZK-SNARK for this example as it is easier to grasp, and it already offers some sources to gain information from and solid developer community.
Firstly, I must take multiple steps before diving into this case study. Before the user can register as a student at CTU, one condition must be met — they need to hold at least one SCIO exam attempt with a score higher or equal to 90 points. If this condition is met, then the users can register. The problem is that everything needs to be on-chain for smart contracts to retrieve (and verify) this information, so how can SCIO assign exam attempts to a person? We need to create a smart contract called Registry. The authority will privately assign personID and seedID to every person (when this person turns 18 years old, for instance). Every piece of information will be stored as a hash, so there is no risk of information leak. The SCIO authority will register exam attempts for this person on their smart contract so the CTU registration smart contract can verify it.
Once a student is registered, we will have authentication infrastructure ready for additional features.
Blockchain infrastructure overview
The blockchain infrastructure consists of a registry smart contract, SCIO smart contract, registration smart contract and login smart contract. A verifier smart contract will verify the proofs for each of these smart contracts stored in the verifier variable.
Registration
I suggest a registration process which is entirely private and non-repetitive, i.e. the user cannot register twice as the same person (see the diagram below).
The process begins with a person wanting to apply to CTU. Firstly, the person needs to have a blockchain identity. If the person has none, this identity has to be issued. This identity is issued by the registry authority (municipality, for instance) on registry.sol smart contract. The registry authority will generate proof using personID and seedID created off-chain. This personID and seedID will then be privately handed to the person. The public part of this proof is linked to the hashed personID into the blockchain for later verification via setPerson method. Once the verification of a proof is needed, the proof will be checked using public information stored in the registration smart contract to ensure the external user cannot prove knowledge of someone else’s personID and seedID. The verification part is done via the verify method which uses the submitted proof, hashed personID and remaining public inputs. The registry smart contract will then call the verifier smart contract using verifyTx method and includes this person’s accessLow and accessHigh hashes into the function attributes. The registry verifier then can verify the proof sent by the person created on client with RegistryVerifier.zok.
Next, this person needs to have at least one SCIO exam result with a score over 90 percentile points (the user can take as many attempts as desired). Exam supervisors will verify that the person writing the exam knows their personID and seedID (the person will disclose hashed personID and a proof verifiable on Registry.sol smart contract). With every attempt, the SCIO authority will add a proof of a score to the blockchain (that the score is indeed equal to or higher than 90 percentile points) created via SCIOVerifier.zok and link it to the hashed personID inside the SCIO smart contract via addExamResult method. Once the user is confident with the results, they can proceed with the actual registration to the CTU.
Firstly, we need to assume that every applicant has a wallet connected to the client to ensure that the same proof (submitted by someone else) from transaction data cannot be taken from the public blockchain and reused. This will be guaranteed with a public key in the proof itself and private key signing the transaction.
Secondly, the user creates username and password for authentication within CTU blockchain infrastructure.
Thirdly, the user needs to present a proof that they indeed own the identity (i.e. knows personID and seedID) and a proof that they know the preimage to the created password together with hashed password and generated public key (i.e. wallet address, which is by default available inside smart contract function context thanks to private key signature). Fourthly, the registration smart contract verifies that the user has at least one attempt over 90 percentile points on the SCIO smart contract, the SCIO smart contract verifies the identity, and the CTU registration smart contract verifies that the user knows the password to the preimage. If everything runs smoothly, the smart contract will add an entry to the registration smart contract, and the person is finally registered as a student.
Login
Suppose the user wants to use a feature smart contract which has authentication as a requirement (the login smart contract’s authenticate method needs to return true). In that case, the user must submit a proof to the login smart contract that they know the password (which they submitted during the registration process). The smart contract also verifies that the user is a student of CTU. If everything is verified, then the feature can be used. One drawback of this approach is that the user (or someone else) can only reuse a proof they previously generated and pass the authentication of this system. We can overcome this issue the same way as in the registration process. On the client side, user's wallet public key will be included in the proof and private key will sign the transaction. Like this, we can ensure that nobody else except the user with the correct key pair cannot submit a valid proof taken from public input of the blockchain.
This authentication system can be plugged into every smart contract and enable features only to the students. Possible features include withdrawing the allowance or rewards, applying for an exam, competing in mini-games etc. It is also much safer than conventional solutions using Web 2.0 approach, because username, password and other information will not be relayed over the internet.
Possible improvements
In this example, only those users (who apply for a CTU) who already have a wallet are considered (signing the registration is required, otherwise the proof can be reused). It would be quite easy to create a Web2 access to this Web3 system by simply using a meta-transaction with the generation of a wallet for each transaction, then the authorities would have to pay for the gas fees. The user can then create a username and password on the CTU registration contract and authenticate each time they want to use a feature using only the classic login form.
Conclusion
Web 2.0 is remarkable but has some major drawbacks regarding privacy and ownership. We are in a stage of experimenting with what we can do with blockchain technology in terms of privacy, ownership and transparency. Even though blockchain is impressive, it is limited by cases where privacy is the most important aspect of a system. Zero-knowledge proof represents an approach that can only solve some of the issues. However, it works very well in blockchain protocols like ZCash protocol or famous zero-knowledge rollup, widely used in Polygon and other L2 solutions. As this project demonstrates, it can also work sufficiently in areas where maintaining privacy in EVM-compatible chains is a priority. The developer community is interested in enhancing zero-knowledge proofs since there are already protocols which will prevail in the post-quantum era, suggesting that this technology will be used more widely in the future.
Today, blockchain is different from the blockchain we will see tomorrow. It is an ever-evolving ecosystem with great potential, but sometimes there needs to be a little technological push to meet the people’s demands.
This article is based on my semester project as part of the B4BPROJ6 course at CTU in 2023.
Github repository with working proof of concept here.
