Panel on Account Abstraction with @sarangparikh2, @gitpusha, @ThisisVanshika, @adietrichs

Transcript

[ __ ] GM super so super excited to be hosting this uh panel session with amazing people out there right uh we'll start with quick introduction hi uh I am vanshika from bichonomy and today we'll be hosting a panel on account abstraction we'll be looking at different aspects we've got uh we've got answer we've got Sarah and we've got Lewis from gelato so yes over to you uh let's go one by one for your introductions hear me ah now you can hear me hello everyone um amanska I'm a member of the ethereum

foundation research team um I have been working on a computer in the past specifically in 2020 when we co-authored an EAP that basically is the predecessor of the of the current erp437 hey everyone I am Sarang I work at Sushi swap it's one of the best dexes and yeah so I'm pretty excited about account abstraction because it makes a lot of things inside Sushi and other apps uh quite ux friendly so yeah hello hello I'm Lewis I'm co-founder of gelato Network and we've been in the area of smart contract automation relaying and off-chain computation

yeah and also obviously interested in account abstraction and I'm a 3078 maximalist I'm very very sad it was never adopted but that's gonna be a fun panel then yeah cool all right so let's begin right my very first question is for answer right there have been evapes that uh existed earlier on AAA like 86 2938 but 4337 is extremely popular and being adopted of very rapid space so how does the history looks like and uh towards moving 437 and how different it is from the older versions of AAS yeah it's a good good question so um basically I think the idea for count

obstruction has been long around for the for a long time basically the beginnings of ethereum you can go back and um look at vitalik's writings from the early days and the idea to basically give smart contracts the the ability to pay for their own transactions was there from the very beginning there was a very early APA I think 60 something right that that already proposed like a first summer naive kind of um way of doing it um it basically lay dormant just because it wasn't a priority uh until early 2020 then Vitali kind of had another write-up of where this where the state of the research was and then we back back then I wasn't at the ethereum foundation but over at consensus we as a research team we went ahead and spent the summer of

2020 basically um iterating on those ideas and bringing it in the form of an EIP that was 2938 and basically um the only difference to the this this new Erp that is out there is that we wanted to basically natively enshrine the kind of obstruction on ethereum so that would have acquired a hard Fork to to basically change the protocol and other than that basically after after we finished it became obvious that just on the protocol level we were busy with other things so there was no time to do this for now and so vitalik basically got a new team together um including UF and and Kristoff who I think talked about this last year here at East Dubai um and they basically just took this Erp

that that that that we created back then and basically ripped out the protocol parts and turned it into an ERC so ercs are standards for things that don't need a hard Fork um but other than that it's it's the ideas of course they added a lot of features now they are pay masks does it it's it's now much more of like a full featured Erp but basically the core idea is is basically kind of coming out of that tradition but but that's why now it's gaining traction because now it's finally in a form where it can just basically it's ready to go right now we don't have to wait for anything anymore that does make sense right like we do not want to change the actual protocol layer and then uh want to create something on top of it like a counter factual thing so yes so second question

for you starting right uh what are the current challenges in implementing account abstraction within the dapps I mean like at the at the application Level like there's still certain things that we we can't fix or we have to kind of like rewrite for uh you know like account abstraction to be used of them like to start with like a lot of applications which uses like signature based uh you know like methods to verify the ownership you you can't use uh account abstraction unless the EIP passes in which lets contract sign something uh but you know unless that happens we can't use it there are like a lot of prominent apps have like checks based upon TX dot origin uh which also can't get it they have for the reason that you know they don't want contracts

to kind of you know interact with each other and then there are these various nft means in drop which basically use methods uh to you know like stop like mass minting that they don't allow uh contracts to kind of do it uh though they use like very bad uh prevention they just check the contact storage but those kind of applications are still broken by you know kind of a current implementation let's say four three three seven right so and that kind of the people that this kind of also targets right like those people who are into this nft space who are kind of mass minting it but sometimes it's not going to work for them right so there has to be like a shift on how people gonna develop application where they have to all where they have to make sure that the contracts kind of support both the

Paradigm from now on and also don't couple that together with the the message or sender instead use uh different methods to kind of you know like transfer the position or have like maybe like something like deposit four where you can kind of you know uh use account abstraction and also maybe like you know store it in a different storage state or something like that right although I think kind of one interesting aspect of um that sets 437 apart from earlier versions of kind of out of protocol kind of abstraction is that it does not need like special account obstruction um like opt-in by every dab right like um the only the only thing and you're talking about this the the only thing you basically have to make sure is that

your protocol supports smart contract wallets in general I mean but my condo boards already exist today so if your protocol is not compatible with no to say for example right because it doesn't support um smart contract signatures these kind of things then of course you will also not be be compatible with with account abstraction because account again a conversation just allows my contact wallets to directly initiate uh transactions um but as long the all the pr the previous versions of relayer networks always basically require manual opt-in by dabs and now basically we are removing this restriction and for from the point of the dab as long as you're compatible with my contact wallets you will be compatible uh with the kind of

abstraction yeah and that's that's like a very good thing with what introduces is 436 seven so this is on the changes of the DAP developer side instead like you know these smart contract orders have to be smart enough to actually you know like make use of 4337 properly because if they keep disallowing contracts to be used uh you know like to be like a callable function in their own contracts we cannot kind of get the true power of a out so the next question is for you Lewis uh gelato is an automated smart contract execution now what difference does it make you know when you include the account abstraction part in that and what have been your learnings uh you know while implementing this thing I'm sorry the Acoustics are really badly

because the speakers are facing that way I'm trying to understand all of the questions but I would be lying if if I said that I understood all but it's about account obstruction and automation right um yeah okay so yeah so gelato is a smart contract automation protocol um but we also have relaying components and so on that are super useful to be combined with smart contract wallets um but for smart contract automation specifically uh actually interestingly in gelato we won um we built a smart contract wallet into the protocol that was in 2020 or so and because we really wanted every user to be as my contract wallet because then you know um everything becomes

programmable and programmatability is is the the holy grail for automation right like you can now have your assets custody in a self-custered yellow wallet and you can Define arbitrary conditions transaction flows Asset Management all these things and have them be executed for you by a decentralized network at the right time your your bank account like your your own chain bank account now becomes an automated trading tool and automated manager so it's super cool stuff um back then we worked together with Instagram and many people don't know this but instead app was also a smart contract wallet always um they're known for their D5 strategies but really when you use instead app you have to deploy a smart contract wallet

they call it these a and two years ago we worked with them on a basically account abstraction for smart contract wallets and they had this tool where you would automatically like move your funds between other and compound and so on to optimize yield there was there was before a year before urine was was there um so so so yeah it's it's super useful in general for me smart contract or account abstraction is nowadays currently it's defined as a smart contract wallet in combination with a relay Network and ESC 4337 is just a way of opening up the market for for relayers so so yeah it's definitely interesting to see in general and

probably centralization so so whatever works will works uh will work and uh yeah as long as more people use Smart contract wallets I'm happy so the question that I would have there is I think the way we think about um 437 or at least one aspect of it is that it allows a more clean separation of layers like you were talking about that you integrated smart contact wallets into gelato in the 2020 but that needed like is custom support you had to actually think about what does it mean you have to manually Implement support and in the future the hope would be that um with like 437 or future versions of that basically you no longer need special support force

my contact wallet it all basically as long as basically you can focus on your layer right the automation layer and the relaying layer and then basically just have everything else just basically natively work out of the box is that like does that fit how you think about this or like totally I think I maybe misspoke a bit like we had a smart contract wallet that we thought was cool that back then um but really the protocol was always open it just called any contract whether that is a smart contract wallet or not so it was just like for us this wallet automation was a cool thing but nowadays to be honest we work with like the knows the safe team or Instagram uh and and yeah we don't really you know think

about building smart contract while it's ourselves anymore makes sense I mean it also kind of solves one more issue right like most of the teams were rebuilding the same stuff right so we had something at sushi that we needed kind of relaying system to do that and uh if 4337 exists at that time we shouldn't we wouldn't have been building that right we were just passing on to those uh Network like you know those open networks and they could be doing that but instead we had to make sure that that runs properly there is no dos attack there is you know like it doesn't go down and stuff like that so yeah that that also kind of solves uh by 4367 so I think this is a question that a lot of people might be having that you know products like urgent uh GSN they have

been around for like a very long time but um with the account abstraction thing coming into the picture since last year there has been like a hype about it and and why is this happening right now right right um so I would say is my perspective and it fits really well with what we we said just now is basically that um so far you basically always had to have and and the reason is a little technical but you always you always basically have to have special support for whatever relay system you used and the reason I mean maybe it can go into this just briefly but um for anyone who's like a little bit interested in the technical side of things but basically if you if you have normal accounts on ethereum we call them EOS

right just normal ecdsa signature kind of based accounts um transactions that these accounts send they they are like a very simple static validity conditions right so basically you verify the signature once but then you can keep it locally in your node until it's included on chain because you you can you understand and which like it will always remain valid unless someone sends a competing transaction right if you if you basically for example you want to pay more gas and so you send a competing transaction sometimes you know you might know this from from ETA scanner so if you send a replacement transactions but other it's very simple in your transaction pool to have logic for that with smart contact wallets now if if they're able to have arbitrary validity conditions basically it turns

action could be valid one second and invalid the next Second and then valid again and invalid again and you have no idea you know do I keep it in my mempool do I throw it out you can you might be able to spam the network and then it can't be included after all so you don't have to pay for it so basically so far in the past the way people always dealt with this is by just having special logic and trusted relay systems and now for the first time visited we have a standard where it restricts the the the the the the type of validity checks you're allowed to do um payment to like a safe subset of functionality and so for the first time ever we now have trustless transaction pools for these smart for these account obstruction transactions and this is

like I mean it sounds again like a niche technical thing but it is a huge deal because once we have a trustless open transaction pool now we don't need special relay systems with special opt-in for every dab now we can have an open system and over yeah and so at least my perspective here would be I mean maybe also of course with hype it's always sometimes that's also this narrative now it's maybe it has been brewing for a long time people have talked about how uas are not great and you know how it would would be amazing as you were saying right like because my contact wallets have all this amazing functionality potentially so maybe it's part partially it's a narrative but I think the underlying technical improvements really are very meaningful I don't know if you'd agree Network as you told like things were

very rigid right so it was the first good step but we needed a way for this to kind of you know uh have into a validity layer where you could you know just provide custom logic and you could like maybe like let's say if you wanted to schedule a transaction right I can't do it with the urgent but with 4337 and you know like compliant validity instructions I could easily do that but I do feel like even though there is an open market for it which is pretty good there still would exist secondary and private markets for it because for dapps they still value occurred from the user flow that they get and like let's say for sushi like I would probably want them to come through our private obviously first and maybe if we can extract some value on top of it and if

we can't it would go through the open permissions man pool just like how you do it with the flashbots currently would a question that I would have there is like there um for gelato basically um you know in a way would you think about like some of the automation functionality that you provide also is like a almost a type of specialized like mempool where basically because you have an understanding of when when am I supposed to bring this transaction to the chain right which is functionality of course the public pools can't can't provide so isn't in a way maybe gelato like a very advanced form of like a special purpose transaction pool absolutely that's uh the way we have been thinking about it internally at

least for years now um as uh actually and I think like with four three three seven for example one of the reasons I was interested in your earlier EIP that tried to enshrine it at the protocol level is I mean first of all it doesn't make the presumption that everybody deploys a smart contract wallet um I think it was about upgrading EOS to also become sort of smart contract wallet sort of I don't want to misquote you but but something along these lines um that's one cool thing about it but the other thing is um with 4337 for example uh it's a lot of code that you basically ask people to put on their

notes there's dos vectors sure there's code around us but what I'm wondering is where do we make the cut right at what point do we say let's ossify the client should not have more codes let's not add more there's already like flash balls so now USC 4327 and like the code base is growing like this this thing should be stable ossified at what point do we say let's have the networks built on top of ethereum take care of this now of course the cool thing about eoc4337 is it is a open market proposal and that's great and in general if it really works and succeeds then I'm for it um but there's other like good Solutions out there like gelato Network being one

of them um to to achieve similar properties for users the market is more closed but we're also working on opening it up over time we're already adding node operators there's like we're not the only ones running these nodes and hopefully in two years it can be completely open and permissionless maybe it will never reach the same sort of distribution scale as an erc4337 but maybe good enough for something a service like this and and here I think the discussion like has to be had okay where do we stop because you know you could also build a 0x relay order book into a client and have an open Dax in a client but you know um yeah I think that's my my one thing where I'm not too sure like looking at the ERC there's a lot of code in there a lot of stuff that I don't know I didn't

at least two years ago Envision this to be on the ethereum client great uh so you're coming close to the time but I've got the last question for you all that uh you know with what is the future of account abstraction looking in your opinion and uh what do you think how L1 and L2 would be adopting it in the coming days sorry I really struggle honestly yeah so so question basically like the future of account obstruction where do we see it going and does it like is that distinction between layer one and Layer Two basically okay um yeah so I mean there's a big distinction for example I think stock net is this typical example where they

