EIP-2 Homestead Hard Fork Changes (Homestead Hard-fork Changes)
Final · Other · EIP status Final · created 2015-11-15
These are the four rule changes applied in the Homestead hard fork. They cover raising the gas cost of transaction-based contract creation, invalidating signatures with a high s value, clarifying the failure rule for contract creation, and replacing the mining difficulty adjustment formula.
Why it is needed
Right now, creating a contract via a transaction costs only 21,000 gas, cheaper than the 32,000 gas it costs to create one inside a contract with the CREATE opcode. Combined with a selfdestruct (suicide) refund, this lets an attacker send ether for as little as 11,664 gas, opening a hole in the fee system. Because flipping a signature's s value still produces a valid signature, an attacker can change a transaction's hash, which confuses wallet interfaces that track transactions by hash. If contract creation runs out of gas at the final step, an empty contract is left behind, stuck in a state that is neither success nor failure. In addition, some miners mined by stamping timestamps only one second later than the parent block, distorting the distribution of block times; if this kind of mining exceeded 51%, the average block time could grow without bound. The Homestead hard fork fixes all four of these problems at once.
What changes
Today
- Creating a contract via a transaction costs only 21,000 gas, cheaper than the CREATE opcode (32,000)
- Signatures with a large s value are still valid, letting an attacker change the transaction hash
- If gas runs out at the last step of contract creation, an empty contract is left in state
- Mining with timestamps stamped only one second apart keeps increasing the average block time
After EIP-2
- The upfront gas cost of creating a contract via a transaction rises to 53,000
- Signatures with an s value greater than secp256k1n/2 become invalid
- If gas runs out, the entire contract creation fails and any ether sent is refunded
- The new difficulty formula makes it impossible for the long-run average block time to exceed 24 seconds
Who is affected
- Users and wallets: Transaction hashes no longer change midway, so wallets and explorers that track transactions by hash work reliably.
- Contract developers: When deploying a contract via a transaction, the gas cost rises to 53,000, and if gas runs out the whole creation fails instead of leaving an empty contract, making the outcome clearly either success or failure.
- Miners: The difficulty adjustment formula changes so that the strategy of stamping timestamps only one second later than the parent block no longer pays off.
- Client teams: All four rule changes must be implemented and applied starting at mainnet block 1,150,000.
In depth
Raising the Gas Cost of Transaction-Based Contract Creation from 21,000 to 53,000
For transactions where the to address is an empty string, that is, transactions that create a contract directly, the upfront gas deduction rises from 21,000 to 53,000. The structure where the gas cost of the transaction data is added on top stays the same. The path of creating a contract via the CREATE opcode inside contract code is unaffected. The background is a cost inversion: because the transaction path (21,000) was cheaper than the CREATE path (32,000), there was an excessive incentive to create contracts via transactions, and combined with a suicide refund, ether could be sent for as little as 11,664 gas. The source describes this as not a serious problem, but close to a bug.
Invalidating Signatures with an s Value Exceeding secp256k1n/2
All transaction signatures with an s value greater than secp256k1n/2 are treated as invalid. The ECDSA recovery precompiled contract (ecrecover) is unchanged, however, and continues to accept high s values, since it can be used, for example, to recover old Bitcoin signatures in contracts. This change blocks the signature malleability problem: in any transaction, changing s to secp256k1n - s and flipping v from 27 to 28 (or vice versa) still produces a valid signature. Because Ethereum uses the address rather than the transaction hash as the input for sending funds, this is not a serious security flaw, but the hash of the transaction finalized in a block ends up differing from the one the user sent, which interferes with interfaces that use the hash as a tracking ID.
Failing Contract Creation Entirely When Gas for Code Storage Runs Out
During contract creation, if there is not enough gas left to pay the final cost of adding the contract code to state, the contract creation itself fails (out of gas) instead of leaving an empty contract behind. The source lists three benefits. First, the three-way outcome of success, failure, and empty contract is reduced to the intuitive two-way outcome of success or failure. Second, failure becomes easier to detect, since the contract account is never created at all unless contract creation succeeds completely. Third, contract creation that sends ether along with it (an endowment) becomes safer, because only one of two things can happen: either the entire initialization process completes, or the transaction fails and the ether sent is refunded.
Replacing the Difficulty Adjustment Formula
The existing formula, block_diff = parent_diff + parent_diff // 2048 * (1 if block_timestamp - parent_timestamp < 13 else -1) + int(2**((block.number // 100000) - 2)), is replaced with block_diff = parent_diff + parent_diff // 2048 * max(1 - (block_timestamp - parent_timestamp) // 10, -99) + int(2**((block.number // 100000) - 2)). // denotes integer division, and difficulty never falls below the minimum set by minDifficulty. The old formula targeted a median of 13 seconds, so when miners stamped timestamps as parent_timestamp + 1, the median held but the average rose, and if this kind of mining reached 51%, the average could grow without bound. The new formula targets roughly the average instead, and it can be proven that it is mathematically impossible for the long-run average block time to exceed 24 seconds. Using (block_timestamp - parent_timestamp) // 10 as the input, rather than the raw time difference, preserves the algorithm's coarse granularity, blocking the incentive to tune the time difference to exactly 1 to produce a slightly higher-difficulty block. The floor of -99 is a safeguard so that an unexpected event, such as a client security bug, that causes a very large gap between two blocks does not cause difficulty to drop to an extreme degree.
Activation Block and Status
The four changes apply when block.number is at or above HOMESTEAD_FORK_BLKNUM: 1,150,000 on mainnet, 494,000 on the Morden testnet, and 0 on later testnets. This EIP is the core list of changes referenced by EIP-606, the meta document that defines the Homestead hard fork, and its status has been finalized as Final. The source points to four corresponding locations in the Python implementation (pyethereum) as the basis for the implementation.