Zero-knowledge's Power: Decentralized Privacy-Driven Innovation

Introduction

The Zero-Knowledge (ZK) technology is capable of addressing privacy and security issues in the decentralized world. This article illustrates the pivotal role of ZK technology through four examples: DEX, oracle, voting, and auction.

• ZK technology is employed to ensure that transactions on DEX can be verified whilst protecting user privacy, concealing their identity or other transaction details.

• The technology guarantees the accuracy of data obtained from oracles and prevents data from being tampered with during transmission or computation.

• In blockchain voting projects, eligible voters can vote anonymously, and the voting information can be protected from pre-tampering. This is also a problem that ZK technology can solve.

• This technology can also provide identity privacy protection for bidders in blockchain auction projects and resolve issues of fraudulent bids.

Privacy Risks in a Decentralized World

As we all know, blockchain has no secrets. All information is under public view, which makes it somewhat lacking in terms of privacy protection. In addition, the operation of many smart contracts depends on data off the chain, bringing additional security risks. In the following, we will explore in detail the security issues and potential risks that these two characteristics can cause.

Security issues triggered by the transparency of blockchain

The transparency of the blockchain ensures the traceability of transactions, but at the same time, it can also raise security issues. For example, risks of personal privacy breaches and front-running transactions in DeFi.

• Privacy leakage: Methods such as address tag dyeing, transaction IP matching, and broadcast node probes can easily associate the real-world identity of the addresses on the chain. These analysis methods not only reveal the identity of users but also expose their behavior patterns and investment strategies. For instance, frequent transactions or specific types of transaction activities from a certain address can reveal the user's investment preferences or habits. This information is often improperly used for competitive advantage or inappropriate utilization.

• Front-running transactions: Attackers can take advantage of the transparency of the blockchain to monitor the queue of pending transactions. By analyzing these unprocessed transactions, they can set higher transaction fees, thereby inducing miners to prioritize these transactions. In this way, attackers can execute transactions before other users to gain a first-mover advantage and seek benefits for themselves. This behavior not only distorts the fairness of the trading process but can also lead to market manipulation and situations that are disadvantageous to other users.

Therefore, the design and implementation of DeFi protocols should fully consider these potential security threats. We should consider introducing additional privacy protection measures to protect users from risks such as privacy leaks and transaction behavior analysis.

Security Risks When Blockchain Acquires Off-chain Data

In the blockchain, smart contracts cannot directly access off-chain data; they can only access transaction data on the blockchain or the state of other contracts. Smart contracts are programs that execute automatically on the blockchain, and their execution results must remain consistent across all nodes, i.e., given the same input, their execution results must be exactly the same. If smart contracts were to access off-chain data directly, this could lead to variability since off-chain data might change. Different nodes executing the same contract could then produce different results, thereby breaking the consistency of the blockchain.

However, in many scenarios, smart contracts need to rely on off-chain data. For example, a DEX needs to get the latest price of a specific stock or cryptocurrency. This price data generally needs to be obtained from off-chain financial markets or other exchanges. Blockchain systems usually use oracles to get off-chain data. When a smart contract needs off-chain data, it can request the oracle, and the oracle will get the off-chain data and return it to the smart contract. Moreover, oracles can also transmit on-chain data to off-chain.

However, introducing oracles also brings new security risks, as in some scenarios, oracles may provide inaccurate data due to errors or malicious behavior. Therefore, designing and implementing oracles demands a strong focus on security.

Blockchain projects involving voting and auctions also need to consider special security protection measures. Blockchain technology provides transparency and tamper-proof characteristics for voting platforms. However, screening qualified voters, anonymous voting by voters, and preventing voting information from being tampered with in advance have become new challenges. The core issues of on-chain auctions are false bids and account visibility. When you can see through the other party's chips, you have the advantage of taking the initiative.

Privacy-driven Scenario Innovation

ZK Private DEX

The transparency of blockchain brings privacy challenges to many projects in the DeFi field. In the face of such challenges, Salus will take DEXs as an example to discuss the key role of ZK technology in enhancing privacy protection for DEXs.

Suppose there is a private DEX with privacy protection features. By using ZK technology, it can hide part of the transaction information while verifying the validity of these transactions. In this DEX, only part of the transaction information is public, such as all registered users, their bank accounts, and the names and quantities of assets deposited and withdrawn, as shown in Figure 1. The trader himself would know all his transaction information, but other traders cannot see the complete transaction information of others. Below, five specific transaction events will be used as examples:

