Remove gas from NEAR Protocol UX

[jakmeier]

I have spent more than a year understanding all the intricate details of gas in NEAR Protocol. I have seen both smart contract developers and protocol developers stumbling over these complicated details many, many times. Both are concerned with avoiding contracts from running out of gas in corner cases and this slows down the productivity of both groups a great deal.

Finally, I came to the conclusion that we would be better off removing gas all together from Near Protocol. (edit: or at least hide it from the user)

I know, it's a wild idea. But let me explain. And please, hit me with all critical thoughts and comments as to why this doesn't work!

Suggestion

In one sentence: Pay in $NEAR instead of gas and only limit the execution cost if the user explicitly wants it to be limited.

User view: Just drop the --gas argument. Actual costs in $NEAR stay the same. (Optional: users can put e.g. --near-limit 0.1 if they want to make sure less than 0.1 $NEAR is spent on execution fees.)

Smart contract developer view: Instead of specifying the gas amount per cross function call, specify the max number of allowed hops following that call. (hop = cross contract call)

Protocol developer view: Transactions are paid for in NEAR instead of in gas. The prepaid cost for a receipt is num_allowed_hops * 0.03 $NEAR. (Equivalent to 300Tgas per receipt.) Refunds happen the same way as today, hence users get all unspent tokens back.
Chunks can still be filled as they are today, the numbers just change from gas to $NEAR.

What are benefits of removing gas?

• Users don't have to think about gas ever.
• Developers don't have to estimate gas usage.
• The protocol becomes simpler. (No dynamic gas price adjustments, no pessimistic gas pricing, no implicit limits based on gas)
• Congestion problem could be solved with per shard pricing, something that the current gas model doesn't allow without major changes to how receipts work.
• No more artificial limit to transaction size at 300 Tgas. (But individual receipts will still be limited by 300 Tgas.)

Hold on, why can we remove gas? Surely it is there for a reason?

Gas serves two main purposes but does a really bad job at both IMO.

1. Fair market evaluation of limited chunk space
2. Deterministically fill a chunk with receipts

For the first point, the gas price is virtually always at the bottom. Users and smart contracts also don't have the tools to adjust their behavior should the price increase. As a result, a cap was put in place 2 years ago to protect users from this incomplete mechanism. (#4302)
With that, I would argue, gas doesn't actually solve point 1. But that's okay because the truth is we don't need dynamic pricing at all, at least at the current usage. Removing dynamic pricing will clear this up and allow a proper solution to emerge that works outside the constraint of gas. (Maybe a per shard cost multiplier? Sorry I'm going off-topic...)

For the second point, we in the protocol team are constantly fighting theoretical undercharging problems for maliciously crafted receipts. In contrast, on mainnet we find that the average case is often overcharged by 10x. This leads to heavy under utilization of the validator's hardware.

My proposal doesn't improve or hurt this second point. It just rephrases it to $NEAR instead of gas. And with NEP-455 we already plan to separate gas costs from chunk filling, so this shouldn't be an issue.

---

Gas also has a number of secondary functions, all of which don't really need gas. But as of today, they happen to be (half-way) solved with gas and we have to take it into consideration when removing gas.

3. Gas is used to prepay for execution costs. This is a counter measure to DoS attacks, supposedly making them expensive. (Today you have to pay 1N to clog one shard for 10 blocks. Dynamic gas pricing doesn't actually work against clogging a single shard. But let's say we somehow fixed that, then it would be 20N for 10 blocks. Note that we can achieve the same, in fact easier, without going through the extra step of gas.)
4. Gas limits the size of each receipt, making sure at least 4 receipts can fit in a chunk. We can keep using the same limits and keep calling it gas, it just won't be visible to the users.
5. Gas limits the sum of all receipts that belong to the same transaction. We can remove this limit when we remove gas.
6. Gas limits the number of hops, in other words how deep a cross contract call chain can go. (somewhere around 64 hops) We can make this a hard limit and make everybody's life easier.

Feedback

There are almost certainly things I missed. But if we can remove gas, I think this would propel usability and speed up protocol development tremendously! So please, leave some feedback if you have any thoughts on this at all.

[Longarithm]

Side thought: we can try to adjust transaction costs to NEAR market price (using ref.finance contract?), so that block/chunk producers receive fair compensation for executing them. Like, if NEAR grows 2x, current "gas price" should decrease 2x and vice versa. I remember a concern that chunk producers are not profitable.

[Ekleog-NEAR]

I think the idea is awesome, but it would not actually remove gas from the NEAR protocol. By this I mean that the alternative idea of a per shard cost multiplier would imply a conversion between the "$NEAR" unit and the "execution cost" unit. And I think it makes sense that we keep these two units separate, with $NEAR being one and gas being the other; as it helps mentally distinguish the two concepts.

