Panel on Account Abstraction

Transcript

okay let's start so this is uh it's great to be here we are going to discuss account obstruction and its use cases on ethereum so before we start we are joined by uh Lucas from safe and Scar from ethereum Foundation sain from bonomi Kell from block Scout and uh Lewis from gelato and Pedro from wallet connect so before we start if you can just introduce yourself and uh let us know what you're working on that' be great all right let me start so yeah I'm L I'm the founder of gelato Network um we did a bunch of stuff we have been around for five years actually I shared a co-working space with Lucas and I think you were there as well in full note in Berlin back in the day five

years ago full note shout out and yeah so I mean obviously gelato has been originally uh working on Smart contract automation which has its application inside of account obstruction as well uh so we're quite excited about account obstruction and automation we also built our relay API system 3 years ago for for gas transactions like back then was all about meta transactions not so much about um smart accounts yet um and uh yeah we also dabbled a bit with 437 uh just making our relay infrastructure compatible with that we we had a project with safe uh working with their conection SDK at some point um but uh more recently uh we sort of withdrew ourselves a bit from the active development inside 437 and focus more on our rollup as a service product um where

we want to work with anyone who's building 437 enabled accounts or or others uh to basically distribute them to to um developers uh but yeah I have my takes on 437 and whatnot but but yes not super actively working on it at this stage hi my name is Kil I'm an engineer and the head of protocols research at bog Scout so recently we have completed the integration of the RC 4337 at block Scout we added the full support for indexing of the account obstruction and user operations for the cold data Deon and so on super excited to support all of the upcoming eips rollup Improvement proposals and to discuss the ux implications of of

those hi my name is Pedro founder of wall connects if you don't know wallet connect it connects your wallets as it says on the name but most importantly it's an inability layer between dabs and wallets so it affects a lot of the user experience that we face today because there's a lot of fragmentation in a lot of wallets and uh wallets are getting more complex so now not only you have like external accounts but you also have Smart accounts and kind of fixing those problems is something that we focus a lot and improving the experience to have less clicks because with all of these operations and batching uh everything is getting a little bit more complex and we want the users to be completely abstracted from that hi everyone uh this is Sachin I'm from bomy uh CTO and co-founder and uh B economy uh is actually focusing on

improving the user experience um on all the blockchains so we've been here since 2019 and our main focus is purely to improve the user experiences and uh we have infra uh structure built for that um and our clients are actually application developers and wallets uh so they use our infra uh we provide gas abstraction um you know execution abstraction so all the things uh that you need to uh like do in terms of transaction management and gas management you don't have to do that we abstract all of the all of these uh at the infr layer and we started with gas L transactions in 2019 19 and then we know we uh try to solve the problem for cross chain Bridges and now we are currently

focusing fully on uh account abstraction so we have uh full stack solution for account abstraction especially 437 uh uh we have Smart accounts we have bundlers we have pay Master Solutions uh for anyone to use that uh it's a plug- inpl SDK that's where we are currently focusing on um and uh I think 3074 kind of uh slows uh the efforts on full you you know on achieving the full account abstraction but maybe we can talk about that later uh but yeah our main focus is purely on improving the user experience thank you yeah hi uh I'm Ana I am a researcher at eum Foundation now actually most of my account obstruction work used to be um at a team before that called quilt we

were at consensus and summer 2020 to Summer 2021 we basically for like a year we focus on account abstraction we create two eaps one of them was basically the spiritual kind of predecessor of 4337 that was basically anrin version that was the EAP 2938 which then because of uh 1559 and the upcoming merge basically there was no room to do that on mainnet so then people instead went ahead with basically this out of protocol version of of of 4337 and then kind of as a side product kind of like a just like a random accident there we also kind of stumbled upon the idea of like 3074 back then we basically thought that uh kind of contion just still needed some time to grow and so we thought it was like a good kind of transitionary EIP to just

make EAS have more functionality while we wait for csection to arrive I'm in this weird position now where now 3 years later I'm not so sure that it's still the right time for 3074 just because now account obstruction is so much more mature I still think if we get this right it might still basically help with getting a lot of traction around like just getting kind of dap standardized DB support for all these more advanced account features but I think um as we just heard on in in in the previous talk right I think there now also is a lot of downside risk of like if we don't get this right we end up with like two separate tax stxs here so so I don't know I'm basically just now entering the C obstruction space again to to help kind of guide this a little

