Token interfaces and standard-ish

[LHerskind]

Currently we have a bunch of tokens that are used in tests here and there, but they are following different interfaces even for functions such as transfers and the like.

We should try outlining a possible variation of token standards such that we can more easily extend on these and have an expectation of interfaces for contracts that work with multiple tokens such as uniswap or the like.

Generally, we should also consider, if we want it to part of such a token standard to do bridging, or if it is more useful to have that separate since it is not strictly needed inside the contract itself and increase the attack surface for tokens as they now also have to handle the bridging logic and failure cases (if bridge can freely mint tokens might be of similar end).

The designs should take into account decisions made in regard to something like EIP-1271 as mentioned in https://discourse.aztec.network/t/account-guardians-eip1271-and-recursive-proofs/675

Dependencies

Preview Give feedback

1. EIP-1271 like functionality #1913
   A-internal-devex T-feature-request +2
   
2. Update selector computation #1990
   A-internal-devex T-bug +2
   

---

Proposal Idea

My thinking is that a minimal token that is native to the Aztec network should support the following functions.

contract Token {
  #[aztec(private)]
  fn transfer_private(from: Field, to: Field, value: Field) -> Field;

  #[aztec(public)]
  fn transfer_public(from: Field, to: Field, value: Field) -> Field;

  #[aztec(public)]
  fn shield(from: Field, amount: Field, secret_hash: Field) -> Field;
  
  #[aztec(private)]
  fn redeem_shield(to: Field, amount: Field, secret: Field) -> Field;
  
  #[aztec(private)]
  fn unshield(from: Field, to: Field, amount: Field) -> Field;

  // Unconstrained functions
  fn total_supply() -> Field;
  fn balance_of_public(address: Field) -> Field;
  fn balance_of_private(address: Field) -> Field;
}

To bridge the asset between Ethereum and Aztec, one can use a separate Bridge contract which is connected to Ethereum using a portal.

contract Bridge {
  #[aztec(public)]
  fn claim_private(msg_key: Field, secret: Field, canceller: Field, to: Field, amount: Field) -> Field;
  
  #[aztec(public)]
  fn claim_public(msg_key: Field, secret: Field, canceller: Field, to: Field, amount: Field) -> Field;
  
  #[aztec(private)]
  fn exit_private(from: Field, toOnL1: Field, amount: Field, callerOnL1: Field) -> Field;

  #[aztec(public)]
  fn exit_public(from: Field, toOnL1: Field, amount: Field, callerOnL1: Field) -> Field;
}

No approvals

The above have neither approvals in private or public. In both cases, we could use the is_valid family of functions that we are exploring with #1913. This would give a similar from for builders to use private and public, and we don't need any lingering approvals 👀.

In private the is_valid can use an oracle to fetch a signature or whatever required, while it for public can read storage values written to earlier. We cannot use the oracle method in public since it is not executed at the device of the user.

Something that I find interesting, is that if "approvals" are done this way, it is possible for a user to revoke all approvals at once updating one storage slot in the account contract. Also possible to sandwich a defi interaction with a set and unset call to update this approval storage, that way only as part of his transaction is there an approval.