Always producing an additional nullifier used as a tx hash

Correction: two users could create the same nullifier.

It sounds like our nullifier code that I pointed to is just an example. The [current] goal is to have “custom nullifiers” where an app circuit is responsible for defining the structure of the nullifer and the rules for who can nullify what. So, the user’s private key may not be a part of the nullifier. That is up to the app circuit.

Nullifiers will be hashed again with contract_address in the private kernel to ensure siloing between contracts (to prevent nullifier collisions between contracts).

Edit: so I guess that is relevant here and supports our usage of a TX hash and not just hash of nullifiers & commitments. I think the main issues Santiago mentions are the ability of nodes to update world state and identify which TXs got included in a block. I am still making sense of those issues and our decision.

Edit: relevant convo on custom nullifiers here

1 Like