Community Notes

Hi everyone. So, yeah, today, so I'm Yoav Vais from the Ethereum Foundation. I'm a researcher working on account obstruction. And today, in this talk and the next two afterwards, we're going to talk about the state of account obstruction, where we stand now, and where we're headed. לדבר על תקופה של תקופה של עקבים, איפה אנחנו עולים עכשיו ואיפה נכנסים.

נכון, אז קודם כל, אנחנו הולכים לבריפה לזכיר כמה זה כל כך התקופה. אז, התקופה, זה כל כך התקופה, אז זה התקופה, בעצם, כך שכן, אתריאום התקופה. started in, so it started at the same time Ethereum started actually. So when Vitalik wrote about Ethereum before the launch, he already blogged about what accounts should ultimately look like. So this was the first mention of account abstraction.

And then in the following years until 2020, there was a lot of research done on this, a lot of research done on this, a lot of interesting proposals, and the idea kept evolving. Then in 2021, Vitalik came up with a new idea. Trying to get to account abstraction and start experimenting with account abstraction models without protocol changes, which makes it much easier to get started. And this has led to ERC-437. The idea was to get to full account abstraction without protocol changes, but also without compromising on censorship resistance by relying on centralized relayers.

So that's what we've been doing with ERC-437. Now, censorship resistance, it requires having a permissionless mempool because otherwise someone could always censor you. But it's a challenge. And the reason it's a challenge is that full account obstruction means also obstructing the validation. And when you obstruct validation, it means that it depends.

The validity of the transaction now depends on mutable state. So this enables a lot of DOS vectors, a lot of denial-of-service attack vectors that need to be mitigated. Just to give a quick example of such attack and why we need to solve for this, is let's imagine an attacker implementing an account. And this account has a dependency on a flag stored in a singleton smart contract. So every account using this implementation looks at the same flag in order to determine transaction validity and also flips the flag.

And now the attacker sends thousands of such transactions on an ongoing basis. Every time such transaction gets included when a transaction gets included, it immediately invalidates all the other ones. So they can't be included in the chain. And now they have to be dropped. And they have to be dropped without paying for gas because they are not valid.

So we can charge them. But they still cause a lot of validation work for every node in the mempool. And this can easily escalate to a point where the nodes cannot do any useful work. So we need to mitigate for this kind of attacks. And the way to do it is to separate between validation and execution so that we can limit what can be done by an account before execution, before it agrees to pay for the gas.

Now, the question is, what do we want to limit? What kind of restrictions could we apply? The easiest way, the no-brainer, is let's not let the account access any state outside the account until the transaction is valid. So it can only access its own storage. It cannot access any other contracts, and it cannot access environment opcodes, such as a timestamp or a block number.

So this solves the denial-of-service problem, but it also limits usability quite a bit. So, for example, you cannot support popular use cases, such as paying for gas using an ERC-20 token because you cannot look or modify the balances of that ERC-20 token during validation. So, over a couple of years, we worked on developing a set of rules, a set of validation rules, that support as many use cases as possible while still mitigating denial of service. And this enables use cases such as paying us with tokens and many others that wouldn't have been possible otherwise. So the way it works is these rules are applied at the mempool level.

The mempool will only propagate transactions if two conditions are met. One, the transaction must be valid. And two, it must also comply with the rules. So a valid transaction in an account that doesn't comply with the rule will still not be propagated. Now we fast forward to the present.

Where are we now? So ERC-437 went live last year, and it gained quite a bit of adoption. There are now over 20 million accounts, mainly on different layer tools, and a lot of activity. What's interesting is that most of these transactions, the vast majority of the transactions, actually you also do gas abstraction using Paymasters, which greatly improved UX for situations like onboarding. We are abstracting gas, and this alone is a great improvement.

And over the past two years, we also saw a lot of great projects, a lot of awesome stuff being built by the community. Some of it is things that we really couldn't imagine before. And I'm not going to dive deep into this because one of the next two talks by Tom is precisely about diving into the numbers and interesting use cases. So be sure to stay for Tom's talk. Another recent development is that the public account obstruction mempool just went live.

