Validation Centric Design | Nic, imToken | ETHTaipei 2025

[Music] Okay. Um, hi everyone. I'm Nick. Uh, today I'm going to talk about uh something about account abstraction. Uh, sharing some experience about our design and uh some problem run into.

So my topic the name of my topic is pretty long. is called uh valentry design, agile and safe development for devs and interchangeable air wallet for users. I will break down what this means uh pretty soon. Okay. So here are the uh parts of my talk the agenda.

Uh first I will briefly goes through uh what AI is what AI wall is and how the devs are built in that and next I will go through the topic the validation entry design and the third part is the challenges that comes after comes with this design and the last part will be the interchangeable wallets for user what it means okay so um how are air wallets built today what are what is an air wallet so it stands for account absorption wallet uh which basically means smart contract wallet. Uh so with uh a wallet you can use multisig pass key email to authorize your transactions. You don't have to use your uh private key or pneumatic words to do that. You can use whatever uh methods you want. And next you can pay gas fee with uh USDC USDT or other tokens other methods like credit card.

You can also do that too. Or you can even get the dev to sponsor your transaction. And the third one uh third advantage is that you can recover your wallet if your private key or uh your method is lost like your uh email account is lost. You can still have uh set up a recovery mechanism in advance to save your wallet regain the control of your wallet if you ever ever happen to lose the key lose the control. And also you can authorize the third party to perform actions on your behalf on your wallet's behalf like for example you want uh do a monthly sub subscription to an app you don't want to like come out and use your us your wallet to pay for the subscription every every month every week etc you can have with the air wallet with smart control wallet you can have third party do that task do that errors run running the errands for you okay so in this talk uh when I say I wallet I also you also means that they will also be the same as smart contract wallet.

Uh when I say wallet it will basically mean your account users account. Okay. How how does the uh the devs how do devs build the air wallet today? Uh so I'll term it term the design as account as centry design. Uh in the contrast to what I'm talking about today the uh validation centry design.

So in a accountcentric design uh account host the users asset uh naturally that's uh very obvious uh but this account also contains the uh complex logics like validation logic like how you validate your transaction how you authorize your transaction or how you pay your pay your transaction fees for example you can hold it simply hold the ETH on you or hold the USDC on you or you you can possibly uh stash your USD USDC on some D5 protocol and use it to pay for the fee when you uh send in your transaction etc. And you also could also have your recovery logic. It could be a very complex recovery mechanism and you also u the account is also going to be upgradable because as a devs you know the current version is not going to be a find final version. So you have to make it upgradeable so you can uh add in new features uh remove delete old features uh as time goes. So uh also uh this is optional uh the account can be made modular.

If you're uh wallet devs you probably heard of the the ERC uh 6900 or 7579 these are very popular modular standards. So um yeah account not only holds the usage asset but it can also contain very complex logics and so devs will keep iterating on this same contract. Uh for example you start with uh 0.1.0 0 and then keep going on to 0.

2.5 and then keep going to version 1.0.0 and then one day you might reach uh two version 2.0 to up version 2.

0.0. Yeah. So that basically means that you're going to keep upgrading on this same account. Now I'm going to spread some thought about like upgra upgra upgradeable contracts.

So uh use the last August exploit on the Ronin bridge contract uh as example which is an upgradeable contract. So the Ron bridge contract uh when during its upgrade process it defines both uh two functions uh version three and version four initialization function but only the version 4 initialization function was called uh during the upgrade and that leads to the exploit. So if the version 3 initialization was called together with v4 uh nothing will happen. So it's clearly that it's an operational oversight. The devs forgot to like trigger the v v3 uh initialization.

And so yeah that that's true. But also uh you might wonder why would there be version three and four coix? Why do they coexist? So imagine uh like you're a wallet devs and your latest wallet version is uh version 2.00 but your user Bob uh his wallet is might still be on uh version uh 0.

10 or version two uh 0.2.5 2.5. Um, but he hasn't used it for a long time.

