Replies: 6 comments 16 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
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) |
Beta Was this translation helpful? Give feedback.
-
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:
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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.
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.
From contract developers:
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. |
Beta Was this translation helpful? Give feedback.
-
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:
|
Beta Was this translation helpful? Give feedback.
-
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?
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.
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.
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.
Beta Was this translation helpful? Give feedback.
All reactions