On-chain application solution for privacy payment using zero-knowledge proof (ZKP)

Hash (SHA1): 6ec9df3960804ae5e6b0bee29289da35f3abc356

No.: Lianyuan Security Knowledge No.133

Zero-knowledge proof technology is a branch of cryptography that can solve the expansion and privacy problems for many Layer 1 blockchain projects. Blockchain can use zero-knowledge proof technology to increase transaction throughput, protect user data privacy while verifying user identity, implement complex calculations, and allow companies to use blockchain technology while protecting their intellectual property rights. In all of the above application scenarios, zero-knowledge proof is an indispensable key technology.

To date, among all the utilities provided by programmable blockchains - security, predictability, interoperability, and autonomous economy, etc. - the most widely used blockchains do not provide privacy utilities, which remains a key obstacle to their widespread adoption. Therefore, more and more people will pay more attention to the privacy security of the chain, and private payments are born.

Basics

Zero-knowledge proofs are divided into two types of proof schemes:

1. Interactive argumentation scheme
2. Non-interactive argument scheme
3. Interactive ZKP

Interactive Zero-Knowledge Proofs (IZKPs) require a back-and-forth conversation between the prover and the verifier, in which the prover responds to the verifier's queries. This interaction can take place in person or over a network such as the Internet. Multiple rounds of interaction with the verifier are required so that the verifier can ask for additional information beyond the statement being proved. In each round, the prover needs to provide a response based on the verifier's query.

IZKP requires interaction between the prover and the verifier, which can be inefficient and time-consuming. To complete a proof, the prover must send multiple messages back and forth with the verifier. This can take a significant amount of time, especially when the proof is complex or involves a large amount of data. This can be a problem when speed is critical, such as in high-frequency trading or real-time decision making.

The specific implementation scheme is zk-starks. STARK allows the blockchain to transfer calculations to an off-chain STARK prover, and then use the on-chain STARK verifier to verify the integrity of these calculations. Layer-2 networks can achieve scalability by using STARKs to calculate a large number of transactions in a single batch, and then use a single STARK proof to confirm the validity of the transaction on the chain. All transactions in the batch share the cost of on-chain operations, providing low gas costs for each transaction on the Layer 2 network.

Importantly, STARKs do not require a trusted setup ceremony, as the randomness used by validators is publicly available and proofs can be verified without relying on any external parameters.

StarkNet, dydx, and Polygon Miden all use zk-rollup solutions using zk-starks

Non-interactive ZKPs

Non-interactive zero-knowledge proof (NIZKP) does not require any interaction between the prover and the verifier. Non-interactive zero-knowledge proof means that the prover can generate the proof once and send it to the verifier without multiple rounds of interaction.

The specific implementation scheme is zk-snarks. SNARKs are more efficient and faster because they can be verified in a few milliseconds. However, this efficiency comes at a cost, because some SNARKs rely on trusted setup ceremonies that have security weaknesses. This means that the initial parameters used in the proof must be generated in a secure environment, and any leakage of the parameters may lead to security vulnerabilities.

Both zkSync and zcash use zk-snark's zk-rollup solution.

Privacy transaction concept

To understand the concept of private transactions, we need to consider both the transaction subject and the transaction details, and distinguish between two types of privacy: anonymity and concealment.

A normal transaction consists of the following elements:

• Transaction subjects: including the sender (trader A) and receiver (trader B) of the transaction.
• Transaction details: including transaction amount, number of sub-transactions, transaction hash and other specific details.

Private transactions can be divided into two categories based on the degree of information visibility to third parties:

• Anonymous transactions: In anonymous transactions, the addresses of the sender and receiver of the transaction are unknown to third parties. This means that during the transaction, other than the two parties involved in the transaction, no one else can determine the specific participants in the transaction. For example, Tornado Cash is a privacy protocol that achieves anonymity by obfuscating transaction paths.
• Hidden transactions: In hidden transactions, although the addresses of the sender and receiver of the transaction are visible, the specific details of the transaction are unknown. This means that detailed information such as the transaction amount, number of sub-transactions, and the hash of the transaction are hidden from third parties. This privacy can be achieved by using technologies such as zero-knowledge proofs. For example, Zcash is a privacy cryptocurrency that uses zk-SNARKs technology to hide transaction details.

Existing privacy payment solutions