Figure 1-test: Private DEXs, where only partial public information is known. Image source: https://arxiv.org/pdf/2309.01667.pdf-test

Assume that five transactions have occurred on this private DEX platform, and their corresponding event information is:

• Alice deposits 1000 USD on the platform.

• Bob deposits 10 BTC on the platform, at which time the price of BTC is 1000 USD.

• Alice makes a transaction on the platform, swapping 800 USD for 0.5 BTC, at which time the price of BTC is 1600 USD.

• Alice withdraws 0.3 BTC on the platform, at which time the price of BTC is 2000 USD.

• The platform records Alice's all cost and all gain, which are 480 USD and 600 USD respectively.

This private DEX platform, based on ZK technology, has implemented privacy protection features, where the complete transaction information is only visible to the users participating in the transaction. The platform does not publicly display the complete transaction event information but provides private event information. Next, we will explain in detail what the private event information refers to and how to verify it:

• When depositing 1000 USD, the bank account will reveal Alice's identity. Alice then receives an asset certificate or signature generated by the platform. To prevent double spending and ensure compliance, the signed message must contain additional properties beyond the asset details. These properties include a unique asset identifier, which is Alice's user identifier. This information should be hidden to maintain the anonymity of the user. Alice is required to prove, based on ZK technology, that her blinded user identifier equals her registration credential. To meet tax-report-client-compliance, the proceeds from selling assets in the exchange and withdrawal transactions need to be calculated. This requires including the exact cost at the time of asset purchase in the deposit and transaction. For this, we introduce the purchase price as an additional attribute in the asset certificate.

• When Bob deposits 10 BTC, the platform does not know Bob's identity as this transaction is not a fiat deposit.

• When Alice swaps 800 USD for 0.5 BTC, she uses a 1000 USD asset certificate to request two new certificates, namely the remaining 200 USD and 0.5 BTC, keeping the details hidden. The platform approves her request under certain conditions, including proving based on ZK technology that she has enough USD, ensuring that the certificates share the same user identifier, confirming that the remaining USD amount is non-negative, matching the BTC price with the latest certificate, and verifying that the total transaction value is equivalent.

• When withdrawing 0.3 BTC, it is similar to the exchange operation, except for the exchanged-in asset. Alice also verifies the receipt of the withdrawn BTC on the blockchain.

• When files all cost 480 and all gain 600, Alice presents a valid registration certificate with her identity and requests an updated registration certificate with a new index, resetting cost and gain to zero, and obtains a document certificate for presentation to regulators. The document certificate contains Alice's real identity, the correct cost of 480 and gain of 600, and some regulatory auxiliary information. Since the cost and gain are hidden by the platform to avoid information leakage, Alice should prove that the committed cost and gain are equal to the values in her registration certificate, and the platform will sign blindly. Alice runblinds it and submits the message signature pair to the regulator for tax reporting.

zkOracle

Suppose there is a blockchain-based agricultural insurance smart contract that relies on data provided by an oracle to determine whether to pay compensation to the insured farmers. If a region suffers from severe drought, then the farmers in the region can receive compensation from this insurance contract.

Nevertheless, if the oracle mistakenly reports the weather data for a region, significant issues can arise. For instance, suppose the region is facing a severe drought, but the oracle indicates normal rainfall levels. This inaccurate information would lead the smart contract to incorrectly assess the situation, resulting in a refusal to pay compensation to the farmers who are genuinely struggling with drought conditions.

From the above example, it can be seen that it is crucial to ensure the accuracy of the data provided by the oracle. zkOracle is an oracle based on ZK technology, an oracle that is secure and requires no trust. Below, we will specifically introduce the main differences between traditional oracles and zkOracle, and explain why ZK technology plays a key role in it.

Traditional oracles can be divided into three different types, input oracle, output oracle, and Input/Output (I/O) oracles. We will elaborate and compare the differences between each oracle from the following four dimensions:

	Input Oracle	Output Oracle	I/O Oracle
Usage	import off-chain data to on-chain context	export on-chain data to off-chain context	automate smart contract with off-chain computation
Data Source	off-chain data	on-chain data	on-chain data
computation	simple(only aggregation and uploading)	complex(indexing, aggregation, filtering…)	complex(indexing, filtering, trigger condition checking...)
Output	on-chain data	off-chain data	on-chain data and target smart contract call

In this article, we focus on the discussion of Output Oracle and I/O Oracle. The data of these two types of oracles originate from the blockchain, which means that these data have been verified and protected by the blockchain. How to ensure the security of the oracle's computation and transmission is the key issue we discuss.

