About HIPs

    GitHub Logo HIP-868: Support Cancun Self-Destruct Semantics in Smart Contract Services

    Author Danno Ferrin
    Working Group Nana Essilfie-Conduah, Jasper Potts, Richard Bair, Stoyan Panayotov, David Bakin
    Requested By EVM developers
    Discussions-To https://github.com/hashgraph/hedera-improvement-proposal/discussions/872
    Status Accepted ⓘ
    Needs Council Approval Yes ⓘ
    Review period ends ⓘ Wed, 06 Mar 2024 07:00:00 +0000
    Type Standards Track ⓘ
    Category Core ⓘ
    Created 2024-01-24
    Updated 2024-03-08

    Table of Contents

    Abstract

    Add support for EIP-6780 SELFDESTRUCT semantics while supporting the Hedera account model.

    Motivation

    EVM Equivalence requires that Hedera add features supported by Ethereum Mainnet (mapped to Hedera semantics). This effort also spans to the rare occasion that Ethereum removes features from the EVM.

    In this case Ethereum is wanting to remove the SELFDESTRUCT opcode in order to make future upgrades achievable. The removal of all contract state as part of self-destruction would make future data model changes prohibitively expensive. However, there were a number of contracts that depended on side effects of SELFDESTRUCT not related to the contract storage and contract code removal, namely the transfer of Ether to a beneficiary address. Similarly, some DeFi usage patterns used “transient” contracts to store data between calls within the same transaction, and self-destruction was key to being a good citizen and not leaving garbage around.

    To reduce the damage that would occur from simply disabling the opcode Ethereum decided to change the behavior of SELFDESTRUCT depending on the age of the contract. If the contract existed prior to the start of the transaction the operation would change so that neither the code nor the storage was deleted, but the ether balance would be sent to the beneficiary. This moved the operation into a “sweep” operation that allowed contracts to clean up all balance without having to query it. For contracts that did not exist prior to the transaction SELFDESTRUCT would continue to operate normally. Balance would be sent to the beneficiary, and code and storage would be deleted. Since none of this data had been part of the committed data the deletion did not impact any plans for changes to their storage model.

    Within the EVM Hedera should support a similar model, as contracts will now expect SELFDESTRUCT to operate as a sweep in some cases. Outside the EVM, however, there is no need to change any semantics. HAPI calls can still be used to delete a contract and state expiry can still delete an account.

    Rationale

    Hedera will support the EIP-6780 change to the SELFDESTRUCT operation. If the contract existed prior to the transaction the contract will not be destroyed and the contents will instead be swept to the beneficiary. Contracts within the same transaction will be destroyed as per prior behavior.

    However, since Hedera places “ownership” of token balances with the account holding the balance we will need to extend the behavior of the sweep mode to also transfer all HTS tokens to the beneficiary. Notably, for a successful transaction beneficiary accounts must support the receiving of HTS tokens via association configuration. This is consistent with current self-destruct behavior and consistent with the spirit of the Ethereum change in that code and the account are no longer deleted.

    When the self-destruct is invoked on a contract within a transaction the behavior of Hedera will remain as it currently is in all respects.

    User stories

    • As a smart contract developer I want to use the “sweep” semantics of EIP-6780 in my contracts to sweep out value (HBAR and HTS token balance) while not destroying the contract.
    • As a smart contract developer I want to be able to continue to use the transient contract pattern and have it behave the same way prior to this HIP.
    • As a HAPI user I want to be able to control my contract account in the same ways I did prior to this HIP.

    Specification

    There are no changes needed to the JSON-RPC relay.

    EVM Implementation

    The SelfDestructOperation will be re-implemented with hedera semantics. An existing hedera version of self-destruct exists that may be manipulated in a way similar to how the Besu EVM’s implementation was altered.

    The existing transient self-destruct behaviors will be retained, and the new sweep mode changes will be added. All hBar and HTS tokens will be swept as part of the self-destruct to the beneficiary address, what will change is that the contract will not be marked for removal.

    Hedera Services

    This HIP addresses only EVM changes with respect to self-destruct, and thus, only involves changes to the case where a SELFDESTRUCT is done as a sweep (the contract being destructed existed prior to the transaction in which it is destructed). When it is a transient self-destruct no changes to existing Hedera behavior will be made.

    • For a transient self-destruct the record file will record the EVM address of the contract and not any Hedera contract id.

    Backwards Compatibility

    This change could break contracts that depend on selfdestruct destroying old contracts. Relying on such behaviors has been discouraged for years and formally deprecated for at least a year on Ethereum Mainnet, so it is expected that such use cases have never found their way onto Hedera’s Mainnet.

    In the event such a pattern is discovered, the ability to use HAPI calls to delete the contract can be used as a shim to restore proper functionality between transactions.

    Security Implications

    The substantial changes of this HIP are the removal of some functionality in some circumstances. There are no known security impacts of this removal and furthermore there are no known security mitigations that require the presence of the removed functionality. It is expected the security implications will be minimal to none.

    How to Teach This

    When discussing fork compatibility it should be called out that HTS token balances will be included in sweep operations. Such documentation should already exist for the existing self-destruct behavior. Because the SELFDESTRUCT operation is still formally deprecated for remove it is not recommended that any tutorials be written to demonstrate sweep mode or transient contract deletions. Tutorials should only be written for features that have been signaled as long term stable.

    Reference Implementation

    A reference implementation will be provided later.

    Rejected Ideas

    One alternative is to simply not implement EIP-6780 and to continue to allow contracts to use SELFDESTRUCT. This was rejected because we do not want to encourage smart contracts to use deprecated design patterns and rely on out-of-date features within Hedera.

    Open Issues

    There will be EVM non-equivalences where self-destructed contracts hold HTS tokens and/or use Hedera system contracts, especially in the transient case (where the HTS tokens are transferred to the contract in the same transaction as it has been self-destructed), where the Hedera security model interacts with the sweeping of tokens and balances. For example, if, the beneficiary account doesn’t have an allowance for a token held by the contract. In this case (and similar situations) the SELFDESTRUCT will fail, where in the EVM it never fails. These non-equivalences already exist and will not be resolved by this HIP (but can be reconsidered in the future.)

    References

    • EIP-6780: SELFDESTRUCT only in same transaction

    Copyright/license

    This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

    Citation

    Please cite this document as: