Spotlight 3.0 Recap: Account Abstraction and what follows, with ERC-4337 Co-Author

Moderator:

• Lucas, Senior Research Manager at Huobi Incubator
• Jenny, Senior Operations Manager at Huobi Incubator

Speakers:

• Kristof Gazso, Co-Author of ERC-4337, PM at Nethermind
• Praneeth Srikanti, Investment Partner at Ethereal Ventures

Moderator: Can each speaker introduce yourself?

Kristof: I joined Nethermind in May 2021, and about this time last year in November I was thinking what I want to do next in this area and what the biggest problems are. And for me by far the biggest problem was seeing the average person who is not technically inclined, has great difficulties using ETH applications. For me the most leverage thing that I can do to improve Ethereum user experience is to solve the account and wallet problem for Ethereum.

There are two types of accounts: Private accounts(EOA) and Smart Contract Account. Right now Ethereum is dominated by EOA accounts usage. ( ie. Metamask and Rainbow), with restrictions on them.

I was looking for solutions around this, and then I discovered account abstraction. I realized that where was no proposals with realistic chance of getting on mainnet yet, all the previous proposals were either too complicated or require too much work on the proposal side, so with Vitalik and OpenGSN, we worked together find ways to get account abstraction on mainnet without requiring consensus-level protocol changes. And this is the main innovation of ERC-4337.

With this proposal can be implemented right now, we can see until now there are already some applications being built on top. Right now, I am in the process of fostering the growth of this ecosystem and pave the way for ERC-4337 to get popular.

Praneeth: I’m an investment partner at Ethereal Ventures, which is a new standalone crypto firm that was set up by the former venture investment team at ConsenSys.

To get more people into Web 3 it needs much more easier and relatable experience adopted across the space, the typical conventions that people are fundamentally used to, such as authentication and social recovery.

With account abstraction, it is able to provide capable solutions to these problems. I am very interested in seeing the evolution of ERC-4337 and working with people and stakeholders in the ecosystem to see that happen.

Moderator: This year ERC 4337 about implementing account abstraction came out and also during Devcon we had several panels on Account Abstraction, it actually became a buzz word and we saw the momentum of building around AA despite a current deeply bearish market. So first of all, could you please explain what is account abstraction?

Kristof: Let me break it down not so technically. In Ethereum, accounts most people use are private key accounts and we call these externally owned accounts.

However, there’s another type of accounts in Ethereum as well, and these are smart contracts accounts. So whereas EOA accounts are controlled by private key, smart contract accounts are controlled by their code.

However, the problem is, in Ethereum, the EOA accounts have very special permissions and have a lot of rights which smart contract accounts do not have. For instance, only EOA accounts, only private key accounts can initiate transaction, smart collection accounts cannot do that.

Furthermore, EOA accounts are very hard coded in how they work, so with EOA accounts, the way gas payment works is that you basically front all the gas in ETH that you’re going to use in the transaction and if you have any leftover, it gets refunded back to you.

The signature verification is also very hard coded in EOAs, such as ECDSA signatures. There’s nothing wrong with that per se, but we’ve had lots of innovations in this scheme that we can use today.

So account abstraction is simply trying to break down this barrier by getting rid of the notion that there’s only one type of account. This give more power to smart contract accounts and give them the power to initiate transactions.

Praneeth: Account abstraction is able to introduce a lot more security and user friendliness to the space, and this is what we want users to feel when they first start interacting with the blockchains. The experience of thinking about how they need to store and remember their private keys without granting access to a specific smart contract to spend their funds is bad.

Account abstraction provides us capability to do things in a very user intuitive manner. People can use it to fine grain controls on key permissions, something that people fundamentally used to today on Web2 accounts.

We also need to fundamentally think about what is the limiting function of a given wallet and try to see if we can move away from a transaction based model to something that could hopefully be an intent based model for Ethereum platform.

Kristof: To give a bit more context on what you might be able to do if we make a really good transition to smart contract wallets, here’s a few examples of the powers you get on top of the current features.

An example is gas fee sponsorship. Dapps will receive the abilities to very easily sponsoring people’s transactions. You will also be able to pay with different tokens or even off-chain credit card so no ETH is required to transact. Any sort of system or personal sponsorship is possible now.

With the signature schemes you can have social recovery schemes and multi signature schemes. You can define completely customize how you want your account to behave and what sort of permission for your sub accounts.

So you might have your main account controlled by a multi-sign and you might be like, OK, I’m going to grant a quick access via a private key, but only if it’s interacting with this on-chain game contract. With this being setup, your wallet and the on-chain game will be able to transact on your behalf, but only with very restricted permissions. So the whole idea is that you can define completely with EVM/Solidity code how your account should be, you can give custom permissions such as time based permission, spending limits and more. You can read more about this in detail: https://twitter.com/kristofgazso/status/1595849349799501824?s=20&t=RLqFRoi8RdBixW_bRcLTcw