So the idea with the ERC-4337 has always been to have censorship resistance by having all the bundlers connected in one peer-to-peer network, one mempool where transactions get propagated. And this way, you're pretty much guaranteed that someone will include your user operation. But until recently, every bundler maintained its own private mempool, and they were not really connected while we were still working through the coordination of this mempool and they were not really connected while we were still working through the coordination of this mempool. And recently with an effort with a coordination effort for the protocol, three of the bundler implementers EtherSport, Candid and Silius managed to finally bring it up so now we have this mempool. And thanks.

I want to thank these three teams. And I should also thank Fastlane that made it possible to have the mempool on Polygon. So thank you. And this way we have... So now we have the mempool running on several chains and more are coming soon.

I hear that also other bundler implementations are going to join the mempool soon. So we'll see it growing. What does the future hold? Where do we go from here? So one thing we saw is that many, so we started seeing layer twos introducing native account abstraction in order to have a better integration, more gas efficiency.

Now, the problem is that they enshrined the modified versions of ERC4837, which are not standardized. And this started causing wallet fragmentation. So suddenly we see wallets, pretty nice wallets, that work only on one chain and cannot be used on any other. And that's really not great for the ecosystem. Because if you found a great wallet you like, you should be able to use it on every chain, not only on one chain and then look for another wallet for something else.

So we realized that this is actually not an account abstraction specific problem, but a coordination problem that could cause issues in other fields, which led us to start the roll-up improvement proposal, also known as Roll Call. That's a coordination effort with all the layer twos to coordinate standards that would benefit the entire ecosystem. After we started this process and brought the Layer 2s on board, we started also working on RIP 7560, which is a native account obstruction proposal for Layer 2s. And a Layer 2 that uses this will get a better user experience and better gas efficiency. Now, what about layer one?

So I said that RIP 7560 is an RIP, it's for layer twos. But for layer one, we are thinking more long term because we at Ethereum are notorious for taking our time to get things right on layer one. So this is no exception. We have a proposal called EAP-7701, which is native account abstraction using EOF. And the dependency on EOF means that it's not going to happen very soon because EOF is not included in Pectra.

But once it's enabled, it's going to enable interesting account abstraction models and not limit us to just one. And it will enable things like improved censorship resistance through inclusion lists, which are not possible to support otherwise with something like 4337. So that's something to look forward to and we're working on it. I'm not going to dive further into native account obstruction but there's a the next talk after mine is by Alex and this is specifically about native account obstruction proposals so he's going to dive much deeper into this. We also saw strong demand for supporting EOAs to give EOAs at least some of the benefit of account obstruction.

Now, it's not possible for an EOA to get the full benefit of account obstruction because ultimately it's an EOA. It still has a single key, single ECDSA key that cannot be rotated, but we can still give it quite a lot of the benefits. And that's exactly what EAP-7702 does. It enables adding code to an EOA without invalidating its key. So now the account is actually both a smart account and an EOA.

And this works great with ERC-4337 because it allows us to set the code to turn any EOA into a 4337 account, which uses the 4337 mempool. And this automatically enables use cases such as paymasters. Now you can have an EOA that uses 4337 Paymasters. So you can, for example, pay GAZ with tokens or get GAZ sponsorship for an EOA transaction. And on this one, there was already a talk by Light Client that took a deep dive into it.

So if you're interested, you should check out the video for this one. Now, how does it all fit together? So we talked about several different account abstraction models, which would probably be confusing for someone looking into what to implement. So the answer is that the account model is identical. They all use the same kind of separation, the same account model, same gas abstraction, everything.

So it's actually quite easy to build an account that supports all of them. So you develop it once, you can deploy it everywhere on every chain, whether it has some kind of native account abstraction or not. You can use it, you just use it everywhere. And once it's deployed, once it's deployed, if a chain later, if a chain on which the account lives switches to, enables native account abstraction, it will be able to benefit from the improvements. Now, the goal, so this seems like moving a bit beyond account obstruction, but it's actually part of the same thing.

