EIP 3298: Removal of refunds

Relevant prior discussions: EIP-2751

As a holder of millions of dollars worth of refunds, tokenized and otherwise, I would be strongly interested in a compensation plan. I can prepare an EIP for this. The search for parties to compensate can coincide with cleanup, which would reduce the amount of state formerly dedicated to this purpose. Hence I suggest postponing this change until the ETH2 merge.

My current refund compensation plan would use a 50,000-block average of the gastoken’s Uniswap-V2 WETH token ratios pre-fork to determine their compensation eth value, then replace their contract with another holding that much ETH. The new contracts would replace the free, freeUpTo, freeFrom, and feeFromUpTo methods to “burn” those tokens and send ETH to sender according to the ratio of burned supply to the remaining. The mint function would become a no-op. Then, all of the gastoken state could be removed with the hard fork. The supply-weighted average of GST2 and CHI’s resulting price can be used to value SSTORE refunds as well, such as GST1 and Cancel contracts.

An alternative way to disable refunds gently would be to phase them out, with the refund decreasing by 1 every 1,000 blocks after activation. This approach would not require compensation, and they would clean themselves up automatically over time.

Without compensation, I would be incentivized to floor the gas price to increase the likelihood that my refunds get purchased or used before they are deactivated, and/or seek legal action off-chain. But I suspect cleanup and compensation would be agreeable to all parties.

particularly in exacerbating state size

Quantitatively the space consumed is very minimal, several MB. There are ways to reduce this to about 1 MB that have been proposed in the past; they take advantage of the fact that gastoken contracts are all identical. I mentioned this optimization in the Motivation section of EIP-2185.

inefficiently clogging blockchain gas usage

They only “clog” blockchain gas usage during times of lesser congestion. During that time they are outbidding other activity that would also create space; but unlike that activity, the space is eventually cleaned up. Unlike a hypothetically-functional EIP-1559 variant, state growth is normalized and counter-balanced from the resulting block elasticity.

inefficiently

It can be made more efficient by increasing the refund :stuck_out_tongue:

  • Refunds increase block size variance. The theoretical maximum amount of actual gas consumed in a block is nearly twice the on-paper gas limit (as refunds add gas space for subsequent transactions in a block, though refunds are capped at 50% of a transaction’s gas used). This is not fatal, but is still undesirable, especially given that refunds can be used to maintain 2x usage spikes for far longer than EIP 1559 can.

It is not a problem that ethereum can use double it’s current target because it’s currently far below its capacity, which is good for sync times and state growth. But Binance Smart Chain is demonstrating that modern hardware can still sync the blockchain when the gasLimit/minute is >16x higher. It seems 4x is a recent concern due to EIP-1559, but since we are so very far below capacity I would pitch it as a strong advantage: block elasticity means lower highs during peak gas congestion from the additional capacity. Gastokens are also massively under-utilized, despite efforts to democratize their usage. Next, the duration that gastokens can be used to 2x capacity is limited by the current supply; gastokens are relatively scarce. Shortly, 4x is a non-issue because gas targets are coordinated around sync time and state-growth, not processing time. This is also why the miner-coordinated increase from 10m to 12.5m coincided with an unpredicted decrease in uncle rate.

I’m skeptical that EIP1559 will improve block elasticity, but that is another discussion. For the case that it doesn’t, this should be delayed until after London. The gas price estimation user experience would be much worse with more volatility.

1 Like