arc_0020

[EdVeralli]

Implementation of the 6 mandatory rules and 3 optional rules in Leo Programming Language so that they can be invoked in a Smart contract.

[evanmarshall]

Honestly, I don't think this is ready to merge & much of the implementation in the repo is missing / mocked. Please see this PR & this file specifically for how I believe the token program should be implemented.

Critical problems:

• There needs to be a public version of transfer with an accompanying transfer_public_to_private & transfer_private_to_public & combine_token_records. Most of the functionality of using tokens in other programs won't work without public state. This requires use of a mapping.
• transfer_from only works with a mapping and should be dependent on the implementation of self.parent.
• balance_of doesn't make sense without a mapping and would only be able to show the public balance of an account. It shouldn't be able to somehow know how much each account is holding privately in records.
• You don't have any mint functions or anyway to initialize a balance on the deploying user. Aleo doesn't have an equivalent of constructor in Solidity. This should probably be another ARC.

I also don't think the reference implementation should be on Leo. It should probably be in Aleo until Leo catches up with feature completeness.

Thank you for getting the ball rolling on this standard.

[EdVeralli]

Hi Evan, thanks for your comments. This is a first iteration. As the platform progresses I plan to continue improving these functions.

[evanmarshall]

I think the point of these ARCs is to create the specification, not the implementation. Once accepted, a specification shouldn't change. I suggest that you create ARCs necessary for the features to create the finalized version of this one. It's good to start a discussion early but we shouldn't merge ARCs prematurely, especially when we know they'd have to change.

[fulltimemike]

Evan makes good points, and I have a few to add too:

ERC-20 started with core functions that had to be agreed on, and then was expanded to add mint/burn/capped/pausable tokens. The ARC-20 should likely have more core functions than the ERC-20, because we need to make a distinction between private transfers and public transfers. There are certain functions in the ERC-20 that we may not choose to follow exactly, like the balance_of function. In order to implement balance_of exactly like the ERC-20 standard, all users' balances would be public which would remove privacy from the ARC-20 token entirely.

I also don't think Aleo supports what is necessary to make a full ERC-20-like Aleo token yet. The features I think we'd ideally need to have before we can fully debate ARC-20's standard and implementation are:

• reading from public state
• accessing the parent caller of the token contract (this is necessary in the case where a contract has been approved to spend tokens on a user's behalf)
• storing interfaces in mappings (maybe not a necessity)
• storing program-level variables (not a necessity, as we can allocate a mapping for a single value, so we can at least define the interface)
• supporting strings (unless we store the name of a token encoded as an array of integers, but it's hard to define an interface that returns a type that is not yet supported)
• supporting events

This implementation makes some of those decisions implicit, but taking a step back, I think Aleo devs need to agree on some important points:

• Should we follow the ERC-20 standard exactly, or change it to match with a privacy-first mindset? E.g. perhaps the total_supply should be public, but balance_of only applies to public balances for users.
• Events are also a part of the ERC-20 standard but not yet supported in Aleo. What should the events be for the ARC-20? Privately transferring tokens (or creating approvals) and then emitting an event broadcasting the transfer's information cancel out any privacy.
• Approvals could generate a record for the approved party, which could be spent at some point, but the approver's token allotment would need to be stored in a mapping so that the approved party could spend them. Should the approved party's address also be added to the mapping, or should that be stored privately in the record?