EIP-7702: Set EOA account code

[matt]

@yoavw

You’re taking the proposal out of context. These decisions were deliberately left open, and you’re making it seem like the original proposal considered them and decided against them by default.

All I know is that the original proposal doesn’t have many of the security features you deem critical. If they were so critical, I would have expected them in that proposal instead of the “insecure” variation.

@yoavw

Revocation is 1/6 that happened to be consistent with the 2021 version of 3074. How about chainid? Signing over address rather than code? Anything at all that this thread changed your mind on?

@vbuterin

1. Should the contract_code signature also sign over the account’s nonce?
2. Should the contract_code signature also sign over the CHAINID?
3. Should the contract_code instead be an address? This would save calldata, though only a little bit of calldata because ERC-1167 proxies only take 44 bytes.
4. Should SSTORE inside the “temporarily contract-ified EOAs” be prohibited, like it is in EIP-5806?
5. Should we have initcode and not just contract_code?
6. Should we just add a flag to NOT set the code back to zero at the end? Thereby making this EIP also supersede EIP-5003.

1. same as 3074 – should be handled by the code which the account has delegated to.
2. same as 3074
3. I don’t recall discussing whether 3074 should sign over code vs. an address. I believe it was always an address. I could misremeber though. I did consider a bit using address in the tuple but still signing over code. The main reason to not do this is you now impose a database lookup on clients before they can determine the signer of the auth tuple. The reason it’s okay to skip signing over chain id is wallets can ensure you only sign to contracts with a deterministic address. This was the same argument for 3074, but we added it because it didn’t feel like such an inconvenience. Now people are requesting the nonce be optional. At that point, we should just drop it altogether.
4. SSTORE should not be banned because smart contract wallets need to figure out how to deal with storage conflicts today. It’s a known problem and will be solved by the application layer. It’s not necessary to inhibit the protocol by it. Additionally, banning SSTORE means we can not as directly use existing smart contract wallet code. Avoiding “two tracks” of AA development is a main goal of this EIP.
5. This one I am very conflicted on. In general I prefer not having initcode as it feels weird to run initcode in accounts that have already be “initialized”. On the other, it feels weird to allow anyone to take 7702 auth tuples and force code into your account in contexts that you may not have expected. After much discussion, I feel like setting code directly is still okay to do. In either case, a dishonest user will be able to sign multiple messages and grief people sending 1155 tokens. Honest users / wallets should follow the safe guidelines, and that is to only sign a single 7702 message per account to a proxy contract. That will allow them full flexibility of changing / revoking code, without potential of being griefed.
6. This is something we might be able to do in the future, but it seems out of scope for pectra at this point.

Obviously this thread and other discussions informed my view. I wasn’t aware of issue with 1155, but I am confident the solution we proposed is suitable. If there is a better solution, we could consider.

@yoavw

after 3074 was included, based on adding chainid+revocation to overcome ACD objections, you immediately started working on removing them.

I didn’t start working to remove them. Client devs and 4337 devs beginning to ask why the nonce was there. That’s why max nonce has been discussed so much and why there have been other alternative proposals.

I have always been consistent about not wanting these values in the signature. If client teams again decide that they should be in 7702, they will be. ACD is constantly trying to do the best thing possible. That’s why we’re even discussing 7702 in the first place. 3074 was previously accepted and some are upset saying ACD shouldn’t waiver like this. I disagree. Our job is to create the best protocol we can with the information available to us.