bit to close the round I'm Lucas from safe we have one goal one goal only to make every account a smart smart account because it will make the ecosystem much more secure um I used to say uh more convenient than secure convenient part maybe we will have uh 3074 solve but it will definitely make uh EOS more secure and we do bunch of things like uh open source developer tooling uh infrastructure interfaces to and ecosystem initiatives to support that but but really we want to do is to accelerate this transition to smart consons thank you all so uh my starting question would be that 4337 is just the first step in the long journey of a cont obstruction so and like to start with you in knowing uh when the eventual road map of a on

ethereum finishes what it's going to look like to transact on ethereum uh what's the ux going to be and what are we exactly abstracting away at the protocol layer audio is a little bad but I'll try to answer from Frome um so yeah kind of the I I think the the the the road map for constrction on on on ethereum is is is a little messy right now right because we have we these kind of two two separate paths now now with kind of 437 which is the proper way to do full account obstruction but it also is basically requires more of an active kind of effort for op opin support for deps and everything so it's still in a more kind immature stage and now we have uh 3074 which basically promises to make existing accounts smarter but it doesn't

deliver full account abstraction um as and I I think like Lucas did an amazing job to just kind of tease out the the the differences so I think basically in the in the optimistic case here basically 3074 becomes a stepping stone that accelerates general adoption of more advanced smart features that then lead to the end goal of us moving away from EAS but basically in a way it it UPS the stakes because now if we don't get it right we end up with this kind of messed up transition that ends up has stranded in this local maximum of of of basically smarter EAS but but not full account obstruction all right so is is it correct to say that like in Far Future uh users will just the uh like the dependence on ecdc signatures uh or any kind of signatures is abstracted

away at the protocol LEL so us are free to choose what kind of signature schemes they they want and what kind of like multi- or any kind of validation mechanism they want so at the protocol L is that the abstraction layer that we're talking about that uh authentication mechanism for transactions um so what I mean to say is ultimately when at the protocol layer account obstruction is fully adopted so uh what is exactly abstracted away when we say account abstraction right because right now uh everything is done at the uh application layer but when it's ultimately adopted by the protocol uh what it's going to look like then at the protocol layer itself so so on the protocol layer

itself um I think it's basically about EIP 5,000 three maybe no the the rip I guess would be the what's the RP 75 I mean we we basically we just need to to have find a way to to migrate existing users right um but then in in terms of like yeah support for the protocol itself so so so so one thing that I I feel like because everyone uses the term account obstruction slightly differently right and so so for example one thing that to me is is a very crucial part of of account obstruction and that specifically you don't get with 3074 is a fully decentralized me pool and and why is that such a concern for the base protocol because we care about sensorship resistance and we need we

have all these mechanisms in the work of like inclusion list and everything and for that we need a basically like a a decentralized kind of Base M Pool um and and and and actually making making basically like getting a c obstruction right is not obvious on the protocol level because you need arbitrary validity conditions that still can basically be uh be be processed in a in a non in a mol that's not open to Dos attacks and and and and and and and and that's a really hard challenge that's what kind of 437 was all about solving and that's what 3074 in itself does not solve so basically we need to find some way on the base protocol that's not at all about like how does this look like for apps or anything that's just the base protocol layer right we need we need to find a way to basically to to enable such a such a permissionless mold

so we can have all these kind of features that we need for sensorship resistance and basically um that that that that looks something like 437 so we need we need to find some sort of path in in that direction yeah and uh I think the ultimate goal uh is actually to enable full account abstraction at the protocol level and there are you know uh efforts around that like RP 7560 uh is actually built on 437 uh to enable the same kind of account abstraction at the protocol level and uh and right now you know 3074 is coming that you know empowers EO ways uh but we don't again want to end up in a situation where we have to manage like two different standards of account abstraction and uh I guess wallets needs to uh redesign the way application

actually interacts with the wallets today and so far you know all the wallets that have been designed uh were designed keeping the EA in mind you know EA interaction and now you know smart accounts are coming ultimate end goal is you know full account abstraction where every account is actually smart account so I think there is a need need to uh redesign that interaction between daps and wallet so that it works with both standards so tomorrow when you know native account AB section comes uh DBS again don't you know find themselves need to change again you know uh the way their users use their application I I kind of don't like how we're always comparing 374 to 4337 because we're always forgetting about the fact that 4237 has the requirement