To build a secure oracle, we can implement ZK technology in output oracles and I/O oracles, thereby creating output zkOracles and I/O zkOracles. The following section will compare the workflows of traditional oracles, output zkOracles, and I/O zkOracles, and will elaborate on how the output zkOracles and I/O zkOracles have been transformed using Zero-Knowledge (ZK) technology.

1. Traditional Oracle

The workflow of a traditional oracle is shown in Figure 2 as follows:

• Step ①：Obtain data from the data source.

• Step ②：Calculate the data in the computation component.

• Step ③：Output the calculation results.

Figure 2: Traditional Oracle

ZK technology can be used to modify steps ② and ③ in the traditional oracle workflow, while step ① remains unchanged.

2. Output zkOracle

• Step ② - ZK modification: Computation and ZK Proof Generation

In the computation component, calculations are made on the data obtained from the data source based on ZK technology, usually indexing, aggregation, and filtering, and the result of the calculation is a ZK proof.

• Step ③ - ZK modification: Verify ZK Proof

The ZK proof obtained from the computation in step ② can be verified in a smart contract or any other environment. The verification can confirm the validity of the computation in step ②.

Figure 3: Output zkOracle

3. I/O zkOracle

• Step ② - ZK modification: Computation and ZK Proof Generation

The computing components of the I/O zkOracle include the output zkOracle and the input zkOracle. Compared to the previously mentioned output zkOracle, the main content of the computation has increased, particularly the input zkOracle, which involves converting off-chain computation results into calldata for smart contract invocation. The combination of these two parts makes it possible to achieve the automation of smart contracts through complex off-chain computations.

• Step ③ - ZK modification: Verify ZK Proof

The output of the computation in step ② includes on-chain data (as calldata to complete the smart contract call) and a verifiable ZK proof. This ZK proof can be verified in a smart contract or any other environment. The verification can confirm the validity of the computation in step ②.

Figure 4: I/O zkOracle

Anonymous Voting

In voting activities conducted on the blockchain, all information is public, which may allow potential attackers to obtain the privacy information of voters. Blockchain-based voting faces two major challenges:

• Voter identity privacy: To ensure voter privacy, voting needs to be conducted with anonymous identities.

• Verifiability of voting results: To prevent voting data from being tampered with, a mechanism needs to be designed to ensure the verifiability of voting results.

In blockchain-based voting, how to protect the privacy of voters' identities and ensure the verifiability of voting results is a problem that needs to be handled cleverly. Using ZK technology can effectively achieve a balance between the two.

In Anonymous Voting on the blockchain, ZK technology and Merkle tree are combined to implement anonymous voting and verification. We divide the voting process into three main stages:

1 Generate Anonymous Identities for Voters Using Hash and Signature Methods

Before voting, voters need to use their real identity information for qualification and identity verification. After verification, they will obtain an anonymous identity unrelated to their real identity. Voting with this anonymous identity can protect personal identity information from being leaked.

2 Verify Voter Anonymous Identities Based on ZK Technology and Merkle Tree

Before voting with an anonymous identity, voters need to verify their anonymous identity. Only those who pass the verification can vote.

A Merkle tree is used to store the anonymous identities of all voters to prevent tampering and ensure the integrity of voter identity information.

The identity commitment generated from the voter's anonymous identity information is used as a leaf node, and a Merkle tree is constructed from a certain number of leaf nodes. A verification circuit based on a Merkle tree is used to verify the identity of the voter. The verification requires three pieces of data:

• The current voter's identity commitment, referred to as the input target node.

• The root node of the Merkle tree.

• The path index from the input target node to the root node. The path index represents the position information of the target node in the Merkle tree, represented by left 0 and right 1.

During the process of generating the root node from the input target node and the path index, the sibling node and the identity commitment generated from the user information are used to determine the user's identity. To ensure the uniqueness of the user's vote, we use the hash-processed identity identifier and external identifier as the ballot credentials.

3 Voting and Verification

This stage can be divided into the following six steps, as shown in Figure 5:

• Calculation problems: Insert the voter's anonymous identity into the Merkle tree and verify it.

• Equivalent conversion: The problem is successively transformed into a ZK low-order circuit, an R1CS structure (rank-1 constraint system), and a QAP (quadratic arithmetic program) problem to generate a process for verifying and proving keys.

• Public parameter generation: To ensure the security of the ZK system, a trusted setup is required to generate a common string used for generating proofs and verifying proofs.

