Things you didn't know about contract deployment

Hi everyone, good morning. My name is Teresa. I am a smart contract auditor at Chain Security and today I'll talk about things you didn't know about contract deployment. So I suppose many of you didn't know about contract deployment. So I suppose many of you have deployed a smart contract at some point.

And this session aims to take a behind-the-scenes look at what happens at this process. So as a short recap, these are the three ways to deploy, to initiate smart contract deployment on Ethereum. So either via the creation transaction or the create or create two opcodes. All of these will trigger the EVM to execute the init code. So it will trigger construction execution.

Now the question becomes, what if we want to deploy a contract at an address of an already existing account? Can we do that? And for that we must understand what it means for a contract for an account to exist. So let's recap that every account holds a state. We have a state that contains four fields, the nonce, the balance, the storage root, and the code hash.

And for account existence, let's go all the way back to EIP-161 that specifies prior to the execution of the init code, the nonce is incremented by one. So this means for an address with a non-zero nonce, we can say an account exists at that address. But what does this mean? What are the implications on contract deployment? Can we deploy at an address with non-zero nonce or non-zero code hash?

Well, we can't. There's EIP-64 that will revert if you try to initiate creation at an address with non-zero nonce and non-zero code hash. What about the storage? Do we need to care about the storage route? Interestingly, yes.

There's also a check on that, And this has more of a historic flavor. There are still a few contracts on mainnet that have zero nonce, zero code hash, but non-zero storage. And these are from before EIP-161 that I just mentioned on the previous slides. All right, and what about the balance? Can we create at an address with non-zero balance?

Yes, yes, we can. And then that number of way is just owned by the address. All right. Now, during contract construction, there's quite a specific behavior of the EVM. So usually, when you measure the code size of a contract from within a contract and Externally, it should give you the same size the same byte length Interestingly during deployment during contract construction.

This does not hold so measuring the code size from within and From externally will give you different Values and this is an important detail to know and from externally, will give you different values. And this is an important detail to know. And one important aspect I would also want to shed a little light on is the values XcodeHash can take. And this is specifically important. If you do EOA checks using XcodeHash, you must know what states you can be in and what values Xcode hash can take.

So for an empty account, so to recap, Xcode hash returns the code hash of the address you query. So for an empty account, that will be the value on the top right, the zero byte string. Now, if we deploy successfully to an empty address, this will just take any value the hash of the code deployed. Alright, now how can we get from the zero address from an empty account to the hash of the empty string? This is if you just send if to a random address where no contract lives.

Xcode hash will return the hash of the empty string. And also during contract construction, this will be returned. Then from this value, you can, of course, then create on this contract. Because the nonce is still at this account, at this address, sorry, because the nonce is still set to zero. So you can create on that.

Now, I want to finish off by asking if this is the complete picture. And in the interest of time, I'm taking this away for you. Well, no. You can still, still after Cancun, this still holds. So you must not rely, when you do an EOA check, that once you get the result of a random byte string that this will hold.

Because within the same transaction, contract state can still be deleted. So don't let yourself be deceived by the return value of Xcode hash. So in summary, we've seen that for account existence, the launch is incremented. And this is done before constructor execution. We learned that you cannot create on existing accounts or on UAs.

And there exists some legacy contracts with nonce zero storage, but zero nonce and zero code. And for the Xcode hash transitions, I really encourage you to try it out yourself. We set up this Remix workspace where you can measure the output of the opcodes and play around with that to really understand the transitions. Thank you very much for your attention, and if you want to reach out to us, I'm happy to chat after this talk, and you can also do so via the platforms. Thank you.

Thank you, Tersa. Question time. The one I love the most. Who is going first? Question four.

Oh, okay. I'll try. Yeah, so how would this EUA checks transform after the EIP 7702, where they implement the auth op code and then EUAs can also have EXT code? I'm not sure. Could you specify which EIP?

The 7702, the auth op code EIP, where we can delegate EOS to contracts. I see. I'm not entirely sure about that, but what is important for now, after the Cancun upgrade, is that within the same transaction, you can have a creation, and you can have any function execution, and then still the self-destruct. And that is, I think, for right now, what is often left out of sight is that, yeah, it's still the same transaction and the self-destruct can still occur. Last question?

One more question? No more question? Oh, okay. Teresa, thank you.