of deploying a smart account as smart contract account and 3074 kind of allows us to leverage all of the infrastructure that 4227 has created for Eos as well now can you get the full benefits no I understand that because at the end of the day account abstraction uh which is a terrible term a smart account uh which is a much better term consists of multiple things that we want to achieve we want to use different types of cryptography we want to use uh delegated signing we want to have Subs sub subsidized transactions uh new recovery systems and 3074 essentially just allows us to do uh delegated signing essentially and with that we can actually subsidize transactions using

the existing 4237 infrastructure right so I don't think it's exclusive uh because we have to understand that yes we're going to on board a billion people into this world but there's already a hundred I don't know there's a number of people in here and these people need to use 4237 without deploying an account so we need to have a benefit for the existing community and the future community and taking a fully exclusive approach of 4337 we're basically saying oh all the nice features are for the new people the existing people you guys just bear with it you know so 3074 kind of finds that balance and I don't think it kind of affects the prer that we had in fact it allows us to test with the

existing Community to leverage the infrastructure the 4227 has built uh yeah I agree with you uh but for example with 3074 the way daps are going to interact with wallets now um is there going to be like a new sort of API between daps and wallets to access you know 43 3074 signatures and when tomorrow uh Native account abstraction comes and uh all users wants to move to Smart accounts U will they again need to you know change those interactions so I'm saying like why not make that interaction uh in a way that's compatible with 3074 and you know native account abstraction tomorrow I mean but Lucas just presented so for those who

were here you saw that 5792 which is wallet call Api method already creates that obstruction layer it's a brand new interface for wallets to talk to dabs which does not think about is this a smart account or not you know it has completely decoupled that interaction for the DB to have to understand am I talking to an external account or a smart account I think we're fixing these problems all there's multiple work streams here you know and and and maybe just briefly mention because I think in a way like that's where 374 has this double- edged character where it can actually be quite helpful because the way it works is that you need these individual invokers for like individual functionality and it could well be that these invokers end up being like good kind of crystallization points for standards for depb to wallet interaction

right so once you have a batching invoker you have that defines that standard or once you have a recovery invoker something basically where where when we now we specifically kind of get and we get the critical mass of all the UA users so that that we finally get like proper smart account feature supported by all the LI depth basing libraries and if we get it right and it's all compatible which is a big if and I think we really have to make sure we get there and we don't end up with two separate TS but if if we make it compatible I think it can also have this catalyzing effect and don't forget that user operations for 437 are not perfect either like if you read all the rules that it takes for you to you do a user operation you limit yourself to like

pretty much most smart contracts are too complex to be embedded into a user operation so with these invokers we might be a able to actually solve that problem there's like two approaches to this we either all deploy smart contracts and we use modular smart contracts with like 7579 and now we have a module system that will abstract all of these user operations but then the EAS can't use these because user operations are so limited to protect the bundlers but okay sorry I don't want to keep but like just briefly respond to this because I think this is really really crucial because you you made this distinction between convenience and and security right and like this is is a great example because yes it's more convenient to have more features the reason why 437 is so restrictive in that sense is

specifically to allow for decentralized me pools which is it's a huge challenge right like usually what all these kind of um SP sponsored transactions gas station networks all these kind of these nosis sa used to do is is just trusted relay networks where basically hey if I'm nosis I just run the relay for you I know my account so I can just have special logic to support it and that works fine until the relay goes offline right and so if we end up in a world where yes the convenience is great but then I just trust that my I don't know metamask relayer is always online and if it's offline I don't have a fallback because I fundamentally can't have a decentralized mempo for these type of operations then basically it's all fine until it isn't right and it's a very brittle architecture that we were building would be building actually to

ref on that point part of the reason that I lost a bit of interest on 437 was because I I agree with you that I understood it originally to the the main goal to be to have a permissionless mol mimicking the original public mol that I mean nowadays we don't even use that often because of sandwiching and whatnot right but but that was like the idea and in practice I think a lot of the companies um that you know were building in the space were actually still privatizing all of the user operations so I guess Alchemy probably B economy as well I don't know even we at gelato when we dabbled with it like the bundlers privatized the order flow the users would still submit their their use operations to a private endpoint that's that's how the business is is being

