EIP-684: Revert creation in case of collision


  Ethereum Improvement Proposals
        
        
          
            
              
            
          
        

        AllCoreNetworkingInterfaceERCMetaInformational

      



      
        
  
    

  
    
    
    
    
    
      Standards Track: Core
    
  
  
    
      EIP-684: Revert creation in case of collision
    
    
      
        
      
    
    
      
        
      
    
  

  Revert contract creation if address already has code

  	Authors	Vitalik Buterin (@vbuterin), Renan Rodrigues de Souza (@RenanSouza2)
	Created	2023-03-20


  


  

  
    Table of Contents

    	Abstract
	Specification
	Rationale
	Backwards Compatibility
	Test Cases
	Security Considerations
	Copyright



  


  
      
      
         Abstract
      
      
    


This EIP causes contract creation to throw an error when attempted at an address with pre-existing code. This prevents an attack consisting of deploying contract code and later changing the code arbitrarily by “creating” an account at that existing address.

  
    
      
      
         Specification
      
      
    


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.


If a contract creation is attempted due to a creation transaction, the CREATE opcode, the CREATE2 opcode, or any other reason, and the destination address already has either a nonzero nonce, or a nonzero code length, then the creation MUST throw as if the first byte in the init code were an invalid opcode. This change MUST apply retroactively for all existing blocks.

  
    
      
      
         Rationale
      
      
    


One of the core tenants of smart contracts is that its code will not change. However with sufficient computing power an attacker can change the code stored in an address to any other code, steal funds or execute other malicious activity.

  
    
      
      
         Backwards Compatibility
      
      
    


This is an execution layer upgrade, and so it requires a hard fork.

  
    
      
      
         Test Cases
      
      
    


Given a genesis allocation of


Address : 0xd0bBEc6D2c628b7e2E6D5556daA14a5181b604C5,
Balance : 1000000000000000000, // 1 ether
Nonce   : 0,
code    : "",

Address : 0x7658771dc6Af74a3d2F8499D349FF9c1a0DF8826,
Balance : 0,
Nonce   : 1,
Code    : "0xB0B0FACE",





A contract created in the first transaction from EOA 0xd0bBEc6... (227bcc6959669226360814723ed739f1214201584b6a27409dfb8228b8be5f59), with no salt, should revert.

  
    
      
      
         Security Considerations
      
      
    


This EIP is a security upgrade: it enforces the imutability of deployed code.

  
    
      
      
         Copyright
      
      
    


Copyright and related rights waived via CC0.


  Citation

  Please cite this document as:

  
  Vitalik Buterin (@vbuterin), Renan Rodrigues de Souza (@RenanSouza2), "EIP-684: Revert creation in case of collision," Ethereum Improvement Proposals, no. 684, March 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-684.






      
    
  

  

    Ethereum Improvement Proposals


    
      
        	Ethereum Improvement Proposals


      


      	 ethereum/EIPs





      
        Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.