Notes
- A Note represents an Anoma resource in Taiga.
- Note Operations
- Creation: Creating a note means computing its commitment (a hash), and adding it to a global merkle tree of commitments.
- Transfer: Invalidating a note means revealing its nullifier, a secret value bound to the note. Note ownership is determined by knowledge of the nullifier plus arbitrary logic in a VP associated with the note.
- The global state is a hashset of note nullifiers and a commitment tree.
- Whoever knows the nullifier key, can compute the note's nullifier and spend the note.
- The notes are distributed in an encrypted form, and only the owner knows the decryption key. To prove properties of the notes (e.g. ownership) without revealing the notes, we use ZK proofs.
- Notes are never deleted from the note commitment tree.
- Some notes in Taiga can be dummy, meaning that unlike "normal" notes, the merkle path isn't checked for them.
Transactions
- Every partial transaction consists of exactly two input notes and two output notes.
- Output notes are crafted by the creator of the partial transaction.
- If a transaction gets executed, its inputs notes are invalidated, and its output notes are "created" (added to the commitment tree). We can use "ephemeral" notes to fill the empty slots.
- Note: this is how settlement between two or more Zones should be performed.
- Considered valid if all programs (VPs) associated with the notes comprising it are valid
- Question: can we use a flexible number of i/o notes? vs chaining multiple transactions
- It's valid if:
- all contained partial transactions are valid; and
- the transaction is balanced
Applications
- Application states are stored in notes. One application can have notes of multiple types, all of which are derived using the application address
- Each application has a unique application identifier that we call an address. The application address is derived from its application VP.
- The application a note belongs to is indicated by the note's type.
- The application VP of each application is hidden (applications are shielded)
Partial transactions
- We call a partial transaction a state transition for which all VPs evaluate to True, but the state transition is unbalanced.
Circuits
-
Action Circuit. Ensures that the proposed state transitions follow the Taiga rules.
Check the old state (spent notes):
- the note existed before (can you spend a note that doesn't exist?),
- the note haven't been spent yet,
- the spender has a right to spend it (do you own the note?),
- and that the application the note belongs to approves the action (sure there is some application approves the check, but is it the one the note belongs to?).
Check the new state (created notes):
- the correct application approves it (same check as for spent notes)
- and the note commitment is derived correctly (the thing that makes everyone to know that the note exists must indeed represent the note)
- if the note is encrypted, check the encryption correctness (will the owner be able to decrypt it?)
-
Validity Predicate. A piece of code defined by an application that authorizes transactions the application is involved in. Every VP is called once per transaction to validate the state transition.
-
Hierarchical VP structure
(Intents are expressed as userVPs)
- A transaction that changes the state of two applications has to be:
- checked against the Taiga rules by the Action circuit
- checked against the VP of the first application
- checked against the VP of the second application
Note that this is how we could model partial transaction solving.