EIP-6046: Replace SELFDESTRUCT with DEACTIVATE


  Ethereum Improvement Proposals
        
        
          
            
              
            
          
        

        AllCoreNetworkingInterfaceERCMetaInformational

      



      
        
  
    

  
    
    
    
      ⚠️ Draft
    
    
    
      Standards Track: Core
    
  
  
    
      EIP-6046: Replace SELFDESTRUCT with DEACTIVATE
    
    
      
        
      
    
    
      
        
      
    
  

  Change SELFDESTRUCT to not delete storage keys and use a special value in the account nonce to signal deactivation

  	Authors	Alex Beregszaszi (@axic)
	Created	2022-11-25
	Discussion Link	https://ethereum-magicians.org/t/almost-self-destructing-selfdestruct-deactivate/11886
	Requires	

  EIP-2681, 

  EIP-2929, 

  EIP-3529




  


  

  
    Table of Contents

    	Abstract
	Motivation
	Specification
	Rationale
	Backwards Compatibility
	Security Considerations
	Copyright



  


  
      
      
         Abstract
      
      
    


Change SELFDESTRUCT to not delete all storage keys, and to use a special value in the account nonce to signal deactivated accounts. Because the semantics of revival change (storage keys may exists), we also rename the instruction to DEACTIVATE.

  
    
      
      
         Motivation
      
      
    


The SELFDESTRUCT instruction currently has a fixed price, but is unbounded in terms of how many storage/account changes it performs (it needs to delete all keys). This has been an outstanding concern for some time.


Furthermore, with Verkle trees, accounts will be organised differently: account properties, including storage, will have individual keys. It will not be possible to traverse and find all used keys. This makes SELFDESTRUCT very challenging to support in Verkle trees.

  
    
      
      
         Specification
      
      
    


	
    Change the rules introduced by EIP-2681 such that regular nonce increase is bound by 2^64-2 instead of 2^64-1. This applies from genesis.

  
	
    The behaviour of SELFDESTRUCT is changed such that:

  



	Does not delete any storage keys and also leave the account in place.
	Transfer the account balance to the target and set account balance to 0.
	Set the account nonce to 2^64-1.
	Note that no refund is given since EIP-3529.
	Note that the rules of EIP-2929 regarding SELFDESTRUCT remain unchanged.



	Modify account execution (triggered both via external transactions or CALL* instructions), such that execution succeeds and returns an empty buffer if the nonce equals 2^64-1.



	Note that the account can still receive non-executable value transfers (such as coinbase transactions or other SELFDESTRUCTs).



	Modify CREATE2 such that it allows account creation if the nonce equals 2^64-1.



	Note that the account (especially code and storage) might not be empty prior to CREATE2.
	Note that a successful CREATE2 will change the account code, nonce and potentially balance.



	Rename the SELFDESTRUCT instruction to DEACTIVATE, because the semantics of “account revival” are changed: the old storage items will remain, and newly deployed code must be aware of this.


  
    
      
      
         Rationale
      
      
    


There have been various proposals of removing SELFDESTRUCT and many would just outright remove the deletion capability. This breaks certain usage patterns, which the deactivation option leaves intact, albeit with minor changes. This only affects newly deployed code, and not existing one.


All the proposals would leave data in the state, but this proposal provides the flexibility to reuse or remove storage slots one-by-one should the revived contract choose to do so.

  
    
      
      
         Backwards Compatibility
      
      
    


This EIP requires a protocol upgrade, since it modifies consensus rules. The further restriction of nonce should not have an effect on accounts, as 2^64-2 is an unfeasibly high limit.


Contracts using the revival pattern will still work, but the code deployed during revival may need to be made aware that storage keys can already exist in the account.

  
    
      
      
         Security Considerations
      
      
    


The new behaviour of preserving storage has a potential effect on security. Contract authors must be aware and design contracts accordingly. There may be an effect on existing deployed code performing autonomous destruction and revival.

  
    
      
      
         Copyright
      
      
    


Copyright and related rights waived via CC0.


  Citation

  Please cite this document as:

  
  Alex Beregszaszi (@axic), "EIP-6046: Replace SELFDESTRUCT with DEACTIVATE [DRAFT]," Ethereum Improvement Proposals, no. 6046, November 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6046.






      
    
  

  

    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.