So the goal with account obstruction has always been to go beyond the individual, beyond improving the UX for the individual chain, and to also solve the cross-chain problem. And in a minute you'll see why it makes sense to use account obstruction for this. And anyway, now that we have the basis for it, it's time to start really solving the chain obstruction problem, having great cross-chain UX. So the cornerstone for this is that account obstruction enables trustless bridging. So with account obstruction, you don't have to trust a bridge operator.

You no longer need these multi-sig bridges. And the reason is that the operator is not in the loop. The operator is not a part of the transaction in the sense that the message sender is never the operator. The message sender is always the user's account. As opposed to the EOA case, where message bridges are a part of the transaction and are trusted in a sense.

So with this, the user can create a transaction that actually operates on several chains. So we have one transaction running on multiple chains, and the bridge operator can execute it on all the chains on behalf of the user, and even transparently deploy the user's account on chains where it doesn't exist yet, but the operator cannot change the account in any way. The account, because the account self-validates its own deployment. And this means that now the account can validate the transaction on each of these chains. So once it validates the transaction, it means that the bridge operator is not at liberty to mess with the transaction in any way.

So because it cannot mess with the transaction, we don't need to worry about the bridge operator, which leads us to trustless bridging and to permissionless bridging. So you don't need a permissioned bridge operator. Anyone can join and be the bridge operator, including the user or anyone else. As for the GAZ, with Paymasters, it means that you can have the account paying for the GAZ using a Paymaster on each of the chains. So the user only pays on the source chain, and the bridge operator uses a Paymaster deposit to pay for it, and then ends up getting compensated from the user's deposit on the source chain.

So that's how we can solve bridging. And using a few more standards, some of which are being developed and some will need to be developed, we can really solve the UX problem and make it seem like using one chain. The idea is that the user will never have to select a chain in the wallet and it will feel like really using a single chain. Some of these standards are, among them are key stores. With key stores, the idea is that you can run any...

So with key stores, you manage your credentials for your account on a single chain, whether it's layer one or whether it's a designated ZK layer two. You can manage it in one place and use the same credentials everywhere. If you rotate your keys, they get rotated automatically on all chains. Another thing is that the user can send a single transaction that runs on multiple chains and doesn't even need to hold the native coin of each of these chains to pay for the gas. So it feels like using only the source chain.

The wallet can also use something like intent solvers for more complex operations. So, for example, performing a complex trade on multiple chains is possible with intent solvers, but unlike with the EOA case, here the account can enforce the result and revert if it doesn't like it, which means that the user doesn't have to take risks when using intents. Another thing is that addresses will become chain-specific addresses. That's a standard that is nearly ready. With chain-specific addresses, the address includes the name of the chain on which the address resides.

And this chain actually uses an ENS name of that layer 2. To give an example, let's say we have a user on Polygon that wants to send USDC to a friend, but the friend uses Base. So with this, the friend gives the user an address that looks like 0x1234 at Base.eth, and the wallet knows how to deal with it. So the wallet can look it up.

It knows how to bridge to Base. So the user pastes the address, the USDC gets sent, The wallet can look it up. It knows how to bridge to base. So the user pays the address, the USDC gets sent, and there's no need for the user to even notice that they're actually not on the same chain. In order to achieve this, the ENS name for each of the layer 2s actually refers to a few records that help with chain discovery.

The reason we need this is we're going to live in a world where there are many layer tools and many more coming up every month. So we don't want to configure the wallet to support each of these chains. We want automatic discovery. So with ENS, we can get just that. We can have, for example, we can have a record for a standardized bridge.

So now the wallet can look at an address and find out exactly how to bridge assets to that chain. It can have a record for RPC provider. So if the wallet needs to transact on this unknown chain, it has an RPC to use. And then it also have, and it doesn't even need to trust the RPC because there's also going to be a light client implementation, a CCIP-based light client implementation that can validate the chain state against its Layer 1 contract. And this is also a record.

