Dynamic gas pricing for opcodes (miner decided opcode pricing)

[BlameByte]

The current pricing scheme for opcodes is not in a good state as is shown by the attacks and the hard fork, there needs to be something more decentralized and faster reacting to both attacks and hardware / software improvements.

Having a hard fork each time these opcodes require changing is not sustainable and will require setting the opcodes higher than they should and likely will mean they never get reduced even with speed improvements.

The solution I have allows miners (who create blocks) decide what these opcodes should ultimately cost, allowing both quick action to both opcode price increase or decrease and allowing it to be decentralized.

Proposal A

• Target a block in the future
• The price the opcode the miner wants to be (within the range*)
• Taking the average price of what the miners set their price over 64 blocks
• The range is limited to 2x increase of decrease of current price, minimum limit is the default cost of opcode, if default cost was 0 and it increases, it may never return to 0.

Proposal B

• Target a block in the future
• Factor in the time it took to process the transactions into the block
• Weigh in the amount of times each opcode was used and the time it took to process the block
• Every 16 blocks adjust the pricing so it matches the amount of time it took for each opcode

Proposal C

• Target a block in the future
• Record the amount of times an opcode is used over 32 blocks
• If a certain opcode is used very often and processing is taking longer than expected increase the gas cost of that opcode
• If the opcode stops being used frequently and processing remains higher reduce price of opcode and increase price of another highly used opcode
• If the opcode continues to be used but the processing lowers reduces dramatically the opcode price back in between new and old value.

Proposal A is more simple and ultimately gives the decision to the miners to set it to whatever they wish similar to block limit. It is slower than the other two methods and requires miners to change their pricing to react to attacks / badly priced opcodes.
There is a WIP of this proposal which shows an incomplete implementation of how it would look like in go-ethereum: BlameByte/go-ethereum@c15b516

Proposal B takes the approach of automatically timing each opcode but to keep consensus (faster or slower machines) we rely on the speed of the miner, but this is across the past 16 blocks so it will not be any one miner. It is also the fastest reacting to an attack.

Proposal C is likely the most complicated and is also automatic. It is primarily to protect against attacks as if there are opcodes that are being used frequently to slow down the network it will increase the costs associated to them. It will also recover the prices of opcodes after they are used less frequently.

[gcolvin]

I'd be happy if some variation on your proposals can be made to work at the protocol level, but that's not my expertise. At the EVM level one problem is the need to count how often opcodes are used. It will slow down an EVM, and likely force it to operate in an instrumented mode where the relative costs might not be the same as in normal operation. E.g. a JIT might have to disable optimizations and insert special counters. This can likely be mitigated by moving the counting to an analysis phase after the block is processed, by sampling like profilers do, or other such tricks, depending...

[nicksavers]

I agree on making changes in the gas cost flexible as part of the protocol, because it depends on the performance of client implementations and cost of hardware components relative to each other and I expect more changes to come in the future.

Instead of building a separate block-based voting system for this in the protocol, if the gas cost was to be stored in a contract it could be voted on with a proof-of-stake model or perhaps even using a prediction market and go all futarchy-style, if that proves to work as advertised.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.