ECIP-1084: Hard cap on the gaslimit for the ETC mainnet as an in-protocol consensus rule.

[bobsummerwill]

Hard cap on the gaslimit for the ETC mainnet as an in-protocol consensus rule.

From the block that this ECIP was activated, gaslimit would follow a
curve defined in this proposal rather than being subject to miner voting.

[bobsummerwill]

ECIP Editors: @soc1c @YazzyYaz @meowsbits @sorpaas @BelfordZ:
Please can you review/comment/merge? I think this is ready to go. Thanks!

[meowsbits]

I'm OK merging from a technical ECIP-draft perspective.

• Front matter seems in order
• Formatting and sectioning seems in order

[bobsummerwill]

@meowsbits I see some comments from you in the Discord ecip-github channel but cannot see them here.

Raised from what value to 8M?

What was this in reference to?

This is not obvious to me. My client seems to run fine on ETH, ETC, and test networks. Can you provide benchmarks here?

What was this in reference to?

In general, I am talking about the full-sync from Genesis times for both ETH (which we want to avoid reaching) and ETC. Both time to sync and disk usage.

[bobsummerwill]

You asked "what from" on the gaslimit, @meowsbits?

Here is a historical graph of the ETH gaslimit, which I believe that ETC has pretty much inherited by mistake due to whatever the Parity-Ethereum defaults have been:

https://etherscan.io/chart/gaslimit

The limit was lowered at the time of the Shanghai attacks in Sep/Oct/Nov 2016 or so and you can see a dip in the historical progression there, but you can see in general it was:

3M during 2015
4.7M during 2016 to mid 2017 (barring dip for the attacks)
6.7M mid 2017 to late 2017
8.0M during 2018 and until Sep 2019
10M since Sep 2019.

Full-syncs are horrific now on ETH: https://twitter.com/jgarzik/status/1217488290900848640

See also articles like: https://hackernoon.com/the-ethereum-blockchain-size-has-exceeded-1tb-and-yes-its-an-issue-2b650b5f4f62

[antsankov]

I think this is a great proposal and look forward to working on it after Phoenix is activated. A few thoughts:

• I personally like either of the two gas limit functions proposed and believe something that approximates Moore's law - gas limit doubles every 2 years seems like a good target to shoot for.

• One advantage of this, is that it would allow network participants to provision for "maximum scenario" disk storage requirements. For example:

"I know between now and 2 years from now, a 2mil gas block will be at most 5KB [1], assuming 13second blocks, there will be around 5mil blocks before a gas limit increase. Based on 5KB * 5mil = 25GB. I will only need a 25GB hard disk for the next 2 years"

These numbers are somewhat rooted in reality, but when this gets deployed we should be able to propose this information as a node-operator standard.

Ultimately in favor of this proposal, and looking to see how it progresses.

[1] https://ethgasstation.info/blog/ethereum-block-size/