Reduce the number of refund receipts

neps/nep-9999.md

@@ -0,0 +1,129 @@
+---
+NEP: 0
+Title: Reduce the number of gas refunds
+Authors: Evgeny Kuzyakov <ek@fastnear.com>, Bowen Wang <bowen@near.org>
+Status: New
+DiscussionsTo: /~https://github.com/nearprotocol/neps/pull/0000
+Type: Protocol
+Version: 1.0.0
+Created: 2024-03-12
+LastUpdated: 2023-03-12
+---
+
+[This is a NEP (NEAR Enhancement Proposal) template, as described in [NEP-0001](/~https://github.com/near/NEPs/blob/master/neps/nep-0001.md). Use this when creating a new NEP. The author should delete or replace all the comments or commented brackets when merging their NEP.]
+
+<!-- NEP Header Preamble
+
+Each NEP must begin with an RFC 822 style header preamble. The headers must appear in the following order:
+
+NEP: The NEP title in no more than 4-5 words.
+
+Title: NEP title
+
+Author: List of author name(s) and optional contact info. Examples FirstName LastName <satoshi@fakenews.org>, FirstName LastName (@GitHubUserName)>
+
+Status: The NEP status -- New | Approved | Deprecated.
+
+DiscussionsTo (Optional): URL of current canonical discussion thread, e.g. GitHub Pull Request link.
+
+Type: The NEP type -- Protocol | Contract Standard | Wallet Standard | DevTools Standard.
+
+Requires (Optional): NEPs may have a Requires header, indicating the NEP numbers that this NEP depends on.
+
+Replaces (Optional): A newer NEP marked with a SupercededBy header must have a Replaces header containing the number of the NEP that it rendered obsolete.
+
+SupersededBy (Optional): NEPs may also have a SupersededBy header indicating that a NEP has been rendered obsolete by a later document; the value is the number of the NEP that replaces the current document.
+
+Version: The version number. A new NEP should start with 1.0.0, and future NEP Extensions must follow Semantic Versioning.
+
+Created: The Created header records the date that the NEP was assigned a number, should be in ISO 8601 yyyy-mm-dd format, e.g. 2022-12-31.
+
+LastUpdated: The Created header records the date that the NEP was assigned a number, should be in ISO 8601 yyyy-mm-dd format, e.g. 2022-12-31.
+
+See example above -->
+
+## Summary
+
+[Gas refund](https://docs.near.org/concepts/basics/transactions/gas#attach-extra-gas-get-refunded) is a mechanism that allows users to get refunded for gas that is not used during the execution of a smart contract. Due to [pessimistic gas pricing](https://docs.near.org/concepts/basics/transactions/gas-advanced#pessimistic-gas-price-inflation), however, even transactions that do not involve function calls generate refunds because users need to pay at a high price and get refunded the difference. Gas refunds lead to nontrivial overhead in runtime and other places, which hurts the performance of the protocol. This proposal aims to reduce the number of gas refunds and prepare for future changes that completely remove gas refunds.
+
+## Motivation
+
+Refund receipts create nontrivial overhead: they need to be merklized and sent across shards. In addition, the processing of refund receipts requires additional storage reads and writes, which is not optimal for the performance of the protocol. In addition, when there is congestion, refund receipts may be delayed during execution. Whenever this happens, it requires two additional storage writes to store a gas refund receipt and two additional reads and writes when they are later processed, which incurs a significant overhead. To optimize the performance of the protocol under congestion, it is imperative that we reduce the number of refund receipts.
+
+## Specification
+
+Pessimistic gas pricing is removed as a part of this change. This means that transactions that do not involve function calls will not generate gas refund receipts as a result. For function calls, this proposal changes the gas refund to be
+```
+refund = max(0, gas_refund - 5Tgas);
+```
+per receipt. In other words, for each gas refund, there is a 5Tgas penalty that is applied. The penalty is added to gas burnt. This means that for receipts that involve gas refund less than 5Tgas, there will be no gas refunds.
+
+## Reference Implementation
+
+The protocol changes are as follows:
+* When a transaction is converted to a receipt, there is no longer a `pessmistic_gas_price` multiplier when the signer balance is deducted. Instead, the signer is charged `transaction_gas_cost * gas_price`. There is no gas refund for actions other than function calls.
+* For function calls, if X gas is attached during the execution of a receipt and Y gas is burnt, then max(0, X-Y-5Tgas) is refunded at the original gas price.
+
+## Security Implications
+
+This change may lead to less correct charging for transactions when there is congestion. However, the entire gas price mechanism needs to be rethought any ways and when only one or two shards are congested, the gas price wouldn't change so there is no difference.
+
+## Alternatives
+
+One altnerative is to completely remove gas refunds by burning all prepaid gas. This idea was [discussed](/~https://github.com/near/NEPs/issues/107) before. However, it would be a very drastic change and may very negatively damage the developer experience.
+The approach outlined in this proposal has less impact on developer and user experience and may be extended to burning all prepaid gas in the future.
+
+## Future possibilities
+
+Burning all prepaid gas is a natural extension to this proposal, which would completely get rid of gas refunds. This, however, would be a major change to the developer experience of NEAR and should be treated cautiously.
+At the very least, developers should be able to easily estimate how much gas a function within a smart contract is going to consume during execution.
+
+## Consequences
+
+[This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones. Record any concerns raised throughout the NEP discussion.]
+
+### Positive
+
+* p1
+
+### Neutral
+
+* n1
+
+### Negative
+
+* n1
+
+### Backwards Compatibility
+
+This proposal changes how gas refund works today and as a result, users may need to pay slightly more when they send a function call transaction. However, the difference is quite small (0.0005N at most).
+
+
+## Changelog
+
+[The changelog section provides historical context for how the NEP developed over time. Initial NEP submission should start with version 1.0.0, and all subsequent NEP extensions must follow [Semantic Versioning](https://semver.org/). Every version should have the benefits and concerns raised during the review. The author does not need to fill out this section for the initial draft. Instead, the assigned reviewers (Subject Matter Experts) should create the first version during the first technical review. After the final public call, the author should then finalize the last version of the decision context.]
+
+### 1.0.0 - Initial Version
+
+> Placeholder for the context about when and who approved this NEP version.
+
+#### Benefits
+
+> List of benefits filled by the Subject Matter Experts while reviewing this version:
+
+* Benefit 1
+* Benefit 2
+
+#### Concerns
+
+> Template for Subject Matter Experts review for this version:
+> Status: New | Ongoing | Resolved
+
+|   # | Concern | Resolution | Status |
+| --: | :------ | :--------- | -----: |
+|   1 |         |            |        |
+|   2 |         |            |        |
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).