Try   HackMD

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Future of EOA/AA Breakout Room #6

Date: July 31 2024, 14:00-15:00 UTC

Agenda: https://github.com/ethereum/pm/issues/1118

Recording: https://www.youtube.com/watch?v=Oct83bBp3Z8

Summary/Next steps:

  • Migration off the table for EIP-7702. Could be proposed as a separate EIP.
  • Not enough support for storage change, should be looked as a separate proposal.
  • Keep EIP-7702 as slim as possible to include in Pectra, include the PR in latest specs.

Links:

(Notes+zoom chat)

Nicolas: Initiated the call.

  • Going to discuss the latest change requests and hopefully by the end of this call we have some decisions for ACD call.
  • Lightclient give us a quick update

Vitalik: In a state with couple of proposed changes

  • it keeps increasing based on ongoing discussion. There is a strong desire to get to a point where we decide on Finality on spec.
  • About a week ago, Vitalik suggested breakout to discuss different ideas around.
  • And discuss the proposal to replace the current design
  • Ideas
    • Code reset opcode
    • adjusting the storage opcode
    • and more
  • We can talk about the underline philosophy

Ankit+1

  • we wrote the document on code reset
  • it is at the last mile and making suggested changes
  • A workshop posted by wallet connect folks
  • Ephimeral vs non-ephimeral
  • Shared the screen to share the doc
  • Discussing mitigations doesn't feel very strong at this point
  • Focusing on suggested changes make more sense

Ansgar Dietrichs (Jul 31, 2024, 10:05 AM)
to push back on Vitalik a bit, to me it feels like there are simply still remaining open questions, I don’t have high confidence that we are in a good place to pick the final shape of the EIP yet

Ahmad Bitar (Jul 31, 2024, 10:07 AM)
I disagree, I feel like the EIP in its current shape is actually enough and covers most of the concerns.
It does feel that the remaining concerns can be mitigated by certain patterns or actions

Ansgar Dietrichs (Jul 31, 2024, 10:08 AM)
I think I said that on the last call, but CODERESET seems like the wrong direction to me. we decided early on in the process that 7702 was not supposed to ship with permanent upgrade capabilities, and this idea would introduce such permanent upgrades through the backdoor

Ansgar Dietrichs (Jul 31, 2024, 10:09 AM)
although I will admit that the additional capabilities look nice. but it should be its own separate EIP then, not piggybacking off of this one that has a very different focus

Ansgar:

  • looks like interesting feature but I am opposed for it to be in 7702 because the proposed change we considered this initally out of scope.
  • it can be good feature to have in the future but no reason to combine this with 7702

Ankit+1: I agree, this is a deviation if the EIP isn't intended to acheive the goal.

Arik:

  • the entire idea with 3074 moving on to 7702 is to align a lot of things which were not aligened with EOA, will be addressed.
  • As soon as we have those capabilities with 7702, we would be building smarter wallet and contracts to allow the better UX experience be widely adapted.
  • want to raise as the question is the ability to build code or save the code for future txs.

Vitalik:

  • unless in a way Self Destruct already work

Arik (Jul 31, 2024, 10:12 AM)
What if the CODERESET is added alone, just as a way to make a cheap/1-time delegation? Without making the change that disallows EOA transactions?

Julian Rachman (Jul 31, 2024, 10:14 AM)
You still have unlocked functionality even if the pk is the master key. I believe safe asked for more concrete reasonings from wallet providers

Sachin Tomar (Jul 31, 2024, 10:14 AM)
“the delegation designation can be revoked at anytime signing and sending a EIP-7702 authorization to a new target with the account's current nonce”
Can this new target be ZERO_ADDRESS to remove the code from an EOA?

Elias Tazartes (Jul 31, 2024, 10:16 AM)
we are designing an EIP that is scheduled for inclusion, it feels a bit bad no? how much sunk cost can we bear as a governance body

Arik (Jul 31, 2024, 10:17 AM)
Sorry Derek didn’t see you were earlier 🙏

Ivo Georgiev | Ambire (Jul 31, 2024, 10:17 AM)
There’s very little use case for one txn delegation, if not none.

Gas sponsorships are pointless because you need an eoa txn first, same goes for batching

So I can’t imagine any useful one transaction delegation use case

Darek (Wallet Connect)

  • I agree with many people including Arik
  • I talked to a bunch of wallets, Trust is a special case but other than that adoption of 7702, ephimeral case for 7702 makes it easier migration path to wallet
  • In favor of 7702 in its current form

Ahmad

  • Designation delegation fixed most of the problems, but received comments that some wallet dont like that.
  • there is always a spec which is going to be the best for most but won't work for some.
  • Code reset is not the way to go because it provided the ability inside EVM and not the wallet
  • in the last discossion, ansgar mentioned of DOS vector, may want to touch on that.

Arik (Jul 31, 2024, 10:19 AM)
reduced risk = functionality

Ansgar Dietrichs (Jul 31, 2024, 10:20 AM)
which exact version does ephemeral storage refer to?

vub (Jul 31, 2024, 10:19 AM)
Do we need a new opcode for CODERESET, or is this a small tweak to the functionality of SELFDESTRUCT?

Julian Rachman (Jul 31, 2024, 10:20 AM)
a flag be added to the 7702 transaction’s authorization_list that would designate it as ephemeral, clearing the code hash at the end of the execution

Nicolas:

  • any strong opinion on this?

David(Trust Wallet)

  • Code reset will be useful
  • batch sponsorship will be done by 7702, but many wallets need to handle key mgmt.
  • beside institutional functionality, we want to unlock some validation related features.

persistnace doesn't has to be in EOA's own storage

Ahmad Bitar (Jul 31, 2024, 10:22 AM)
7702 is not supposed to be the EIP to fix it all

Sachin Tomar (Jul 31, 2024, 10:14 AM)
“the delegation designation can be revoked at anytime signing and sending a EIP-7702 authorization to a new target with the account's current nonce”
Can this new target be ZERO_ADDRESS to remove the code from an EOA?

Ronny Panford (Jul 31, 2024, 10:23 AM)
I guess the concern is not allowing the signing key to ultimately reset the account at any time be it by pointing to ZERO_ADDRESS or null bytes. To help create credible smart accounts. Thats why CODERESET only in the contract code, is what I understand, but this opens new gate ways of concern todetermine malicious use of CODERESET. But I agree crafting this solution might be too late for 7702.

Ankit+1:

  • EOA can move contracts away
  • A question is to whom we want to delegate what job
  • one concern - why making pvt key available to root user
  • we need to educate the user
  • Even the wallet don't understand the current spec, it will be difficult to expect from the users.
  • Educating user the users will be useful
  • Over 99% tx on mainnet do not have TVL

lightclient (Jul 31, 2024, 10:24 AM)
you were never supposed to get security of smart contract wallets

derek (Jul 31, 2024, 10:24 AM)
@Derek could you type out here again why some wallets you talked to felt that 7702 in its current form wouldn’t be widely adopted? I didn’t completely catch your point

Ahmad Bitar (Jul 31, 2024, 10:24 AM)
7702 was not aimed to fix this

Ahmad Bitar (Jul 31, 2024, 10:24 AM)
7702 was not aimed to fix this

lightclient (Jul 31, 2024, 10:24 AM)
where have you been the past year?

Julian Rachman (Jul 31, 2024, 10:24 AM)
Does that really create a new account though? It is just an eoa with smart functionality

Sudeep | Erigon (Jul 31, 2024, 10:24 AM)
I think the feedback from wallet teams was the opposite some time back — an account should be able to act as both EOA and SCA — so that the apps which EOA interact with continue working; and then SCA based functionalities/dapps can be optionally interacted with (and slowly transitioned to).

gajinder (Jul 31, 2024, 10:18 AM)
ephemeral storage takes away none of the functionality and reduces complexity

Ansgar Dietrichs (Jul 31, 2024, 10:25 AM)
ah. then I would just ban storage within 7702 accounts completely, instead of turning it ephemeral. but we discussed this a few months ago - the feeling was that it would be better to have decisions mirror the 4337 situation

Ansgar Dietrichs (Jul 31, 2024, 10:25 AM)
so rather keep storage enabled, because changing implementations is already a problem that the 4337 ecosystem has to solve. otherwise we end up with 2 separate tech stacks again

gajinder (Jul 31, 2024, 10:26 AM)
or this PR: https://github.com/ethereum/EIPs/pull/8762

Francisco (Jul 31, 2024, 10:26 AM)
7702 is not migration, education should start by avoiding that term

Ivo Georgiev | Ambire (Jul 31, 2024, 10:26 AM)
Also please let’s not forget the signature complications from the concept of converting EOAs to real smart accounts

ankitchiplunkar (Jul 31, 2024, 10:27 AM)
https://hackmd.io/-V7ywDDZRDKrXMRRkulOpQ?view

Matt:

  • ENS is at risk
  • I took a random token and found that at risk
  • I think ENS with billion dollars is at risk and I won't do that to put it on risk

Aniket+1

  • there are two tokens are at risk

Jochem (EthJS) (Jul 31, 2024, 10:28 AM)
What is the ENS risk? Someone has a description of this problem?

Ahmad Bitar (Jul 31, 2024, 10:29 AM)
the idea is that, if the EOA key is leaked somehow, then the assets are still secure if the migration to sca is final
but looking at ENS token for example, you find this to be un true

lightclient (Jul 31, 2024, 10:29 AM)
ENS doesn’t support 1271 so a EOA pk can spend the funds even if EOA is migrated

Sudeep | Erigon (Jul 31, 2024, 10:24 AM)
I think the feedback from wallet teams was the opposite some time back — an account should be able to act as both EOA and SCA — so that the apps which EOA interact with continue working; and then SCA based functionalities/dapps can be optionally interacted with (and slowly transitioned to).

Ahmed Al-Balaghi (Jul 31, 2024, 10:29 AM)
“wallets don’t like eoa retaining root access” is def over exaggerated < why do you think so?

Aniket+1:

  • shared screen to discuss alternate proposals
  • with one proposal if user leak their pvt key

Matt

  • there sare so many thing wrong with this comparision
  • when people migrate to smart contract wallet, they expect Smart contract wallet to secure their fund.
  • A true smart contract wallet will be in position to secure them
  • It will be difficult to educate every retail users about the security consideration.

Julian Rachman (Jul 31, 2024, 10:31 AM)
That is a reallllly binary questioning

derek (Jul 31, 2024, 10:31 AM)
I don’t think anyone is disputing that by permanently migrating the EOA, the impact of leaking the key gets lower. But that’s not considering all the other factors

Ansgar Dietrichs (Jul 31, 2024, 10:31 AM)
my personal 7702 wish list:
make it fully ephemeral: store delegation target, but turned off by default. 7702 txs manually enable delegation for a list of addresses
change code read behavior to not return delegation target code
(maybe) add initcode behavior, running at the beginning of a 7702 tx with separate gas limit

Derek (Jul 31, 2024, 10:31 AM)
SCA based functionalities/dapps

what exactly is that? atomic batch transactions and dapp sponsored / erc20 paid transactions?

Ivo Georgiev | Ambire (Jul 31, 2024, 10:32 AM)
There’s more signature risk than just permits IMHO. Just taking any dapp login as an example that doesn’t support 1271

there are even dapps which support 1271 but verify ecrecover first or as a fallback 🤷‍♂️

Matt

  • Let's simplify this for end users.
  • the point of 7702 is not to migrate EOA

Aniket+1:

  • our intent was to add some features to enhance the present proposal

Yoav

  • concerned about EOA migration
  • I like the change form protocol perspective.
  • It has some security considration
  • what the change does is alternating the account between EOA or smart wallet. Never both at any point of time.
  • we need to decide one of the proposed change and write it to the security consideration

Darek

  • two points
    • every one is aligned with the risk of migrating EOA
      • it cant be done perfectly.
      • there is no EOA migration proposal that address all risks
    • people actually want to keep their EOA
      • if people have to try out the features of smart contract, there is alternate ways to try
      • that depends on the smart contract
  • the third point is that we probably we can all agree that the most important thing is to ship this in Pectra
  • or a slightly better proposal in the next upgrade. I prefer the Pectra.

Pedro

  • Nicely put.
  • From my take, the current solution put account in an ambigous state
  • we have the ability to revet back to EOA.

lightclient (Jul 31, 2024, 10:40 AM)
we should move to the next topics, CODERESET isn’t going to be support by 7702 in pectra and there are other things ppl want to discuss

Derek (Jul 31, 2024, 10:31 AM)
SCA based functionalities/dapps

what exactly is that? atomic batch transactions and dapp sponsored / erc20 paid transactions?

Sudeep | Erigon (Jul 31, 2024, 10:40 AM)
yes

greg (Jul 31, 2024, 10:37 AM)
Does the current impl of 7702 have sstore

greg (Jul 31, 2024, 10:42 AM)
Unless we want collisions you technically need it

Yoav

  • there are user's perspective and protocol perspective

Pedro

  • the pvt key should be secondary in this migration

Ahmad Bitar (Jul 31, 2024, 10:43 AM)
it is a "delegation" and not "migration"

Agus (Jul 31, 2024, 10:43 AM)
I don't think it's such a UX problem. Smart contract wallets are mostly presented as multisigs, so it can always be displayed as if the wallet has "one more key" that is not revocable

Julian Rachman (Jul 31, 2024, 10:43 AM)
The vm and wallet interface lines are blurring…

greg (Jul 31, 2024, 10:37 AM)
Does the current impl of 7702 have sstore

Ansgar Dietrichs (Jul 31, 2024, 10:43 AM)
the same is true for changing smart account implementations today.

Pedro

  • In theory it sounds good, but may not be in practical ways.

Matt

  • until we are able to do it in a nice way, we can do it at the protocol level
  • there are other problems to be considered, but we need to focus on what it adds

Darekn (Wallet Connect)

  • Billion of dollars at risk - I still have to lose my pvt key for those funds to be at risk

Matt

  • Risk can not be fixed with 7702
  • we are just doing that EOA's can do execution txs.

pedrogomes (Jul 31, 2024, 10:46 AM)
I would disagree simply because we the current proposal is halfway-migration but we are just renaming it to delegation

Ansgar Dietrichs (Jul 31, 2024, 10:46 AM)
I am open to reopening the permanent upgrade conversation - but then we have to be okay with 7702 very possibly missing Pectra

Ahmad Bitar (Jul 31, 2024, 10:47 AM)
i am not. if we want to open the permanent upgrade conversation, it can be in a totally different EIP than this one

lightclient (Jul 31, 2024, 10:47 AM)
ephemeral setting doesn’t match with 4337

Darek

  • one wallet start using and another one doesn't then users may have issues.
  • I suggest to keep it simpler for wallets.

Vitalik:

  • it feels to me that chances of getting consensus in time for pectra is Zero
  • if we do 7702 (as is), it is still compatible for us to do migration latter
  • so I think, for questions we get consesnus around but basically ask questions for full account migration (kick the can down solution) is not do that now, and continue to be open as long as some people care about it.
  • May in long term people figure out how to do that.
  • Does 7702 as is solve all the problems, if no then see if that can be updated with a new EIP in future?

Matt

  • It make sense
  • I am not against EOA migration, but against this with 7702

Ahmad Bitar (Jul 31, 2024, 10:51 AM)
always depending on pay masters and bundlers to include my transactions is not something i want to do. I like the ability to use them without being forced to use them

derek (Jul 31, 2024, 10:48 AM)
Why don’t we tackle permanent EOA migration in a separate EIP? As long as we are aligned that 7702 in its current form is a big value add, and is NOT incompatible with future EOA migration proposals, why don’t we move ahead with it for Pectra and tackle EOA migration in a separate proposal?

As Ansgar said before, a permanent migration proposal completely changes the character of 7702 and should be considered a separate EIP

derek (Jul 31, 2024, 10:51 AM)
The very reason why no EOA migration proposal has gained any traction, while 7702 did, is because 7702 is not attempting to do EOA migration… so trying to add EOA migration back to 7702 seems like a backwards move to me

Stephane (Jul 31, 2024, 10:51 AM)
Is that the reason?

Agus

  • we rae discussing many dapps and tokens
  • dapps may have to consider this fully in order to prevent vulnaribility
  • At some point every single wallet will be smart contract wallet.

Aniket+1

  • it's a good idea to separate out the migration concerns
  • i think things to consider are the side effects
  • i know some people will be disappointed that they are waiting on support for the migration

I can only see power users wanting EOAs

Ansgar Dietrichs (Jul 31, 2024, 10:53 AM)
side note: I still like the idea of exploring modifying ecrecover to check if there is code in the account associated with the recovered address, and throw if so. not sure if good idea, but worth exploring for full migration

Ansgar Dietrichs (Jul 31, 2024, 10:55 AM)
for 3074, we even considered a variant where instead of throwing, ecrecover could call into the smart account to have it check the “signature” instead

Ahmad Bitar (Jul 31, 2024, 10:53 AM)
So, we want to force users to migrate to sca by making sure the EOA experience is bad. I hate this argument 👎

Greg

  • The fundamental thing to remember it took long to discuss 3074
  • we're not going to get everything
  • get as slim as lean as we can to hold this to make EOA a little ahead of the curve and in the next year see what i sthe best way to move this forward.

Agus (Jul 31, 2024, 10:56 AM)
we wouldn't be forcing users to migrate tho, we would be forcing dapp devs to account for smart contract wallets, the other way around

Ahmad Bitar (Jul 31, 2024, 10:57 AM)
They have to, because they will want to support delegated accounts
delegated accounts will have the exact same features that SCAs will have beside security

pedrogomes (Jul 31, 2024, 10:58 AM)
Delegated accounts is not a strong enough reason because they can still act as EOAs

gajinder (Jul 31, 2024, 10:57 AM)
+1 with greg, we should just push for completion of 7702 rather than radically change it

Eric

  • pragmatic usage of 7702 - I'd love to see modification that would make it cheaper

lightclient (Jul 31, 2024, 10:58 AM)
let’s take migration off the table once and for all

lightclient (Jul 31, 2024, 10:58 AM)
should be a separate proposal

Greg

  • where 7702 sits is not the dream but at least it gets the job done

Yoav

  • in future if we discuss we should have only one thing in
  • since we are not using this form of mitigation. It should be mentioned in the Security consideration for the awareness of clients.

Ansgar
open questions from authors pov

  1. Exact ephimeral nature of delegation
    • you turn it off default
    • to me it feels safer to keep it off (default)in case of attacks
  2. Code accesses
    • to me seems very dangerous
    • never be able to access the code to the delegation target
  3. Init code
    • In the past it wasn't considered
    • it seems reasonable to potentially have init code in

frangio (Jul 31, 2024, 11:04 AM)
is limiting to one transaction in mempool a problem eg. for UX?

lightclient (Jul 31, 2024, 11:06 AM)
i don’t see why it would since the user would most likely be using a relayer if they’ve upgraded their account
but even if not, if they are self-relaying their account supports batching so no need for multiple txs pending

lightclient (Jul 31, 2024, 11:07 AM)
if you run the initcode first, how do you determine how much gas was used to charge that user via a paymaster?

Ahmad

  • response to Ansgar's 3 points
  • I don't see the first as a concern
  • for 2nd - I agree with Ansgar
  • for 3rd - I know initializing the smart contract in current form is ugly but having init code may complicate it.

Dror

  • Regarding init code - the minimal we should add a very stron security consideration to the EIP.
  • you must have a set of signature or you are vulnerable
  • it is a call data at the begining and not the init code

gajinder (Jul 31, 2024, 11:09 AM)
can we also discuss : https://github.com/ethereum/EIPs/pull/8762 for storage colllision resolution

Ansgar Dietrichs (Jul 31, 2024, 11:09 AM)
might be some confusion on what I meant with “ephemeral”.

my question here was basically:
user sets delegation target in tx A.
in tx B, someone calls into their account. does the code run or not? (i.e. does it behave like an EOA or a smart account)

Ahmad Bitar (Jul 31, 2024, 11:10 AM)
smart account
unless A resets the delegation

Jochem (EthJS) (Jul 31, 2024, 11:10 AM)
Frontrun could be mitigated by adding ORIGIN to the authority lists: https://github.com/ethereum/EIPs/pull/8763 (but this depends upon the situation)

lightclient (Jul 31, 2024, 11:10 AM)
this isn’t needed, just use a sig from the account

Jochem (EthJS) (Jul 31, 2024, 11:11 AM)
So in that case you can ensure that a specific ORIGIN will send your tx and other EOAs cannot "steal" / frontrun your tx by either replacing another code, or setting code before your tx and performing arbitrary code execution (assuming that the delegated contract has no entry guards to check callers)

Ansgar Dietrichs (Jul 31, 2024, 11:12 AM)
the idea would be that all 4337 bundles would be 7702 txs in the future

Jochem (EthJS) (Jul 31, 2024, 11:10 AM)
Frontrun could be mitigated by adding ORIGIN to the authority lists: https://github.com/ethereum/EIPs/pull/8763 (but this depends upon the situation)

gajinder (Jul 31, 2024, 11:14 AM)
this is wallet side providing security post delegation, above Jochem's is user side, both are different

Ahmad Bitar (Jul 31, 2024, 11:14 AM)
Yeah, i was saying someone can copy the delegation from previous 7702 tx and include in a new one. if the nonce is still valid or the delegation had no nonce, then the problem is not solved. thus, i am not seeing how the ephemeral idea fixes this

lightclient (Jul 31, 2024, 11:15 AM)
to be clear it isn’t really initcode?
it’s calldata into the account they’re proposing?

Yoav

  • I'd prefer call data
  • but init code more consistent

Matt: what is the flow

Yoav

  • You set the code that allow to work atomatically

Wallet developers agrees to keep it simple

Dror

  • I understand the complexities to add any such data.

Matt

  • No problem adding security considertaion

Ansgar Dietrichs (Jul 31, 2024, 11:22 AM)
only a wallet could make the mistake of whitelisting a non-7702 contract

Ivo Georgiev | Ambire (Jul 31, 2024, 11:22 AM)
We’ve worked around the initialization issue and we don’t use a setup function so that’s what makes things easier for us

I could be misunderstanding this a bit but still two implementations is not a big sacrifice in our case

Arik (Jul 31, 2024, 11:22 AM)
It would be useful to be able to use the most proven smart contract wallet in the space…

frangio (Jul 31, 2024, 11:22 AM)
regarding gas metering for init calldata why wouldn't the user just specify an exact amount of gas and pay for that

Arik (Jul 31, 2024, 11:22 AM)
But feels like we need Safe on the call for this

lightclient (Jul 31, 2024, 11:23 AM)
i think ppl want to discuss storage

Gajinder

  • I have put up a PR
  • it is also compliant to the verkle implementation
  • this will solve the problem of conflict
  • I think it is worth to include

Matt

  • not with 7702
  • it may restrict some of the changes for EOA and smart contract wallet
  • this is not a protocol problem but a implementation problem

Ansgar Dietrichs (Jul 31, 2024, 11:24 AM)
I don’t love collision avoidance solutions that are specific to 7702, because the long-term future of smart accounts will not be 7702-based

Yoav (Jul 31, 2024, 11:25 AM)
I agree, we should have the same solution for both account types.

Gajinder

  • want to hear other opinions

Ahmad

  • since we have whitelist of designations
  • Ahmad Bitar (Jul 31, 2024, 11:27 AM)
    we can have the user clear the storage from the old wallet using the old wallet interface before migrating to the new one if aconflict could arise

Matt:

  • not enough support for storage change, should be looked as a separate proposal

Vitalik

  • the bars for changes in 7702 is difficult to get out from and will be considered as separate EIPs
  • it feels like, in general there is no consensus on status quo (have to hear again)
  • we are not rubberstamping 7702 as is but pretty close and is progress

Eric

  • everybody feels that the next iteration will be in next 2 years
  • will be nice to have some space in future forks

We still dont have proper tests. clients forked a lot in devnet-1 because of 7702 transactions

Matthew Smith (Jul 31, 2024, 11:28 AM)
matt's proposal is extremely well thought out. just a few minor points to clear up. let's ship it

Ansgar Dietrichs (Jul 31, 2024, 11:29 AM)
I still feel very strongly about code reads. I think the current spec is a clear mistake there, and would really like to see changes

Ansgar Dietrichs (Jul 31, 2024, 11:30 AM)
all my other proposed changes are more preferences, where I am happy to stick with the current spec instead.

Ahmad Bitar (Jul 31, 2024, 11:30 AM)
Agree

Ahmad

  • Code read
  • in EOF we usually try to avoid any code read, copy exit code, hash exit code, size. Basically it's Code introspection and here it does not make sense to me to allow code introspection into the EOA's delegated account.
  • My preference will be to have these specific code return the normal thing that they'd usually return for an EOA and we can simply add that to the EIP?
  • what matt and other client implementers think of this?

Yoav

  • one argument against is there are already contract that make it deliberate to not communicate anything related to account abstraction but to only serve EOAs.

Ahmad

  • so we can keep it for non-EOF

Yoav

  • yes

Ahmad

  • make sense to me

Ansgar Dietrichs (Jul 31, 2024, 11:32 AM)
there are 4 options imo:
behave like an EOA
return the raw code, i.e. the delegation format
behave EOF-like, return “0xEF”
current spec, return delegation target code

andrei (Jul 31, 2024, 11:33 AM)
current spec + allow to delegate to EOF only

Ahmad Bitar (Jul 31, 2024, 11:34 AM)
I actually like that

lightclient (Jul 31, 2024, 11:34 AM)
i think we should let pectra get a bit farther down the line, but yeah in a few months would be down to also do this

dror (Jul 31, 2024, 11:34 AM)
re: initcode:
Without initcode, we're not allowed to use existing deployed contract code, and t should be mentioned in the EIP's security consideration

Specifically, we can't use a contract code that relies on storage initialization, since any "setup" function is not protected by the "authorizer" signature (unless it performs "require address(this)==ecrecover(something)"

E.g. In the current design, signing an "authority" to use Safe's masterCopy as your account makes this transaction front-runnable, and someone could frontrun with a different setup and take over the account.

The same goes for any existing contract code, including any ERC4337 modular framework.

Arik (Jul 31, 2024, 11:36 AM)
I do think it’s something that is unfortunate - there is a lot of value with using “lindy” smart contracts…

Ansgar Dietrichs (Jul 31, 2024, 11:36 AM)
I think most people already left, we should not discuss this now
(even though I tend to agree with dror on this)

Ansgar

  • I wrote the alternative options in chat

Yoav

  • do you see anyone using this method?

Ansgar

  • it is unpleasent that we have to make these assumptions
  • I am talking conseptually it doens't see the right thing to do

Yoav

  • we should spend some time looking into it

Dror

  • Observation regarding Initialization code - you can only allow monolithinc account that requires set up

Matt

  • you can modify
  • just set up master controller

Frangio

  • Code will be reenabled
  • a discussion to be had and make a decision

Nico

  • keep it as small as possible in pectra
  • future improvements in separate EIPs.

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Future of EOA/AA Breakout Room #5

Date: June 26 2024, 14:00-15:00 UTC

Agenda: https://github.com/ethereum/pm/issues/1081

Recording: https://youtu.be/_S01TtA3lao

Next steps:

  • People are aligned to see Matt's proposal in the next devnet.
  • It will be merged in next week or so.
  • It is devnet 2 and we will take it from there. will explore more in the next stages.

(Notes+zoom chat)

Nicolas
To discuss that last update to 7702

Kevin

  • The proposal is basically serving the same purpose of revokability in the same way.
  • The new ver is also going in the same direction by trying single implementation at a time.
  • Our proposal was mimicing what proxies are doing.
  • Except migration being more difficult, I don't see the new proposal to be any different.
  • I think we're going into more permanent.

Julian Rachman

  • I am against the permanent approach. I think we talked about this throughout the weeks

Matt/Sam/Ansgar
Ansgar

  • couldn't look into proposed change

  • conceptually it is somewhat cleaner, and in principle I like it.

  • two different option to activate the delegration target

    • add another field to 7702. give a list without authentication. It will make the tx make it active when needed, not permanenetly.

Sam

  • If we're doing a permanent delegation, why not just make a tx type that deploys code into the EOA

Richard Meissner

  • So the question is if the permanent approach is an acceptable path to approach the revocation topic.
  • So far it feels that while now Nethermind is fine with the proposal, other teams that did not have too much of an issue with the revocation, would rather stick to the non-permanent proposal.

Julian Rachman

  • So why dont we just push the current 7702 language then?

kevin

  • That’s also part of the proposal Ledger made, having an access_list like option a transaction to activate or not the behavior

Richard

  • That would still mean only one delegation target at once, right @Ansgar Dietrichs

@Arik you advocated to allow multiple delegation targets, right?

Richard Meissner
basically on chain it is said which delegation target can be used, but it will only be used if you specify it in the transaction.

Ansgar

  • Basically the original version of 7702 will be used, but limited to the address (singular) that is set onchain in the account.

kvn

  • Not that we don’t like the permanent approach, it’s just like it feels like it was the kind of things that people tried to avoid during the discussion for EIP-3074 -> EIP-7702

Matt

  • In case of Revokation
    • you have given permanent delegation
  • the nice thing about 7702 is that autherization is only valide one time while setting the account.
    • the a/c is delegated to smartcontract wallet
  • now that we can write into the account feels like the best thing to happen.
  • Let people slowely migrate to smart contract wallet.

Arik
I think you can just add a small flag to decide if the delegation is single transaction or permanent and it should solve everyone’s issue…

Richard Meissner
should the single tx authorization be reusable?

Arik
No, if you used it and you want to authorize again you would need to do it on a new nonce… cause it increased

Ansgar Dietrichs
yes, I think in every variant of this, I would appreciate a one-time use flag, basically “don’t store this as delegation target at all, just use it for this tx”

Arik

  • Ansgar, I am not sure I understood the mechanism fully - can you write it down?

Ansgar Dietrichs

  • right, Richard summarized it well. With the additional asterisk that now by default “turning on” 7702 delegation for an already set target would no longer require any sort of signature by that account at all

yoav

  • Seems like the right trade off to make

Hoshiyari

  • Using this a malicious EOA would act as a genuine contract for eg; a vault until have enough funds to run away.

I was wondering how the new version can mitigate this actor vector…

Sudeep | Erigon

  • I don’t know if temporary delegation adds anything. Permanent delegation simplifies what 7702 does — which is to set a delegation designation.
    Also in temporary delegation wouldn’t you need to have a new authorization (since it’s nonce based) the second time you make a 7702 tx?

Richard Meissner

  • yes, that is basically what arik is asking for. It is basically to bring in features like batching

Ansgar Dietrichs

  • by temporary delegation, do you mean my alternative idea or the proposed one-time use flag Arik just mentioned?

Richard Meissner

  • there no long running authorization is required, it is ok to do a per transaction authorization to batch and sponsor

Sam

  • Can you self-destruct in the delegate call target?

Matt thinks

Temprorary delegate allocation does not bring us closer tothe smart contract wallet

Arik thinks other wise

  • just having the ability to delegate may increase adoption

Sudeep | Erigon

  • I don’t know if temporary delegation adds anything. Permanent delegation simplifies what 7702 does — which is to set a delegation designation.
    Also in temporary delegation wouldn’t you need to have a new authorization (since it’s nonce based) the second time you make a 7702 tx?

Ansgar Dietrichs

  • right. so in that variant, once the delegation target is set, “turning it on” within a second (or third, or fourth, …) 7702 tx would not require a signature at all. 7702 basically would have 2 lists: one to change 7702 delegation targets, that comes with nonce and sig. and then one for accounts that should have their delegation enabled, without any sigs

Arik

  • I think you can just add a small flag to decide if the delegation is single transaction or permanent and it should solve everyone’s issue…

Ansgar Dietrichs

  • so one problem with this is frontrunning the one-time use tx (e.g. for griefing the user), if you send it via a public mempool. because the sig doesn’t commit to being used within a specific tx

  • temporary delegation

  • longterm deleg

  • permanent deleg

Ansgar

  • The problem we are trying to solve is Frontrunning.
  • I am wondering any good ways to mitigate this as it is not with the protocol.
  • Matt proposal may have more context and I think could work. Unsure of any other ways to mitigate it.

Matt

  • using in temp deleg or perm delegation
  • if there is a piece of code which has risk then there is no point of having of temporary delegation

Richard Meissner (safe)

  • what is the most realistic version to push into the h/f
  • what is the complexity as we want to ship with devnet 2
  • for me this is the pressing matter that if it is enough to implement
  • there are way more qns around revokability at this time
  • consideration of security and revokability are good way to go for us
  • agree to what ansgar says about timeline

Julian Rachman

  • I guess we are using very loose terms here with “permanent”, “temporary”, etc.

Maybe current “permanent” is better said as “persistent” delegation and “temporary” is better said as “expiring” delegation

Ansgar Dietrichs

  • I would say “one-time” for those that cannot be used more than once.
    And then “optional” for those that are stored, but only active in the initial tx and in future txs that explicitly activate it again

Julian Rachman

  • Sure!! Honestly anything away from using “permanent” and “temporary” would be right

lightclient

  • ultimately you can also implement the one-time use with the current proposal

lightclient

  • so there is no need to over complicate 7702

Ansgar Dietrichs

  • on a more general note, I will say that it really worries me how much the 7702 spec is still in the air, with regard to Pectra timing.

For context though, Pectra size is very very large, so full rollout of the fork will probably take quite some time still. Imo the worst timing risk here is that Pectra ends up split into two parts, and that 7702 won’t be ready for the first part, so will end up having to wait an additional 4 months or so.

Ahmad

  • suggestion - to preserve old 7702 behaviour, we can add a boolean flag
  • the nice thing about this is that once it absorbs the nonce, we gain the implemenattion simplicity from the core dev perspective

Richard Meissner
@Ahmad Mazen Bitar how do we handle the DoS vector that @Ansgar Dietrichs outlined for this approach?

Richard Meissner

  • in the sense that the authorization can be invalidated by malicious parties

Ahmad

  • this approch of adding flagg may satisfy all three concerns with a better implemenation of EIP

Arik

  • Can someone explain why the persistence version is not attackable by this DOS vector?

Ansgar

  • the prob I see is that if you send one time use tx, and is picked up by a bundler of anyone, the tx doesn't make use

Richard Meissner

  • because if you frontrun the authorization it is available onchain
    and therefore it will still be valid in the tx that was frontrun

Ivo Georgiev | Ambire

  • Unless im missing something, temporary authorizations would be quite limited in terms of UX

You send one txn to set a delegation, so that you can then benefit from SCA features for one transaction

Sounds like something that will never be used in the wild

Richard Meissner

  • for batching and sponsoring this should be sufficient, right?

Ahmad

  • it will just validate the tx.

Ansgar

  • it will not activate and will not make use of the one time.

Ahmad

  • got it, will think about it.

Antony Denyer

  • You can basically “unbundle” it?

kvn

  • Also, the more options we have, the more complicated the Wallet UX will be… Explaining this AA behavior in ten different ways for X different AA "brands", and making sign (very powerful) authorizations 10 times, is definitely something that feels very niche to me

Ansgar

  • Pectra is very unprecedented
  • 7702 spec should be final very soon otherwise, it will not make it.
  • what could happen, that the EIP is split up in two
  • if that were to happen, we really need to decide.
  • I think we need to make decoision
    • what recommendation to ACD on what to ship in the next h/f
    • can we ship matt's change. - yes or no
    • I persopnally want to make delegation transparent
    • we should focus on the spec that we want people to use on the upcoming devnet

Ahmad

  • EOF tries to look into code & gas introspection
    • I'd try to avoid intrspection of code and account
  • If we have the knowledge of one time designation will be consumed by the sender account, then we can authorize
  • unsure if it will work with paymaster
  • also if this is a requirement to allow authorization.

yoav

  • It’s roughly equivalent to SSTORE so we could use the same pricing model (which will change with verkle)

Ansgar Dietrichs

  • on a more general note, I will say that it really worries me how much the 7702 spec is still in the air, with regard to Pectra timing.

For context though, Pectra size is very very large, so full rollout of the fork will probably take quite some time still. Imo the worst timing risk here is that Pectra ends up split into two parts, and that 7702 won’t be ready for the first part, so will end up having to wait an additional 4 months or so.

Julian Rachman

  • Do you refer to the pre-matt proposal version?

i wish we could have pre-matt’s proposal version but have come around to be ok with matt’s proposal

Ivo Georgiev | Ambire

  • Unless im missing something, temporary authorizations would be quite limited in terms of UX

You send one txn to set a delegation, so that you can then benefit from SCA features for one transaction

Sounds like something that will never be used in the wild

Ivo Georgiev | Ambire

  • Yes but you send one txn which isn’t sponsored or batched to get
    one that is? Sounds convoluted since many batches will be no more than 2 calls in the first place
    The sponsoring is even more convoluted
    I’m talking about temporary one time delegations ofc

Richard Meissner

  • would this then be like a new param in this EIP, the expected tx.origin?

Arik

  • Is it possible to make the “griefing” use case too expensive to be efficient?

Ansgar Dietrichs

  • I don’t think restricting to a specific 7702 tx sender would be the right approach, that way it would be incompatible with 4337

Ansgar Dietrichs

  • at least with the public 4337 mempool

Richard Meissner

  • could be optional xD (this is more a joke)

Matt

  • The hard thing is we have too many people with different requirements'

Richard Meissner

  • Do we have a summary on what we align on so far? Or at least 2 options that we have to decide between?

Yoav

  • not in favor of temp delegation, if we still want to mitigate the issue raised by Ansgar, it will become possible for 4337 to better use.

Ansgar

  • how will you handle different cases, seems difficult

Yoav

  • agreed
  • maybe we don't need a temporary delegation.

Sam

  • Unless you're running initcode, you don't get to revert before your code is deployed

Richard Meissner

  • Just to understand the emulation: it would still have a delegation set and therefore behave different to an EOA when being called (or being the target of the EXT* methods), right?

kvn

  • I don’t think we answered what would be the behavior of delegated accounts without the authorization in the transaction (having another list like access_list basically was mentioned ?) and in the context of transaction type < 3 ?

Sam

  • Wouldn't it be a self-destruct?

Yoav

  • if used during a tx, and says now it is becoming validated, it could work.
  • It is hard to think of all the scenarios.

Matt

  • we can’t use the storage
  • the protocol should not touch the user space storage

Kevin

  • we kind of changed the opinion on that, but I understand.

Ahmad Mazen Bitar

  • I dont think client teams will go to change this on devnet1. We already finalized devnet 1 spec

lightclient

  • agreed, this would really be for devnet 2

Ansgar Dietrichs

  • what is devnet 2 timing? would we have to decide on the spec to use by next acde?

Nicolas

  • let's go for last round of for and against
  • dev and researcher thinks this is

Richard M

  • might be helpful to go one more time
  • we don't allow temp delegation
  • will be dependent on nonce

Ansgar

  • we seem to mostly align with Matt's proposal as the next step
  • we can explore my proposal as conceptually the extension of Matt's idea
  • my qn- do we have people on the call who strongly oppose matt's or my proposal as matt's extension?

Ivo

  • I am opposing temporary delegation
  • there are various AA cases where it works better
  • eg. for batching

Sam

  • If the delegation target is stored in code and you can change your delegation target, then you can mutate your account's code.

Julian Rachman

  • I mean it would be wrong to not say that I do like the flexibility of pre-matt 7702.

BUT I bias towards matt 7702 because we would be WAY worse off having this fall out in the worst case (knock on wood). The ethos for what 7702 is trying to do is still there and we want the ethos to be something we push into Pectra.

Richard Meissner

  • I also find the idea of Sam interesting to utilize self destruct to reset delegation.

Ansgar

  • with original 7702, it was also the sace
  • my extension of this was conceptually more permanent and advantageous

Richard

  • with intrspection, I agree the changes of behaviour. With Proxys we already have a way to look into.
  • I like the one time allowing because if it is revert, you have to create a new authorization to reactivate again
  • Selfdestruct by itself will be interesting, but unsure if it is going against the isead of deprecating self destruct.

Arik

  • I disagree with the statement regarding the batching use case - but it’s probably not worth the discussion here. 2 signatures that run an atomic 2-action code is not the same as 2 signatures that run two separate pieces of code.

But again - this is not the main point in this discussion

Sam

  • are we not planning to remove the self destruct even in the same tx

Ansgar

  • as per Vitalik's proposal - yes

Next steps

Nicolas

  • People are aligned to see Matt's proposal in the next devnet
  • it is devnet and we will take it from there.
  • will explore more in the next stages.

Matt

  • thanks for the feedback
  • will try to merge early next week
  • if any different idea is emerged may merge by the next ACD

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Future of EOA/AA Breakout Room #4

Date: June 05 2024, 14:00-15:00 UTC

Agenda: https://github.com/ethereum/pm/issues/1054

Recording: https://youtu.be/gsc_yTdHRig

Links shared:

Next steps

  • discuss this more in All Core Dev and if we want another call.

(Full Notes in WIP)

Tim Beiko: Okay, I guess we probably get started. Had a few things on the agenda for today. basically some spec discussions. Then, following up on what is best practices and the proxy pattern and see how how things go.

Yeah, let's maybe kick this off with the revocability conversation. So Sudeep, I believe you are the one who posted on the Erigon’s behalf on the magicians.

Optional revocability.

Tim Beiko: Do you wanna take maybe a minute to like, walk through your views and concerns.

Sudeep | Erigon: Yeah. So we have been considering, the security handling and concerns, and saying that it's the same as a private key or a seed phrase. I disagree there, because once you delete the wallet from your browser, the seed phrase, or the private key is supposed to be gone, and no more with the wallet provider. But with the signatures, it's a different deal like once you make a 7702 transaction, the authorizations live on the chain. And so let's say, if I don't trust the wallet anymore, and I want to move to a different wallet. Then I should have an option to do something similar to, Sign out of all accounts, or sign out sign out of all devices. There has to be like a mechanism for that. otherwise, there's always a lingering question about Is it safe? There was an authorization that that was there, and it wasn't really revoked. So what what happens there?

Sudeep | Erigon: Second point is that the people who are opposed to revocability. I don't think they're opposed to revocability as such. But the constraints that it poses on the wallet providers. and I think the nonce solution, nonce revocability is definitely too constraining for the wallet providers to create a proper ux. So I think we should investigate like more solutions. Certainly, Max nonce is one such option. The nonce manager is one such options. I think we can like come together with come together with more solutions on top of this, which have revocability baked in, and also allow the wallet providers enough sort of breathing room to create the UX that they want.

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Future of EOA/AA Breakout Room #3

Date: May 29 2024, 14:00-15:00 UTC

Agenda: https://github.com/ethereum/pm/issues/1053

Recording: https://youtu.be/0vHHhZgrJ58

Links shared in chat:

Next steps

  • next call - 1 week from now, then bi-weekly
  • start working on best practices

By next call we hope to

  • explore different specs & changes by Vitalik
  • ERC Proxy [Richard & Ansgar]
  • getting progress on best practice document [Ansgar]

Agenda

Tim: Since the last meeting, PR on EIP7702 and the Berlin talk are the two main things.
Hopefully, we can discuss and get next steps.

Matt: PR is based on different convo in Berlin and at different places.
In Berlin, we talked about some restrictions with wallet devs over there.

Takeaways from Berlin

  • will not have a flag to persist the code, because of open question of EOA
  • need to do more research on storage allowances

Issues

  • storage key collision between…, added 7610
  • Replay protection

Ansgar:
In Berlin , different dimensions and open questions were discussed.

  • How do you specify the target
    • specify the address and not the code
  • Decision is that launching something that is already having flag is not right
  • other than storage, the other big thing was to start working on a wallet guidence
  • how should this be supported by Ledger brought different questions and concerns, thus warrented for a guideline

Pectra 7702 spec

Update EIP-7702: refine based on discussions

Ansgar Dietrichs
I really think this PR should be merged instead of being the perpetual catch-all for all changes to the EIP. I keep meeting ppl that only see the main EIP and are unaware of any of these changes.

AA Berlin Workshop Summary

Open questions:

Replay Protection

Ankur Dubey
Just to confirm, for replay protection has it been decided that both nonce and chain_id will be optional, by setting it to 0?

Julian Rachman
And then nonce would be set to null

Daniel Lehrner (Besu)
Yes, just one correction: nonce must be null, not 0 to be optional. Because nonce 0 is a valid value.

Storage Restrictions

Yoav:
@lightclient @Ansgar Dietrichs update re storage. I talked to the solidity team and they started looking into supporting storage layout remapping. Just got off a call with them and they're on it. If we agree on a standard for storage bases, it can be made safe without sstore restrictions.

Basically resolving this old issue:
https://github.com/ethereum/solidity/issues/597#issuecomment-1537533170

  • whether to make it safe

Felix:

  • it is usually unsafe to sign conflicting code, the safe side will be to allow only one proxy
  • it will allow contract development system to develop the idea of storage system as it is fairly new

Konrad

Richard Meissner
I tend to disagree @Konrad. I.e. with Safe the implementation effort is little, but migrating users is a huge effort. Also auditing this and performing formal verification with external storage increases complexity.

Ahmad

  • specifying a proxy and only allowing single contract

Felix

  • the difference is that changing destinantion of the proxy
  • if want to switch from one to another wallet type, initially you'd point the proxy and when want to point to another wallet
  • with authorization approach, you'd be allowed to sign by anyone and run code in the context of account. Will be more risky as it is not an onchain action to designate which code to be run.

Richard Meissner
It is possible, but definitly way more effort than when we can directly use existing contracts. (Note: I do not see this as a blocker, just a comment on compexity)

Ansgar Dietrichs
I will say, if we think the “only one authorized implementation at a time, with changes requiring onchain actions” pattern is desirable, we should think about a more fundamental change to 7702 instead of just enshrining a specific proxy as target

Ahmad:

  • it does not make sense to restrict the design

Richard Meissner
I tend to disagree @Konrad. I.e. with Safe the implementation effort is little, but migrating users is a huge effort. Also auditing this and performing formal verification with external storage increases complexity.

Richard Meissner
As said it is not a blocker, but we have to consider our existing users. Maintaining multiple contract versions is not really efficient over a longer time

Konrad
Could this be determined at runtime (ie having a flag that determines whether to use contract storage or external storage)? That way it’d only be one codebase

Ansgar Dietrichs
I agree with felix to some extent: there is some risk that given pectra might be relatively soon, that we don’t have enough time to fully figure out best practices. in an ideal world then wallets would wait before adopting 7702, but competitive pressures might make this infeasible

thogard
Could use a diamond storage pattern with address(this).codehash as the storage salt?
But I agree w/ yoav - sequential storage would be a nightmare

Ahmad:

  • I will not prevent SSTORE

Tim

  • So the SSTORE will act like what TSTORE does

