Switch access key allowance to number of transactions

[ilblackdragon]

Currently access key allowance is measured in the NEAR.

This is really weird, as it doesn't really provide any guidance on how much that can be used for.

Also given a massive amount of NEAR that must be attached when transaction is getting dispatched (64x of the actual amount most of the times), this makes this allowance almost useless / prohibitive for actual protection purposes.

Not counting that if gas price increases, the allowance will start make even less sense.

Allowance really is to define how many transactions can this user issue, so why don't we switch to that? Just keep count of how many more tx can this key dispatch in the allowance field.

We will need to figure out migration process but that shouldn't be super complex (divide allowance by 50Tg * current gas price) as it's expected that if keys have non 0 allowance there should be way to reset it.

Thoughts?

[bowenwang1996]

This doesn't work well when there is congestion. Measuring allowance in number of transactions defies the change in gas price, which means that the total gas cost that can be spent (measured in NEAR) by a single access key is not bounded

[ilblackdragon]

Correct, but currently allowance is pretty much useless. In case of congestion access key in general may become useless as contracts would add the access key with hard coded allowance but users won't be able to use it at all.

[bowenwang1996]

@ilblackdragon do you think the problem would be solved if we do not do pessimistic gas pricing and burn prepaid gas instead? cc @evgenykuzyakov

[ilblackdragon]

Nope, it wouldn't really. If anything allowance should be measured in Gas at least. Then developers can control how much gas it can use. That said, given gas usage can grow and we can change some gas params - it's only marginally better.

[bowenwang1996]

Nope, it wouldn't really.

Can you elaborate on this? It seems to me that your concern is that pessimistic gas pricing means that allowance needs to be relatively large, which is suboptimal, but maybe I misunderstood what exactly your concern is.

[evgenykuzyakov]

I feel the current allowance makes sense, it means the app can consume at most 0.25 NEAR for function calls. What needs to change is a near-api-js handling of out of allowance error.

I've added this logic to berry cards front-end and also the out of prepaid gas error retrying here (that happens for AVL rebalancing): https://github.com/evgenykuzyakov/berry-hot/blob/119f8eebb719d2282e0c753bdd072363850639c2/frontend/src/pages/Home.js#L42-L61

[ilblackdragon]

What do you suggest we do in the case of https://github.com/near/near-linkdrop ?
Specifically near/near-linkdrop#12 (comment)

[evgenykuzyakov]

Well I think we should just add a way to reclaim the linkdrop by the sender. It's how amazon gift cards work. You can reclaim the gift card you've sent if until the receiver doesn't claim it.
Then we can decrease the allowance and if the allocation gets locked due to low allowance, then the owner can send a new one. Once we have a congestion issue on the network, we can figure out other options.

[ilblackdragon]

Linkdrop has a better fix now (described in the repo). But the issue here is pretty general. We are going to be using AccessKeys more as an onboarding tool. So making sure they work predictably is important.

…

On Thu, Mar 4, 2021 at 4:19 PM Evgeny Kuzyakov ***@***.***> wrote: Well I think we should just add a way to reclaim the linkdrop by the sender. It's how amazon gift cards work. You can reclaim the gift card you've sent if until the receiver doesn't claim it. Then we can decrease the allowance and if the allocation gets locked due to low allowance, then the owner can send a new one. Once we have a congestion issue on the network, we can figure out other options. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#164 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABK27WNMCGBCXBPDMYRJKLTCAPSDANCNFSM4YQJIABA> .

-- Best regards, Illia Polosukhin