Rework linkdrop to support more functionality and reduce required price

[ilblackdragon]

Figure out if we can now use 0.01N or something similar for access key budget here https://github.com/near/near-linkdrop/blob/master/src/lib.rs#L18

Previously it was this high due to how much transaction would prepay if it would take next 100 blocks of receipts with constant price increase. Is this still the case?

[bowenwang1996]

Is this still the case?

Yes. That part has not changed. Also it is 64 blocks instead of 100

[ilblackdragon]

Ok, so here is suggestion how to address this issue:

• we actually leave 0 allowance on the access key
• but we remove it after 1st usage always (e.g. even if it's failed)
• to make sure we can capture any call - we will need to wrap JSON parsing and other errors within functions (e.g. switch away from using near_bindgen for those functions).
• if there are errors - funds stay in the account and the key becomes invalid. To make sure funds can still be withdrawn, we will record how much each user deposited and allow them to withdraw it back via separate method.
• given contract does pay for that tx, so keep it balanced we want to charge whatever 0.001 that tx fee costs. Given cost can fluctuate based price and other parameters, it probably make sense to still have a fixed fee specified by contract. We can make it adjustable and charged on "entrance". E.g. if it's changed later - the drops added already don't get affected.

If near/NEPs#164 gets accepted and implemented, then this logic is not needed as would be able to just limit access keys to 1 usage.

Interface:

• new(owner, fee)
• get_fee()
• set_fee()
• stage_upgrade
• deploy_upgrade
• send -- initiates a send action. Even if sending only other FT/NFT tokens still need to first call send to allocate storage and add the key.
• send_ft21 -- support NEP-21 transfer_from pattern
• send_nft -- support NEP-4 transfer_from pattern
• ft_on_transfer -- suport NEP-158 pattern, still need to call send afterwards to attach the fee and potentially some $N to create account on the other side (storage). msg contains which PublicKey to attach this drop to, must already call send on it.
• claim -- only can be called once and with signer_id==current_account_id, signer_pk gets removed
• create_account_and_claim -- only can be called once and with signer_id==current_account_id, signer_pk gets removed
• on_account_created_and_claimed -- callback from create_account_and_claim
• create_account
• on_account_created
• withdraw_all -- sender can withdraw all the assets back, even if key got invalidated

Storing a lookup map of <PublicKey, Drop>
Where Drop:

struct Drop {
   /// Who initiated this drop
   sender_id: AccountId,
    /// Amount of NEAR
   amount: Balance,
   /// Balances of FT tokens.
   ft_tokens: HashMap<AccountId, Balance>,
   /// List of NFT tokens in the drop
   nft_tokens: Vec<NFTId>
}

Where NFTId is universal NFT identifier that contains both contract id and token id inside it.

[evgenykuzyakov]

but we remove it after 1st usage always (e.g. even if it's failed)

It's possible to attach low gas amount, so the call will fail and we can't remove it within the call.

Let the sender claim it back.

Alternative is to decrease the allowance from 1 NEAR to minimum required balance in gas at near BASE gas price cost. This still supports a single valid function call, or multiple invalid one.

If the call fails for some reason (or the link is lost), the original sender will be able to claim it back, so you don't need the worry about funds from being locked. This is fairly simple to implement

[ilblackdragon]

What would happen if gas price goes up? User will not be able to execute such tx until gas prices lowers back?

Claiming back by sender make sense for sure, but I don't understand how this solves the problem at hand.
Btw, for frontend for sure would be good to know amount that will be held back to attach extra to what user sends and show to user how much they receive.