zkopru-network / zkopru

Ethereum L2 scaling solution for private transactions using zk-SNARK and optimistic rollup.
https://zkopru.network
GNU General Public License v3.0
215 stars 28 forks source link

New UTXO & nullifier structure #34

Closed wanseob closed 3 years ago

wanseob commented 4 years ago

Is your feature request related to a problem? Please describe. The sender creates a UTXO for the recipient, and therefore the sender can track the 1st transaction after the recipient receives the UTXO.

In version(0.7.0), Zkopru computes the hash of the UTXO with

var intermediate_hash = poseidon(ether, pub_key.x, pub_key.y, salt)
var result_hash = poseidon(intemediate_hash, token_address, erc20, nft)

Describe the solution you'd like

The recipient create a zk-tx public key with the following logic and share to others.

var zk_public_key = poseidon(pub_key.x, pub_key.y, nullifier_seed)

We can generate the UTXO with following steps:

var asset_hash = poseidon(ether, token_address, erc20, nft)
var utxo_hash = poseidon(zk_public_key, asset_hash, salt)

Then finally the nullifier becomes

var nullifier = poseidon(nullifier_seed, leaf_index)

Describe alternatives you've considered MPC protocol can help this, but non-interactive way preferred.

Additional context N/A

wanseob commented 4 years ago

The solution described above increases the complexity of the system because the sender also requires the jubjub point of the recipient for the DH key exchange(the shared key is used to encrypt leaf data.) Furthermore, the wallet should manage the nullifier_seed together which means if a user only has the private key without the nullifier seed, the user loses UTXOs.

Therefore we can only modify the nullifier computation logic using the EdDSA signature just like

nullifier = hash(EdDSA, leaf_index)

This makes sense because

  1. EdDSA's signature is derived from the private key, therefore the sender cannot know unless the signer reveals it. It means the sender can infer the nullifier.
  2. EdDSA signature does not allow malleability by the specification. https://tools.ietf.org/html/rfc8032#section-8.4 Therefore, there is no possibility of double-spending caused by the signature malleability that can allow multiple nullifiers for one UTXO.

But currently, this is not sure that the current circom circuit supports the non-malleability of the EdDSA. This feature will be part of the Burrito version.

wanseob commented 3 years ago

We've decided to change the UTXO & nullifier's detail structure to follow ZCash's viewing key & spending key structure.

p = random() // spending key
n = ff(sha3(p)) // nullifier seed, viewing key
N = n*G // public nullifier seed, public viewing key
s = random() // tx sender's ephemeral key
K = s*N // shared secret key for chacha20 encryption/decryption
P = poseidon(p*G, n) // public spending key
utxo = poseidon(P, data, salt)
nullifier = poseidon(n, index)

Account shares (P, N) and store (p, n) For the effective account restoration protocol, we can derive nullifier seed n from p for example (n = ff(sha3(p))

wanseob commented 3 years ago

closed by #44