diff --git a/README.md b/README.md index 33494d582..f7e31c053 100644 --- a/README.md +++ b/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 | diff --git a/neps/nep-0460.md b/neps/nep-0460.md new file mode 100644 index 000000000..a11065acc --- /dev/null +++ b/neps/nep-0460.md @@ -0,0 +1,100 @@ +--- +NEP: 0460 +Title: Zero Gas Limit +Author: Anton Puhach , Aleksandr Logunov +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/).