The Power of ZK: Privacy-Driven Innovation in a Decentralized World

1 Introduction

Zero-Knowledge (ZK) technology can solve privacy and security issues in the decentralized world. This article illustrates the key role ZK technology plays through four examples of DEX, Oracle, voting and auction. ZK technology is used to ensure that transactions on DEX can be verified and protect user privacy, hiding the user’s identity or other transaction details. Based on ZK technology, the accuracy of the data obtained from the oracle machine can be guaranteed and the data can be prevented from being tampered with during transmission or calculation. In blockchain voting projects, qualified voters can vote anonymously, and voting information can prevent pre-tampering, which ZK technology can solve. This technology can also provide identity privacy protection for bidders in blockchain auction projects, while also solving the problem of false bidding.

2. Privacy risks in a decentralized world

There are no secrets in the blockchain, and all information is under public view, which makes it lacking in privacy protection. In addition, many smart contracts cannot operate without off-chain data, which brings additional security risks. Below, we will discuss in detail the security issues and potential risks caused by these two features.

Security issues caused by the openness and transparency of blockchain

The openness and transparency of blockchain ensures the traceability of transactions, but it also raises security issues. For example, the risk of personal privacy leakage and front-running transaction risk in DeFi.

-Privacy leakage: The true identity of the address on the chain in the real world can be easily associated through methods such as address label dyeing, transaction IP matching, and broadcast node probes. These analytical methods can not only reveal the identity of users, but also their behavioral patterns and investment strategies. For example, frequent transactions or specific types of trading activity at a certain address can reveal the user’s investment preferences or habits, and this information is often improperly used for competitive advantage or inappropriately exploited.

-Front-running transactions: An attacker can exploit the transparency of the blockchain to monitor the queue of pending transactions. By analyzing these unprocessed transactions, they can set higher fees in the transactions to induce miners to process these transactions first. In this way, attackers can execute transactions before other users to gain an advantage and benefit themselves. This behavior not only distorts the fairness of the transaction process, but also leads to market manipulation and situations that are detrimental 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.

The security risks of blockchain when obtaining 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 status of other contracts. Smart contracts are automatically executed programs on the blockchain, and their execution results must be consistent across all nodes. That is, given the same input, their execution results must be completely consistent. Since off-chain data may change, if smart contracts directly obtain off-chain data, different nodes may obtain different results when executing the same contract, which will destroy the consistency of the blockchain.

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

The introduction of oracles, however, also brings new security risks. In some scenarios, oracles will provide inaccurate data due to errors or malicious behavior. Therefore, the design and implementation of oracles need to pay great attention to security.

Blockchain projects involving voting and auctions also need to consider special security protection measures. Blockchain technology provides voting platforms with transparency and immutability. However, screening qualified voters, voting anonymously, and preventing voting information from being tampered with in advance have become new challenges. The core problems of on-chain auctions are false bidding and account visibility. When you can see through the opponent’s chips, you have a first-mover advantage.

3. Privacy-driven scenario innovation

3.1 ZK Private DEX

The public transparency of blockchain has brought privacy challenges to many projects in the DeFi field. In the face of such challenges, Salus will explore the key role of ZK technology in enhancing privacy protection in DEXs.

Suppose there is a private DEX with privacy protection functionality. By using ZK technology, it can hide certain parts of transaction information while still verifying the validity of these transactions. In this DEX, only partial transaction information is public, such as the bank accounts, assets names, and quantities of deposits and withdrawals for all registered users, as shown in Figure 1. The traders themselves will have access to their complete transaction information, but other traders will not be able to see the complete transaction information of others. Below, let’s take five specific transaction events as examples:

Figure 1 Private DEXs with Partial Public Information (Image source: https://arxiv.org/pdf/2309.01667.pdf)

Assuming that five transactions occurred on this private DEX platform, the corresponding event information is as follows:

1. Alice deposited 1,000 USD on the platform.
2. Bob deposited 10 BTC on the platform, and the price of BTC at this time was $1,000.
3. Alice conducts a transaction on the platform and exchanges 800 USD for 0.5 BTC. At this time, the price of BTC is $1,600.
4. Alice withdrew 0.3 BTC on the platform, and the price of BTC at this time was $2,000.
5. The platform records Alice’s total expenditure and total income, which are US$480 and US$600 respectively.

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

1. When there is a deposit of 1000 dollars, the bank account will display Alice’s identity. Then Alice will receive an asset voucher or signature generated by the platform. To prevent double spending and ensure compliance, the signed message must include additional attributes beyond the asset details. These attributes include a unique asset identifier, which is Alice’s user identifier. This information should be hidden to maintain user anonymity. Alice is required to prove, based on ZK technology, that her blinded user identifier is equal to her registration credential. To meet tax-report-client-compliance requirements, the proceeds from selling assets and withdrawal transactions in the exchange need to be calculated. This requires including the exact cost of asset purchase in deposits and transactions. To achieve this, we introduce the purchase price as an additional attribute in the asset voucher.
2. When Bob deposits 10 BTC, the platform does not know Bob’s identity. Because this transaction is not a fiat currency deposit.
3. When Alice exchanges 800 USD for 0.5 BTC, she requests two new vouchers using 1000 USD worth of assets, specifically the remaining 200 USD and 0.5 BTC, while keeping the details hidden. The platform approves her request under certain conditions, including proving she has enough USD based on ZK technology, ensuring the vouchers share the same user identifier, confirming the remaining USD amount is non-negative, matching the price of BTC with the latest voucher, and verifying the equivalence of the total transaction value.
4. When withdrawing 0.3 BTC, it is similar to the trading operation, except the assets being exchanged. Alice also verified the receipt of the withdrawn BTC on the blockchain.
5. When the total expenditure is 480 and the total revenue is 600, Alice presents a valid registration certificate with her identity and requests an updated registration certificate with a new index. This updated certificate will reset the expenditure and revenue to zero and provide a document certificate for presentation to regulatory authorities. The document certificate includes Alice’s true identity, the correct expenditure of 480, and the revenue of 600, along with some regulatory auxiliary information. As the platform hides the expenditure and revenue to avoid information leakage, Alice needs to prove that the committed expenditure and revenue are equal to the values in her registration certificate. The platform will provide a blind signature for verification. Alice will then unblind the signature and submit the signed message to the regulatory authorities for tax reporting.

3.2 zkOracle

Suppose there is a blockchain-based agricultural insurance smart contract that determines whether to pay compensation to insured farmers based on weather data provided by an oracle. For example, if a severe drought occurs in a certain area, farmers in that area can receive compensation from this insurance contract.

However, if the oracle incorrectly reports the weather conditions in the area for some reason, such as the area is actually suffering from a severe drought, but the oracle reports normal rainfall, this erroneous information will cause the smart contract to make an error judgment, thereby denying compensation to farmers who are actually facing drought hardship.

From the example above, it can be seen that ensuring the accuracy of the data provided by an oracle is crucial. zkOracle is an oracle based on ZK technology, which is a trustless and secure oracle. In the following, we will specifically discuss the main differences between traditional oracles and zkOracle, and explain why ZK technology plays a key role in them.

Traditional oracles can be divided into three different types. We will elaborate and compare the differences between each oracle from the following four dimensions:

In this article, we focus on the discussion of Output Oracle and I/O Oracle. The data from these two oracles are sourced from the blockchain, which means that this data has already been verified and protected by the blockchain. Ensuring the security of the oracle’s computation and transmission is the key issue we are discussing.

In order to implement a secure oracle, we can perform ZK transformation on the output oracle and I/O oracle to implement the output zkOracle and I/O zkOracle. The following section will compare the workflow of traditional oracle, output zkOracle and I/O zkOracle, and explain the aspects in which output zkOracle and I/O zkOracle have been transformed by ZK.

1. Traditional Oracle

The workflow of the traditional oracle machine is shown in Figure 2:

1. Step ①: Obtain data from data source
2. Step ②: Calculate the data in the computation component
3. Step ③: Output the calculation results

Figure 2 Traditional Oracle

ZK technology can be used to ZK transform steps ② and ③ in the traditional oracle workflow. Step ① remains unchanged:

1. Output zkOracle

Step ②-ZK transformation: calculate and generate ZK proof

In the computation component, the data obtained from the data source is calculated based on ZK technology, usually sorting, aggregation and filtering. The result of the calculation is a ZK proof. Make calculations and outputs verifiable.

Step ③-ZK transformation: verify ZK certificate

The ZK proof calculated in step ② can be verified in smart contracts or any other environment. The validity of the calculation can be verified through confirmation step ②.

Figure 3 Output zkOracle

1. I/O zkOracle

Step ②-ZK transformation: calculate and generate ZK proof

The computing component of I/O zkOracle consists of output zkOracle and input zkOracle. Compared with the aforementioned output zkOracle, I/O zkOracle has more main contents of calculation, that is, input zkOracle involves setting the off-chain calculation results as calldata called by the smart contract. The combination of these two parts makes it possible to use complex off-chain calculations to automate smart contract operations.

Step ③-ZK transformation: verify ZK certificate

The output of step ② calculation includes on-chain data (used 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. Verification can confirm the validity of the calculation in step ②.

Figure 4 I/O zkOracle

3.3 Anonymous voting

In voting activities conducted on the blockchain, all information is public, which will allow voters’ private information to be obtained by potential attackers. Blockchain-based voting projects face two major challenges:

1. Voter identity privacy: To ensure voter privacy, anonymous identities are required to vote.
2. Verifiability of voting results: To prevent voting data from being tampered with, a mechanism needs to be designed to ensure that the authenticity of voting results can be verified.

In blockchain-based voting projects, how to protect the identity privacy of voters while ensuring the verifiability of voting results is a problem that needs to be handled skillfully. Using ZK technology, a balance between the two can be effectively achieved.

In the Blockchain Anonymous Voting project, anonymous voting is implemented and verified by combining ZK technology and Merkle tree. We divide the voting process into three main stages.

1. Use hashing and signing methods to generate anonymous identities for voters

Voters need to use their real identity information for qualification confirmation and identity verification before voting. After passing the verification, they will get an anonymous identity that has nothing to do with their real identity. Voters using this anonymous identity to vote can protect their personally identifiable information from being disclosed.

1. Verify the anonymous identity of voters based on ZK technology and Merkle tree
   Before voters use their anonymous identities to vote, they need to verify their anonymous identities. Only voters who pass the verification can vote.

Use a Merkle tree to store the anonymous identities of all voters, which can prevent tampering and ensure the integrity of the voters’ identity information.

The identity commitment generated by 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 merkle tree-based verification circuit is used to verify the identity of the voter. Verification requires three aspects of data:

1. The identity commitment of the current voter is recorded as the input target node.
2. The root node of the Merkle tree.
3. Enter the path index from the target node to the root node. The path index represents the position information of the target node in the Merkle tree, represented by 0 on the left and 1 on the right.

In the process of generating the root node from the input target node and path index, the identity of the user is determined using the identity commitment generated from the sibling nodes and user information. To ensure the uniqueness of user votes, we use hashed identity identifiers and external identifiers as proof of vote.

1. Vote and verify

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

1. Computational problem: Insert the anonymous identity of the voter into the Merkle tree and verify it.
2. Equivalent conversion: The process of converting the problem into ZK low-order circuit (low-order circuit), R1CS structure (rank-1 constraint system) and QAP (quadratic arithmetic program) problems in order to generate verification and proof keys.
3. Public parameter generation: In order to ensure the security of the ZK system, a trusted setup is needed to generate public strings used to generate proofs and verify proofs.
4. Generate ZK proofs: ZK circuits can be used to generate ZK proofs for voters. In order to generate such a proof, the anonymous identity information and voting information of the voter need to be used as the input of the ZK circuit. This step is usually completed off-chain. Afterwards, the generated ZK certificate will be uploaded to the blockchain.
5. Verify ZK proof: Verify the proof on the chain, that is, verify the validity of the vote, that is, verify whether the voter’s vote satisfies this circuit bounded system. Returns 1 if verification is successful, otherwise 0 .
6. Voting contract: The voting contract verifies the voting results based on the deployed verification contract and verification key. During the interaction between users and contracts, the generation and verification of ZK proofs are calculated based on ZK circuits, which can protect the identity information of voters to a great extent.

Figure 5 Voting verification process

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

3.4 Privacy Auction

Public blockchain auctions have a drawback. Since blockchain transactions are public, anyone can observe bidders’ bids and financial status. If a bidder knows the bids of other bidders or their identities, they can determine the available funds of those accounts based on the publicly available blockchain transaction information. Using this knowledge, the bidder can adjust their own bid to win the auction. Public blockchain auctions face challenges such as the disclosure of bidders’ identities and financial exposure. Privacy auctions can prevent such unfair practices from occurring.

In a private auction, bidders can submit bids without revealing their identity or available funds. To realize privacy auctions, two major difficulties must be overcome:

1. Protect Buyer Identity: The identity of the buyer’s account needs to be kept secret, as revealing the account will reveal their available funds in the auction.
2. Protect seller interests: Auctions need to prevent malicious bidders (buyers) from submitting bids that exceed their available funds.

Use ZK technology to protect the privacy of bidders’ identities while being able to verify that they have the funds available to bid.

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

1. Public staking account: used to transfer the admission fee of the auction in advance;
2. Private account: This account holds the actual funds used by the bidder to satisfy the winning bid. In other words, if the bidder succeeds in winning the bid, the money in this account will be used to pay the winning price.

The two account addresses are unrelated, and others cannot determine the highest bid under the privacy account through the transactions of the bidder’s pledge account.

The privacy auction process is as follows:

1. Verify account address and available funds based on ZK technology

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

1. Verify the account to prevent artificially raising prices

Before a bidder submits a bid, the privacy auction contract can verify the account of the previous bidder. In order to prevent the same account from artificially inflating the price, the previous bidder cannot be the same person as the current bidder. Although such a setup cannot completely prevent one person from controlling two staking accounts and two privacy accounts at the same time, it is important to note that having two accounts means that there will be less funds available in each account. This further reduces the chances of winning the auction because after the funds have been staked to the Merkle tree, they will not be able to be transferred to a privacy account.

1. Verify whether 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 available funds and bidders’ bids. If the comparator’s ZK circuit returns true, it indicates that the bidder’s available funds are equal to or higher than the bid, that is, the bid is valid, otherwise the bid is invalid.
• The circuit also includes intermediate checks to prevent tampering with witness files.
• Check if the hash of the account address and available funds exists in the Merkle tree.

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

4. Summary

We cannot ignore the challenges that blockchain projects face when it comes to security. ZK technology can provide privacy protection functions for DeFi projects and avoid security issues such as user identity leaks and front-running attacks. This technology can also provide a more secure data verification method for oracles. In blockchain voting projects, the application of ZK technology can realize anonymous voting, which not only protects the identity privacy of voters, but also verifies the authenticity of voting information. In blockchain auction projects, using this technology can protect the identity privacy of bidders while verifying that they have sufficient bidding funds, thus protecting the interests of sellers.

Disclaimer：

1. This article is reprinted from [PANews]. All copyrights belong to the original author [Salus]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.