handled so this this mempo isn't there's really no incentive to share this flow there's no incentive for for Alchemy to share this user operation so I think it's sort of a broken mechanism to be honest where 437 is still cool because if we standardize the vendor locken isn't so strong if you want to switch from Alchemy to B economy or whatnot you can do that more easily you don't have to update a bunch of cod on it's sort of more easily done but like the actual feature of this sort of me em meol out there that I don't really see it in practice maybe that's the case nowadays but when I was looking at it like I don't know half a year or year ago the space was not really going there promise last comment but like I think the problem with these things is

just like with something like censorship resistance right censorship resistance works great if it's preemptive where basically you know that trying to censor it does not will not work because there's always a way to basically fall back and have some forced inclusion mechanism if you can't have a for inclusion mechanism basically now it means that yes sure maybe there's like five different big kind of relay companies that all are happy to relay my 3074 transaction but basically now if I want to just censor it's very easy for me to go to all these five companies and I'm like hey please you're not allowed to relay these specific type of transactions and then because only like 0.1% of users are affected those users are just out of luck and have no way of actually getting their transactions onto the chain anymore right so like we are just on a default path now where basically we end up in in this situation

where most users have a great and very convenient experience and a few users are Bas basically completely out of luck if if we again this is not a necessary consequence of 3074 but if we don't get this right okay uh my next question is to KL so with 4037 3074 intents are also coming up so I just want to know how our block expor is going to involve with all all of this because right now the user perspective is that I pay for gas and I SW or Bridge or transfer an esc20 but now soon enough the perspective might change from that I have 20 usdc on optimism and I want to pay someone in E on arbitrum so do you see explorers evolving with all this to show all the details yeah I think one of the big problem with the this end game for

account abstraction full account abstraction is that it also brings this increased complexity in the ux in the dev ux so we don't have the standardized way how the wallets interact with this account abstraction how they the B operation where this oparation mulled and so on and from from the ux this also increased um increase the complexity of how this operation can be indexed how they can be parsed how they can be decoded because if you take a look at this just in a single example of the transaction sent to the ERC for 337 entry point which contains like multiple transaction in multiple batches it's very hard to reason about just from this from the current level of development in

the block explorers and other infrastructure so we definitely will need to spend much more effort into decoding this uh patches into developing and new ways to display this meta transactions and user operations and actually bringing them back to to the way how the simple transactions were displayed to the users before so that we can decode simple actions the users perform in this user oper ations we can interpret them using AI or similar tools and so for that we'll have to standardize certain interfaces on the smart contract wallets so like for now just an example basically every smart contract wallet uses a different signature for the execute method which

makes it harder to for us as a Blog Explorer or similar infrastructure projects to decode this these methods and to actually understand what contract is being called and how to reason about this internal call datas so yeah we'll definitely have to put a lot more effort to improve this ux in the devx to actually make uh account obstruction more usable and as friendly as the current simple operations user sent through EAS yeah thanks uh my next question is about the introduction of a new mol in 4337 so we have already seen in the usual BR production that there are some entities like reers who uh on which there are some trust uh trust relied on uh from

validators with 4237 there are new resource requirements as well that uh that are introduced but a notstar of ethereum has been to keep the resource usage low so that an average person can participate in running the blockchain so do you see some centralization happening the on 4337 mol as well and are there any concerns about how to mitigate that or something like that so with the with the me pool 437 meol like we have seen in in the usual meol that there are some centralized relas uh where the trust is placed upon by the validators right and uh do you see similar concerns happening with the 437 mol because I see similar patterns emerging in that mul as well so do you

see uh similar pattern emerging there as well and what are there any concern on how to mitigate the emergence of centralized player in this whole uh ecosystem yeah I think uh there is some you know active active work going on in decentralizing the 487 mempool uh and uh I think I think everyone like knows that there is a centralization risk with the way current you know bundlers are operating and this has been thought of like before uh and that's why there's already a road map first to decentralize that bundlers uh so that there is a shared uh and decentralized user of mol and then from there we can easily go to 7560 where these bundlers don't have to be run by some external you know actors uh

the validators itself can you know run this uh bundling logic in the validated node and that's where we all want to reach that's the native you know account abstraction uh yeah I would also say I don't think centralization in itself is something negative or something we have to avoid it's really more about centralization is okay as long as there's always an easy fallback and and and to me that's what I'm what I'm mostly focused on like we have to make sure that it's it's it's very easy to like if those centralized parties go away or for some reason they do a bad job or they they do something we don't like that there's always an alternative and so making sure that that those alternatives are built and are usable actually in practice I think I think that's that's the important thing and then yes we will see over time more and more specialization more and more like

