Skip to content
Permalink
master
Go to file
…th format and the first reference must be linked. (#2947)

I have gone through and updated all existing EIPs to match this rule, including EIP-1.

In some cases, people were using markdown citations, I suspect because the long-form was a bit verbose to inline.  Since the relative path is quite short, I moved these to inline but I wouldn't be opposed to putting them back to citation format if that is desired by the authors.

In doing the migration/cleanup, I found some EIP references to EIPs that don't actually exist.  In these cases I tried to excise the reference from the EIP as best I could.

It is worth noting that the Readme actually already had this rule, it just wasn't expressed properly in EIP-1 and the "Citation Format" section of the readme I think caused people a bit of confusion (when citing externally, you should use the citation format).
5 contributors

Users who have contributed to this file

@jamesray1 @cdetrio @Arachnid @MicahZoltu @axic
29 lines (21 sloc) 1.64 KB
eip title author type category status created
170
Contract code size limit
Vitalik Buterin (@vbuterin)
Standards Track
Core
Final
2016-11-04

Hard fork

Spurious Dragon

Parameters

  • FORK_BLKNUM: 2,675,000
  • CHAIN_ID: 1 (main net)

Specification

If block.number >= FORK_BLKNUM, then if contract creation initialization returns data with length of more than 0x6000 (2**14 + 2**13) bytes, contract creation fails with an out of gas error.

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.

References

  1. EIP-170 issue and discussion: https://github.com/ethereum/EIPs/issues/170
  2. pyethereum implementation: https://github.com/ethereum/pyethereum/blob/5217294871283d8dc4fb3ca9d8a78c7d416490e8/ethereum/messages.py#L397
You can’t perform that action at this time.