And finally a very common UX problem is the lack of batched transactions. Instead of having to approve and then swap on Uniswap which is 2 transactions right now, you could do that in the same transaction. In fact, any number of separate operations you can now put in the same transaction.

These powers all combined to give a really powerful user experience for the next generation of crypto users. You’ll basically be able to have the same experience as you would if you used NEO Banks.

Moderator: Ethereum community is pushing forward the implementation of EIP-4337, which was on top of EIP-86, EIP-2938 etc. Why we are having a new protocol level standard for AA? What would be the implication for the ETH dev community and users?

Kristof: The most relevant previous proposal is EIP-2938, this was coined by my friend Ansgar.

And this defines a mechanism for account abstraction that is ingrained into Ethereum, so it actually changes in the protocol level of how Ethereum is going to work. Now why is this not on maintenance? The problem is that any sort of protocol level change is a really, really difficult process to push through. And over the past year and a half, pretty much all core developer effort was put into getting the merged up, so there was no time for core developers to try and implement the account abstraction proposal.

The account abstraction is very useful in the UX terms, but it’s just not as high of a priority as scalability and safety, resources are currently allocated on merge, withdrawals, and things like EIP-4844 proto-danksharding and EVM object format, and it will take at least another 2–4 years for core developer community to turn their focus on boosting user experience. That’s why we decided to try and come up with the new proposal ERC-4337 that can be realized with smart contracts deployed with Ethereum with no need to deploy on protocal level.

I guess the final reason why the community didn’t go with something like 2938 is because account abstraction by its very nature introduces some potential denial of service risks. With account abstraction you allow the wallet to define whether a transaction is valid or not, and basically you have to execute custom EVM code to determine whether a transaction actually pays the miner or the validator. So introducing something like that directly into consensus is a really big risk, and it’s a lot better to try with ERC first without actually changing the node software.

Praneeth: I think this is a pretty nice means for 4337 ecosystem to get bootstrapped in similar EVM compatible environments so that it can be fully friendly in later protocols and inspiring other inventions.

Moderator: With AA being a standard, contract wallet becomes the first class citizen, and we are talking about Gnosis Safe, Argent and the likes. Which functionalities now are available and popularized and which are expected to arrive in the near future?

Kristof: It’s important to note first of all that Gnosis Safe and Argent have not yet become compliant with ERC-4337. So ERC-4337 is simply a standard that defines how account abstracted wallets and paymasters and the rest of the ecosystem should look like.

And to your other question, which is, what features have we seen and what features are we expecting in the future? With Argent, we’ve already seen things like payment with ERC 20 tokens. We haven’t seen a very general form of a gas sponsorship yet. That’s definitely the future with Gnosis Safe and Argent. We’ve seen lots of difference in interest schemes like social recovery and multi-sync, but we haven’t really seen things like generation of sub accounts and very custom permissions being given to a sub account.

However, with Argent I remember there is a feature where you’re able to generate a signer key which has access to transact on your behalf under your regulated terms. So you might go to your social recovery signers and you might ask them to approve the allowance of a special key which can transact for day. And that means you can execute lots of transactions in a sequence without having to go back to your signers at every single time. So that’s already a basic example of what might be possible in the future.

As far as I know there isn’t anything like spending limits that introduced, which I think will be very important for future UX. Wallets like Argent and Gnosis Safe have not yet become compliant with the standard, once they do, they’re going to unlock lots of really cool features.

Praneeth: There’s suddenly a broader road map for ERC — 4337, that is also fundamentally associated with converting existing EOS to smart contract wallets. ERC-4337 fundamentally still requires existing users to upgrade the console we have to something that is ERC-4337 compliant by moving assets and activity over to new account.

There are a few more things that need to come into play to making sure that the migration process can happen in a way that is smooth and hopefully not introducing too much friction, especially for accounts that don’t have too much activity in the back.

But beyond that I think there’s still the idea that we will have EOAs always being the first class citizens and we would probably see more of the capabilities associated with the account abstraction come into play especially on Layer Twos where people are taking inspiration from 4337 and actually implementing that in production. We would start seeing those capabilities emerge more. The path of getting EOA migrating accounts would be a very interesting one and hopefully one.

Kristof: Praneeth, you mentioned a very interesting talk, which is how on Earth are we going to migrate EOAs to smart contract wallets in the future. That’s a really important problem. Many people whom I have talked to about smart contract wallet have a common response of feeling the hassle of transferring everything to a new wallet, especially with soul-bound tokens.

