Ethereum Forks And Their Impact On Smart Contract Security

Transcript

Hi everyone. I'm Don. I'm a security engineer at Signal Prime. Uh we're a blockchain security and R&D firm. Uh we do security reviews onchain and offchain stuff and we've also got some cool projects uh like Lighthouse the uh consensus client for Ethereum and Anchor uh the SSV client. Uh so this is a talk uh I made on the Ethereum hard forks uh and how they affect uh smart compact security. Um so and he focus in particular the Fusaka uh upcoming hard fork. Um so if you are a developer or a security engineer uh working on Ethereum smart

contracts and you have no idea uh what's in the upcoming Fusaka fork uh this talk is perfect for you. All right. So, I'll start uh start off with an overview of the upcoming forks uh sort of in terms of scope and in terms of timeline. Uh then I'll hopefully try to convince you why this matters uh why you should pay attention to this. Uh then we'll actually dive into the changes uh in Fusaka. Then we'll have a look at uh Glamsterdam uh which is the fork after Fusaka. and then hopefully we'll have some time uh left over uh for Q&A.

All right, so currently we're on the PCRA fork. Uh it was activated I think in May this year. Uh it contains some cool features uh like account delegation with 7702. Uh then the next fork is Fusaka which should um activate in I think a little under two weeks. uh it contains uh the major feature feature peer and then the fork after that is glam. Okay, so why why um why does it matter? Why should you be paying attention to these forks and their funny names? Um well the pro the core problem here is that smart contracts are immutable uh but the EVM is not. Uh and that can cause issues. Uh if we go for example

with the Jenga analogy here um if your smart contract is on top uh and the EVM changes below uh well the stack might come tumbling down uh and that's not great. Uh the Ethereum core developers they try really hard uh to ensure there's no breaking changes uh in each fork. Uh but sometimes changes have to be made uh and in such a case it's really important uh to be aware of these changes uh and to take action uh if it's required. The great news here is that the changes in Fusaka uh are much less severe than uh compared to PCRA for example. Um if you remember in PCRA we had AIP7702 which introduced delegate accounts. Um

and that broke uh this check right here message sender equals transaction origin. Um that caused a lot of issues. Um many large Ethereum projects uh for example L2s relied on this check to ensure that um a a transaction was sent by a EOA and not a smart contract. Uh and this uh EIP broke that check. All right, let's dive into the actual changes uh into Fusaka.

Uh so first off, there's two changes to the mod exp pre-ompile. Uh mod XP is a pre-ompile for modular exponentiation. Um it's not used that often. Uh but it's used in cryptographic operations. Uh most notably RSA verification uses it. Um if you want to call mod XP, you'll have to give six inputs, a base, an exponent, and a modulus. And each of these requires a length as well. Um and so currently on mainet, these inputs cannot be of any arbitrary size. Um and as you might imagine um that causes a lot of difficulty for implementations uh and as a result mod XP has been the

source of many consensus blocks uh in the past and that's why this EIP um has sort of been uh is now is now included in Fusaka and the idea is that after this EIP is activated the each of these inputs must be 8,92 bits or smaller Uh so there's a limit on input size. Uh now that means that if your contract currently on mainet relies on mod XP with these large inputs um then that will actually no longer work after this EIP is activated. Um, so if you if you send uh an input larger than 8,192 bits after Fusaka, the pre-ompile will

actually return an error uh and it will consume all the gas uh which is not great, right? That'll basically cause uh DOS issues in your contract. The good news here is that the EIP authors um did some analysis and they found out that there's basically never been an a successful invocation of mod XB with an input larger than 513 bits. Um so all in all it's expected that this really won't break anything. Um the majority of the infocations even use size 329 uh 28 and 256 bits. So that's all in all quite okay.

The second change to model exp uh is a change to the gas schedule. Um the gas schedule was changed to this function. Um now I know it's kind of boring so I won't explain it all. I'll give you the TLDDR uh which is at the minimum cost was increased to 500. The general cost was tripled. Uh and there's an extra cost for large inputs uh larger than 32 bytes. Um so the impact here again is if your existing contract uh calls mod XP with a fixed uh gas typocation will actually run out of gas uh causing

errors and a revert. Uh so this again can cause uh DOS issues for existing contracts that use mod XD. Um in general assuming that any gas cost in the AVM is going to remain fixed is a bad idea. Uh so you should really not assume uh fixed gas costs. The third change is uh the introduction of a gas limit cap uh for transactions. Currently a transaction can basically take up the whole block uh which is 45 million gas today. Um and after this EIP uh a transaction will be limited to 60 million gas. Uh basically

uh decreasing the maximum size by three times. Um so the impact here is that functions that require a lot of gas may no longer be executable. Uh to give a quick example here, the top function um is a bad implementation. If the user uh array grows too large then at some point um the function is going to require much more gas than the 16 million limit uh and will be unexecutable uh because it will always revert. Uh the second function is much better. Uh there's a start and limit parameter uh and can and as such it can be called uh across multiple transactions.

