EIP-3300: Phase Out Refunds by wjmelements · Pull Request #3300 · ethereum/EIPs

wjmelements · 2021-02-27T00:31:40Z

Phase out refunds for SSTORE and SELFDESTRUCT
Reviewer @lightclient

vorot93 · 2021-02-27T18:53:29Z

GasTokens are effectively an exploit, and their authors warned that it may be fixed at core devs leisure.

It's not our fault that certain people hoarded them against this advice. And most certainly it shouldn't lead to stretching out selfdestruct phase out.

wjmelements · 2021-02-27T21:14:33Z

Use the discussions-to URL

…

On Sat, Feb 27, 2021 at 10:53 AM Artem Vorotnikov ***@***.***> wrote: GasTokens are effectively an exploit, and their authors warned that it may be fixed at core devs leisure. It's not our fault that certain people hoarded them against this advice. And most certainly it shouldn't lead to stretching out selfdestruct phase out. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3300 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGDGVJOCDYOTWPAFLGSHLDTBE5TJANCNFSM4YJKZMHA> .

MicahZoltu

Some changes required to the formatting and the metadata. My comments about improving the specification section can be dealt with sometime before Review.

EIPS/eip-3300.md

MicahZoltu · 2021-02-28T08:55:41Z

EIPS/eip-3300.md

+On the block this EIP activates, and again every 100 blocks, the gas refunds for `SELFDESTRUCT` and `SSTORE` would diminish by 1, until reaching their refund activation cost.
+When reaching their refund activation cost, refunds will be removed.
+The refund activation cost of `SSTORE` is defined to be the lowest possible opcode cost of setting a nonzero value to zero.
+The refund activation cost of `SELFDETRUCT` is defined to be the lowest possible opcode cost of `SELFDESTRUCT`.


It would be valuable to spec this out a little more clearly. Defining the refund provided for each operation as a function of block number would be the best I think. It would also be good to include details on how this interacts with the various refunds of SSTOREs based on their previous and new values and mention how this interacts with the SSTORE counters from EIP-1283.

The lack of clarification is deliberate because the SSTORE pricing seems to change with every hard fork, and might be changed again in London. But I can be more absolute.

I see why the prior specification was insufficient; metering approaches can be complex. If 2929 happens in Berlin I'll specify that behavior too, but it currently seems to be excluded from the hard fork meta.

https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/berlin.md
2929 is definitely on board for Berlin.

Okay. I thought perhaps it was removed because it wasn't in EIP-2070.

Co-authored-by: Micah Zoltu <[email protected]>

wjmelements · 2021-03-01T21:10:11Z

I think removing the early removal "activation cost" specification is worth it for simplification. It also plays nicer with metering.

MicahZoltu

Minor cleanup suggestions for consistency with one real suggestion. Nothing blocking merge as draft though.

MicahZoltu · 2021-03-02T15:00:38Z

EIPS/eip-3300.md

+There is also a case where `SSTORE_CLEARS_SCHEDULE` is removed from the refund counter.
+That removal will also diminish by `REFUND_DECAY_STEP` until 0, maintaining the non-negative refund counter invariant.
+
+


Suggested change

MicahZoltu · 2021-03-02T15:00:46Z

EIPS/eip-3300.md

+
+This change is less work for the protocol developers than compensation and cleanup, while likely still achieving cleanup.
+
+


Suggested change

MicahZoltu · 2021-03-02T15:00:56Z

EIPS/eip-3300.md

+* `SSTORE_SET_GAS - SLOAD_GAS` (20000 - 100)
+* `SSTORE_CLEARS_SCHEDULE` (15000)
+
+


Suggested change

MicahZoltu · 2021-03-02T15:01:03Z

EIPS/eip-3300.md

+
+For gas-cost regimes with refund removals that cancel prior refunds, the invariant that the refund counter cannot go negative will be preserved by diminishing the magnitude of those removals by `REFUND_DECAY`, until 0.
+
+


Suggested change

MicahZoltu · 2021-03-02T15:01:10Z

EIPS/eip-3300.md

+Computed:
+* `REFUND_DECAY`: `REFUND_DECAY_STEP * ceil((block.number + 1 - FORK_BLOCK_NUM) / REFUND_DECAY_FREQUENCY)`
+
+


Suggested change

MicahZoltu · 2021-03-02T15:01:53Z

EIPS/eip-3300.md

+The rate of diminishing specified would currently require (24000-5000) * 100 = 1,900,000 blocks for `SELFDESTRUCT` and (15000-5000) * 100 = 1,000,000 blocks for `SSTORE`.
+This timeframe is currently about a year, which should be enough flexibility for the remaining refunds to be consumed.
+
+


Suggested change

MicahZoltu · 2021-03-02T15:04:02Z

EIPS/eip-3300.md

+### EIP-2929
+The refunds as of EIP-2929 are as follows:


Suggested change

### EIP-2929

The refunds as of EIP-2929 are as follows:

The refunds are as follows:

Ideally, we should try to avoid creating dependencies between EIPs (when possible) and instead prefer to just assert the new behavior. This way, the EIP makes sense with or without the dependent EIP or knowledge of it. In this case, we can just state the new gas refunds as of this EIP's implementation and ignore 2929's existence.

MicahZoltu · 2021-03-02T15:04:53Z

