EIP-8141: Frame Transaction deep dive - Alexander Forshtat

Transcript

Hello everyone. My name is Alex and today I'll try to make a deep dive into EIP-1541 frame transactions. Uh so let's start from defining the problem that we are trying to solve. Uh so uh in say Bitcoin in its simplest form, a transaction performs the validation of a signature, transfer of a BTC tokens from one address to another, and it also pays its uh transaction fee. Uh so Ethereum comes along and it reduces in place of uh BTC transfer arbitrary code execution. However, the validity of transactions uh still defined by signature validation and gas fee payment that is like rigidly defined by the Ethereum protocol.

Uh so users must rely on their uh private key controlled accounts or externally owned accounts to include transactions in Ethereum blocks. Uh so someone may ask what is wrong with using EOAs? So there is a number of things like first uh EOAs just have a completely unforgiving uh user experience. So we tell the people like we have reinvented the future of finance, so please write down these 12 words on a piece of paper and hide it around your house. And you cannot change this logic. The logic that is given to you by the protocol is there. Your private key has a super admin control of your account and there is nothing you can do to modify it, put any kind of limits.

Uh you also need to pay your own gas fees. And that is becoming an issue for users who are onboarding on Ethereum and especially in the multi-chain environment where people are often missing like native tokens for their specific uh chain. And last but not least is that the cryptography used by EOAs today uh it's all same and in case if it were to be uh to fail, it would mean a total collapse of the Ethereum chain and as has been in the news recently Google published a research claiming that by year 2029 the entire cryptography used in Ethereum today may become obsolete due to a progress with this quantum computing. So the process of replacing this

protocol defined logic with a programmable validation of transactions is what we call account abstraction. The first viable attempt at account abstraction on Ethereum was taken by ERC 4337. What it allowed users to do is to they could adopt smart contract accounts as their own chain identity and find a designated like sophisticated service providers third parties who would control EOA's for the inclusion of transactions in a block. So they would submit a signed messages that we call user operations to this entity called bundler and the bundler will actually put the transactions on chain.

The first step towards native account abstraction was taken later by EIP 7702 which allowed externally owned accounts to inject code into their address by signing a special verification authorization message. So it fully addressed the problem of EOA's not having execution code but it didn't do anything with validation. You still have the private key that has full control of your account that you cannot rotate. With that in mind we are seeing a growing adoption of account abstraction solutions across all of the EM chains and they're often used together. There has been more than a billion of user operations signed across all the chains and more than a million millions of 7702 authorizations.

That doesn't mean the account abstraction was solved by these projects because there are a number of issues. The first family of issues is the privacy censorship and centralization. There is around a dozen of bundler providers on the market. However a smaller number controls the vast majority of these services creating like a kind of bottleneck. And the other one is complexity. Not only gas overhead, but also the entire technology that has to be built in the out-of-protocol solution. And with 7702, the problems are various, but there is also issue of abuse of this protocol where you can see like almost 70% of transactions with 7702 were classified

by some block explorers as crime. The idea of introducing native account abstraction on Ethereum is absolutely not new. It's the opposite of that. In fact, it's one of the earliest EAPs. The first one was had a number of EAP 86. And for years since there has been a significant evolution of the way we think about account abstraction and what we need to do to fully solve it on chain. And this accumulated knowledge allowed native AA to become a huge topic for the upcoming hard fork called Hegota.

So, for Hegota, multiple client teams and alternative layer ones introduced the proposals specifying their preferred preferred way of addressing native account abstraction. And I am bringing those proposals up because they kind of allowed us to define the design space of native account abstraction solutions on Ethereum. So, for a number of decisions, you have to put yourself on a point between like two extremes on the axis of this design space. So, for example, you can have a fully arbitrary validation logic in your accounts or you can enshrine some specific validation operations or some subset of

you can allow completely arbitrary access to storage on on of the Ethereum state or you can limit what storage can be uh read. In more general terms, you can uh try to foresee and accommodate future needs for account abstraction, or you can try to make a short list of like particular pain points that you are trying to address, and like check them out one by one. And uh like emotionally, you can be like kind of brave now, or you can try to delay making like certain core decisions as much as possible. When I say brave, I'm saying like specific uh fears people have about the future. Like sometimes they uh would say that uh maybe somebody in the future will come up with even better

