KL Mini Hack 2023: Account Abstraction Simplified | February 14 | 9:00 PM
Ethereum Malaysia·Mon, Oct 9, 2023, 12:00 AM
UX has always been a pain point in web3 as the wallets we have now are notorious for being 'unintuitive', making it hard to onboard new users especially the non tech savvy ones. Account abstraction attempts to improve this and recently we have seen many attempts by developers and companies to create a more user friendly wallet. WeiHan will take us through this very novel idea using simplified and easy to understand concepts
Transcript
Okay. So, um yeah, let's begin. So, um welcome everyone to another installment as part of the K hackathon. Today we have a backto-back session firstly by going to be presenting abstraction simplify followed by introduction start by so um if you're ready feel free to start oh just a quick sohan is um if you missed the previous session um is a currently working as a document engineer is for member of Okay. Thanks, Kevin.
Let me just share my screen very quickly. All right. Can you see my screen just to double check? Can see? Yep.
Looks good. All right. Cool. Yeah. Uh, so let's start right away.
So, just to reintroduce myself. Hi, my name is Wayhan. So like what Kevin said, I'm working as a blockchain engineer at a company called Note. So yeah, I basically do a lot of L L1 stuff. So um yeah, today's session is going to be on account fraction like what it says here.
But I won't go too deep into the technical part because it will take a long time to talk about technical part. But I believe this is more like a um simplified version of account of traction or I would say aa and um hopefully it'll give you an introduction to accountraction and where you can start your research on right so what I'm going to talk about today is on four parts firstly introduction secondly use cases third uh the evolution or and lastly the state of adoption currently right so let me just open the chat all right so yeah without further ado let's start with some recap Right. So just to refresh your knowledge on before we really go into account attraction. So for those who have attended the first session on Ethereum basics um this you will see something like this. If you haven't attended it's fine as well.
But basically what um this what what this slide is trying to say is that uh Ethereum is just uh chain of state and facilitated by a chain of blocks. So that means that Ethereum is nothing more than just um a transition of world state from one to another. Right. And how how can a wor state transition to another the second world state is that uh is fac facilitated or is executed by uh transactions right and transactions are included into a block right so this is the Ethereum basics and inside the world state right the primary citizen in this world is an account or many accounts right and in this one account or an account is just a mapping of address to account state and account state contains non balance storage hash and code hash Okay, this is just a recap. So now we're going to talk about the more about um accounts which is the firstly the types of accounts on Ethereum, right?
There are two types of account in Ethereum. First one is called EOA externally own account right. So what is an EOA is very simple. So in EOA basically if you have combination of these three things SER EOA and funds SER means your private key um you will be able to perform a transaction right. So EOA bas basically contains a public address and can store user funds.
User funds means your if right and transaction can be initiated if um a user or an external actor sign the transaction uh by creating a signature using the private key with the EOA's public address. Right? So this is how an EOA can transact. Secondly, we have an account called um contract account. Right?
So again we have these three things signer EOA and funds. With a combination of these three things you can make a transaction such that you can activate a contract account which might hold some fund right and then this particular contract account can transact or to be more precise is to perform message calls. Right? And the key thing here for contract account is that it cannot initiate uh transactions. It must be activated by an EOA.
Right? So everything that you do in Ethereum, you must always start with an EOA, right? So to simplify things, EOAs are called the first class citizen in the Ethereum ecosystem. No matter what you do, you need to start with an EOA, right? And we'll explore why is this bad or why could this be bad, right?
In terms of EOA. So the first problem with or the general problem with EOA is that there's no separation of concepts. So what do we mean by concepts here? So there are two concepts that we are trying to that that we have right. So the con the first concept is a concept of serer right a signer means the like your bank password right the the primary responsibility for a serer is to allow people to spend tokens right um uh wait I'm I'm looking at a lot of sorry u unlimited people so um can can I just admit all yeah I'll just admit all okay sorry for the interruption um but let me just proceed yeah like what I like what I Um the concept of signer is to allow people to spend tokens and you have another concept which is accounts or EOA in this case which the primary responsibility is to allow people to hold tokens or to hold money right.
So if you think about it in terms of web two um web two concept, you have your bank password which the primary responsibility for for a bank password is to access an account and the primary you have another uh uh another component which is uh your bank account and the primary responsibility for a bank account is to make transaction right. So or no um to yeah to make connection and also to hold money. But in the concept of Ethereum or or in the concept of EOA the current EOA system is that these two concepts of signer and account they are merged together. So what do you mean merged together? It means that you can't have one without another right.
So in order to make a transaction you must have these three things or you must have these two things which is signer and uh an account or EOA. So let's explore some just a quick scenario right so let's say you you yourself as a user you have your own private key or you you as a signer right you hold your own private key or or you hold your own seat phrase if you have your private key that means that you have access to your EOA which in which you would have access to your funds so that means that you have your funds right and what if you you lost your private key due to whatever reason right you write on the paper but then you lost it so if you lose your private key or If you lose your seat phrase, you will lose your money forever because you will have no access to your EOS forever, right? There's no way to recover it. And um the third scenario will be someone has your p someone has your private key. So if someone has your private key, they will have your own account.
I mean they will have your whole account and they can transact with your account or they can just steal your money, right? So as simple as that, right? So there's no way for you to decouple this um this private your private key from your account. So hence the problem the general problem with EOA right now is that it's a single point of failure in the current EA system. Right?
So that's the problem that we are trying to solve with accountraction. So next now this is the accountraction part. So what exactly is accountraction or what's the purpose of accountraction? It's just very simple. It's trying to combine the concept of EOA and the concept of or I mean yeah the concept of EOA and also the concept of contract account.
So that a single contract account can both transact with your tokens and create contracts. So that means that they can initiate transactions on their own. Right? So this is the new type of contract account and the primary purpose of account structure is also to decouple signer with account. So decouple here means that it's trying to separate the concept of signer with the concept of an account.
Right? So in this diagram here it may look very subtle but if you look closely this ser is no longer merged with the account and funds. The concept of serer here or the primary purpose of the serer is to allow a user to access an account which holds some funds and this account here is a smart contract account and um once you uh have access to a contract account you would be able to perform a transaction right so from this diagram it doesn't it doesn't look like oh it's account attraction but this is literally account attraction it's just decoupling the key from the account okay so now that hopefully you understand what is account of traction. Let's talk about um the use cases which is the fun part. Generally um there are four major categories of use cases.
Account of recovery, signature abstraction, gas abstraction and batch operations. But um to be honest the you with account traction you can unlock a lot of different things. So it's really up to imagination on what you what kind of application can you build with account traction because it's really really wide. But let's explore some of the uh the major ones I believe. So the first one is called um account recovery.
So very simple right previously we I mentioned right. So if you lose your private key you lose account forever. So the concept account recovery is that okay even if you lose your current signer or your current private key let's say you would be able to set up a backup key such that this backup key can still access your smart contract account. So there's there's no longer the concept of if you lose your private key, you lose your account forever because there could be many backup keys. So yeah, it really depends on how you set up your this uh particular uh wallet or this particular key or this particular backup key.
Yep. So that's first major use case and the second major use case is signature abstraction. So signature abraction basically um is to allow two things multi multi or multi- signature enabled and secondly is uh you can have different signature schemes. So let's say if you don't want to go with the default signature scheme that Ethereum has you can go with like BLS quantum safe or whatever other signature schemes that you have. But uh in this example, let's say um you have a wife which has her own um private key and you also have a husband which which uh in which his he also own a private key with the combination of these two keys you would you can access a joint account right so this is how you know we can have a multi application enabled so yeah this is one one of example there could be many other sign multiC examples and third we have the guest abstraction uh use So get attraction basic um the first I think primary use case is guest sponsor sponsorship by pay master.
So the idea of this guest sponsorship is that this pay master can sponsor the user guest gas guest fee. So why do we want to sponsor people gas fee is that we will want to onboard more users into the entire ecosystem. So that means that people from web two even if they create an account right a new metamas wallet let's say they can interact with the blockchain or with ethereum without paying if right because it the gas fee is sponsored by someone else. So an example right you have a user with a private key and then this user can access um the account with the private key and with the account he can interact uh he or she can interact with the central application without paying any gas fee because the gas is paid by the pay master right so if you give you a real life example let's say let's say on Binance right if I want to onboard more users from web two to web three if they create an account on Binance let's say I will allow uh Binance will spawn sponsor them a free guest uh free guest fee for 30 days because they are new users. So that's one of the use case that I can think of when it comes to this guest uh sponsor uh sponsorship.
It would dramatically um improve the user adoption when it comes to um adopting people to a new platform. Yeah, let's say. And lastly, we have batch operations. So batch operations is just batching transactions into a single uh transaction. Guess it exist in UA as well.
Yeah. Um but in this case this is also one of the use case for account traction. Yeah. Um coming back to batch operations. So you have a user that can access um an account and this account can do multi calls basically calling like multiple contracts at the same time.
So if let's say if I were to give an example of like um uh let's say you are playing a game right if you I mean the current the current system is that you have to keep every time you make an action you have to keep u making like metamas transaction or you have to keep signing signing the transactions. So it's not smooth for user uh experience. So you if you have an application that can enable the account to perform multiple calls at the same time. Um so it's just it's just a better user experience for users as well. So yeah these are the some of the use cases for account refraction and um definitely like what I said you can explore more definitely more than this right in terms of account fraction.
All right so um let's explore the history of account of fraction so that we know like where we stand right now. So um account attraction the concept account attraction it started in 2017 right actually it started in 2016 uh when Vitalic I think he published an article on account in 2016 but I think the first EIP is published in 2017 which is EIP 86 right so you can see these three EIPs here they are all stagnant only the last one is draft so I'll focus more on the the last one later on but uh uh let me just go through the previous EIP as well So in EIP86 just to summarize briefly uh what what he's trying to do is to abstract signature verification and non scheme and um users can create like non- hardcoded contract accounts um so as compared to the use cases that I mentioned just now it doesn't support all the use cases right like gasaction uh multi multisync I believe it also doesn't support so it's still very limited even though it's still very limited it still requires a protocol level changes protocol level changes could potentially means that a hard fought. And we know that protocol level changes require a lot of effort both from the developer point of view and also the user point of view. So yeah, it's not it's not worth it for to mix to use so much effort for this minor change, right? And lastly, it doesn't it still doesn't remove EOAs, right?
Um the concept of removing EOAS is that in the long term we would want to um transition from a state where EOAS are the first class citizen to completely no EOS at all meaning it's being replaced by smart contract accounts. I think in the long term that's what um the Ethereum Foundation is trying to do but I don't think it will happen in the in upcoming future. Yeah. Uh last next we have EIP 2938. So in EIP 2938 introduces two new op codes and a new type of transaction.
I won't go too deep but basically it allows smart contracts to act as EOAS to transact and pay gas fee right so this EIP is more like a rest restricted version of uh account fraction it doesn't it still doesn't support all of the use cases that I mentioned just now and it requires pro protocol level changes which is not efficient right and not impactful enough and lastly I mean not lastly uh the second last one which is EIP 3074 this is an interesting one so let me just use an diagram to illustrate. So in EIP 3074 it has um I believe two new op codes. So the first op code that introduces an op code called off which basic basically means authorization. So user can sign a message with this new op op code called off right. So with this signed message right it can invoke a smart contract to authorize I mean to transact on behalf of user right and this smart contract can make transactions on behalf of user by using an op code called off call right so smart contracts can use off call to perform transactions so coming back to the previous slide um the major changes are like what I said it it's sort of like the opposite of the previous one now um the EOAS can act as a smart contract or the control of EOS is delegated to a target smart contract.
So with this change you enable some of the use case that I mentioned which is gas monitorship and multi call execution. But the huge problem that is being um that this EIP face is security issue. So imagine what if you accidentally your user accidentally sign a uh a message with a malicious smart contract right that particular uh smart contract can wipe out the user funds very quickly and we know that from history humans are very bad at managing uh malicious things right so it's again it's still not a good user experience right and users are still expected to back up their seat phase which basically still doesn't eliminate the idea of single point of failure Right. So yeah, these are the three EIPs that are stagnant, the previous ideas. And now let's go into the current EIP, which is the famous one, EIP 4337.
Right? So I won't go too deep into the technical details, but I'll just illustrate the flow of how this EIP works in terms of the infrastructure uh layer or infrastructure level. Right? So first step is that a user will send something called a user operation into a separate meool called user operation meool. So this user operation meoo is the is is an alternative meool uh than the current one that we have right now.
So it's like the second one right. So this user operation you can think of it as a a replacement of for a transaction or not really a replacement maybe a secondary type of transaction or you can think of it as a new type of transaction. It's basically like a a zon z json object sorry yeah um but yeah just think of it as a a new form of transaction. So what the user will do is that you will send this user operation into this alternative meool. The second step is there's this new thing called BL bundle, right?
This bundle will receive the user operation from the meool and bundle it into a a transaction called a bundle transaction. So a bundle transaction is a single transaction that contains multiple user operation. Right? So yeah, this is the second step. And the third step is that once you have this bundle transaction, the bundler can send the bundle transaction to a contract called entry point contract.
So this entry point contract is a global uh single contract. Meaning that only one can exist in one chain. Meaning that it can only uh let's say only one entry point contract can exist in Ethereum mainet, right? So yeah that means that people have to do a lot of auditing on this entry point contract before releasing it to the mainet because it's going to be used by um everyone in terms of accountraction right so this is the third step once you send the bundle transaction into the entry point contract you would um call two different contracts one is user wallet contract the second one is pay master contract right so from this diagram for now you can see how the decoupling works or the separation concept works. The user is here and his account is here, right?
Or his wallet is here. So, it's totally being decoupled, right? They are not merged together, right? So, the user wallet contract um basically holds the funds and then the pay master contract basically uh you will check whether it's is is it being authorized to uh pay gas fee for the that particular user, right? So, as simple as that.
And the last step is basically just um this or once everything is being executed you will be included into a block like a normal transaction right. So yeah this is the simplified version of how EIP 437 works. You have five steps right uh you have user sending operate user operation to the meoo bundle will bundle it into a bundle transaction then send it into a entry point contract. entry point contract will call user wallet contract and pay master contract and then this transaction will be included into a block like any other normal transaction right so yeah it looks simple but it's I believe it's very hard to implement yeah okay let's talk about the major changes and problems faced so the major changes are you basically introduces a new form of uh transaction uh called user operation and then you have to also implement uh something new called bundler and you have you also have to implement an alternative meool but but the advantage here is that it does not require protocol level changes that means that um it doesn't require hard fault right um I believe yeah and the problem but the problem face is um firstly the user operation it will introduce a higher gas fee right and um if you think about it in terms of the long-term goal of replacing uh EOAS completely it still doesn't achieve that uh because a wallet's built on top of this particular EIP they still remain as secondass citizen meaning that EOA still exists but the advantage here for this EIP is that it's a good start right it's a good start to experiment with accountraction right so now you have gone through the history I believe hopefully you understand um what is what what is accountraction now in terms of both the high overview and al high level overview and also the technical details and let's talk about the current state of adoption in terms of the implement mentation of for this particular EIP is being done by actually few companies like stackup, infinitism and also mind right so they are implementing all this um the bundler that I mentioned and also some of the contracts I mentioned just now and secondly there are some uh L2 that will actually support accountraction for example snarknet and ck I believe there are many more as well and thirdly there are actually quite some uh account of wallets that are developed. The first one being Arjunx which is built on the stacknet ecosystem.
Then there so wallet and stackup wallet as well and potentially trust wallet. Yeah. So this is pretty much the summarized version of the state of adoption. And if you think about it in in terms of the future for accountraction in the short term uh protocol changes won't happen anytime soon. This is I think discussed by I think Vitalik as well.
Um and what he says is that um it the uh Ethereum foundation will focus more on experimenting in the layer 2 protocols because they have lower fees and it's much faster to experiment with accountraction in layer tools like stucknet and uh I believe what he also say is that uh he wants people to um sort of like start to prepare for this shift from EOS to accountraction at least in the short term by ensuring that the decentralized applications are compatible with smart contract wallets but uh that's what she said but I don't see any practical implementation of this compatibility at least from for my research but um feel free to chip in if you have found any research materials on this but yeah in the long term um I believe what they want or what we want is to replace EOAS completely because smart contracts are much more flexible and it was it can support much uh many more features right and definitely we would require some major protocol changes is because um EIP 437 is still not perfect uh but it's a good starting point right and there will also be some EIPs to reduce gas cost and also to improve not incentive and possibly changing some of the econ um some parts of the econ economy model a little bit but yeah it's still in the long term so yeah um we are reaching the end so just to summarize basically what econom is trying to do is to replicate web 2's user experience with web 3's techn technology, right? As simple as that. It um it solely focuses on the user experience mainly, right? And in my opinion, uh why am I so excited for account attraction is because uh I believe account of traction will be the catalyst for a chat GBT moment for blockchain. If you want to on board more users for user adoption, um I think account attraction will be the key catalyst for this um chat G GBT moment to onboard let's say 100 million user into the entire ecosystem.
So yeah, that's it for echo attraction. Hope you guys find it helpful. Yep, that's all for me. Uh, how does DK come to play with account attraction? Well, this is not this not my expertise.
Maybe uh Chi can talk about this. Uh, thank you. Uh, so Zigg has nothing to do with account attraction. Uh, they are to two entirely different concepts. Uh yeah, I think that's the short answer.
Yeah, maybe you can think of some use case of ZK stuff with echo attraction. Um but I think currently I don't see any connection as well. Uh AA sounds very promising. Yeah, it does sound very promising. But yeah, um uh okay.
So just zking support AA. Uh yeah, because ZK is basically like a new you can think of it as a new chain. uh so as stucket uh and they they're free to change what whatever they want. So they they support like a natively in the chain. So yeah, that's that's where the connection comes in.
Yep. So any more questions? If not, I'll pass it back to Kevin. Cool. Cool.
All right. So yeah, Kevin, let's take over. Yep. Thanks. Thanks.
U very good talk on the construction.
Automatic transcript — names and jargon may be misspelled.