anoma / taiga

A framework for generalized shielded state transitions
https://anoma.net
GNU General Public License v3.0
144 stars 24 forks source link

Implement new address format #3

Open ghost opened 2 years ago

ghost commented 2 years ago

Addresses now must commit to VPs, so we must distinguish between old-style public key addresses (which we are also keeping, but only have meaning inside of VPs) and new-style VP addresses.

There is a special case to handle of mutually-self-referential addresses. This does not appear to require any protocol level or address format changes, but rather is a VP implementation task (#2)

ghost commented 2 years ago

Each address in Taiga is used in two places, spending:

  1. The address is contained in each Note commitment (either as a user, or token, address) which commits to at least the spending VP.
  2. The address is used by a transaction builder to create Notes with that user or token address by proving that address's receiving VP.

For example, suppose Alice builds a transaction that creates Notes that belong to Bob. These new notes contain Bob's address (and the token address). Alice also needs to prove Bob's receiving VP. So Alice must know:

  1. A hiding commitment to Bob's spending VP, to put in the new notes
  2. Actual knowledge of Bob's receiving VP circuit, to authorize the creation of the new notes

Therefore the desired requirements for the address format are (roughly):

  1. The address includes a binding commitment to the sending VP, nullifier key, and receiving VP.
  2. The receiving VP commitment can be opened separately from the sending VP (and nullifier key). This is so that the Alice can send notes to Bob's address (using Bob's receiving VP) while Bob's sending VP remains hidden from Alice.
  3. The address must include enough details so the sender can prove the receiving VP (this may make the address extremely large)
  4. The default receive VP cases (e.g. receive all-allowed) should have short addresses, probably special-cased. This might require a set of receive VPs built into the wallet.
  5. The addresses must be easily re-randomizable for unlinkability between addresses with the same spending VP. Since the receiving VP must be known to the sender, unlinkability must be at the transaction level.
  6. Support for self-referential and mutually-referential addresses. This is nontrivial, but mostly necessary, because a VP may transfer assets temporarily to another VP, to be returned later.
  7. Only the owner of the sending VP can derive new addresses with this sending VP

This last property may not be possible to achieve (and is not achieved by the current design). The sender may substitute any receiving VP they want and construct a new address with the existing spending VP, and the new receiving VP. So receiving VPs are essentially useless currently.

XuyangSong commented 1 year ago

Some above descriptions and tasks are done, and some need to be updated. But we might still need the new address format design. The address-relative fields are nullifier_key_commitment, app_data_dynamic, viewing key(note encryption), and other potential data. #132 #123