ARC20 try #3

[vicsn]

Working on the previous two ARC20 proposals, please check out the README in this PR for a rationale: #41

Curious to hear your thoughts on design, test cases, etc.

[HarukaMa]

https://github.com/AleoHQ/snarkVM/issues/2139 should apply here.

For "An update to snarkVM should soon enable passing an aleo program id as program input to snarkos developer execute", as we can't dynamically call other programs (yet, hopefully), what exactly is this for? (cast program id to address?)

Also, it seems the comment doesn't match the actual code logic in approve method:

    // if approvals for approver field times spender field exists, the approved amount is increased.

I could guess what the initial design looks like, but the code is using the hash of the struct for the key instead.

[mwyatt896]

@vicsn -- sorry been pretty sick for the past week and trying to tie up loose ends for our Puzzle's coinflip game before Devconnect. Can't do a full write up right now bc of that but planning a much longer write up for after devconnect. After meeting with Felix -- he said we should drop a message here with a summary for now.

Lots of lessons learned between Puzzle's MPC & Programmable multisig work, Coinflip work and a couple other dApps we've worked on (Auction, Voting, DeFi, etc). Many warrant a much deeper discussion but need to save for later as heads down.

TLDR;
We've found 3 common patterns in our Fungible & Non-fungible Token Contracts from our work:

1. Ownership Patterns
2. Issuer Patterns
3. Auditor
   These are represented by records for our token contract having OwnerRules, Claim, Audit, Notify, IssuerRules. All token contract functions take in OwnerRules or IssuerRules -- we believe this may be a design standard that should be adopted for ARC20.

In our coinflip game, there are two players: the challenger and their opponent. A challenger will create a game with opponent by locking up funds in a multisig and hiding a coin on one of two sides. The opponent will lock up equal amount of funds in the multisig and try to guess the answer. If the opponent is right -- they get all the funds. If the opponent is wrong -- the challenge wins and gets all the funds in the multisig.

Let's briefly walk through starting a Coinflip game to see how it applies to our Puzzle token used in the game.

The challenger will kick off a game by creating a multisig with their opponent and send a fungible Puzzle token to the multisig via a transfer_stake_private.

• The transfer_stake_private function returns a Claim Record with the amount and msg.signer address to the multisig address as owner.
• The Puzzle token requires OwnerRules records as inputs for all functions. The challenge had to spend an OwnerRules in their initial token transfer to the multisig.
• The multisig works with Puzzle token because Puzzle token requires "OwnerRules" records to be spent in order to transfer. The OwnerRules for the multisig is to hold the signatures for the multisig and addresses on the multisig. For some Puzzle token functions, there is additional logic where transactions can be completed even with partial OwnerRules records such as the transfer_stake_out_private. This function also takes in a Claim Record and will consume OwnerRules even if there's not enough signatures. If the opponent doesn't respond, the challenger can withdraw their Puzzle from the multisig using this function.
• When a multisig transfer_stake_out_private happens, we are testing various "Audit records" or "Notify Records" to the counter party on the multisig to notify that stake has been removed such that their main account in the wallet can detect the change for good UX/history.

Lastly -- for the minting and usage of Puzzle token -- we are testing out various "Issuer Enforcement Rules" record patters. and "Issuer Creation Rules" record patterns.

[vicsn]

Thank you so much for all of the thoughts!

I should clarify the scope of this particular standard, namely to be very minimal. It only provides a way for everyone to agree on what it means to transfer a token - whereas concepts like minting can be added by others as they wish, or even be standardized separately.

It would be very cool if we can fit a good abstraction for multisig-based transfers in the same standard, perhaps by indeed requiring some form of OwnerRules (which can be left empty for non-multisig transfers). Or, if the differences are too big, we can also create a new standard. Do you have a link to the program you're referring to? :)

[jinqiao0423]

I think this is a very clear description of an ARC-20's functionality. I agree that some functionalities such as minting and burning can be added as author's wish well some others such as name, symbol, totalSupply (for public?) and especially decimals should be added to this standard, as it would be convinient for all users to parse and distinguish different tokens.

[pa-long]

On the othe hand I would prefer using self.parent than self.caller in functions like transfer_public, which works better especially when the direct caller is a program rather than a user address. By the way, programs should be considered able to keep token balance as well.

@jinqiao0423, from my understanding:
self.caller (from original ARC030) = self.signer (currently in snarkVM)
self.parent (from original ARC030) = self.caller (currently in snarkVM)

[jinqiao0423]

Thanks for the remind! Have updated correspondingly