update

neps/nep-0536.md

@@ -20,17 +20,25 @@ Refund receipts create nontrivial overhead: they need to be merklized and sent a
 
 ## 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
+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 introduces cost of refund to be
 ```
-refund = max(0, gas_refund - 5Tgas);
+REFUND_FIXED_COST = action_receipt_creation + action_transfer + action_add_function_call_key
+refund_cost = max(REFUND_FIXED_COST, 0.05 * gas_refund);
 ```
-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.
+per receipt. The refund fixed cost includes consideration for implicit accounts (created on transfer) and refund for access key allowance, which requires an access key update. The design of refund cost is supposed to penalize developers from attaching too much gas
+and creating unnecessary refunds. Some examples:
+* If the contract wants to refund 280Tgas, burning 5% of it would be about 14Tgas, which is a significant cost and developers would be encouraged to optimize it on the frontend.
+* If refund is 100Tgas, then 5% is 5Tgas, which is still significant and discourages developers from doing so.
+* If the refund is <10Tgas (very common case for cross-contract call self-callbacks), the penalty should be just 500Ggas, which is less than the gas refund cost. So only the fixed refund cost will be charged from gas to spawn the gas refund receipt. No UX will be broken for legacy cross-contract call contracts, so long as frontend correctly estimates the required gas in worst case scenario.
+
 
 ## 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.
+* For function calls, if X gas is attached during the execution of a receipt and Y gas is burnt, then `max(0, X-Y-refund_cost)` is refunded at the original gas price where `refund_cost = max(REFUND_FIXED_COST, 0.05 * X-Y)`.
+* Tokens burnt on refund cost is counted towards tx_balance_burnt and the part over `REFUND_FIXED_COST` is not counted towards gas limit to avoid artificially limiting throughput.
+* Because refund cost is now separate, action costs do not need to account for refund and therefore should be recalculated and reduced.
 
 ## Security Implications
 
@@ -43,7 +51,7 @@ The approach outlined in this proposal has less impact on developer and user exp
 
 ## 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.
+* 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
@@ -64,8 +72,7 @@ At the very least, developers should be able to easily estimate how much gas a f
 
 ### 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).
-
+Developers may need to change the amount of gas they attach when they write client side code that interacts with smart contracts to avoid getting penalized. However, this is not too difficult to do.
 
 ## Changelog