So, we have to find a solution to make EOA wallets into a smart contract. There’s two main choices that we can take. One is the weaker version, which is we can introduce a new transaction type. And what this transaction type would do is, if you submitted a transaction, it would simply convert your EOA into a smart contract account with the code that you specified in the data field, for example. So with this you would simply have to call 1 transaction and you would be able to define in very completely custom way how your account should look like with smart contract code. And this would be the same address as you had before with all your token, all your NFT or everything. That’s one option.

The other option is a stronger version of this, which is, instead of giving users the option to turn their EOA into a smart contract, you can transform every single EOA into a very simple smart contract account immediately once the hardfork happens, so this smart contract account would have the same scheme as you always have now. It would rely on ECDSA, but this would be a lot more future proof as this basically get rid of EOA in one fell swoop.

It’s a really big trade off that we’re thinking about right now and it’s likely that we’re going to lean into the second option, trying to get the stronger version of this out there. Because if you take the weaker version and you allow people to turn EOA into smart contract accounts, you actually using EOA even more. So you’re going to have a transaction type whose only use is to turning EOAs to smart contract accounts. But what if ever in the future you want to get rid of EOA completely, then this is going to be technical debt, this is going to be redundant. So this is a topic for the future that we’re trying to figure out.

But as I said before, any sort of consensus change that we’re going to try and introduce into Ethereum is going to take a long time to be implemented, like 1–3 years. So definitely don’t bet on getting rid of the EOAs anytime soon.

Praneeth: Definitely agree on that point. It’s also changing these assumptions of application developers as it relates to some contracts typically rely on certain assumptions around signature schemes which then basically indicate whether that signature is related to an EOA account or not.

But I think there’s going to be a lot more issues as it might come down to a mandatory conversion for accounts that are potentially old and maybe not really detectable in some sense where people have not yet made any activity for multiple years. But I think there’s definitely some changes that might need to come into the broader mindset of people who are using EOAs.

Moderator: If account abstraction is a game changer and the integral and default setting of our future crypto experiences, many other Dapps and stuff needs to be built in order for it to work properly. For devs among our audience, which wallet support is needed, and how Dapps can plan ahead to design features based on smart contract wallets?

Kristof: There’s two very simple answers to this which Dapps can hopefully achieve and not too difficult way. One is stop discriminating against smart contract accounts, like stop using transaction origin. It really does like that’s going to be very misleading in the future once we have account abstraction, and even right now with 457 if you use transaction origin, it’s going to point you to the Bundles which is an ecosystem player who bundles user operations together. So stop using transaction origin and don’t ban smart contracts from interacting with your Dapps.

Two is start to become compliant with EIP-1271. So this EIP defines a way to sign things with smart contract wallets. So if a smart contract wallet implements the function “if valid signature” and it returns “true”, as far as I know that’s how it works, then you would treat it as if it’s the wallet signed that message. But many Dapps are still not compliant with this and they assume a simple ECDSA signature from EOA accounts to determine whether it was signed or not. So I guess those are the two things. One, don’t discriminate against smart contract accounts and two, become compliant with the EIP-1271.

Praneeth: Yeah, I think that’s that’s pretty spot on. Just one thing to keep in mind, all of the changes that are coming around the EVM object format likely going into Shanghai.

A lot of work that would hopefully happen around like dedicated US sections is going to be pretty important fundamentally as we think about the broader long-term road map for proposal/builder separation and making sure that we have the capability to be considered by core protocol teams as you’re thinking about new mechanisms and models around like proposal/builder separation schemes that play out.

But just making sure that you keep a close eye out on the EOF and EIPs so that you have a better sense of understanding what is the notion of validation and execution in protocol. Having that at the back of your mind would also be a good thing to think about.

Moderator: Are we talking about account abstraction only in context of Ethereum ecosystem comprised of Layer2s and Layer3s or we are talking account abstraction in a broader multi-chain ecosystem? Why Layer2 would be the originating place than ETH for AA? What is StarkNet current undertaking in developing AA?

Kristof: So I can answer your first question, which was why are we seeing the development of account abstraction in Layer2s in two words: gas fees. With the account abstraction you rely on smart contract code to validate whether your transaction is valid or not. With EOA this happens for free by the nodes themselves.

Since Layer1 mainnet gas costs are lot higher than they are in Layer2, this added gas cost penalty in Layer1 is a lot more significant. In layer one, an EOA transaction might cost $10 and a smart contract wallet transaction might cost $20, this can be one cent in Layer2 versus two cents. So the difference is a lot more negligible in Layer2 and that’s why we’re expecting to see Layer2 come way before any certain Layer1 adoption.

And StarkNet. As far as I know, StarkNet has a lot of their mechanism inspired by ERC-4337. I’m not as closely familiar with them, but they already allow you to deploy smart contract and initiate a transaction with that contract directly. So they implemented in a way something similar to 4337 and they’ve already trying it into their protocols. They’re taking basically a massive leap forward which is pretty inspiring to see.