Um so this is this is a known a known issue uh for Ethereum. Um and we often see that for these kinds of easy view functions uh clients do um implement a second version like the good version um but it's also important to notice for more complex functions complex functions like liquidations for example um this should also be taken into account um you can maybe imagine uh a user if a user is is uh liquidated there are multiple positions let's say that have to be liquidated it at once. Um, and that may also cause these types of issues. Um, so it's important to keep that in mind.

All right, these last three issues were the only ones in Fusaka that will impact existing contracts. The following two um will only impact uh new contracts. So there's a new uh up code in town uh CLZ count leading zeros. Uh it's a great up code. It'll make some math and crypto operations easier. Uh it allows you to count the leading zeros uh in a stack element. Um now the issue with a new up codes is that um L2s might not immediately support it.

Um so for example, yeah, that's that's an issue when you deploy a contract uh which uses CLZ uh on a chain that does not support CLZ. So for example um let's say you have a contract with a deposit function and a withdraw function and the deposit function does not make use of CLZ um then users can just freely deposit money everything will work um while when they call the withdraw function and CLZ is uh triggered uh a revert will occur because the L2 does not support CLZ and as such funds will remain stuck in the contract.

not great. Um, for now, Solidity does not support CLZ. Um, there is, however, I think a pre pre-release version uh, which does allow CL uh to be used in assembly blocks. Um, but generally it's not yet not yet used in code generation, but of course, expect this uh to change. Then there's also a new pre-ompile uh the P256 verify pre-ompile which allows uh EC ECDSA signature verifi verification over this particular curve.

um if you call it with a public key and a signature, it'll return uh one if the signature is valid. And similar to EC recover, it'll return the empty return data if the signature is invalid or if the inputs are generally malformed. Um so similar to the last issue, the the problem here are L2s that don't immediately support the pre-ompile. Um, currently Solidity does not support P256. Um, so you have to use a low-level call.

Um, yeah, a note here is if if you use a low-level call, um, and the contract does not exist, for example, if the L2 does not support it, uh, then the EVM will return successfully by default, uh, with no return data. So there may be some, uh, confusion there. All right. So those were the changes in Fusaka that will actually impact smart contract security. There's of course many other uh most notably pardas uh which will increase the number of blobs available. Uh and there's a lot of other changes as well uh but again these should not really impact smart contracts so I'm not going to go over them.

Nice. Uh we can look forward then to Glamsterdam which again is the fork after Fusaka should be coming next year. Uh Glamsterdam is currently uh currently has two headliners EPBS and block level access lists. Uh neither of these should have any impact on smart contracts which is great. Um and then there's many other uh proposed EIPs currently. I think roughly 50 are currently proposed. Um of those the ones that have uh any impact on smart contract execution uh we can basically sort them into three major uh categories that is new up codes, new recompiles and gas changes. Um

we don't know of course yet which one will actually end up in in Glamsterdam but it's pretty pretty clear that some combination of these uh categories will end up in Glamsterdam. Um so again to for new up codes and new pre-ompiles uh the potential issue there are L2s that don't immediately support it. Um so you have to watch out there and then gas changes are a bit more tricky. Um and the key diaries of course don't assume uh a fixed gas cost for certain operations in the EVM. Um that's really key.

All right. So to sum up, um being aware of these changes is really important. Um as as you've seen, um like these these assumptions you might make during uh development of your contracts uh can really change after your contracts has been deployed. Um the good news here is that the the impact in Fusaka is pretty limited uh especially compared to Petra which was more uh severe changes. Um and then for Glamsterdam we're not sure yet what's really going in the fork but we can expect new up codes uh new pre-ompile and cast changes. So make

sure to uh expect those. All right. Are you do we have any questions? Feel free to put your hand up. [applause and cheering] >> More of a general one. >> Yes. >> Just myself. Are there any plans at any point in time to ever add back uh any of the EI of the EOA detection functionality that getting rid of TX.org origin and message sender erased.

>> Yeah, great question. Um, as far as I know, there's no plans. Um, there is a like a new version of the check uh that can be used to still distinguish uh smart contracts from EOS EOAS and smart accounts uh which is basically adding the Xcode size uh check. Um, so yeah, that that's a way to still do this. >> Oh, hello. Uh, great thought. And I have a question about the do you know how many attacks happened because AIP 7702 changed the situ assumption?

>> Sorry, can you repeat the question? >> Oh, how many attack happened because AIP 7702 change assumptions? Yeah, as far as I know, there's not been any actual attacks uh from these changes. Um, but there have for sure been like uh yeah, some projects have had to make updates to account for these changes. Uh, for sure. Uh, yeah. >> Thank you. Is there any way to like know who the p the person that initiated a transaction initially rather than knowing the contract address or a dedicate like to

know who actually is the transaction origin starter? >> Sorry, could you repeat? like is there any way to know who actually initiated a transaction to the blockchain and be accurate that yes it was this address? >> So the question is who in initiates a transaction? The question is yes to know if an address is actually the TXO region regardless of these new changes like if I delegated to a different address can you still know that it was me who started the transaction.

>> Um yeah transaction origin will still point you to the person who who originated the the transaction. Uh for sure. Yeah. >> Okay. >> All right. I think that's it. Thanks, guys. [applause]