ECIP-1047: Reduce Gas Limit to 1 Million

[pyskell]

Discussion regarding ECIP-1047(#6). Please discuss here and refer to #6 for the latest version of this ECIP.

[soc1c]

ECIPs are meant to help protocol discussions. block gas limit is completely up to the miners.

[realcodywburns]

ECIP types

There are three kinds of ECIP:

A Standards Track ECIP describes any change that affects most or all Ethereum Classic implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Ethereum Classic. Standards Track ECIPs consist of two parts, a design document and a reference implementation.

An Informational ECIP describes a Ethereum Classic design issue, or provides general guidelines or information to the Ethereum Classic community, but does not propose a new feature. Informational ECIPs do not necessarily represent a Ethereum Classic community consensus or recommendation, so users and implementors are free to ignore Informational ECIPs or follow their advice.

A Process ECIP describes a process surrounding Ethereum Classic, or proposes a change to (or an event in) a process. Process ECIPs are like Standards Track ECIPs but apply to areas other than the Ethereum Classic protocol itself. They may propose an implementation, but not to Ethereum Classic's codebase; they often require community consensus; unlike Informational ECIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum Classic development. Any meta-ECIP is also considered a Process ECIP.

[bobsummerwill]

I am supportive of this ECIP.
We need to get the gas limit under control PRIOR to potential mass migration from ETH or ETC when we catch up on protocol.
1MB might be too low.

I think we also need to look at adding UASF/UAHF as the means of implementing this limit, rather than just having this as something "informational". So really looking at BTC-style limiting, to avoid compromising decentralization and avoiding pushing scaling beyond what our POW L1 can currently cope with.

[bobsummerwill]

Also, outside of the ECIP process, we can just create PRs for the clients themselves which lower the default settings. That does not even require this ECIP.

[TheEnthusiasticAs]

I support it too.

[bobsummerwill]

@streetcrypto7 I agree that 1 million gas is likely too low. We can debate what the actual figures should be, but the key point of this proposal is that 8M is too high.

[phyro]

@streetcrypto7 you could argue that some contracts will need more than 100 million gas limit for deployment. It's about what is good for the network long term and having it set so high is definitely not and we can see this in practice with what is happening to the ETH chain.

[IstoraMandiri]

I support having a more refined block gas limit.

Figuring out the limit itself is the hard part, as there are several tradeoffs to consider. I think we should be methodical about finding the right number.

I was originally in support of having 1 million as a target (in theory); if developers need to deploy with +1 million gas, they can do so by code splitting into multiple contracts. However, deployments of existing popular contracts frequently breach this limit.

Some random examples:

Wrapped Ether: 966,549 https://etherscan.io/tx/0xb95343413e459a0f97461812111254163ae53467855c0d73e0f1e7c5b8442fa3

Gnosis Multisig: 2,674,708 https://etherscan.io/tx/0x55befd6ad29c13eb16be00e888cf7a676ad4c02b8a942099c278a2efa4bade08

Uniswap Exchange Template: 3,340,999
https://etherscan.io/tx/0x9d30e48fb33a7b760d0b5c33253eb5a774c9dc8e9ee2768ad3425249a3319e09

I think that it would be best strike a balance between enabling reasonable sync times (what is reasonable?) on various future hardware requirements (mobile, commodity laptop, EC2?), and not making it too annoying to migrate popular contracts from ETH to ETC (some contracts are easier to code split than others).

I support targeting a gas emission curve (chain bloat curve) to fit future hardware requirements.

I think a soft fork is probably best avoided if can't be done with defaults and/or information campaign.

To follow up I'll attempt to do some more data gathering:

• Compile stats on all popular contracts and their deploy costs
• Estimate future hardware requirement categories (mobile, commodity, EC2$$)
• Model a gas limit emission curve to fit expected hardware development

Another option here (@phyro suggested) is to have longer block times (without changing the gas limit), which would achieve the reduced chain bloat, whilst still enabling larger contracts to be deployed in a single block. Obviously many other implications.

[phyro]

nice research @hitchcott !

Regarding the longer block times. I'd like to hear arguments as to why fast blocks would be a good idea (I did very poorly when I tried to think of these reasons). My main reason for considering longer block times was because given a time interval (say 10 minutes), you have the same security regardless if your block time is 15 seconds or 2 minutes because it's the number of hashes you've tried in that interval that is the important part. Blocks can be thought of as snapshots or packaging of these hash tries (a pack of energy?) and because you don't want to store all the hashes you tried, you store a proof that shows you tried approximately this many hashes. Notice here that the way you package these things is completely irrelevant to the security. The time passed and the number of hashes that were tried during that time period is what brings security. Higher block times also bring less frequent block propagation over the network and fewer block headers (the block header issue is already solved with the flyclient but still saves some space). So far, the only use I've found for fast block times was when I was researching ways to make 51% attacks more expensive and having blocks come really fast makes it easier/faster to gather 'statistics' around who is mining the blocks. I'd love to hear other pros (and cons) of having fast blocks. The con of changing it to longer block times:

1. it is changing a core part of the system
2. it would likely change other things as well, possibly the monetary policy due to the uncle rewards being less frequent
3. possibly other stuff

While my current view is that longer block times are superior, I really don't like that it might be touching the monetary policy. I don't know the exact definition of what defines the policy. I'm sure we could mathematically prove that the expected emission of coins over time stays the same (looking at time ticks in 2 minutes instead of 15 seconds of course). How bad of a change we consider this is unclear to me.

Another thing I'd like us to consider is:
Deploying a contract is a constant (it happens exactly once per contract), so perhaps a deploy could be allowed a higher gas limit. I'd pair this up with a higher contract deploy cost to avoid spamming. Rationale: it makes no sense to have cheap deploys since everyone in the world will have to drag this data along. Serious projects will have no problem paying a few $ to deploy a contract. Testnets can have cheap deploy prices, but deploying on ETC is worth way more imo. I'd also argue that deploying a dapp for 10$ is still unbelievably cheap considering it will run forever.

[soc1c]

Following problems should be fixed with ECIP-1047:

• This should not be an ECIP but an ECBP
• Specification should include instructions for Geth Classic, Multi-Geth, Parity-Ethereum, and Hyperledger Besu
• Link to Geth Classic should be updated

Personal opinion: This should not be part of the ECIP process.

[IstoraMandiri]

Can we change the title of this ECIP? 1 million is presumptuous.

I don't think we shouldn't specify a target until we figure out what the target should be.

Personally I think 4 million is more reasonable due to contract deployments.

[bobsummerwill]

I am preparing an alternative proposal on gas limit too.

[BelfordZ]

Gas limit is something that is meant to be adjusted by miners. Sadly, there is no 'defacto' strategy for increasing or decreasing gasLimit, and so miners generally seem to not care.

Let's close this issue, and centre future proposals around algorithms and strategies for decreasing or increasing block gasLimit

[bobsummerwill]

@BelfordZ So you have closed this issue, but https://ecips.ethereumclassic.org/ECIPs/ecip-1047 remains in draft.

[BelfordZ]

and so it shall remain until someone decides to withdraw it or remove it.

Do you have any suggested alternate ways to proceed?

[bobsummerwill]

I think we will "process" all the gas-limit / gas mechanism type proposals as part of the HF after Phoenix at which point we can likely get to a resolution.

[BelfordZ]

as I understand it:

1. Request for miners to vote up one way or another is not something that should be done via ECIP
2. we should close any such requests.

In this case, the request is for miners to vote to decrease the block gas limit. AFAIK, this is something that should be handled with miners directly, or with pool software/client developers such that they may change how the miner vote is decided.