DAOFest – Jaye Harrill: Quantstamp - The Nature of Immutability in opcode CREATE2

so welcome everyone so I my name is J I am the communicate I am a communications manager with quants down and my talk today was created by a few of us and it is about the nature of immutability in the wake of create - which is crate - is a new opcode that was created in order to create or in order to enable useful off chain scaling solutions create - changes the way smart contracts smart contract addresses are created they're actually created before I'm sorry before create - when the original create opcode the etherium state influenced the smart contract address that a contract was deployed to now with create - there's no this is no longer the case the etherium state is no longer required to create the address that a contract corresponds to create - also enables something else that was previously impossible now it's possible for two different contracts to be active underneath the same address at different points in time so pretty pretty interesting but what does that mean for immutability because it actually does potentially change things well let's take a look at that so with immutability before the dow we had very cipher cypherpunk attitudes you know funds can be taken from you unless you unless they had the private key not your key it's not you're not you're you know not your keys not your Bitcoin so and and that also had the question of like who should have the authority to make decisions to edit the botching well ideally in that scenario no one does you know the like I said the the attitudes were quite cypherpunk but the community subscribed to this hardline attitude towards smart contracts exploits even if these exploits led to users losing their if you lost funds because a smart contract because about smart contract loss that got hacked code is law and you had to live with the results this is because smart contracts were seen as advancing the usefulness of traditional contracts except once deployed the contract doesn't need a judge to enforce it and it must be enforced once deployed that a smart contract was equivalent to signing to a signed contract that is instantly self-enforcing code is law so it was important if someone else could come in and fix that hack what does that say about censorship censorship resistance the main selling that was the main selling point of cryptocurrencies at least at the time with immutability after the dow and nature hacks this Coda's law ideology was tested with the dow exploit this mechanism found in the Dow allowed technically was with the cyberpunk ideals and this recursive allowed the siphoning of many of a lot of funds the goal was to fund development in the theorem ecosystem and the fear in community ultimately was heavily invested in the project at one point 14 percent of all ether tokens in existence were deposit in the Dow then in dramatic fashion we know what happened an enormous amount of ether was stolen the community was devastated and the etherium bought chain or and the etherion block she was still young at the very time at very young at the time it had been only been live for less than a year the community made a controversial decision to reverse the exploit continued which forced a contentious hard fork if you're in classic was of course born and because it violated the core beliefs of what immutability stood for at that time haxe again once a play once again plagued theorem in 2017 and you know there were two parody wallet hacks that resulted even more funds denominated an ether to be locked essentially destroyed and on this occasion the etherion community chose not to hack but there's still some gray areas about immutability what about upgradable and permissioned contracts we started to slowly get into the gray areas of vulnerability it seemed became common practice to enable contract overt owners to upgrade their smart contracts upgradable smart contracts meant errors to be corrected and optimizations to be made by giving a centralized administration administrator permission to modify the code and we were okay with this because it wasn't technically changing the underlying principles of chain code but it does sort of get into a bit of a gray or have you made the immutability you know the contract owner for example could set certain privileges apart from upgrading you could for instance set a blacklist so now with with create - it's actually now even more different so let's take a look at create for just a second so how does the original create opcode work so first of all you have this your transaction or you know I'm gonna in the next evolution of create to create to is an opcode that used when you want to publish a smart contract create to is useful because it makes it easy for developers to generate a large quantity of smart contract addresses before the contract is deployed but then how does the original create opcode work before smart contract addresses before smart contract address is calculated using the address of the smart contract employer then the sender nonce and the value based on the storage on the blockchain if I attempted to deploy the redeploy the exact same smart contract immediately after I deployed the first one it would have had a totally new address because it would have a new nonce and it would have a new input value to calculate calculated to calculate the smart contract so we have the nonce with the sender address and at the same time contract address is created and contract storage is created and it's all deployed all at the same time with create - actually this has changed what you have sorry if with Korea - a contract is now calculated using initialization code and a valley called salt and the deployers address right so you can actually calculate it during deployment ahead of time but not actually the smart contract storage is deployed so your contract address is is created you can create many of these and then you can then actually deploy that using the initialization sequence it doesn't matter when I deploy the contract the contract will have the same address as long as the sender address the salt value and the initialization code stays the same and this is key so then that's where there's actually vulnerability potentially so you look at the crate tooth initialization code and it can get it can start to complicate immutability it creates a new attack vector that is now possible to completely replace a contract at a specific address with an entirely new contract in other words a smart contract under a specific address can look completely different at two points in time the key to this exploit is in the initialization code so let's take a look at the pseudocode I have here so if if time is less than a return bytecode one so there's that bytecode else return bytecode - so this contract using this initialization constructor will look completely different depending on when I publish it using the same init code it will deploy two different smart contracts to the same address depending on the time so as we move forward in time so here's the exploit scenario then you deploy a contract that seems innocent you trick the user to using that contract you self just youth maybe this contract has a self-destruct function in it you self-destruct that contract deploy a malicious contract at that same address because it's in the unit code right because we've moved forward in time and now we're deploying the next byte code and so now users are actually interacting with the same address at the a player what they think is their their contract but actually the underlying byte code and in the contract storage has changed so that actually changes again our idea of immutability so who's responsible for immutability users can now unknowingly interact with a smart contract that might look entirely different tomorrow and what does that mean for immutability immutability has gotten a little complicated but will users care are they even technical enough to look through the initialization code and figure it out users ultimately want to barely feel they're using the blockchain like in web to many future users just expect it to just work which is fair but if your user expecting it to just work but you're also told that there's this immutability function or of this entire system you're gonna use it it's gonna look like it worked but maybe your funds are actually taken in this scenario so ultimately it is up to the project's themselves to protect their users if they have a lot at risk if something happens that is outside of the expectations of the users they will lose trust of the community and develop and move on to a different competitor so there's a lot of state there's a lot at stake when the consequences are so high so you know what do you think oh sorry so what do you think about immutability where does your feelings about immutability lie does it just stay with the chain code or does it stay with the overall interaction with blockchain if anyone has a question this is this is the time to ask but if not no worries but in any in any case this talk was made possible by research engineer on our team Martin Utley with some prior research he found Julie Martinez a core person on the communications team with me and it kind of came out of a discussion that we started to have so if please feel free to reach out to me or any of my collaborators and of course you can check us out at quanta home slash solutions thank you