Update EIP-3860: Fix linter warnings

EIPS/eip-3860.md

@@ -7,8 +7,8 @@ discussions-to: https://ethereum-magicians.org/t/eip-3860-limit-and-meter-initco
 status: Review
 type: Standards Track
 category: Core
-requires: 170
 created: 2021-07-16
+requires: 170
 ---
 
 ## Abstract
@@ -24,17 +24,19 @@ Lastly, the size limit results in the nice-to-have property that EVM code size,
 During contract creation the client has to perform jumpdest-analysis on the `initcode` prior to execution. The work performed scales linearly with the size of the `initcode`. This work currently is not metered, nor is there a protocol enforced upper bound for the size.
 
 There are three costs charged today:
+
 1. Cost for calldata aka `initcode`: 4 gas for a byte with the value of zero, and 16 gas otherwise.
 2. Cost for the resulting deployed code: 200 gas per byte.
 3. Cost of address calculation (hashing of code) in case of `CREATE2` only: 6 gas per word.
 
-Only the first cost applies to `initcode`, but only in the case of contract creation transactions. For the case of `CREATE`/`CREATE2` there is no such cost, and it is possible to programmatically generate variations of initcode in a relatively cheap manner. In the past it was possible to craft malicious `initcode` due to a vulnerability fixed in 2017 by [geth 1.6.5](https://github.com/ethereum/go-ethereum/releases/tag/v1.6.5).
+Only the first cost applies to `initcode`, but only in the case of contract creation transactions. For the case of `CREATE`/`CREATE2` there is no such cost, and it is possible to programmatically generate variations of `initcode` in a relatively cheap manner. In the past it was possible to craft malicious `initcode` due to a vulnerability fixed in 2017 by geth 1.6.5.
 
-Furthermore the lack of a limit has caused lengthy discussions for some EVM proposals, influencing the design, or even causing a delay or cancellation of a feature.
+Furthermore, the lack of a limit has caused lengthy discussions for some EVM proposals, influencing the design, or even causing a delay or cancellation of a feature.
 
 We are motivated by three reasons:
+
 1. Ensuring `initcode` is fairly charged (most importantly cost is proportional to `initcode`'s length) to minimize the risks for the future.
-2. To have a cost system which is extendable in the future (i.e. for proposals like EIP-3670).
+2. To have a cost system which is extendable in the future (i.e. for proposals like [EIP-3670](./eip-3670.md)).
 3. To simplify EVM engines by the explicit limits (code size, code offsets (`PC`), and jump offsets fit 16-bits).
 
 ## Specification
@@ -74,7 +76,7 @@ The value of `INITCODE_WORD_COST` is selected based on performance benchmarks of
 
 We have chosen the cost of 2 gas per word based on Geth's implementation and comparing with `KECCAK256` performance. This means the per byte cost is `0.0625`. While fractional gas costs are not permitted in the EVM, we can approximate it by charging per-word.
 
-Moreover, calculating gas per word is compatible with the calculation of `CREATE2`'s _hashcost_ of [EIP-1014](./eip-1014.md). Therefore the same implementation may be used for `CREATE` and `CREATE2` with different cost constants: before activation `0` for `CREATE` and `6` for `CREATE2`, after activation `2` for `CREATE` and `6 + 2` for `CREATE2`.
+Moreover, calculating gas per word is compatible with the calculation of `CREATE2`'s *hashcost* of [EIP-1014](./eip-1014.md). Therefore, the same implementation may be used for `CREATE` and `CREATE2` with different cost constants: before activation `0` for `CREATE` and `6` for `CREATE2`, after activation `2` for `CREATE` and `6 + 2` for `CREATE2`.
 
 ### Reason for size limit of initcode
 
@@ -92,22 +94,14 @@ The initcode cost for create transaction data (0.0625 gas per byte) is negligibl
 
 ### How to report initcode limit violation?
 
-We specified that initcode size limit violation for `CREATE`/`CREATE2` results in `0` on stack. Most checks in these instructions are specified this way, with the exception of 3 checks not specific to creation instructions (stack underflow, out of gas, static call violation). In these three cases the entire execution is exceptionally aborted. However we decided to be consistent with the majority of the possible error conditions in order to keep the specification and implementations simple.
+We specified that initcode size limit violation for `CREATE`/`CREATE2` results in `0` on stack. Most checks in these instructions are specified this way, except for 3 checks not specific to creation instructions (stack underflow, out of gas, static call violation). In these three cases the entire execution is exceptionally aborted. However, we decided to be consistent with the majority of the possible error conditions in order to keep the specification and implementations simple.
 
 ## Backwards Compatibility
 
 This EIP requires a "network upgrade", since it modifies consensus rules.
 
 Already deployed contracts should not be effected, but certain transactions (with `initcode` beyond the proposed limit) would still be includable in a block, but result in an exceptional abort.
 
-## Security Considerations
-
-For client implementations, this EIP makes attacks based on jumpdest-analysis less problematic, so should increase the robustness of clients.
-
-For layer 2, this EIP introduces failure-modes where there previously were none. There _could_ exist factory-contracts which deploy multi-level contract hierarchies, such that the code for multiple contracts are included in the initcode of the first contract. The author(s) of this EIP are not aware of any such contracts.
-
-Currently, on London, with `30M` gas limit, it would be possible to trigger jumpdest-analysis of a total `~1.3GB` of initcode. With this EIP, the cost for such an attack would increase by roughly `80M` gas.
-
 ## Test Cases
 
 Tests should include the following cases:
@@ -117,6 +111,14 @@ Tests should include the following cases:
 - `CREATE`/`CREATE2`/creation transaction with `len(initcode)` at `MAX_INITCODE_SIZE`
 - `CREATE`/`CREATE2`/creation transaction with `len(initcode)` at `MAX_INITCODE_SIZE+1`
 
+## Security Considerations
+
+For client implementations, this EIP makes attacks based on jumpdest-analysis less problematic, so should increase the robustness of clients.
+
+For layer 2, this EIP introduces failure-modes where there previously were none. There *could* exist factory-contracts which deploy multi-level contract hierarchies, such that the code for multiple contracts are included in the initcode of the first contract. The author(s) of this EIP are not aware of any such contracts.
+
+Currently, on London, with `30M` gas limit, it would be possible to trigger jumpdest-analysis of a total `~1.3GB` of initcode. With this EIP, the cost for such an attack would increase by roughly `80M` gas.
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).