specialized me pools private men pools private order flow all this kind of thing I think that's inevitable but it's always important to have this this decentralized fall back couldn't users run their own relayer in case they're censored by others well yes but then you need an EA again like then we are back to square one like yes but then you don't have a c abstraction but it is a fallback it's like uh I mean there's also fallbacks that are not that nice when like sequencer on L2 start censoring you and they also not ideal right yeah but at the end of the day like it's something that the ethereum blockchain itself should have done in the first place like there's so many nodes in the ethereum network like not leveraging those nodes

to actually become bundlers you know that that's something that we should be really accelerating I understand there's like skepticism from like core developers to like go fullon native account obstruction but the benefits completely outweigh the risks in my opinion one one point I want to make earlier is for me my the major concern around 3074 is that it both feels too late and too early at the same time like too late because it would have been a viable kind of stepping path towards Full Count abstraction if we wouldn't go the 457 route but now that we went the 457 route we didn't wait long enough that we actually started having the learnings that we could then have to uh form around 3074 because like the it's similar challenges there around like

cross chain like you might not have the same invokers on different networks it's same like you don't have like a a smart account plug plugin at the same address on different networks it's about the security permissioning system it's about the standardization of uh of of the modularity in a way that like we we just we we just like really like a half a year ago we started having like an ecosystem and we started having learnings from more and more users and now we have uh unleashed the same problems that we have with smart accounts to EA users without actually having any answers to these learnings yet like we're working on on on all of them but we don't have the solutions yet and that yeah I see risky it's it's funny you say that but the reason 374 even got included in the first place and got all of this momentum was because of

4237 because I remember 3074 at the beginning I was so excited about it and everyone just thought oh this is too many security risks and it didn't even have a nons at the time people just complained complained complain and then 4337 showed up everyone was super excited about and then what created was now a polariz because some people were really happy about 437 and some people just thought it was over engineered and that all of the sudden people started liking 374 for its simplicity so it was a little bit of a cycle there because I remember you were saying like oh no all of these memes about 374 but those memes started because 437 was too complex you know so but at the end of the day they're like complimentary I don't see a problem I

just see like progress progress progress like in 2019 we were talking about meta transactions and it was like the best thing that we got was like gas station network and it was still like really centralized you know uh my next question is about fragmentation on evm across different rollups and chain with push zero op code uh the main net adopted first and then it came out slowly on other l2s and some l2s have not even adopted po Zer until now 3074 introdu introduces two new more op codes um and again it will be rolled out on M it first and probably will come on some l2s later and uh so do you see this as a feature or a bug so with different evm versions on all all of these chains and wallet supporting all of them how do you see this

fragmentation playing out I mean one thing that I'm starting to like that it's happening is because we're basically modularizing everything really fast and everything is just being so fragmented but at the same time it's allowing us to kind of redefine what a blockchain is so if we do have have like these bundlers or sometimes people like to call it like Searchers um become almost the cross-chain layer for all the blockchains users can like sign operations for multiple chains and just like bundle them together and they can evaluate if this is going to uh succeed on a multi-chain level and then just settle them all at the same time because the biggest problem with like all of the

cross-chain communication is that one transaction had to set alone chain a and then on chain B so if we actually like just take all of the settlement away from the blockchains themselves and then just resolve uh all of the operations of chain then we can actually know that once we settle them we have guarantees that given the mle that we have these chains on and these operations on different chains will all resolve at the same time so I think we're actually going to have this full chain abstraction as a consequence of abstraction and I think this is my last question as we are almost out of time uh Anar you recently uh express your disagreement with 3074 rolling out here

and then this is one of the common concerns with this uh and people are raising concerns about nons uh in this but these are the CIP has been disc has been discussed over several years so if you can give us insights on how to if any interested people can how to how can they get involved in discussing eips and what goes behind the scenes in uh you know creating an EIP taking it through all the way to mainnet so just some behind the scenes action on that just so basically like kind of just talking about how basically how to get how to get involved with yeah because there was a famous tweet uh floating around that don't don't get involved in EIP discussions but I mean which is actually interesting because the talk I gave two years ago about 3074 specifically I think was like 3074 and the governance process of of ethereum or

something so like I think people want to go back and and and and and watch also about like how how did it kind of how does this process work I think in general um I mean a it's easy to get involved right like um a lot of these conversations happen like especially for like the EIP process there's every time you can open EIP like e St ethereum.org it usually link it always links to a to a discussion forum um at thread so you can you can go in there you can read the messages you can you can you can comment you can participate um so so that's a good way to to get involved of course the the the the hurdle to actually like get involved in a way of like creating your own eips and actually push for changes in the in the evm that's that's a bit of of of a of a higher hurdle

because they what sometimes we see is people who like have an idea and then they they put in basically the minimum effort to like come up with some spec and then they put it out there and they're like hey can you have a look and just see if it's a good idea or bad idea like usually what you what you need to do there is like to actually really put in the effort of like really kind of talking to people getting feedback figuring out like how would that interact with all the different pieces of the ecosystem so so basically creating earpiece and they're going through the entire process is is a very kind of like involved multi-step multistep process and I would say that it's interesting we we in an interesting moment in time right now where basically we talked about like evm equivalence just now right and like how basically

this this interacts with different chains and everything and in the past we saw a lot of layer tws that basically just copied what layer one did with evm equivalence we are we starting to move a little bit away from that so so now like you talked about the IP 7 7,000 something something like the the INR account obstruction IP rollup Improvement proposal so we we created a a separate standards process now for rollup changes um and so I I I think we're starting to see a lot of like active participation in that governance process from the layer two side as well now and so like maybe if you have interesting ideas that might actually be an interesting starting point to like go talk to L twos understand their specific needs and maybe instead of creating an EIP maybe create an IP and like kind of get involved that way I think that's

like a very time timely moment like like like thing to do um yeah any last comments we are nearing the end of the panel yeah I think this is it well thank you all for um this very interesting exchange maybe we have a couple of minutes to to take a few questions if anyone has a question raise your hand y just as it heads up the audio pretty bad up here when getting questions so please make sure to speak up loudly uh question is why do we need to enshrine account abstraction at the base layer why don't we rely on the rollups to implement it in their opinionated way

um so like ZK sync already has account abstraction um and they may choose to do it differently why do we Implement a very specific uh design a can abstraction at the ethereum main net why don't we just delegate it all to the rollups uh I think one of the reasons is actually to save uh gas cost uh because once you uh Implement these protocols at the base layer and that the protocol layer um uh for example in RP 7560 these entry points and some other you know contracts are supposed to be pre compiles so it does not take that much gas as compared to if you just you know deployed them as a smart contracts so that's like one of the reasons uh why

native account abstraction makes more sense because these days uh you know applications do complain about uh smart account deployment costs and uh uh even 437 transaction why it's costlier than you know native like EA transaction can we bring that cost down to uh comparable to at least you know EA transactions so that's why like that's one of the reasons U and of course like decentral ization is another one like removing the central uh point of failure in any any protocol uh I know like there is uh you know decentralized bundler network uh coming uh soon uh but uh yeah but that may that may work that may not work uh we don't know uh but yeah in shrining at

the protocol level definitely will save you some gas and you can actually be in a world where you can compare EA and you know uh smart account transactions I mean at the end of the day you also have to kind of count the cost benefit right like account abstraction not supposed to be used by a minority of people if it's going to meant to be used by 99% hopefully of the users then why build this whole offchain infrastructure when you already have like this whole network of nodes you know you're not leveraging the network effects of the ethereum network and you're just recreating it all from scrp on the top you know I understand that some features are maybe exclusive to like let's say 50% of users but account obstruction is supposed to be for everyone in fact it I

don't want to use Hardware wallets I don't want to use like keys and seat phrases like I want to move away from that I want the account to just exist like to just be universally as a concept uh and I think we all want that we all want that kind of level of convenience and security I think a very important U aspect of having it enshrined at the base layer is also just to sort of force standardization uh to make people agree on a standard even though they will biger about it and and you know certainly we have to be careful not to enshrine the wrong standard but that's always an open conversation you know um but yeah I think that's maybe the most important aspect here because I think like for example with safe U we've built

a our own account abstraction kit before which was non standardized right like we had our own thing and it's a bit like you oper you're developing an as Silo and and and yeah so if you if you are actually you know sort of enforcing a standard which at some point someone has to do then you get um you have less risks when you start building a business on it because it's standardized right like you you don't have to worry so much about it being deprecated or so at some point and uh or or the company that supports that special implementation going out of business so so so yeah I think that's very important um yeah and I think that's probably also uh still one of the biggest hurdles to adoption here is like even now we see that 437 tried to become a standard it had a lot