Praneeth: The Delegatable framework by Dan Finlay, essentially having the ability to add counterfactual delegation to any solidity contract and account, include a lot of the capabilities that you associate with smart contract based wallets: having validation, having the capability to batch transactions and using this framework as a basis to allow EOAs to act as smart contract wallets without deploying contracts by publishing messages off-chain. This is essentially work that has gone towards EIP 3074 and EIP 5003.

But you have signing keys that are still associated with seed phrases that users are still expected to back up. You have the ability to delegate permissions to arbitrary smart contracts, but you still have the issues that are associated with revocation and ability to take permissions away and nodes management. I think there’s some very interesting notions around having some of the benefits of account abstraction but doing this in a way that avoids in protocol modifications. Use some of these experiments to even see if this is a way that could be used towards data migration of a large fraction of the EOA account.

We would encourage people to spend some time looking around the delegatable framework that been playing around with for a bit.

Audience Question (Eric Siu): What are your thoughts on 4337 vs other EIPs like 3074 and 5003 as it relates to account abstraction?

Kristof: 3074 is older than any account distraction EIP. What it does is it gives more power to EOA accounts. So it’s introducing the concept of an invoker and this invoker is basically allowed to transact on behalf of the EOAs under some restrictions that can be defined by the invoker.

There’s two problems with this, and also the reason why it’s probably not going to get into mainnet. The first problem is that it enshrines EOAs, it makes EOA stronger. This is good because you don’t have to transfer your balances anymore if you want to use features of smart contract wallet, but it’s bad because if you ever want to introduce account abstraction in the future, there is going to be a lot of technical debt.

The second problem is that it has some security concerns with Invokers. By giving complete access to the invoker, if it hasn’t evolved then it can result in some really weird side effects. Yoav Weiss who’s a co-author of 4337, has explored a lot of the safety problems that 3074 has, I recommend people checking out his post where he outlines the security concerns. So I guess this is the reason why it’s very unlikely this EIP will make it to the mainnet.

Audience Question (Ric Burton): I’m just really curious what the folks on stage think is possible in the future with all of these starting to work. I think right now we’re focused on the implementation details and how to get Dapps developers aware of all these things. I’m wondering what you’re dreaming of in the future if all of this comes to pass in five years and this is the standard, are there any matching applications or products or tools or services that you think will be unlocked by the work that you are doing?

Kristof: For me, the vision I have is that, once we really have a good ecosystem for account abstraction, operating awards on Ethereum will be just as simple or simpler than using any sort of NEO bank that we have right now. I can transfer to my friend anything very easily. I can use a lot of in-built applications to do saving and budgeting with very restricted permissions such as block my cards and doing these things. I really think that once we have wallets that make use of the lots of the features that account abstraction, we will be able to interact with the on-chain ecosystem just as simply as we can with the off-chain ecosystem with our banks that we have now.

Praneeth: I touched on this very briefly earlier on, but in some sense it’s the ability for users to express their intent and have this performed automatically or in an automatic session for applications and protocol to abstract away the inherent transactions of this composed intent. People need to be in a place where they can do it without actually getting bogged down into details as to how this is implemented in a transactional manner when you interact with these protocols. So I think the capability to batch things together, assign multiple actions that are unblocked, the ability to sign commitments that can be easily submitted to the blockchain later and fundamentally having the core separation between validation and execution is a very nice thing to think about.

Fundamentally it means having the capability to expose a lot more fine grained things related to access and authorization other people are typically used to in today’s world with Web2 platforms. But having those capabilities actually enforced or maybe enshrined in the protocol and having the capability to adjust those through very familiar user flows is gonna be super helpful.

Audience(Ric Burton): I love that. I think as a kind of overarching goal, people feeling like what they want to do being expressed in the transaction is very powerful. I think of all of this system as a giant transaction, construction instrumentation and wallets are part of that, the protocol is part of that. But this kind of intermediary layer is part of that as well. So yeah, thanks so much for all hard work and I’m still catching up to all this. Amazing thinking. Thank you for hosting this space.

— — — — — — — — — — — -

Listen to the Twitter Space episode: https://twitter.com/huobi_incubator/status/1596125338534170625?s=20&t=C8BG3Gx6R96SOG3waPlRIg

Check out more in Huobi Incubator’s twitter page: https://twitter.com/huobi_incubator

Read about other Spotlight of Web 3.0 episodes at: https://medium.com/@HuobiIncubator

Spotlight 3.0 is a podcast hosted weekly by Huobi Incubator, the incubation arm of Huobi Global. With Web3 gathering more momentum than ever before across the world, we are putting the most profound Web 3.0 businesses under the spotlight for their lessons and stories.