So the wallet is able to communicate with every chain. It can communicate with every chain, it can communicate with every chain without previously knowing about it by just looking at an address and then resolving everything, knowing how to trustlessly transact on this chain. From the user's perspective, it all becomes one chain. So account obstruction is already here. It's already thriving.

Native account obstruction is coming. And account obstruction is already improving UX on many chains now. But in the future, in the near future, hopefully, it's also going to improve the UX across different chains. And in the future, it's going to feel like we're using a single chain rather than multiple chains, but with the scaling that comes from our layer 2 strategy. And all this without sacrificing decentralization and synergy persistence.

Alright, I think we've passed our time, so any questions? Yes. Thank you. Thank you so much, Joao, for the wonderful session. We'll start the first question.

How are we supposed to develop a 4337 wallet in the entry point contract keeps changing. Yeah, so the entry point contract will not keep changing. The last change was hopefully the last ABI change ever, unless some critical security bug we're unaware of is discovered and forces us to change something, which can always happen, but unlikely at this point. If not, then maybe there will be some minor bug fixes inside entry point, but not something that would affect ABI and require changing wallet implementations. Do you think we will need L2B style risk dashboards for different wallets to make users aware of what these wallets actually do?

Definitely. I think L2Bit is doing very important work on layer 2s, and we will need this for wallets. It's actually not just for wallets. We need someone to verify that the wallet does what we expect it to, but also when we transact across different chains, even though we want to make it the wallet does what we expect it to, but also when we transact across different chains, even though we want to make it transparent to the user, not all chains are equal, and some actually are riskier than others. L2B does a great job highlighting these differences, and we'll need to also account for that.

So, yes. Does 772 require the wallet provider to be okay with upgrading the EOA to a smart account? What happens with a wallet provider after upgrade practically? Wait, I'm not sure I understand. So, you want...

Maybe the person who... I mean, yeah, it does need... I mean, yes, of course, you need to add the code in order to use it. So you need to add 4537 code to the account, and then you can start using it as a 4537 account. But I'm not sure I understand the last part of the question.

Maybe the person raised the question. Do you want to elaborate a little bit? Maybe by saying wallet provider, they're talking about the wallet as in the part that runs off-chain on the user's machine, in which case, yes, the wallet has to be aware of the implementation, but the wallet is the one setting the implementation. So now the wallet will determine what code gets set into the EOA and will use whatever it can also support. Great.

Let's move on to the next one. What is the plan if there is a critical vulnerability on the entry point? It would be a black swan that would compromise all wallets at the same time. And by definition, it can't be revoked in mass. Yeah, you could ask the same question about something that doesn't use something like entry point.

Because, I mean, what happens if there's a critical protocol vulnerability in Ethereum and then we also, and also a lot of accounts get compromised. So hopefully we audited things enough to prevent such occurrence. And if it does happen, if it does happen, then yes, we will need to deal with it. At some point where it becomes such a big thing on the network, you have to fix such things by hard fork. So let's say EOA was compromised somehow.

We would need a hard fork to deal with it because we are not going to allow a situation where every account on Ethereum gets compromised. So it's quite similar, whether it's account obstruction or EOA. What's the main technical challenge of key stores? Next one. The main technical challenge is being able to access a layer one state during validation and the way to do it is by having an RIP supported by all the layer tools to access layer one state.

And then you can have a key store on layer one. So there are currently two such proposals. One doing L1S load, meaning you're able to load a slot from a layer one contract. And there is also remote static call that would let you perform a static on layer one either of these proposals would enable would enable key stores efficiently because now the validation will be able to actually use that and this will become a part so a part of the proof of the proof used by the layer 2 will prove the correctness of this lookup. Okay, the last question.

Should we adopt AA now, considering future features you mentioned might not be backwards compatible? I don't recall mentioning features that are not backward compatible, and actually our goal is to make it backward compatible. So if you develop a 457 account now, you'll be able to easily make it work with future native account obstruction proposals. And I think the time to adapt it is definitely now because otherwise you're not going to get the benefits of even things like 7.7.

0.2, let alone chain obstruction stuff.