Created
March 19, 2024 14:42
-
-
Save realcodywburns/01a2af8fb4dd8a5bc51089af2036c2a4 to your computer and use it in GitHub Desktop.
Elastic block gas
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| assumptions | |
| • miners and users desire stability in systems | |
| • block rewards will go down, fee market must compensate | |
| • humans setting the block gas limit is inefficient and can lead to perverse incentives | |
| • setting arbitrarily large gas limits can bloat nodes | |
| • the optimal solution should be driven by the network utilization | |
| • Hard edges create targets for exploitation, mess was an exponential scale for this reason | |
| • 1559 style basefee + tip stabalizes fees | |
| • ETC will never burn base fees or tips due to hardcapped supply of coins | |
| • the community should have some control of growth | |
| • the target gas limit should optimize for some community defined percentage of block space utilization | |
| • there is a hard floor and soft ceiling | |
| • the community defines the goldilocks zone | |
| • as block rewards decrease, more fixed gas fee transactions are needed to offset the miner revenue | |
| • unpredictable gas fees are undesirable. fixed gas limits create unpredictable gas fees since higher fee transactions get included. | |
| proposal | |
| • create an 'elastic gas limit' by using block reward incentives | |
| • the ideal block gas limit should be set based on the exponential moving average of the blockchain | |
| • if the current block utlizes gas that is outside the ema +- some % (defined by the community) the block reward is reduced exponentially. | |
| • EMA ensures growth/shrink limit between blocks should be proportional to the trajectory of the network | |
| • If a developer would like to include a very large transaction, a miner could be incintivized to accept the block reward being reduced to zero if the tip is high enough to offset the loss. all nodes should accept this as a valid block. | |
| • if a miner produces empty or low value blocks, they will forfit their block rewards. This encourages creating useful blocks. | |
| • The current block reward should be viewed as offsetting the fee market until adaquate transactions volume exists. glide slope to tx market | |
| goals | |
| • security - miners long-term business planning should target the fee market completely replacing the current block reward system. The number of transactions and gas usage overtime is knowable, more transactions more fees. | |
| • stability - fixed base fees and predictable block sizes allow for long term infrastructure planning, development/deployment cost planning, and user transaction cost modeling | |
| • decentralization - letting the network usage define the block limit prevents collusion of actors | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If EMA would be introduce, wouldn't that lead to gas limit instability in a situation when there are fluctuations in transaction volume? If "someone" manipulates transaction volumes to influence the gas limit, wouldn't that lead to network congestion or under utilization?
Could a threshold strategy for the gas limit, similar to bandwidth allocation in networking (bandwidth throttling - prioritization of certain types of traffic) help with transaction spikes by allowing temporary increases when needed, then bringing the limit back to a more sustainable level? That might create more predictability and mitigate bad behavior, also adding efficiency while still allowing flexibility, right?