Noto nullifiers

[jimthematrix]

(should be merged after #978 )

Adding the capability to spend Noto UTXOs with nullifiers to mask the spending history.

Nullifiers

Given that the commitments for a Noto token is EIP712Hash(amount, salt, owner_address), a typical nullifier scheme would be EIP712Hash(amount, salt, owner_priv_key). However, in Noto we do not make use of ZKPs, which means when the nullifier submitted by the sender is verified by the notary, the sender can not leak its private key to the notary. As such, we design the nullifier hashing scheme differently, by using just EIP712Hash(amount, salt).

This should still preserve the main security guarantees of a nullifier:

• unique binding to the UTXO commitment: due to the uniqueness of the salt, the nullifier is guaranteed to be 1:1 bound to the UTXO commitment
• secret binding to the UTXO commitment: because the salt is only known by the sender and the receiver, no other parties are able to construct the nullifier

This design lacks the guarantee that only the owner of the UTXO commitment is able to construct the nullifier, because the sender also knows the secrets required to construct it (besides the receiver which is the owner). However, this is mitigated by the fact that the notary already checks that the sender must be the rightful owner of the input UTXO, thus completing the security requirements to make this design secure.

Onchain storage

Unlike the regular Noto contract that tracks the UTXOs in a simple map for spent status, the UTXOs in this new NotoNullifiers contract are tracked inside a Sparse Merkle Tree (SMT). This way, a transaction submitter can submit these parameters to the notary, as part of the private transaction payload, for verification:

• input UTXOs
• nullifiers
• outputUTXOs

The job of the notary is to verify that:

• the input UTXOs are included in the SMT maintained by the smart contract
  • to do this, the notary must maintain its own SMT
• the nullifiers are the proper ones corresponding to the input UTXOs
• the input UTXOs and the output UTXOs obey the spending rules (mass conservation, etc.)

Then the notary submits the following (public) parameters to the NotoNullifiers contract:

• nullifiers
• output UTXOs
• merkle tree root resulted from verifying the input UTXOs against the notary's SMT (this does NOT need to be the latest root, just needs to be one of the legitimate historical root)

The job of the smart contract is to verify that:

• the root is a legitimate historical root (validity of the input UTXOs represented by the nullifiers)
  • this check is a safety net for cases when the notary makes honest mistakes and submits transactions out of order, which would attempt to consume UTXOs that have not been produced
• the nullifiers are not seen before (prevents double spending)
• the notary certificate, which is as usual, same as when not using nullifiers

Dependencies

Sparse Merkle Tree supporting configurable hashing algos

This solution depends on a Sparse Merkle Tree that uses keccak256 hashing, rather than the Poseidon hashing as seen in the current implementation. The Poseidon hashing is used for its efficiency inside ZKP circuits, but it's much slower in EVM compared to the "native" hashing like keccak256.

Since for Noto uses we do not need to generate ZK proofs, we want to have an SMT implementation that's based on keccak256, making transaction processing much cheaper when the onchain SMT needs to be updated with new UTXOs.

This is accomplished by enhancing the implementations in Solidity (to use in the NotoNullifiers contract), typescript (to use in hardhat tests), and golang (to use in Paladin's domain implementation):

• Solidity: Enhance the SmtLib to support configurable hashing algorithm iden3/contracts#402
• typescript: Enhancement to support configurable hashing algorithms iden3/js-merkletree#53
• golang: https://github.com/LFDT-Paladin/smt (refactored out of LFDT-Paladin/zeto/go-sdk)

SMT Storage implementation using Paladin's state storage

This was originally implemented for the Zeto domain. It's now moved into a common golang package under toolkit/go/pkg/smt, to be shared by the Noto and Zeto domains.

              github.com/LFDT-Paladin/smt
            (Sparse Merkle Tree implementation)
                             |
                             |
                    toolkit/go/pkg/smt
                   (SMT storage plugin)
                             |
              --------------------------------
              |                              |
        Noto Domain                     Zeto Domain

[github-actions]

This PR is stale because it has been open 30 days with no activity.

[github-actions]

This PR is stale because it has been open 30 days with no activity.

[github-actions]

This PR is stale because it has been open 30 days with no activity.

[github-actions]

This PR is stale because it has been open 30 days with no activity.

[github-actions]

This PR is stale because it has been open 30 days with no activity.