EIP: <to be assigned>
Title: Maximum Gas Limit
Author: Gavin Wood
Type: <Standard Track | Informational | Meta>
Category: Core
Status: Draft
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
Provide a consensus option to reduce 51% attack damage in weak PoW chains.
Public testnets chains can be easly trashed by a 51% attack combined with bloating with contracts that spawn minimal contracts in a while loop of gas remaining. The Ropsten chain have been 51% attacked before, but the attack was easly repaired, but when combined with a bloating attack and gas limit attack, under all valid consesus rules, made difficult to clean up the heavy blocks that rised up to size of 2GB.
Provide a security option to public test chains in order to protect future PoW chains against 51% attacks bloating to inifinty gas limit.
Ropsten defaults:
"maxGasLimitTransition": 543210,
"maxGasLimit": 4712388
The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.
The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.
Copyright and related rights waived via CC0.