But now, uh, once he came back online, uh, he has to upgrade to latest version, right? Uh, so how do you migrate his wallet safely? Are you going to keep upgrading uh, from this oldest version from 0.10 all the way up to like version 2.00 that's going to be have a lot of risk.

So now enter the uh, the main topic of this talk the validation center design. Uh so quick recap of of account centry design in a account center design account contains complex logics validation payment recovery and it's going to be upgradable and optionally it could be modular uh 6900 7579 and this is also the same account that users going to use it to hold the SS and interact with the deps. though do the uh do the above complexities really need to be built into the same account contract? Well, uh we think not. Uh so we think the better design is to move all the unnecessary complexities out of the out of the account contract.

Uh the validation and payment recovery upgradability uh optional features move it all out of the account. the account that user used to hold the assets and interact with with the deps. The account contract can be and should be that simple. It just holds the assets and interact with the deps. So what does it look like?

So uh like here in the picture uh user Alice has an account that he holds her her assets and use the uh her account to interact with the devs he want she wants. And then you have uh right now we call it uh account entry contract. It's a different standalone contract. This account entry contract will uh give instructions to this account contract uh tell him to do this like send money to Bob and interate to swap on unis swap etc. And this account this account entry contract can be simple or however complex you want.

You can be upgradeable it can be modular. It can have recovery mechanism. You can use session key to authorize third party. Uh you can use a different sort of uh authorization me method to uh validate your transaction. Uh yeah, whatever you can it can be simple, it can be complex.

So this will be like the this will compose a wallet for user uh alias user alias wallet. But uh ideally user should not be able to uh be aware of this account entry contract and this is what the wallet software uh needs to do. He he needs to hide this complexity to uh Alice uh she doesn't need to be aware of the account entry. She only needs to rec recognize she only has to know his account where she used to to hold the assets use it to interact with the deps. She doesn't have to know ideally she doesn't have to know the account country at all.

Uh so you can imagine that you can start the Alice can start with a very simple account contract with a security level like a brick wall but later maybe she want more contra um want more features or she wants her account uh to be more secure. Uh so what what she can does is that she can deploy a new account at with security level like a uh like a stone wall and you can add so many feature and make turn it into a Swiss knife. Uh so once uh Alice uh Alice wallet deploy and set out the new account entry contract uh she can just uh send a transaction to like instruct the account saying that now uh telling the old account account entry contract will tell the account that your ownership is changed. Now you will listen to you will follow orders from a new account entry contract and then it's done. You can just simply switch from the new uh from an old account entry with uh simple logics, simple features to an very comp complex one uh just like just a one trans session and you can leave all your technical debt behind.

So now I still have to clarify that uh validation contract it what it does what it doesn't do is that it does not save the depths from the risks or associating with upgradable contract. Whenever you design your account entry contract to be an upgradeable contract, you are still carrying the risk with upgradeable contract. You might still be running to the same exploit like the Ronen Bridge contract. But what it does is that it gives the devs the option to restart just like uh the picture here shows. Uh you can simply switch to a different account contract.

So it gives the devs the option to restart and in turn these options allows the devs to iterate at a faster place at a faster pace. So you can imagine that you might go live devs your wallet you you might go live with modular contract uh 6900 and later a year later uh ERC 7579 a new different module sender came out and you was like oh this 7579 looks simpler more abstract better but now how do I convert my existing wallet of 6900 to a 7579 both are very complex completely different uh wallet 9 uh or vice versa, you want to switch from simple 979 to 6900 or you can imagine that you are going from a non modular account to a modular one because you want more features or vice versa you want you thought the modular uh is too complex you don't want that much features built in you want it to be simple how do you migrate how do you change how do you upgrade your contract from an modular one to a non modular one or you can imagine you go live with this uh diamond proxy pattern which is uh new uh uh rather new uh upgradeable process pattern. Diamond process is very uh modular, very flexible to extend. But um you might you might begin with this design and later thought that this is uh the diamond project pattern is too complex, too modular for me to handle, too hard to manage. So you want to upgrade back to the migrate upgrade back to the old simple uh 697 1967 process standard maybe or vice versa you want to go from simple to complex it's all going to be very difficult if you're upgrading the same contract so this is what I mean by safe and agile uh options to restart uh gives uh the wallet devs safety you can restart leaving all your technical desk behind and the options uh and the option in turn give the devs to iterate at a faster pace and this is what I mean by the age of development you can develop uh the new standard uh new new style new design in the same time parallel and once you think that's mature you don't even have to worry about how do you migrate the old account from to a new one you just like switch to a new one without any technical tech technical deaths okay so that's Uh there's one additional feature I want to uh mention uh that stem from the validation centry design which is the multi accounts.

Um so you can imagine Alice can have multiple accounts account one two and three and one account entry uh contract for her to manage all these accounts. You can imagine that uh for example Alice might might say that I want to buy ETH uh using my account three and I want to pay the fee uh using my assets on account one. So since they all follow the orders from account entry and she only has what this one account entry to send the transactions. So it will be uh completely natural to like compo control multiple accounts at the same time. So it doesn't have have to you you don't have to send two transactions to complete the steps.

You can complete one um multiple account control in just one single transaction. Okay. So there are also some challenges come with the design. The first one is how do we pay the transaction fee. So you might wonder what's the problem.

So the problem is that uh the you user always send the transaction to is this account abstraction transaction. He will send this user the transaction to the entry point contract and the entry point contract you can uh consider it as an the operating system contract for the account abstraction system. So you will send a transaction to entry point but the entry point contract will only recognize entry account entry contract instead of the account contract. So uh obviously the account entry contract has now has to pay the fee because that's the only entity that the entry point recognize. So how do we solve this problem?

Uh multiple solutions solution one you can just directly pay from account entry uh if you have any SS on that. So Alice could for the convenience say like just put her assets on the account entry also and uh save some maybe some majority of the assets on the account contract but say leave some uh on the account entry to pay for the fee. This is one solution and this will do simply but you will probably break the some uh user experience deteriorate that because ideally we don't want the user to be aware of this account entry contract right so solution two you can transfer from the account right after all you have all the all your assets on the account contract so once the entry point as the account entry contract to pay for the fees the account entry can in turn ask the account contract to transfer money to him so that he can he can can pay for the fee. But uh there's a catch that uh this currently this transfer will violate uh ERC7592. This is a bundler regulation rules for AA.

Uh this all these regulation all these rules are to prevent uh bunders being dos attacked. So right now this violet rules though this is uh like a soft rules the bundler really doesn't doesn't have to uh enforce this rule actually. So you can you can imagine uh there's uh there's bunders service that provide custom rules like they are fine with is the risk of this transfer then they can totally accept the transaction and forward the transaction online onchain for you. So this is solution two is uh very straightforward but it also come with uh one downside. So right now at on token our solutions is to use a uh a pay master to bypass the restriction.

So you can have the pay master uh that from the payment the fee payment for the account entry for the user and then charge from the account afterwards after account finish his operations. So in in in this case uh you don't have to do the transfer from account to account entry. So that won't violate any rules and you can also complete the complete the flow. Yeah. Uh okay.

Second challenge is not so critical is that this uh flow this transession will not be easy to view on the explorer. Uh so as I mentioned the the account that user recognize is not the user of sender that means the sender of this transaction. The center of the transaction is actually the account entry contract. So when you throw this transaction onto the explorer, you will see the user will see that uh this account entry contract is a sender but should probably not recognize this address. So this uh user cannot easily see uh which of his accounts are being executed.

So but um this is indeed a problem less uh less severe one but still a problem. But it's also the same problem for meta transactions or for country wallets like safe or for uh some some uh wallet service is try uh experimenting with child accounts sub accounts they all have the same problem that is not easily to be viewed on the explorer because this is all internal operation internal transaction internal part of the transaction. So it's not going to be easy for them to view the transaction to view uh view uh what exactly uh is her accounts involved in this transaction. So that's probably a bigger problem to solve for us for all of all of us all of the wallets as a whole. Yeah.