native account proposal, so now is not a good time to adopt native account abstraction. Um and sometimes there are just legitimate concerns about the complexity of any account abstraction approach, or uh discussions about the specifics or timelines for post-quantum upgrades. Here we introduce uh EIP-8141. This is a frame transaction uh uh format that tries to make all the right choices and more more ambitious uh decisions in a design space in order to become like an end game account abstraction proposal, meaning it contains a modular transaction structure with a fully programmable transaction validity, uh full access to Ethereum

state. Uh it separates between a gas and execution approvals. It has native support for passkeys. It has native support for atomic batching. And crucially, it also supports backward compatibility with existing EOAs, which means uh users don't need to migrate to smart accounts to start benefiting from this transaction type. So now we begin the deep dive. Uh let's begin with from the name. What does do we mean by frame transaction? So legacy transactions on Ethereum have a single top-level execution frame, meaning you create a transaction from your EOA to a specific target contract. And this target contract can make inner calls, and these calls will have be inner

execution frames of this transaction. But there is always one top-level frame. Uh this changes with the frame transaction. So, a transaction now contains multiple top-level frames, and each of these frames has a modifier, and the modifier specifies for the Ethereum protocol the role this frame has in that transaction. And the crucial role is a verify role. Verify role uh signals to the Ethereum that if this frame uh is to be reverted, this transaction is not includable in a block. So, it's not the transaction that is included in a block and reverted. It's a transaction that cannot be in a valid block.

Uh and it is usually followed by execution block frames, and you can join execution frames into an atomic batch that can either execute or revert in its entirety. Uh in terms of transaction payload, like all existing legacy uh transaction types specify their target contract, message data, value, and gas limits. So, we extract these parameters, and we put them in a nested array of frames. Meaning, you still have this a shared data of like uh sender, nonce, and uh your gas parameters, but then you specify an array of calls the transaction is making.

Uh let's look into the modes that you have uh the modifiers of the frame. The first one I already started talking about, it's a verify frame. And the verify frame has to end with an execution of a new opcode we call approve, because we want to prevent existing contract from like accidentally accepting uh frame transactions. So, the contract needs to uh explicitly opt in into a role that it is taking uh in the frame transaction. And the verify frame is static, meaning it can read all the Ethereum state, but it cannot write into it. Uh the default is a regular uh call from an entry point, which is just a constant, to your smart contract and sender is an interesting frame where you can call directly to a target in a way

circumventing your smart account. The approve up code, there are two operations of course you may need to approve for a transaction, the execution of it and the payment of its gas. And there are two separate operations and you can issue both of these approvals within a single frame if your smart account is paying its own gas. So let's zoom into a sequence diagram. So for example, this is a transaction that uses a gas abstraction. So it uses a gas payer contract, which will be invoked in the verify frame and this contract will issue an approval for payment and the smart account issues an approval for execution. These two frames is what we call a validation prefix of

the frame transaction. This is the entirety of code that you need to run to figure out if the transaction is includable on chain. Previously that was defined by the protocol, the ECDSA verification and the nonce check and the balance check. This is followed by the execution normally and this is where you can see the difference. The default call makes a call to your smart account and the smart account interprets the data you are sending to it. It can make nested like inner calls based on the data you gave it. And the sender call goes directly to the target contract. So your smart account approved this call and it is just executing this call and it can have the inner inner calls whatever shape.

Now legacy transaction types have up codes to expose the inter inputs of these transactions into the EVM like message, value, data, origin and stuff like that. This is of course not applicable for frame transaction because there is an array of these things. So we have to introduce four up codes in order to expose the entire structure of the frame transaction into the EVM and there is no hiding here. All of it except for the signature is available throughout the entire transaction body. Uh now the interesting aspects. In order to support existing UAs that have no code injected into them, just like you sign a transaction, frame transaction with your UA,