Ahmad

  • Yes

Yoav

  • We don't want it to work like TSTORE
  • say, setting a threshold for an implementation and the threshold increases. We should not change the semantic

Richard Meissner
Agree with @Yoav I.e. for a normal Safe you could replay txs as the nonce is in storage that would be reset

Ansgar

  • External storage may be the better way

Richard:
One point for the external storage pattern was, that keystore related pattern are going in a similar direction

Ankur

  • Allow the user to specify the additional contract storage address
  • if the user want to switch to another application, it switch to another storage code

Dan Finlay
I thought part of the 7702 motivation was reusing existing code, so making a big difference in the behavior or implementation of these account extensions would seem like it compromises the benefits over 3074.

Dan Finlay
I’ll note 3074 avoided storage issues.

Richard Meissner
That is because 3074 acts like an external storage holder, right?

Dan Finlay
right

Richard Meissner
But agree that with allowing storage it would provide more benefits

Dan Finlay
the invoker initiates the message on behalf of the user

Ansgar Dietrichs
I think it is pretty binary: either there are no changes, or it requires rewrite anyway

elim
Using existing code as-is would be the dream. But if it requires minimal modifications, imo it's still better than an entirely different architecture as required by 3074. Since the 7702 modified wallets can still be used as-is for native aa.

Dror

  • How much external storage change the implementation to EOA

Ansgar Dietrichs
I also strongly disagree with implicit tstore behavior. if behavior is not identical, making it explicit breaking instead of implicit unexpected behavior is much preferable

Ansgar Dietrichs
storage contract defined in tx would not be forward compatible with later permanent transitions, no? unless we would then store that storage contract location in the verkle node and have this difference of former-EOA contracts forever?

Ansgar Dietrichs
I don’t think we can make final decisions on storage today. more important to figure out how we can get to making decisions on this over the next month or so

thogard
One pattern would be to SSTORE / SLOADs point at keccak(actual slot, codehash) for EOAs, but that runs into the same nonce replay issue unless the nonces are stored externally.

Richard Meissner
the "disadnavtage" with this would be that we have to touch existing opcode behaviour

Yoav
I held the same opinion until solidity agreed to add namespaced storage

lightclient
allowing storage isn’t going to block migration

Yoav
With that, it becomes easier to have a standard that all accounts should use

Matt:
Even if we have store, we see migration

  • same thing discussion
  • Solidity is able to suggest storage
  • if it is okay at the protocol level, then it is good
  • Allowing SSTORE to work as it is supposed to work in a normal contract

Tim: Let's move forward with Storage and keep discussing.

Matt

  • in 7702 it is possible to delegate to code offchain and is natural.
  • It is more likely a situation where user will end up
  • One way is to have a proxy contract that is allowed

Sachin Tomar
If we allow storage in EOA, won’t this result in storage conflict when EOA uses different implementations in different txns?

Dan Finlay
And risks the bundler including the wrong 7702 account, changing the behavior of the op

Felix
This is why I suggested to only allow a specific proxy, because then you'd at least be able to perform explicit transitions between the implementations.

Dan Finlay
Yeah, “just allowing a specific proxy” may not solve storage conflict, but does solve this important issue.

Proxy Pattern

https://gist.github.com/lightclient/7742e84fde4962f32928c6177eda7523

Matt

  • Matt thinks this addresses the issue of Offchain delegation of 7702

elim
Not necessarily the proxy code, but rather the implementation slot right?

Ansgar Dietrichs
I don’t dislike one proxy contract, but I would be very reluctant to enshrine it in the protocol. better to enforce via wallet whitelisting imo

Ansgar Dietrichs
also means that every tx is more expensive now, as it always has that additional delegatecall hop

Dan Finlay
I disagree; a user with srps in two wallets could get in hazardous situations easily here

Dan

  • there can be conflicting 7702 message floating around
  • I think this is about ensuring the user about safety

SRP means Secret Recovery Phrase

Ansgar

  • open to the idea, but look more into fundamentally change 7702

Matt

  • what problem is being addressed?
  • (explained at 40 mins)

Andrew

  • extend the account scheme with verkle?

Gary Schulte
Agreed re:verkle, but presumably we don’t want to wait for Osaka for AA

Julian Rachman
So would this proxy be a built-in proxy?

Julian Rachman
Built into the protocol

vub
A few random ideas:

  1. Let the code of ADDRESS + 1 represent an EOA's "backup code", and have 7702 just temporarily flip on the backup codes of the listed accounts

  2. Add an EOF version for "this account's 7702-code is at address X"

Ansgar Dietrichs
can’t do this before eof in pectra is certain

Daniel Lehrner (Besu)
An enshrined proxy could cause problems with L2 compatibility. Not all L2s are on the same hard fork as main net

lightclient
the proxy would not use new ops

elim
Why does it need to be a proxy? We just need to record on-chain somehow who the account is delegating to. So this can just be an agreed upon storage slot. 7702 auth'ed implementations can just "promise" to verify this slot.
Can bypass the extra delegatecall

Matt

  • Merge the PR without the storage restriction
  • and we go from there
  • the client team will implement
  • the wallet team want less permissive system and we will get to know where we land

Vub - agrees

Andrew

  • Noun nonce and zero nonce

Tim: Move forward with the PR to add in Devnet 1

  • will be discussed in ACD meeting

Ivo @ Ambire
My 2c is that no storage restriction is amazing. Huge flexibility for wallet teams, no need to enshrine a contract,

And the storage conflicts are a separate issue that always existed. Yes, 7702 makes it easier for it to accidentally happen but this is up to wallet devs to prevent (make implementations that use unique slots)

Eilas

  • Noob question also that i didn’t get an answer for, why is there a keccak in the spec of the new tx type for 7702?
    It hinders ZK-EVMs

Vitalik

  • it is broader issue
  • can be a part of the broader move

Matt agrees with Vitalik.

Ahmad

  • the wallet developers gather and agree on max flexibility

Tim
+1 on ERC proxy, if we could have a draft for next week’s call that’d be great

Last changed by 
 
poojaranjan
0
1
887

Read more

PEEPanEIP video series

An educational video series talking about Ethereum Improvement Proposal (EIPs) and key features of upcoming upgrades.

Dec 27, 2024
EIP editor "apprentice" handbook

An Ethereum Improvement Proposal (EIP) is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. Ethereum Request for Comments (ERCs) are Standard Track EIPs, which are application-level standards and conventions.

Dec 11, 2024
Ethereum Improvement Proposals Insight

An Ethereum Improvement Proposal (EIP) is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. This document will provide a monthly summary of the standardization efforts for the Ethereum blockchain.

Dec 10, 2024
EIPs Insight (June 2024)

Let&#39;s follow the progress on new and existing Ethereum Standard proposals made in May 2024.

Jul 5, 2024
Read more from poojaranjan
Published on HackMD