Dear friends of NEAR Protocol,
Stability of our blockchain is crucial. The protocol team at Pagoda, which I am a part of, is constantly working on improvements to keep up with the ecosystem growth and new use cases, without compromising stability. Virtually all this work is done in public.
However, it happened in the past that we surfaced corner cases for which nearcore is too slow to keep up with the regular block production time. This means we are undercharging certain transactions, or in other words, the protocol gas parameters are too low. These types of issues must be treated confidentially until fixed, or we risk exploitation.
I propose a solution that translates undercharging issues from stability risks to economical inefficiencies. Please read the proposal below if you find the time and let me know what you think about this strategy.
Gas Weight Proposal
Today, gas has two somewhat orthogonal roles.
Gas is money. It is used to avoid spam by charging users.
Gas is CPU time. It defines how many transactions fit in a chunk so that validators can apply it within a second.
The idea is to decouple these two by introducing gas weights. Each gas parameter still has a gas cost that determines what users have to pay. But when filling a chunk with transactions, each parameter is multiplied with its gas weight to compute the expected CPU time.
The gas weight can be thought of as an undercharging factor. If a parameter is 1.5 times too low to guarantee stability, the gas weight is 1.5. A chunk will be full 1.5 times faster when gas for this parameter is burned. This deterministically throttles the throughput to match what validators can actually handle.
Ideally, all weights should always be 1. But when we discover undercharging issues, we can set a larger weight. (This would require a protocol upgrade.) The stability concern is then resolved as soon as the weight is active.
Questions that Nobody Asked Yet
Why not just increase the gas cost?
Because that would break contracts that rely on current gas costs. It can also steeply increase operating costs for the most active users of the blockchain. I believe the protocol must serve its users and not the other way around. Therefore, increasing gas costs without prior consent by the affected parties can only be considered in absolute emergency scenarios.
Isn’t it problematic to increase gas weights?
Gas weights above 1 would only be a temporary solution. Whenever we have a gas weight > 1, we as the community can discuss this publicly and find a solution to the specific problem together.
In the best case, we find technical optimizations that allow us to reset the gas weight to 1 without increasing costs.
In other cases, the only solution is to increase the gas parameter. But the dApp developers who are affected by this change should have a chance to voice their opinion, suggest alternatives, and implement necessary changes before the gas cost is increased.
What are past examples of undercharging?
We used to undercharge contract deployment. The responsible team has implemented a number of optimizations but a gas increase was still necessary. Meta-pool and Sputnik-DAO were affected by this change, among others. Finding all affected parties and reaching out to them before implementing the change took us more effort than implementing the gas weight proposal would take.
We can also think about gas weights smaller than 1. For example, if we want to charge gas instead of token balance for extra storage bytes, it would make sense to set the gas weight = 0 for the part that covers on-chain storage. Otherwise, the throughput would be throttled unnecessarily.
A further option would be to change gas weights dynamically without a protocol upgrade when block production has become too slow. This would be a catch-all, self-healing solution that requires zero intervention from anyone. The network would simply throttle throughput when block time remains too high for long enough.
Call for Action
Please let us know if you are for or against this change. This proposal is not tied to any specific feature or project, yet. If nobody cares about this, we will simply drop it and focus on other issues. (There is always plenty of high-priority work.)
But if enough people want this, I can try to get this prioritized within Pagoda and actually work on it.