However, the way I understand this idea, it says that we should change the time at which we convert between $NEAR and gas. And I’m 100% for it. If we did not actually prepay for gas with the pessimistic gas pricing and everything; and instead just had each gas cost be converted to the $NEAR cost as time goes… well, then I think we would get the same benefits you mention, without losing the "mentally separate two different units" benefits of having a "gas" unit. And only protocol developers would ever have to care about gas itself in practice; for other people it’d just be a variable that’d appear inside the cost computation formulas.

(The only exception would be for smart contract execution that’d still need to know how much gas is available ahead of time for optimization reasons, because we don’t want to deal with multiplication every time we charge for gas; but so long as the conversion rate stays linear in each individual block, we can certainly just convert the remaining $NEAR limit to a gas limit and then do the conversion at the end of execution like for other actions)

[jakmeier]

but it would not actually remove gas from the NEAR protocol

Yeah that's fair. From a user perspective, I'd argue gas is removed but the title is misleading. I updated the title to reflect that we only remove it from the user experience.

And yes, I agree with your analysis, it's mostly about the time at which we do the conversion. We can keep a separate unit we might want to call gas. But it's now an implementation detail that only protocol devs and maybe a fraction of contract developers need to care. For everyone else, there is just a fee measured in tokens that will be subtracted from their account.

Another reason why I want to frame it as "removing gas" because I also want to get rid of all the ideas and misunderstandings already associated with gas. Most importantly, the current model for dynamic gas pricing does more harm than good IMO, so we would better remove it in a first step and consider in a second step if we want to add something better (per-shard) again later.

[akhi3030]

Given my OS background, I like to think of everything in those terms. In my mind, the NEAR network is a single OS and smart contracts are processes running on it competing for the shared resources. In such a system, we also need the processes (aka smart contracts) to pay for the resources that they are using.

To make things simpler, we want to have a single currency for all the resources and we want to have prices fixed (or relatively stable) in terms of this currency. This is one of the main purpose that I see gas serving. Gas is a single currency that is used to pay for resources and the fees are relatively stable i.e. change rarely. As a smart contract developer, this allows me to figure out a number of things:

• I can look at the gas fees of different resources (or host functions) and compare them to see which one is cheaper, etc.
• If I come up with two different ways of implementing a functionality and come up with a way of estimating their gas costs; I can figure out which one is using less resources and is cheaper, etc.

First off, is my understanding above relatively correct?

While I love your idea of removing the various complexities surrounding gas that you proposed above. I would like to understand how this functionality will be fulfilled.

[jakmeier]

Yes, what you write makes sense to me.

