Update EIP-7702: refine based on discussions

[lightclient]

Based on some discussions I've made the following updates:

• deploy code via template (copy from existing address) instead of specifying code directly
• reduced the per auth base cost to 2500, mostly to account for reading the template account
• sign over the template address instead of code

Additionally, I have added a lot of rationale for why decisions were made.

[eth-bot]

✅ All reviewers have approved.

[derekchiang]

I just want to clarify that, given the discussions on eth magicians, it's clear that many (most) of the updates in this PR are still in contention (even among the EIP authors), so I personally don't think that this is a good time to merge this PR, considering that we will have another ACDE meeting coming up to discuss 7702 and hopefully align on some of these potential updates.

Merging this PR now might mislead the core devs and other community members into believing that decisions have already been made one way or the other, when in reality the discussion is still very much ongoing.

Edit: there's now broad agreement on most of the points in this PR, after the last few meetings/breakouts.

[github-actions[bot]]

The commit 23f2ec02c7b49159b496df7a4aa1f25bf70cbab3 (as a parent of 133edf9abf6f7618f5192c0a154603992011a3c1) contains errors. Please inspect the Run Summary for details.

[Jrachman]

Some thoughts I'd like to bring up as I review this revision:

In the case of multiple tuples for the same authority, set the code specified by the address in the first occurrence. (ref)

So this means that if we have tupleA and tupleB where tupleA comes first in the list and both ecrecover calls come out to be authority, then the code of authority would be set to tupleA and tupleB would be ignored?

Furthermore, specifying code directly would again make it possible for EOAs to have a new, unique ability to execute arbitrary code specified in the transaction calldata. (ref)

Isn't this a good thing? I believe the context this is in makes it sound like a bad thing. I bias towards maximal flexibility. This "creation by template" doesn't necessarily mean that what the EOA can sign/execute is constrained right? It is just choosing the way that code should be signed over?

The main families of instructions where a ban was considered were storage related and contract creation related. (ref)

Potentially dumb question but what happens if an SSTORE opcode is called within a 7702 transaction? Would it just not do anything or act kind of like memory storage because EOA's don't have built-in storage? Also, what are the unnecessary inefficiencies with an external storage contract? - would love to identify them to keep note of them.

A hotly debated element of this EIP is the need for in-protocol revocation. (ref)

I wrote some thoughts here around time-based revocation. Not sure if it is at all useful here but thought I'd throw it into the ring.

The following is a non-exhaustive list of checks/pitfalls/conditions that delegate contracts should be wary of and require a signature over from the account's authority: (ref)

Would this list of params be signed over in the data field of the 7702 transaction? Thinking about this like it's what you sign over in execData for 3074...

[frangio]

If I produce and broadcast one 7702 signature without nonce, I can never again use 7702 without the risk of being frontrun with my previous signature to prevent the new code from being deployed on my account. This does seem like something the protocol should give tools to prevent.

[smartprogrammer93]

If I produce and broadcast one 7702 signature without nonce, I can never again use 7702 without the risk of being frontrun with my previous signature to prevent the new code from being deployed on my account. This does seem like something the protocol should give tools to prevent.

@frangio I am not sure how would be front run. If you send a 7702 tx that you control what authorizations go inside it. Even if there was a 7702 tx before, it wont affect how your tx is executed.

[frangio]

Right, I was thinking of a bundle submitted by a sponsor, and "frontrunning" in the sense of including an authorization before another in a 7702 tx authorization list.

I guess that clarifies why it shouldn't be considered a problem? A sponsor can always just choose not to include your signed authorization, so including two of your authorizations as a way to censor one of them is not really a new capability.

[smartprogrammer93]

@lightclient can we specify exactly the behavior in case the validations of an authorization fails? my assumption is that it gets ignored but the tx goes through regardless. if that is not the case and tx should fail, do we spend all gas? seems excessive.

[yperbasis]

Let's clarify how null nonce (as opposed to zero) is encoded in authorization_list. I suggest to encode it as an empty RLP list to differentiate it from a zero nonce, which is encoded as an empty string per the RLP spec.