status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-01-12 15:54:12 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #850 from jamesray1/patch-9

Browse Source 
EIP-170: Add parameters, capitalize Ethereum and use an em dash.
This commit is contained in:
Nick Savers 2018-01-27 23:35:17 +01:00 committed by GitHub
commit d45a6458d2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
EIPS/eip-170.md
View File

@ -7,6 +7,12 @@ Category: Core
Status: Final
Created: 2016-11-04
```
### Hard fork
[Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md)
### Parameters
- `FORK_BLKNUM`: 2,675,000
- `CHAIN_ID`: 1 (main net)
### Specification
@ -14,7 +20,7 @@ If `block.number >= FORK_BLKNUM`, then if contract creation initialization retur
### Rationale
Currently, there remains one slight quadratic vulnerability in ethereum: when a contract is called, even though the call takes a constant amount of gas, the call can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block's proof-of-validity. At current gas levels, this is acceptable even if suboptimal. At the higher gas levels that could be triggered in the future, possibly very soon due to dynamic gas limit rules, this would become a greater concern - not nearly as serious as recent denial of service attacks, but still inconvenient especially for future light clients verifying proofs of validity or invalidity. The solution is to put a hard cap on the size of an object that can be saved to the blockchain, and do so non-disruptively by setting the cap at a value slightly higher than what is feasible with current gas limits.
Currently, there remains one slight quadratic vulnerability in Ethereum: when a contract is called, even though the call takes a constant amount of gas, the call can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block's proof-of-validity. At current gas levels, this is acceptable even if suboptimal. At the higher gas levels that could be triggered in the future, possibly very soon due to dynamic gas limit rules, this would become a greater concern—not nearly as serious as recent denial of service attacks, but still inconvenient especially for future light clients verifying proofs of validity or invalidity. The solution is to put a hard cap on the size of an object that can be saved to the blockchain, and do so non-disruptively by setting the cap at a value slightly higher than what is feasible with current gas limits.
### References