-
Notifications
You must be signed in to change notification settings - Fork 140
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Create HIP: Adopt Cancun EVM SELFDESTRUCT semantics in Hedera (#868)
Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com> Signed-off-by: David S Bakin <117694041+david-bakin-sl@users.noreply.github.com> Signed-off-by: Danno Ferrin <danno.ferrin@shemnon.com> Co-authored-by: David S Bakin <117694041+david-bakin-sl@users.noreply.github.com> Co-authored-by: Nana Essilfie-Conduah <56320167+Nana-EC@users.noreply.github.com> Co-authored-by: Michael Garber <michael.garber@swirldslabs.com>
- Loading branch information
4 people
authored
Feb 21, 2024
1 parent
b1e53a0
commit 20a21f2
Showing
1 changed file
with
170 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 <stoyan.panayotov@limechain.tech>, 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) |