# Technical analysis how to realize private transactions through zk-SNARK in NEAR

1. transaction
2. Token deposit and withdrawal
3. Transaction Fees
4. future development
5. Conclusion

# Unspent output

In the NEAR ecosystem, we generally use the account model as the bookkeeping method, and private transactions use the UTXO (unspent output) model. Each UTXO is a tuple, containing three elements: amount, receiver, and salt. The amount refers to the transaction amount. The receiver is actually the public key of the token receiver, and “salt” is just some random numbers.

# transaction

Suppose Alice wants to transfer some tokens to Bob in private. The token belonging to Alice is stored in UTXO, and the recipient of the token is equivalent to Alice’s public key. To keep the transaction private, Alice created a transaction in the following form:

• Know some kind of private input 1, private input 2…
• Can get [some conclusion]
• There are four such UTXOs: IN1, IN2, OUT1, OUT2, two Merkel proofs P1 and P2 and a private key x,
• The hash values ​​corresponding to OUT1 and OUT2 are OUT_HASH1 and OUT_HASH2 respectively; the receivers in IN1 and IN2 are equivalent to the public key X corresponding to x; merkel proves that P1 and P2 are in the Merkel tree determined by Merkel root Contains valid proofs of IN1 and IN2; the sum of the quantities in IN1 and IN2 is equal to the sum of the quantities in OUT1 and OUT2.
• There are four such UTXOs: IN1, IN2, OUT1, OUT2, two Merkel proofs P1 and P2 and a private key x,
• The hash corresponding to OUT1 and OUT2 are OUT_HASH1 and OUT_HASH2 respectively; the receivers in IN1 and IN2 are equivalent to the public key X corresponding to x; Merkel proves that P1 and P2 are included in the tree with the determined Merkel root Valid proof of IN1 and IN2; the sum of IN1 and IN2 is equal to the sum of OUT1 and OUT2; and hash (IN1, x) is equal to NULLIFIER1, hash (IN2, x) is equal to NULLIFIER2

# Token deposit and withdrawal

The above types of transactions can be used for the transfer of assets in the pool, but for a fully functional trading pool, it must support the transfer of funds inside and outside the pool. Therefore, we added an extra field to the format of the private transaction, called delta, so that the total amount of input UTXO is equal to the number of output UTXO + delta.

• It is known that for IN1, IN2, OUT1, and OUT2, four UTXOs are counted, two Merkel proofs P1 and P2, and a private key x,
• Then the hash values ​​corresponding to OUT1 and OUT2 are OUT_HASH1 and OUT_HASH2; the transaction receivers in IN1 and IN2 are equivalent to the public key X corresponding to the private key x; Merkel proves that P1 and P2 have a given hash root Valid proof of the merkel tree containing IN1 and IN2; the number of IN1 and IN2 is equal to OUT1, the sum of OUT2 plus the delta value; hash (IN1, x) is equal to NULLIFIER1; hash (IN2, x) is equal to NULLIFIE2R.

# Transaction Fees

Private transactions prohibit the establishment of a connection between the newly created UTXO and the UTXO that was used as transaction input. However, for any transaction that will be recorded on the NEAR chain, the sender of the transaction must pay the gas fee. It is for this reason that there must be a certain number of NEAR tokens in the issuer’s account. The account may not know some means to obtain some NEAR tokens, thus creating some kind of connection between the two UTXOs mentioned above, and the purpose of private transactions will be greatly frustrated.

# future development

The model described above is already a transaction pool that can fully satisfy private transactions. Next, the author will briefly describe how to improve the security or usability of the transaction pool from several aspects.

## Pay

In the process of describing the above transaction, the author mentioned that when Alice quietly issued the token to Bob, he also shared the newly created UTXO with the other party. The realization of this process requires Alice and Bob to communicate off-chain, which we do not want to see. To solve this problem, we can extend the transaction pool to store all UTXOs encrypted with the public key of the transaction receiver. When Alice transfers the assets to Bob and creates two new UTXOs, Bob acts as the receiver and his public key will be used by Alice to encrypt UTXO.

## Decoupling signature and proof

When Alice creates a transaction, she needs to use her private key information to design a complex certificate. Therefore, the machine that calculates the certificate needs to obtain her private key, which we do not want to see. In general, private keys are best stored in some external hardware devices. The functions of this type of hardware are usually relatively simple. For example, some products only have the function of message signature. For this kind of hardware, the proof of computing knowledge is usually outside their function.

• It is known that there are four UTXOs IN1, IN2, OUT1, OUT2, two Merkel proofs P1 and P2, a decryption key d and a signature s.
• The hash values ​​corresponding to OUT1 and OUT2 are OUT_HASH1 and OUT_HASH2; the receivers in IN1 and IN2 are equivalent to the public key X corresponding to d; Merkel proves that P1 and P2 are the Merkel tree of the given hash root and contain IN1 , Valid proof of IN2; the sum of IN1 and IN2 is equal to the sum of OUT1 and OUT2; hash (IN1, d) is equal to NULLIFIER1; hash (IN2, d) is equal to NULLIFIER2, s is message (IN1, IN2, OUT1, OUT2 ) Signature and is valid for d.

## Support more tokens

Private transactions are not limited to NEAR tokens. Developers only need to make minor adjustments so that the trading pool can support any token issued on the NEAR platform. The specific implementation is not repeated here.

# Conclusion

In addition to working with NEAR, ZeroPool is also building a private transaction function for Ethereum. At present, the funds required for team development mainly come from the community, and enthusiastic readers can support them on Gitcoin.

--

--