New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

SELFDESTRUCT Removal, Layer 1 R&D - Day 1

Ethereum DEV NLSun, Oct 9, 2022, 12:00 AM

Removing or neutering the SELFDESTRUCT opcode Speaker(s): Jared Wasinger Hosted at Devconnect Amsterdam, 2022 Visit the website: https://devconnect.org/ Or follow @EFDevconnect on Twitter

Transcript

[Music] all right so um let's talk about self-destruct so self-destruct is an evm op code um and it's been present since uh there's ethereum's genesis launch um the self-destruct op code uh when it is encountered immediately transfers the balance of an executing contract the entire balance of an executing contract to a beneficiary and returns execution of the calling frame the beneficiary being any account you choose and its argument of the self-destruct opcode um after a transaction finishes successfully where self-destruct has been called any contracts which self-destructed are removed from the state um self-destruct was modified in the london hard fork uh so basically self-destruct and self-destruct has existed from the start as a way for um contract user as a way to uh to voluntarily free up the state uh by removing contracts that are no longer used and one of the things it did was basically so if you were to self-destruct a contract it would give you it would add gas per slot per storage slot freed to the to the gas counter [Music] um so basically but so so the basically the problem that this created is that creates an incentive for creating an incentive for people to create contracts fill them up with junk storage when the gas prices were low and then later on in times of high demand they could then self-destruct these contracts and uh get uh get some of the gas back that they had previously stored so this was removed in the london hard fork um just as a random aside uh the parity multisig hack of 2017 um was i guess i shouldn't say caused by self-destruct but a library component of the parody multisig contract was self-destructed and so historical tidbit um so yeah why remove self-destruct um so it's a constant cost operation i think it costs eight gas um but the problem is it can remove it can cause you to change an arbitrary amount of state depending on how much code and well how much storage really the contract you're self-destructing uses um so from a client perspective this makes creating a port performance implementation that can handle can handle this case a bit more complex because you're potentially removing a lot of keys in your database so another issue is that if we go stateless and we we start having uh so when we go stateless in a vertical say in a vertical um in a situation where vertical gets adopted um when you're doing self-destructs you're adding you're really bloating the witness size potentially um so that's a problem um and then the third one is just kind of it's self-destruct is complex for implementing it creates weird logic in clients and really it's there's not as much on on-chain usage as that complexity warrants so we should remove it so eip-4758 is a proposal to do this and eip-4758 renames the self-destruct oops yeah okay it renames the self-destruct op code to send all um so it keeps the behavior where you immediately transfer transfer the balance of the invoking contract to a target beneficiary and returns execution to the calling frame but the only difference is that contracts which actually invoked send all are not removed from the state after the transaction finishes successfully um so there are some backwards compatibility concerns um and i'll i've brought up a few here so right now you can redeploy contracts at the same address using a combination of create to and self-destruct and after this change uh contract deployments in this manner redeployments in this manner will no longer work um they'll no longer work because the contract the original contract remains on the chain so you can't redeploy um so ephemeral contracts are something else that will probably be broken um and so these are contracts which are created and and destroyed within the same transaction and their code never actually lives on chain um but these there may be issues because any contract that is uh that is intended to be executed ephemerally after this will leave its code on chain um and then uh kind of a a third one that may not really cause any backwards compatibility concerns but it's kind of something to note and maybe consider is that um currently if you self-destruct so if you if an account exe if a contract executes self-destruct and the beneficiary is itself that ether is removed from circulation completely and after this change in 47.58 if it goes live that will no longer it will just remain in the account um yeah so i did some analysis to look at the usage of contract redeployments and ephemeral contracts on chain specifically focusing on the time period um since the london hard fork um and so i was trying to identify creators of ephemeral and redeploy the contracts and also the created and also the accounts where they were created um and then uh look at the ether holdings of these accounts so actually there there weren't well first of all there wasn't a huge um there wasn't a huge usage of uh contract redeployments or ephemeral contracts i mean you can you can look at the numbers in the repo i linked but even among these um none of there were only several of them that actually had significant ether balances um so two of these contracts were from a were from pine finance which is um a d5 application uh their source is verified on ether scan um those definitely warrant further analysis if 4758 um is to go live and then there's another outlier um a whale account that is just tagged as an med bot and doesn't have verified source so yeah so next steps for self-destruct removal uh i think getting accepted into into a subsequent hard fork um there needs to be closer analysis of contracts that could potentially be affected and in addition um i think that there could be additional potentially additional analysis work um to identify more of these contracts for example looking for contracts that maybe have large erc 20 or other token holdings um to see if any were missed from the analysis that i've done uh there's a so there there are some spec tests i've linked them here um certainly if this is to go forward additional spec tests will be needed um [Music] and as well as additional fine implementations right now there is a draft pr to implement this and get and that's it um yeah so that's that's all i have right now thank you for listening [Applause] [Music]

Automatic transcript — names and jargon may be misspelled.