• Generate ZK proofs: ZK proofs can be generated for voters using the ZK circuit. To generate such a proof, the voter's anonymous identity information and voting information need to be used as the input to the ZK circuit. This step is usually done off-chain. Then, the generated ZK proof will be uploaded to the blockchain.

• Verifying ZK Proofs: The proofs are verified on-chain to ascertain the validity of the votes, i.e., to check whether the voter's vote complies with the bounded system of the circuit. If the verification is successful, it returns 1; otherwise, it returns 0.

• Voting Contract: The voting contract verifies the voting results based on the deployed verification contract and verification key. During the user's interaction with the contract, the generation and verification of ZK proofs are calculated based on the ZK circuit, which can greatly protect the identity information of voters.

Figure 5: Voting and verification process

Based on this, we can implement a blockchain anonymous voting project.

Privacy Auctions

Open auctions on the blockchain have a drawback. Since blockchain transactions are public, anyone can observe the bids and financial status of bidders. If a bidder knew the bids of other bidders or if they knew the identities of other bidders, they could deduce the available funds of this account based on the publicly available transaction information on the blockchain. This bidder could then adjust their bid based on the bids or available funds of other bidders to win the auction. Open blockchain auctions face challenges such as the public exposure of bidder identities and financial exposure. Privacy auctions can prevent such unfair situations.

In a privacy auction, bidders can submit bids without revealing their identity or available funds. To implement a privacy auction, two major challenges must be overcome.

• Protecting the buyer's identity: The identity of the buyer's account needs to be kept confidential, as revealing the account would disclose their available funds in the auction.

• Protecting the seller's interests: The auction needs to prevent malicious bidders (buyers) from submitting bids that exceed their available funds.

ZK technology is used to protect the identity of bidders while verifying that they have the available funds for their bids.

In a privacy auction, each bidder needs two account addresses:

• Public staking account: This is used to transfer the entrance fee for the auction in advance.

• Private account: This account holds the actual funds the bidder uses to meet the winning bid. In other words, if the bidder wins the bid, the money in this account will be used to pay the winning price.

These two account addresses are unrelated, and others cannot determine the highest bid under the private account based on the transactions of the bidder's staking account.

The process of a privacy auction is as follows:

1 Verify Account Addresses and Available Funds Based on ZK Technology

Each bidder pre-submits the hash value of the account address and the hash value of available funds to the Merkle tree. Based on ZK technology, it is verified that the user indeed owns this account address, i.e., the pre-image (original data) of the hash value is consistent with the account address and available funds.

2 Verify the Account to Prevent Artificial Price Increases

Before bidders submit their bids, the privacy auction contract can examine the account of the previous bidder. To prevent the same account from artificially raising prices, the previous bidder cannot be the same person as the current bidder. While this setup cannot completely prevent one person from controlling two pledged accounts and two privacy accounts simultaneously, it should be noted that having two accounts means that the available funds in each account will be reduced. This further lowers the chance of winning the auction because once funds are pledged to the Merkle tree, it becomes impossible to transfer them to the privacy account.

3 Verify the Bidder's Available Funds are Higher than the Bid Based on ZK Technology

Use a comparator circuit to verify whether the bidder's available funds are higher than the bid, mainly verifying the following:

• Compare the available funds and the bidder's bid. If the result returned by the comparator's ZK circuit is true, it indicates that the bidder's available funds are equal to or higher than the bid, i.e., the bid is valid; otherwise, the bid is invalid.

• The circuit also includes intermediary checks to prevent the tampering of the witness file.

• Check whether the hash values of the account address and available funds exist in the Merkle tree.

Based on this, we can implement a blockchain privacy auction project.

Conclusion

We cannot ignore the security challenges faced by blockchain projects. ZK technology can provide privacy protection for DeFi projects, avoiding security issues such as user identity leaks and front-running attacks. This technology can also provide a more secure data verification method for oracle machines. In blockchain voting, the application of ZK technology allows for anonymous voting, which both protects the identity privacy of voters and verifies the authenticity of voting information. In blockchain auctions, the use of this technology can protect the identity privacy of bidders while verifying that they have sufficient bid funds, thus protecting the interests of sellers.

However, this is just the tip of the iceberg of the potential of ZK technology, and its true capabilities have not yet been fully explored. In the future, we expect to see ZK technology applied in more blockchain projects, providing users with better privacy protection and security guarantees. ZEROBASE is dedicated to utilizing ZK technology to achieve privacy protection in blockchain application layer projects. If you want to enhance privacy for your DApps, feel free to contact ZEROBASE at any time. We are here to provide you with all the help you need.