The blockchain solutions applied to zk on the chain can be roughly divided into several types. One is a rollup as a Layer2 solution, that is, zk-rollup. Compared with op-rollup, it does not require a 7-day challenge period, and its data is more reliable and more secure. However, it has no privacy and can be deployed directly on the middle layer, such as zkSync and scroll, without having to understand zk. This solution mainly uses zk's proof theory to verify data correctness and does not focus on privacy protection.

A separate chain is used to handle transactions that require privacy protection, such as Zcash and MantaPay's privacy asset platform. To interact with privacy assets, you may need to do ZK programming yourself. This is a very interesting thing for developers.

The last solution is a Layer2 solution that can use zk-aluvm verification on the chain or off-chain nodes to perform zk-verified privacy payments. It combines the advantages of L2 and also introduces the function of privacy payment. It may be a more popular method at present, but in actual development, it is also the method that is most affected by technology and policies.

This article will focus on the privacy payment solution based on the zkp blockchain.

zcash

The transaction model of ZCash is basically the same as that of Bitcoin, but the UTXO is replaced by note, which is the basic transaction unit of ZCash. It can also be understood as the plain text of the transaction commitment. We will use note=(PK, v, r, rho) to represent note, where PK is the public key, v is the amount, and r is the random serial number. rho is the unique identifier of each note. When a note is consumed, this value will be placed in the nullifier table, indicating that the note has been consumed. When the same note is consumed again, a double-spending error will be triggered, that is, the transaction double-spending protection mechanism.

In ZCash, there are two tables: commitment and nullifier. Due to privacy requirements, notes cannot be made public. Therefore, it is necessary to calculate the corresponding commitment to represent the note. The calculation method is as follows:

Commitment represents an amount transfer, and Nullifier represents a consumption. Note that for a Note, both Commitment and Nullifier are unique. Because Commitment and Nullifier are the result of Hash, even if these two data are public, others cannot infer the connection between Commitment and Nullifier. In other words, providing a Commitment can indicate that a transfer has been made (the specific information is unknown to others). If the corresponding Nullifier can be provided, consumption can be made.

As a privacy transfer platform, all Commitments (cm) are combined into a Merkle tree:

If a user wants to consume a cm, he must provide a zero-knowledge proof to the blockchain:

1/ He knows a Note and can generate a cm, and this cm is on the Merkle tree with rt as the root

2/ Using the same Note information, a nullfier can be generated, and this nullfier has not been generated before.

The above is just the simplest summary of the general idea of Zcash zero-knowledge proof. The design of ZCash is very complex and rigorous, with many details.

The current version of zcash has undergone two upgrades, Sprout and Sapling, and has changed greatly from the original model. The current model of zcash has a very fatal problem. Zcash only supports private transactions between native tokens ZEC, and it is difficult to support tokens such as ERC20. When using it, users can only buy ZEC on the exchange, transfer it to the Zcash chain, and use ZEC to trade to achieve the purpose of private transactions. Moreover, zkcash is the earliest pioneer of private payment. At the protocol level, it does not integrate too many complex things, resulting in single functionality and historical problems such as low TPS.

TornadoCash

TornadoCash mainly utilizes the zkp-based mixer protocol to solve the single currency problem of zcash. TornadoCash mainly relies on smart contracts on the Ethereum chain to fully expand its usability.

The Tornado implementation path is as follows: TornadoCash uses a commitment to control access rights. The receipt is generated by hashing the secret and nullifier together, commitment = hash(secret, nullifier), and then the user sends the amount to be mixed (such as 1 ETH) and the commitment to the deposit function of the TornadoCash contract. The TornadoCash contract will save these two data, and the commitment will be used to withdraw the deposited funds later.

Each commitment can only be withdrawn once. Use Merkle Tree to record deposit information, use commitment as leaf node and calculate Merkle Root. Users only need to provide data from leaf to root to prove whether the data is one of the leaves of Merkle Tree, and indirectly prove that there was a deposit to TornadoCash before.

When withdrawing funds, users need to use the zk-snark solution to submit a proof that they have a secret and a nullifier. The TornadoCash smart contract will check this proof and then transfer the deposit amount to the specified withdrawal address. For external observers, it is impossible to know which deposit the withdrawal came from. In addition, a nullifier is used to prevent Double Withdrawal attacks.

