Do you have any links to research that has been done into how EXTCODEHASH is being used in smart contracts and analysis of the potential security implications for ones that are using it? A GitHub search finding even one example likely means there are more out there in the wild.
7702 is absolutely being rushed to production. The EIP was written in 30 minutes in May and is slated for the next production release.
Defaulting to “I’m open if you can provide a practical example” is not really a legitimate reply. Changing the functionality of an ecosystem which has billions of dollars of funds reliant on immutable code should warrant a deep testing period, public test nets, prepared wallet integration and testing, public knowledge documentation and more. Application developers are barely aware of the implications of this, and previously deployed protocols will need sufficient time to migrate or upgrade code.
This can’t be a “bury our head in the sand and hope nothing bad happens” moment.
4 Likes
I think a reasonable suggestion is to add 2 opcodes. One opcode that is cheap (2 or 3 gas) to check if 7702 is in play. The other would be an delegatedextcodehash op code that is the code hash that is attached. Leave the original extcodehash as is.
1 Like
With an impending implementation date of “Early 2025,” when can we expect a test environment? This is a change that has the potential to affect all network participants in a way that is more dramatic than most previous upgrades. The end of 2024 is quickly approaching…
1 Like
It’s not major, but if there’s a simple fix I think it’s worth considering.
The basic fix I have in mind is that EXTCODE* opcodes shouldn’t follow delegations, the delegation logic would be used in *CALL opcodes only. I’m undecided whether EXTCODE* opcodes should operate on the full delegation designator, or if they should behave like EOF contracts and act as if the code was just 0xEF01. In either case this would make delegated accounts a lot more like proxies so should be less surprising.
There is a public testnet for Pectra planned to run during Devcon. This will be a great time to test, experiment and even break functionality if you can.
2 Likes
Did some gas cost analysis comparing sweeping under 7702 to 3074. You can check out the findings here:
https://hackmd.io/3PsQucEESHSSzXaWNrnDOg
TLDR: Sweeping is 3x more expensive with 7702 than 3074, which impacts end users.
While we’ve moved beyond 3074, I wanted to raise awareness about the cost implications of 7702, which haven’t been discussed much. Is there any potential for cost improvements in this use case, particularly when delegating multiple EOAs to a single contract in a single transaction? Thoughts are welcome.
1 Like
Cheap sweeping isn’t a goal of 7702.
2 Likes
You could have used the delegation designator prefix of 0xEF ++ MAGIC, i.e. EF05.
Point is that if before account could selfdestruct, and leave any assets locked in there hanging, hence worst of what attacker may attempt to do today is cause harm to the protocol by draining it, yet it will not be able to withdraw funds.
Now with this EIP, it’s EOA, which is able to control these assets, and hence it creates legitimate attack vector that pays back to attacker.
I also assume, that’s obvious that there are numerous assertions that will become faulty via isContract, like this ? Such checks, if checking for isContract==true, will result fault assertions that account cannot send auxiliary transaction while it can.
2 Likes
This one might not be as big of a deal, because OZ’s isContract function already had some noteable workarounds like contracts in construction, counterfactual addresses, etc and thus was already unreliable.
I think that eip7702 contract behaves more like an erc1967 than like a real deployed code.
Just like a proxy code, no one expect to rely on the code of the proxy itself, as the owner might change it.
Eip7702 contract is a low level modifiable proxy, and should not attempt to hide it.
That why it should be visible to the EXTCODE* opcodes, and they should use its real 0xEF… code, not the delegated contract.
1 Like
-
Flag Triggering:
- How does the flag work to make an EOA a permanent smart contract wallet?
- Is the flag set during the transaction? Can the same
contract_codebe reused, or is it one-time(will be dumped afterwards)? - Will users need to sign off on this change explicitly, or could it happen automatically?
@vbuterin @SamWilsn
-
Expensive Transactions:
- Complex
contract_codeorinitcodemight need a lot of gas, especially with things like signature checks or calling external contracts. - Could this make transactions too expensive for users with less ETH? Should there be limits on how complicated the code can be to keep costs down?
@dror
- Complex
-
Interaction with ERC-4337:
- What happens if an EOA temporarily becomes a contract wallet and interacts with EntryPoint contracts in ERC-4337?
- If
contract_codeorinitcodereverts in the middle of a transaction, could this cause invalid UserOperations (UserOps)? - Could this lead to issues with how ERC-4337 handles these failures, maybe even causing a denial-of-service (DoS) attack on the AA mempool?
@Ivshti @0xkvn
-
Unintended Behavior in UserOps:
- Reverts in
contract_codeorinitcodecould cause a bunch of UserOps to fail, especially if the code checks something like the block timestamp and cancels the operation. - Could this lead to a mass invalidation of UserOps, clogging the AA mempool and causing DoS-like behavior?
- Also, what about cross-chain replay attacks if the
contract_codeis chain-agnostic and can be exploited across different networks? - The only way it works is to ask each bundler to inspect initcode which is extremely inefficient, so we must find a way to work around this.
@yoavw
- Reverts in
The basic fix I have in mind is that EXTCODE* opcodes shouldn’t follow delegations, the delegation logic would be used in *CALL opcodes only.
This (EXTCODE* not following delegations) will break EIP-1271/EIP-6492 signatures and has very few upsides.
7702 is absolutely being rushed to production. The EIP was written in 30 minutes in May and is slated for the next production release.
That’s absolutely not what happened, there were multiple iterations, discussions and etc. Most of the concerns and points I’m seeing here in this thread have already been discussed, and most (if not all) of the compromises have been very carefully and deliberately weighted.
As for the attack vector itself, authorizing code hashes sounds like a risky idea from a security perspective in the first place. Analyzing for real-world examples is absolutely the right thing to do - if we bogged down in hypotheticals then it would be even harder to get this to production.
1 Like
Could elaborate on this? AFAIK those EIPs only check for existence of code? e.g. proxies work with them today.
I meant if EXTCODE* doesn’t follow delegations and behaves as if there’s no code for EOAs with a delegation (what @frangio is proposing), EIP-6492 and EIP-1271 will not work.
In the current state of EIP-7702, both EIPs work fantastically thanks to the Delegation Designation.
The proposal is not for EXTCODE* to ignore delegations, just to not follow the delegation pointer, so for example EXTCODECOPY would copy the delegation designator itself. IMO this makes delegations less special (just built in proxies) and should be the default spec unless we have really good reasons to do more (like the current spec).
2 Likes
It would be nice to have some of these compromises made public. 0xth0mas raised a good point in asking if there has been any links to research on how things like EXTCODEHASH is being used in protocols / security implications. The EIP specifically only mentions msg.sender == tx.origin being broken, but no mention of any real other security threats. There are already concerns regarding EXTCODEHASH raised in here not mentioned in the EIP. Changing expected functionality of existing operations when any number of smart contracts could rely on them for security does not seem like something that should be thrown to the side due to a small group weighting them.
Do we really think a short testnet before including in next hard fork is an appropriate amount of time? To be honest, smart contract wallets exist currently and AA is not a pressing concern to move to production ASAP. AA is a great UX level up, but UX doesn’t matter if protocols are being exploited as a side-effect and users are presented transactions they’re not familiar with.
I don’t mean to be overly passionate about this being rushed, but Ethereum is a base protocol supporting over $40b in protocols, potentially written with assumptions being violated by this EIP. Extreme care should be taken with upgrades like this need to be taken with every opportunity granted to client facing applications to adapt to changes needing to be granted.
1 Like
Removing selfdestruct added a security guarantee that the code wouldn’t change. This was part of the rationale for both removing selfdestruct and blocking setcode. This objection is likely the end of this EIP for the same reason.