Create new ARC20 spec

[vicsn]

This ARC introduces a design for minimal Fungible Tokens just like ERC20. It allows for transferring tokens and approving programs to transfer tokens on your behalf.

A big thank you to Valentin Seehausen, Evan Marshall, FullTimeMike and authors of the previous two ARC20 specs Ghostant-1017 and EdVeralli.

Discussion link: #42

[r001]

Let's not use the outdated approach of approve() and transfer_from(). The probem with this is that this is a two step procedure, while it is possible to do it in one step like ERC-2612 using permit().

[asharma13524]

Let's not use the outdated approach of approve() and transfer_from(). The probem with this is that this is a two step procedure, while it is possible to do it in one step like ERC-2612 using permit().

Agree with r001. Would also second the importance of being able to transfer tokens into smart contracts, which I believe is part of r001's wip proposal.

[vicsn]

Hi @r001 & @asharma13524, thank you for the thoughts! I had some discussions about this with the people mentioned at the top of this PR and almost ended up in a flamewar. I decided to pursue the ERC20 route for now because it is well known, and it makes sense to call it ARC20 if it looks like ERC20. Also note that due to the nature of the batch zero knowledge proofs on Aleo, it should be possible in the near-term to execute both approve and transfer_from for effectively the price of a single execution.

More proposals like ERC-2612 are very much welcome, maybe it will have merit to name it ARC-2612 as well!

[r001]

Also note that due to the nature of the batch zero knowledge proofs on Aleo, it should be possible in the near-term to execute both approve and transfer_from for effectively the price of a single execution.

I don't want to push things hard, but I forgot to mention that approve() takes considerably more system resources during execution than offline signature method:

1. Takes additional system resources to call approve() which in turn updates approvals mapping. While all this is not necessary by applying offline signatures.
2. Makes the codebase unnecessarily more difficult by having approve() transition and approvals mapping we could spare 47 lines of code and only have to add the following to verify signature:

    cast r2 r0 r1 r3 into r5 as transfer_from;
    hash.bhp256 r5 into r6 as field;
    sign.verify r4 r2 r6 into r7;
    assert.eq r7 true;

(https://github.com/r001/arc20_0001/blob/main/reference/main.aleo#L47-L51)
and this two lines to check for block height of signature validity:

    lt block.height r3 into r4;
    assert.eq r4 true;
    

(https://github.com/r001/arc20_0001/blob/main/reference/main.aleo#L60-L61)
The whole concept of applying offline signatures is described here.
The code containing the full implementation is here.

[Zack-Xb]

@vicsn @evanmarshall Do you think join and split functions should be included in the ARC20 standard ? As I can see they are currently not.

[stephensj2]

You might want to consider an update to the unapprove logic. As it stands, if someone wants to unapprove the entire balance of another user, they have to specify the exact amount the user is currently approved for. This could cause some some annoying usability issues as it creates a race condition on the current approval. Instead, if an amount greater than the current approval is specified, the approval should just be reduced to zero (rather than reverting).