diff --git a/HIP/hip-868.md b/HIP/hip-868.md new file mode 100644 index 000000000..95465ca01 --- /dev/null +++ b/HIP/hip-868.md @@ -0,0 +1,170 @@ +--- +hip: 868 +title: Support Cancun Self-Destruct Semantics in Smart Contract Services +author: Danno Ferrin (@shemnon) +working-group: Nana Essilfie-Conduah <@nana-ec>, Jasper Potts <@jasperpotts>, Richard Bair <@rbair23>, Stoyan Panayotov , David Bakin <@david-bakin-sl> +requested-by: EVM developers +type: Standards Track +category: Core +needs-council-approval: Yes +status: Last Call +last-call-date-time: 2024-03-06T07:00:00Z +created: 2024-01-24 +discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/872 +updated: 2024-02-21 +--- + +## 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](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/eip-6780): SELFDESTRUCT only in same + transaction + +## Copyright/license + +This document is licensed under the Apache License, Version 2.0 -- +see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)