already enshrined it at the protocol level and sounds super cool um although I haven't tried it out to be honest um and a future of account abstraction like for for me like gelato we're like back in Focus but we also experiment like when we see cool new stuff we also try it out like we also tried out this account obstructed wallet guess that's what we call it and pretty soon was pretty obvious that the problem is really around interfaces and around interoperability between interfaces so wallet connect all these things uh because it's actually pretty hard like once you onboard a user onto their account abstraction wallet the funds are sort of stuck there none of the UI support looking into it so there has to be so much standardization around that

uh like all the uis open C and so on all the wallets have to come together and work on standards here like they did for uas and that's that's like I think as long as this isn't solved which it's it's currently is far from being solved uh um the future you know is questionable but but I'm sure that it will be solved and once once uis natively support smart contract wallets in a much better way than they do today then hopefully there will be a day where not a single account will just be in UA everybody will be a smart contract makes sense yeah I mean like current UI is completely horrible like even after having smart contact wallets from like 2018 we still have to do manual transactions like a transactions right so we still have like a long way and I completely agree on

that and not just like Stark net like ZK sync and not even like evm blockchains but like outside the ecosystem if you look at Sway and fuel they have been like going for like you know like native account abstraction and I feel like not as a joke but I feel like the future of accountabs action is getting and trying it into the protocol uh but I think you you would be the best one to answer when would that happen right and it's a good point because uh like Lewis also was saying right just just a second ago about um the question where do we draw the line of like adding complexity versus at some point basically leaving it up to layers on top and yeah I would say again 437 is also for to start with basically it is a separate kind of layer but I

think there is a desire to maybe over time talk about enshrining it like in the core and like some layer twos that in in that way basically the difference between layer 1 Layer Two is that I think layer twos are more at Liberty to experiment with these things so I would assume I would expect more experimentation around in shrining like making native in layer twos and also just in terms of adoption because for now at least there's still some cost overhead you know you have to if you want my contact wallet so I assume that like we'll see more and quicker adoption on layer twos and experimentation um but in terms of kind of like the the future I do think that um I mean as we're saying like it's all about standard standards and standardization and I think kind of 437 can can really act as like a kind of a

crystallization point for just getting people on board with with the shared standard and then we in the long run we can talk about enshrining it or not and what the trade-offs are thank you thank you for the amazing panel and can we please have a round of applause for all our speakers here all right thanks everyone please have a great evening thank you everybody thank you guys thanks all right one more round of applause for our panel please come on put your hands together yeah do we have any questions for any of the panel members if you do raise your

hand or they can come off the stage and answer questions all right so catch these guys as they come off the stage ask the many questions you have yeah oh sorry here I didn't see you over there buddy uh hey thank you for this uh panel so I have a question uh uh do I have any list of security considerations of using account abstractions because uh I know that there's several differences between the eoa like the teaks origin like the nonsense so non-camber is headed for the uh smart account so uh there's maybe other uh differences so

yeah so uh for the dev Builders and for integrators who gonna to integrate with counter abstractions and for Auditors uh there is a differences between the eua accounts so where is the list or uh do you have some list for uh for this kind of differences right it's a great question so the question like basically what are the security considerations and um I would really stress that basically the specific way eap4337 is structured is that it does not in any way require like new special support So this so so um from a dead perspective but also of

course from the like security and auditor perspective I would really think about it as supporting the current abstraction now is equivalent to supporting smart contact wallets so all the existing security considerations like for example some some devs explicitly bans my contact wallets by using like these tx.origin checks if you do this they will continue to work at least for now this Erp will not change this and it just means that over time as this Erp leads to more was my contact wallet adoption your adapt will just no longer be able to support any of these users right so so if you are today compatible and secure in interaction with my contact wallets this situation will be identical so there is no additional

security considerations entering the picture so what about non-ster settings so if owner creates the account abstraction contract the simple account and then uh distracted so nones will be resetted to zero and everyone can replay the old transactions um so the thing is the um this this like because these user operations are just like an abstract concept um it is basically the the job of the smart contact wallet to keep track of this right so so this from the outside basically there's no change like the only the only change

now is that basically this my contact wallet has to make sure that transactions can't be replayed and whatnot right yeah thank you thank you got it thank you I would say there's also one thing we noticed and part of the reason there sometimes is this requirement and protocols that the sender is in the UA is you know there's programmabilities of flash loans could become an attack Vector for some wallets so you have to be a bit careful I would say there is a change but but like you said it's basically the same that already exists with the smart contract wallets any more questions going once

all right if you have any more questions you can come and see them when they come off stage now we'll give them a round of applause sorry to make you do that three times yay