forked from DecentralizedClimateFoundation/DCIPs
49 lines
2.2 KiB
Markdown
49 lines
2.2 KiB
Markdown
|
---
|
||
|
|
eip: 689
|
||
|
|
title: Address Collision of Contract Address Causes Exceptional Halt
|
||
|
|
author: Yoichi Hirai <i@yoichihirai.com>
|
||
|
|
type: Standards Track
|
||
|
|
category: Core
|
||
|
|
status: Stagnant
|
||
|
|
created: 2017-08-15
|
||
|
|
---
|
||
|
|
|
||
|
|
## Simple Summary
|
||
|
|
|
||
|
|
This EIP proposes to make contract creation fail on an account with nonempty code or non-zero nonce.
|
||
|
|
|
||
|
|
## Abstract
|
||
|
|
|
||
|
|
Some test cases in the consensus test suite try to deploy a contract at an address already with nonempty code. Although such cases can virtually never happen on the main network before the Constantinople fork block, the test cases detected discrepancies in clients' behavior. Currently, the Yellow Paper says that the contract creation starts with the empty code and the initial nonce even in the case of address collisions. To simplify the semantics, this EIP proposes that address collisions cause failures of contract creation.
|
||
|
|
|
||
|
|
## Motivation
|
||
|
|
|
||
|
|
This EIP has no practical relevance to the main net history, but simplifies testing and reasoning.
|
||
|
|
|
||
|
|
This EIP has no effects after Constantinople fork because [EIP-86](./eip-86.md) contains the changes proposed in this EIP. Even before the Constantinople fork, this EIP has no practical relevance because the change is visible only in case of a hash collision of keccak256.
|
||
|
|
|
||
|
|
Regarding testing, this EIP relieves clients from supporting reversion of code overwriting.
|
||
|
|
|
||
|
|
Regarding reasoning, this EIP establishes an invariant that non-empty code is never modified.
|
||
|
|
|
||
|
|
## Specification
|
||
|
|
|
||
|
|
If `block.number >= 0`, when a contract creation is on an account with non-zero nonce or non-empty code, the creation fails as if init code execution resulted in an exceptional halt. This applies to contract creation triggered by a contract creation transaction and by CREATE instruction.
|
||
|
|
|
||
|
|
## Rationale
|
||
|
|
|
||
|
|
It seems impractical to implement never-used features just for passing tests. Client implementations will be simpler with this EIP.
|
||
|
|
|
||
|
|
## Backwards Compatibility
|
||
|
|
|
||
|
|
This EIP is backwards compatible on the main network.
|
||
|
|
|
||
|
|
## Test Cases
|
||
|
|
|
||
|
|
At least the BlockchainTest called `createJS\_ExampleContract\_d0g0v0\_EIP158` will distinguish clients that implement this EIP.
|
||
|
|
|
||
|
|
## Implementation
|
||
|
|
|
||
|
|
## Copyright
|
||
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|