NEP-460: Zero gas limit

README.md

@@ -26,6 +26,7 @@ Changes to the protocol specification and standards are called NEAR Enhancement
 |[0297](https://github.com/near/NEPs/blob/master/neps/nep-0297.md)   | Events Standard | @telezhnaya | Final |
 |[0330](https://github.com/near/NEPs/blob/master/neps/nep-0330.md)   | Source Metadata | @BenKurrek | Review |
 |[0366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md)   | Meta Transactions | @ilblackdragon @e-uleyskiy @fadeevab | Draft |
+|[0460](https://github.com/near/NEPs/blob/master/neps/nep-0460.md)   | Zero Gas Limit | @pugachag @Longarithm | Draft |
 
 
 

neps/nep-0460.md

@@ -0,0 +1,100 @@
+---
+NEP: 0460
+Title: Zero Gas Limit
+Author: Anton Puhach <[email protected]>, Aleksandr Logunov <[email protected]>
+DiscussionsTo: https://github.com/nearprotocol/neps/pull/0460
+Status: Draft
+Type: Standards Track
+Category: Runtime
+Created: 09-Feb-2023
+---
+
+## Summary
+
+The main idea of this proposal is to start producing empty chunks if the blockchain is not able to reach consensus for the last `X` blocks.
+This can be achieved by setting gas limit for these chunks to `0`, hence the name of this NEP.
+
+In particular we want to set shard chunk header `gas_limit` field to `0` if the difference between `height_created` and the height of the last final block is greater than `X`.
+
+## Motivation
+
+Primary motivation behind this proposal is to limit [Flat Storage](https://github.com/near/NEPs/blob/master/neps/nep-0399.md) memory required for `FlatStateDelta` (FSD).
+We store all state changes after the last final block as FSD and we have to store those in RAM in order to guarantee fast access.
+Currently we can have arbitrarily long forks since Doomslug consensus doesn't limit the distance between chain head and the last final block.
+This can potentially result in neard running out of memory for storing FSD.
+This proposal solves the issue since empty chunk doesn't result in any state changes, so FSD for such chunk is also empty hence it doesn't require any memory.
+
+Another reason to have this is to promote faster consensus. Not having any final block for `X` blocks means that the chain is in a problematic state.
+Forcing chunk producers to produce empty blocks reduces load on the network and could help to reach consensus faster.
+
+## Rationale and alternatives
+
+One alternative was to design Flat Storage so that it can handle long forks.
+We tried storing only a subset of FSD in memory and reading the rest from disk.
+Unfortunately performance overhead of such approach was not acceptable.
+TODO Alex: maybe add more details here?
+
+It was also considered to use distance to the last final block instead of height difference.
+This was rejected because we can still have an unbounded number of short forks which could causes the same memory issues for FSD.
+
+## *WIP* Specification
+
+Explain the proposal as if it was already implemented and you were teaching it to another developer. That generally means:
+
+- Introducing new named concepts.
+- Explaining the feature largely in terms of examples.
+- If the feature introduces new abstractions, explaining how users and/or developers should _think_ about it;
+- If applicable, describe the differences between the existing functionality.
+
+For user-facing NEPs, this section should focus on user stories.
+
+## Reference Implementation (Required for Protocol Working Group proposals, optional for other categories)
+
+This is the technical portion of the NEP. Explain the design in sufficient detail that:
+
+- Its interaction with other features is clear.
+- Where possible, include a `Minimum Viable Interface` subsection expressing the required behavior and types in a target Near Contract language. (ie. traits and structs for rust, interfaces and classes for javascript, function signatures and structs for c, etc.)
+- It is reasonably clear how the feature would be implemented.
+- Corner cases are dissected by example.
+
+The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
+
+## Security Implications (Optional)
+
+If there are security concerns concerning the NEP, those concerns should be explicitly written out to make sure reviewers of the NEP are aware of them.
+
+## Drawbacks (Optional)
+
+Why should we **not** do this?
+
+## Unresolved Issues (Optional)
+
+- What parts of the design do you expect to resolve through the NEP process before this gets merged?
+- What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
+- What related issues do you consider out of scope for this NEP that could be addressed in the future independently of the solution that comes out of this NEP?
+
+## Future possibilities
+
+Think about what the natural extension and evolution of your proposal would
+be and how it would affect the project as a whole in a holistic
+way. Try to use this section as a tool to more fully consider all possible
+interactions with the project in your proposal.
+Also, consider how all fits into the roadmap for the project
+and of the relevant sub-team.
+
+This is also a good place to "dump ideas"; if they are out of scope for the
+NEP you are writing but otherwise related.
+
+If you have tried and cannot think of any future possibilities,
+you may simply state that you cannot think of anything.
+
+Note that having something written down in the future-possibilities section
+is not a reason to accept the current or a future NEP. Such notes should be
+in the section on motivation or rationale in this or subsequent NEPs.
+The section merely provides additional information.
+
+## Copyright
+
+[copyright]: #copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).