of backing and on I mean it's probably still on a good way there but we see that it's not fully fully agreed upon yet there's other proposals sort of entering the room entering the chat so so but yeah at this point it seems like 437 is still going to be the standard I guess but but yeah I think that's the the main one of the main benefits of having it at the base layer it's yeah um yeah so uh I recognized account abstraction is bigger than just like uh increasing or adding to the ways that we're able to protect our accounts than having people than forc some people to remember a seed phrase but like I guess my question is do we feel like we're overestimating the web2 experience so in

a sense it seems like account abstraction is to give us parody with like a web2 ux right um were able to like offload and delegate these responsibilities to some kind of let's say centralized force or um entity um but like I still have to have a separate password if I don't want to be like super insecure and risk you know all my accounts being hacked if one of them is compromised for Facebook for Google for Amazon Etc all the different services that I use and then I'm likely using some kind of like password repository like last pass like one password where I have a master password where if that gets compromise and all of my stuff is out right anyway so I'm wondering like what are your feelings um uh towards like or what are your feelings on like what the ultimate goal is for abstract account abstraction

anyway like are is it for web 2 on parody which already seems a bit insecure like I think we're all worried about that we're worried about the security we get with web to anyway um and like yeah what like what are we really trying to achieve um with the account abstraction um in your view with that in mind I mean currently users don't even have an option right so uh I think that's the number one thing that we need to actually consider like it's very well understood that like an EA is just safer in the sense that if you are the pairer of the private key now it's your full responsibility no intermediary risk nothing not even smart contract risk right but now we're forcing everyone to

be a bearer of a private key right uh that isn't like the best experience and we are not even considering other use cases in a normal scenario people have more than one device right even if you don't own a laptop you might own a tablet and you're now going to have to import private Keys around and even in traditional cryptography I mean like pre- blockchain cryptography just the concept that you don't rotate Keys goes against every cryptography principle you know so like smart accounts are actually designing uh proper cryptography principles and actually allowing people to have more organic patterns into how they carry their lives like um we're all kind of like used to now to knowing that

this private key must be secure and don't share it blah blah blah because we've been saying this story like enough to not sound crazy in our heads but like it is crazy like nobody not having recovery is not acceptable like I think we really maxed out on the amount of people that we can really on board to EAS like even now we run to challenges people getting fish losing their private Keys like it's even in a smaller group relatively where we can educate people it's more technical people people yeah even there it causes issues if we scale this out to billions of people that's not going to be feasible so smart accounts are needed to to uh to onboard like a billion people to web fre um and I think actually it would prevent people then

defaulting to cust Solutions that's the main thing because they they yeah like the billion people wouldn't use like these private key uh wallets that they would just use some like questionable NPC solution if they're lucky and or worst case some centralized exchange uh and then we're back to like platform login and all these uh this stuff and I think people don't often talk about security when they talk about account abstraction um and uh that's like very critical aspect of an account uh you know First Security has to be there even when you on board on existing wallet today uh that the part of their onboarding process do you know mention that you have to safeguard this Keys you

know they again make you retype the keys to just make sure that you have the backup so there is uh you know uh focus on Security even with the existing wallets today but again the way eoa security works you know just remembering your seed phrase and when it's lost you just completely give the control to another person that's not the best way of security um you know the best way to implement the security and that's where smart account actually comes into play uh where you don't have to depend on the existing cryptography uh let's say tomorrow uh you know we we are talking about Quantum resistance uh when there are systems that are actually able to you know generate a private key that you own um then what you will do if you are just

stuck with the EA accounts smart accounts have the capability to add different you know kind of authorizations mechanisms not just EA pass keys are there and uh in the future like any new authorization that might come can easily be implemented on Smart accounts so that's why it's very important to actually focus on you know getting the account abstraction fully uh across all blockchains uh that's how I see like we can actually make the future secure yeah I think it all it all comes down a lot to the flexibility not just security so you can't do much with just in eua but with smart contracts we basically want to support the minimum number of eips and different standards for the people to be able to reach like the highest number of different use

cases and customizations including all this recovery Fe key rotation multi seek and so on all right well let's hear it for our panel for account abstraction Pedro Lucas Kel Anar sashin and mul thank you very much oh and and and uh Lucas no Lewis