Developers could keep using their workflow and just look at tokens instead of gas numbers. I believe they either run it locally in a nearcore sandbox, or submit it testnet. Both of them provide them a gas profile. We could make it a token profile. (Or we choose to keep calling it gas and only change the assumptions around how gas works. See Léo's comment.)

[akhi3030]

Léo and my post raced with each other. Now that I understand the proposal better, I agree that this is not a concern anymore.

[bowenwang1996]

It would be really nice if we can get rid of the concept of gas outside of the implementation! @jakmeier the idea you proposed was considered a while ago (in the ancient times before mainnet launched). The main problem is that there is no guarantee that a callback would succeed (because it adds one more hop) and a malicious contract can potentially change its implementation to trick a user to lose money in that way (i.e, running out of hops and end up in an inconsistent state because a callback cannot be executed). That said, there is potentially a way to get around that problem, but we need to think more carefully to ensure the security of smart contracts are not compromised.

[bowenwang1996]

Let's first agree on what our plan is for the congestion problem. If we decide to burn all prepaid gas then we cannot just assume 1 hop = 300Tgas

[akhi3030]

Sounds good!

[jakmeier]

Yes, this clearly has dependencies to the congestion problem. I think we should consider them together.

While on that topic, knowing the exact number of hops each receipt is allowed to produce can also be advantageous to solve the unbounded queue problem. Starting execution of a receipt that cannot make further cross contract calls will definitely not require extra output buffer space, so applying it won't increase congestion. Whereas a receipt with 100 hops might produce more receipts than other shards can accept / we can handle in our local output buffers. Hence we could apply backward-pressure by not starting to apply the 100-hops-receipt until we know we can handle its output.

[bowenwang1996]

@jakmeier do you intend to keep the current behavior of refunding unused gas? I am worried that it would lead to a less efficient system where calls with a lot of hops and consumes little gas in each hop can cause artificial congestion

[jakmeier]

Yes, refunds would stay the same. But I don't understand how this makes our system less efficient than today. Or are you saying it's less efficient under the assumption of some other changes to solve the congestion problem?

At least in the current system, the number of refunds shouldn't change. We already send pessimistic gas price refunds on every hop. And whether we have attached gas = 300Tgas or 1Tgas doesn't affect the decision to include a function call gets in a chunk. So I think the number of receipts and how we execute them wouldn't change at all.

[walnut-the-cat]

Thanks for the great proposal and brainstorming. Without talking about technical details (mostly because I am not familiar enough), similar to what you did, I want to take a step back and think about what are the outstanding issues I see.

• For end users: they have to understand the concept of Gas when it does not mean too much to them. They don't understand why they have to pay anything (when all these things were free in Web2 world). Even if it is a service fee they have to pay to use a service, they want it to be rather given by them (fixed, predetermined, etc) so they don't have to worry about 'how much they have to pay'
• For smart contract developers: the last thing they want to worry about is execution of smart contract. They want their contract to be executed and spits out result at all time. Realistically, no developers would say 'I am okay with my contract stopping in the middle of operation because I want to save 10 cents.' As much as they want to save the cost, as long as the cost stays reasonable, the foremost thing is consistent successful execution of their contract.

From this angle, they are couple things that are not clear to me. Please note that this problems exists as of now and are not introduced by your proposal.
For end users:

• users still have to pay; but I will assume this is avoidable for now.
• Now users don't have to worry about the concept of gas which is great, but they still do not know how much they will be charged unfront. There is no estimated value provided by us (or smart contract). When it comes to money, it's always better to provide accurate data and confronting unknown fee is not great. (maybe there is some way to show estimated value?)

From contract developers:

• developers don't have to estimate gas anymore but they have to now estimate number of hops and I am not sure how much easier that is. Especially under the cross contract scenario, developers will have to do some test runs to find the number X where their contract is executed YY% of the time as of now (and it can change anytime in the future).

In this regard, I feel that the proposal is making things little better but not entirely solve the core problem.

Having said that, I believe that the lesser people(users, contract developers, protocol developers, etc) have to care about gas, the better experience it is so I am happy that we have some idea to gradually get there.

[jakmeier]

Yeah it's very much an idea meant for brainstorming and not a perfect solution.

developers don't have to estimate gas anymore but they have to now estimate number of hops and I am not sure how much easier that is.

I admit there are cases where this can be hard as well. But counting how many cross contract calls you make is something you can do with your fingers, whereas gas calculations needs a turing-complete simulation.

There are two more reasons why I like hop counting better than gas or token counting. The first, obviously, is that users no longer have to think about it. The second is that we, on the protocol level, know more about the intention of the receipts. Knowing the number of hops is much more useful for things like congestion control compared to knowing the gas attached.

There is no estimated value provided by us (or smart contract). When it comes to money, it's always better to provide accurate data and confronting unknown fee is not great. (maybe there is some way to show estimated value?)

In my proposal, we would set the maximum upper limit by default, which would be 0.3 NEAR if we assume 10 hops are enough. Most of it should be refunded, unless the contract is doing something weird. And users always have the choice to set a lower limit, that just voids the guarantees that the call can't fail during execution due to execution fee limits.

Do you think that would be good enough, or would you want a more accurate estimate?
We could probably reduce the 0.3 NEAR number further if we use a more complicated design but I was hoping that it is a small enough value for users to "risk" per smart contract transaction.

[walnut-the-cat]

Knowing the number of hops

Out of curiosity, is it possible to periodically calculate how many hops are needed per operation per contract and build some dependency graph?

[walnut-the-cat]

Do you think that would be good enough, or would you want a more accurate estimate?

I was mostly talking about the ideal case :) : ideally, it's best for users to pay 'fixed fee' or 'deterministic fee' than 'estimated fee'

[jakmeier]

Out of curiosity, is it possible to periodically calculate how many hops are needed per operation per contract and build some dependency graph?

I mean yeah, we could. But what would you do with that? It wouldn't have any guarantees at all to give correct predictions, if that's what you are aiming at.

ideally, it's best for users to pay 'fixed fee' or 'deterministic fee' than 'estimated fee'

Just to clarify:

• The proposed idea gets rid of all estimations on the user side. Users have a deterministic upper bound on fees that is pretty small.
• Users pay an exact amount. That amount is impossible to know upfront in the general case, as proven by Alan Turing in 1936
• The proposed idea also gets rid of most estimations on the developer side. Every smart contract just has to define how many hops each function requires, which is not an estimate but a hard number they can figure out by looking at their code and knowing the hops number for each cross contract call they make. The only thing they might want to estimate is how many extra hops they want to calculate in for cases where upstream contracts change their code and thereby break prior hops numbers. But this should be considered a breaking change IMO.

[jakmeier]

We had an in-person discussion about "simplifying gas" among protocol engineers at am offsite this week. Most of it was just letting people know what was already discussed. But also, @abacabadabacaba brought up some good new points. The main take away for me were:

1. Instead of introducing "hops" on the protocol, we can just remove the limit of attached gas. The SDK, or user themselves, can then attach 300Tgas * number of hops to a call, which would be equivalent to the solution that only allows sending full hops.
2. Removing the gas price and the pessimistic gas price calculations that follow from it could be a separate effort that might make sense even if we don't change anything else.