uh that means that you will be provided uh a code uh for you. This is a default canonical UA code that will run in your validation frame and it supports both EC recover and the P256 signatures uh for uh passkey support. And another canonical feature is a canonical paymaster for gas abstraction. Meaning that this is not provisioned for you. This is a code hash that we allow you to use if you want to propagate your transaction through the uh peer-to-peer mempool of Ethereum. Uh because if you were to use an arbitrary uh paymaster, you could have issues with a single

paymaster suddenly refusing to pay gas for multiple entities, which is uh bring us to a question of tradeoffs that you need to do when you're making ambitious choices. So we made an ambitious choices of allowing arbitrary validation logic. So of course there is a flip side of that. Now in your in a mempool when you receive a transaction, you need to execute some code in order to know if this transaction is even valid. And we allowed arbitrary storage access. So that means that you now need to keep all the state and look it up while running this code, so you can decide if the transaction is valid. So and uh the way we were brave means that if a single state change happened before your executing, like it may invalidate the entirety of your mempool. So in a

perfect world, you would like if every transaction to be living in a sandbox, so you can validate all of them in parallel. If you find one that is invalid, you just throw it away and you continue with the valid ones. And the worst thing that can happen to you if they are not sandboxed and the one state change happens on chain and now the entirety of your mempool is invalidated because they all depended on the same slot. This is what we call a mass mempool invalidation attack and it's a significant like DOS vector. Uh so, how do we deal with this? We introduce what we call a mempool validation strategy, which is a way to decide which transaction can or cannot pass through the peer-to-peer mempool. Uh the limitations are applied

on the level of storage. You will only allow reading the sender inner sender storage in validation code. We are only limit the access to opcodes that are not providing environment introspection. You cannot see like block number or stuff like that. Uh and we cap the verification gas at around 100,000 units. And if you're using a paymaster, it has to be the canonical one. But the thing is important to know that this is applied by the mempool nodes. It is not a limitation on the transaction type itself. If a transaction is included by a block in a like private submission pool, that is still valid and we expect alternative mempools to exist.

now about the timeline and inclusion of this EIP. So, the EIP 8141 is currently considered for inclusion not in the next uh fork there not in Glasterdam, but in uh the following one called Hegota, which I assume is going to land in around 2027. And of course, being like considered for inclusion, it means that there are multiple multiple steps that this EIP still has to go through before it can be considered uh like included. Uh of course, um a proposal of such scale and with these implications cannot simply exist without becoming the hotly discussed and debated topic across the Ethereum crypto Twitter and Ethereum

community. And I believe this is a beautiful thing about Ethereum, how decisions are actually often made by the community. And I want to address the specific like a feedback that we sometimes receive that friend transactions are complex. So, in my opinion, like every feature that we have in a friend transaction exists to address a strategic use case for Ethereum. And if you look at some like ways to simplify native account abstraction, it seems like you risk to snowballing even more complexity into Ethereum over longer period of time.

Um So, what do I mean by that? How can we minimize complexity in Ethereum by introducing a new transaction type and a complex one? So, the idea is that we introduce some, but we will be able to limit or even like exclude some complexity in the future, which will make it worth it in the long run. So, first issue that we kind of starting to see is multiple chains are starting to introduce their own take on account And these are major chains, so all the tooling all the ecosystem will have to support them and we'll end up with a compatibility matrix of what transactions are so exist on each chain.

Um another issue is of course we cannot run away from quantum computing progress and at some point in the future we will need to design a post-quantum transaction type. And that can be a an issue if we have to introduce like a special EOA that is a post-quantum signature. And friend transaction provide a very like agile and extensible transaction type. You could design ways to implement post-quantum signatures, you can implement signature aggregation, you can implement post-transaction assertions or maybe protections on top of an existing transaction frame Uh they in case we were to migrate to some zero knowledge based virtual machine or anything the design translates perfectly to that. So

in summary we can avoid adding more transaction types it can become an end game transaction time. We can avoid introducing new EAs. After that we can avoid keeping the existing EAs post quantum and we can remove the code and all transaction types and eventually we can supersede the entire entity of ERC-437 stack making like a number of things uh obsolete. Uh okay, that's it. Uh thank you very much and thank you to the co-authors of this EAP. I will take the questions.