At the heart of Tornado Cash are smart contracts that enable users to conduct private transactions on Ethereum. When engaged by a user, the contract will automatically perform one of two supported actions: "deposit" or "withdraw". Together, these actions allow a user to deposit tokens from one address, and then withdraw the same tokens to another address. Crucially, even though these deposit and withdrawal events occur publicly on Ethereum's transparent ledger, any public links between the deposit and withdrawal addresses are severed. Users can withdraw and use their funds without having to worry about exposing their entire financial history to a third party.

MantaPay

MantaPay combines the advantages of the first two protocols and independently develops a ZK L1 chain based on the Polkadot chain. By bringing programmable identity and credentials to web3 through zkSBT, MantaPay has successfully solved the problems of privacy payment and prosperous ecology.

MantaPay uses ZK technology to achieve private transfers. When initiating a transaction, users use Manta Signer to submit a transfer request and generate a ZK certificate as a prover. The node as a verifier can verify that the user's transaction is true without obtaining any transfer information.

Manta uses UTXO to verify transactions. Manta UTXO actually has "two trees", all tokens are in the first tree, and the second tree records the UTXO spent by the user. When trading, the transaction will be accompanied by a ZK proof to prove that the state does not exist in the second tree. Since the ZK proof cannot be forged or tampered with, the node verifies the validity of the proof, and as long as the proof is valid, the transaction is valid.

Manta’s ZKEvm is a technology that uses ZK-SNARK technology to create cryptographic execution proofs for transactions similar to Ethereum. These proofs can be used to make the Ethereum blockchain more scalable by reducing the computational load required to verify transactions or building efficient and scalable ZK-rollups.

Currently, Manta does not have better support for ZKEvm. It may be due to the difficulty of development or the impact of regulations, but it has to be said that it is a very futuristic solution.

ZKP on-chain solution concept

The above article describes several existing solutions for privacy payment. In the future, higher TPS and better ecological support will definitely become the mainstream solution. On this basis, we put forward some ideas.

ZK-AluVM

AluVM - (Algorithmic Logic Unit VM) is a pure-play RISC virtual machine designed for deterministic portable computing tasks. It was designed and implemented by Dr. Maxim Orlovsky of Pandora Core AG and maintained by the LNP/BP Standards Association.

AluVM is a purely register-based, highly deterministic, exception-free instruction set architecture (ISA) and virtual machine (VM) that does not require random memory access and is capable of performing arithmetic operations, including elliptic curve operations. The environment in which the virtual machine runs (the host environment) can extend the AluVM ISA to enable loading of data into VM registers and support for application-specific instructions such as SIMD.

The main use of ALuVM is for distributed systems, wherever robust, platform-independent determinism is more important than computational speed. The main areas of application of AluVM (with appropriate ISA extensions) are blockchain environments, consensus-critical computations, edge computing, multi-party computation (including deterministic machine learning), client-side verification, sandboxed Internet2 computing, and genetic algorithms.

ZK-AluVM is used in the blockchain to process transactions, update the state tree and generate proofs at the same time. The implementation scheme can be based on Mina for further research.

Based on ZK-AluVM, we have conceived several expansion solutions

Bitcoin Scaling Solution

Off-chain part: ZK-AluVM is used locally to perform transactions and generate proofs, but the transmission of transaction information is entrusted to centralized operators. In this operation, the transaction perceivers are the transaction parties and the centralized operator. Protocols such as Nostr can be used here to reduce centralization.

On-chain part: On-chain verification is optional. Rollup is used to encapsulate multiple transaction Rollups with the same seal to save Gas. BTC can be changed to Lightning Network to achieve extremely high TPS.

Schematic diagram of Ethereum layer2 solution framework

Off-chain part: Use ZK-AluVM for transactions and proof generation. Here you can choose centralized services, or operate the client itself for P2P transmission.

On-chain part: First, the client sends the transaction to the Layer2 node, sorts it and writes it to Calldata. The execution layer reads the data from Ethereum and processes the transaction. Here, the one-time packaging solution based on UTXO is changed to centralized management using contracts. The on-chain part of this solution is very centralized, and various high-performance EVM public chains can be selected as the base to achieve a higher TPS.

Summarize

Due to length limitations, there are still many good protocols that are not listed, such as Aleo, RGB, etc. However, as users in the field of privacy payment, we care more about security, efficiency, and stability. Among the many products, we must improve our security awareness and increase our understanding of blockchain. No matter what privacy payment solution it is, we must understand its core, be responsible for our assets, and be responsible for our future.