So that's the challenges and the last part is the uh interchangeable wallets for users. What does that mean? So in the world of EOA uh user can just like uh export his private key from one wallet and just like import his uh private key to or an money world to another wallet and begin using his same account. So it's like same account different wallets. The only difference are the wallets platform uh be uh chrome extension uh wallet or wallet apps uh different platform and different user experience provided by the wallets.

So yes, something like this. Same key, same account, different wallets. Uh user Alice can just use it, import, export the key. Very uh smooth. That's the advantage of the EOA.

But now with uh with the account abion, smart contra wallet emerging uh every wallet company is uh designing their own contracts, their own account contracts. So that means user can no longer use the same account on different wallets. It's all different accounts, different design and you can just like import export import keys and user has to create a whole new contract uh for a new wallet. User has to migrate everything to a new account. If she or he wants to uh use the new wallet because maybe he finds the new wallet more convenient, more providing more features.

So yeah, it's stag good. U not the same account, not the same wallet. Uh if uh if Alice wants to like use switch to use Coinbase account, she has to migrate all his or her assets from I'm account token account to Coinbase account. Uh that's going to be uh quite a trouble. So imagine with validation ccentric design wallet companies will focus on developing their account entry contract all the complexities and user can just switch between different wallets by uh simply changing their account entry contract.

You can um you can start with I'm account uh AM token. You can point to AM token account entry contract and later you find Coinbase uh account better account Coinbase wallet better you can just simply switch to the Coinbase account contract and maybe one day you find that you still prefer ARM token you can just switch it back. So this is what I mean by interchangeable wallets for users. You can just remain using the same account holding the same asset to interact with debs and just simply switching between different account contrast so that uh he doesn't she doesn't ever have to like migrate his assets or completely giving up his old accounts and yep so that's a wrap uh this is the resource our repo although we are still waiting for our final audio to complete so before we really uh open source that unfortunately Okay. But you will soon be open source.

Okay. Uh any questions? Any questions? Hi. Uh yeah.

So um so it means that each uh smart contract wallet you will points to a account entry and this account entry will like for example you can migrate to another egg implementation for example uh coinbased wallet but wouldn't be would that uh like storage collision be a problem for that? Uh yeah good question. So this this is going to be two independent contracts. So the storage is going to be completely isolated independent. This is coinbased uh account entry.

It has its own storage. Uh I'm I'm account entry. It's going to has it own entry. So there's going to not going to be a problem of storage storage collision. But switching to different account entry meaning that user will be aware of the change of the address, right?

Uh no. So this is always the address the account that should recognize. Ideally, she she's not going to be aware of this account entry contract. Oh, okay. Got it.

Got it. Okay. Thank you. Hi. Oh, is there a case where if you try to change your account entry, um the one that you're currently on prevents you from redelegating ownership of the underlying account or is that something that's preventable?

You mean like um greedy wallet that doesn't want to let user they want to lock you in? Yeah. Yeah. Yeah. Unfortunately, it's possible because like um there's no um rules like how you should design your account entry.

So imagine this account is like an account uh a contract with owner and she only takes the order from the owners but she she has no uh rules or powers over how this owner transition the ownership. So yeah, I think that might that might be possible if a wallet wants to like trapper users in his wallets. Yeah. So with more competition from all these wallet companies with each other on the smart wallet accounts, do you think that's something that they would do? Yeah, I think that's possible.

But I think it's still like better than the status quo, right? Because status quo is that none none of this is going to happen because the contract the account is inherently different. So we have no choice. We have don't we don't even have the option to migrate without changing the account. Uh that's the status quo.

Uh so with validation central design at least we have the option but though it's true that we have we we we can ask the wallets not to do that not to like uh trap their uh users there but um I think it's still better than a stat. Yeah. Thank you. Any last minute questions? We still have six minutes.

No. If not, then that's give Nick a round of applause and thank thank you for sharing those content. [Music]