EIPS/eip-3300.md

+
+## Specification
+Parameters:
+* `FORK_BLOCK_NUM`: EIP-3300 activation block


Suggested change

* `FORK_BLOCK_NUM`: EIP-3300 activation block

* `FORK_BLOCK_NUM`: TBD

The common way to handle this is to just say TBD here.

wjmelements · 2021-03-02T21:32:08Z

Thanks for the review @MicahZoltu

* wip phase out refunds * update create date and eip number * discussions-to * rename file to eip# * fix discussions-to url error from Travis * Update EIPS/eip-3300.md Co-authored-by: Micah Zoltu <[email protected]> * Update EIPS/eip-3300.md Co-authored-by: Micah Zoltu <[email protected]> * Update EIPS/eip-3300.md Co-authored-by: Micah Zoltu <[email protected]> * Update EIPS/eip-3300.md Co-authored-by: Micah Zoltu <[email protected]> * Update EIPS/eip-3300.md Co-authored-by: Micah Zoltu <[email protected]> * Update EIPS/eip-3300.md Co-authored-by: Micah Zoltu <[email protected]> * Update EIPS/eip-3300.md Co-authored-by: Micah Zoltu <[email protected]> * Update EIPS/eip-3300.md Co-authored-by: Micah Zoltu <[email protected]> * initial clarification * specify 1283 behavior * specify negative refund removal * start specifying activation costs and then simplify by disregarding them * cleanup activation cost specifications Co-authored-by: Micah Zoltu <[email protected]>

wjmelements added 5 commits February 26, 2021 16:25

wip phase out refunds

cb6f397

update create date and eip number

132b71e

discussions-to

3c600d2

rename file to eip#

11fb4d8

fix discussions-to url error from Travis

9034dbd

wjmelements changed the title ~~Phase Out Refunds~~ EIP-3300: Phase Out Refunds Feb 27, 2021

MicahZoltu suggested changes Feb 28, 2021

View reviewed changes

wjmelements and others added 11 commits February 28, 2021 01:13

Update EIPS/eip-3300.md

bab9bdc

Co-authored-by: Micah Zoltu <[email protected]>

Update EIPS/eip-3300.md

8d65436

Co-authored-by: Micah Zoltu <[email protected]>

Update EIPS/eip-3300.md

7a8902f

Co-authored-by: Micah Zoltu <[email protected]>

Update EIPS/eip-3300.md

27a9698

Co-authored-by: Micah Zoltu <[email protected]>

Update EIPS/eip-3300.md

4f052ee

Co-authored-by: Micah Zoltu <[email protected]>

Update EIPS/eip-3300.md

7132ff4

Co-authored-by: Micah Zoltu <[email protected]>

Update EIPS/eip-3300.md

61525af

Co-authored-by: Micah Zoltu <[email protected]>

Update EIPS/eip-3300.md

1117485

Co-authored-by: Micah Zoltu <[email protected]>

initial clarification

53c611a

specify 1283 behavior

cace5f0

specify negative refund removal

1b06d95

wjmelements added 2 commits March 1, 2021 13:20

start specifying activation costs and then simplify by disregarding them

3730b6b

cleanup activation cost specifications

37fc322

wjmelements mentioned this pull request Mar 1, 2021

Proposal to include EIP 3300 (phase out refunds) in London ethereum/pm#258

Closed

wjmelements requested a review from MicahZoltu March 1, 2021 21:51

MicahZoltu approved these changes Mar 2, 2021

View reviewed changes

MicahZoltu merged commit e37dc7d into ethereum:master Mar 2, 2021

		There is also a case where `SSTORE_CLEARS_SCHEDULE` is removed from the refund counter.
		That removal will also diminish by `REFUND_DECAY_STEP` until 0, maintaining the non-negative refund counter invariant.


		This change is less work for the protocol developers than compensation and cleanup, while likely still achieving cleanup.

		* `SSTORE_SET_GAS - SLOAD_GAS` (20000 - 100)
		* `SSTORE_CLEARS_SCHEDULE` (15000)


		For gas-cost regimes with refund removals that cancel prior refunds, the invariant that the refund counter cannot go negative will be preserved by diminishing the magnitude of those removals by `REFUND_DECAY`, until 0.

		Computed:
		* `REFUND_DECAY`: `REFUND_DECAY_STEP * ceil((block.number + 1 - FORK_BLOCK_NUM) / REFUND_DECAY_FREQUENCY)`

		The rate of diminishing specified would currently require (24000-5000) * 100 = 1,900,000 blocks for `SELFDESTRUCT` and (15000-5000) * 100 = 1,000,000 blocks for `SSTORE`.
		This timeframe is currently about a year, which should be enough flexibility for the remaining refunds to be consumed.

	### EIP-2929
	The refunds as of EIP-2929 are as follows:
	The refunds are as follows:

	* `FORK_BLOCK_NUM`: EIP-3300 activation block
	* `FORK_BLOCK_NUM`: TBD

Conversation

wjmelements commented Feb 27, 2021

Uh oh!

vorot93 commented Feb 27, 2021

Uh oh!

wjmelements commented Feb 27, 2021 via email

Uh oh!

MicahZoltu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wjmelements commented Mar 1, 2021

Uh oh!

MicahZoltu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wjmelements commented Mar 2, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants